根据数据策略、延迟和经济性,将AI工作负载分配至云端、组织、个人及边缘设备的技术方案。
AI translation, not an official translation. Refer to the original for technical details.
Adapted from @MichaelGannotti# 混合推理:一种AI体验,四处运算 连接云端模型、组织基础设施、个人AI计算机与物理边缘的技术蓝图。 下一代实用AI架构不会将每项请求都发送至云端,也不会强制将每项请求都压在笔记本电脑上处理。 公共研究任务、机密工程文档、编程会话,以及机器人对周围环境的解析,各有不同的需求。它们不应仅因某人选择了默认模型,就继承同一个推理位置。 混合推理意味着将每项工作负载放置在能够满足其数据策略、质量要求、延迟预算和经济性的位置。云服务、组织数据中心、个人计算机和边缘设备,成为互为补充的执行位置。 最终目标是提供一种连贯统一的用户体验,并以明确的信息流向与任务执行位置决策为支撑。这是一种需要构建和运营的架构,而非一种可以默认每个智能体都已具备的能力。 ## 1. 四个位置,四种不同优势 云端推理提供托管容量、前沿托管模型的访问权限,以及在需求偶发时无需自购基础设施的替代方案。Microsoft Foundry、OpenAI、Anthropic 和 xAI 是这一层的重要组成部分。云端通常适用于经批准的公开信息、突发性工作,或需要本地硬件无法提供的能力的任务。 组织推理将服务基础设施部署在企业自控的数据中心或私有环境中。NVIDIA 数据中心 GPU 和 AMD Instinct 加速卡可支持共享模型服务。组织由此获得运营控制权,但同时也需承担容量规划、补丁管理、租户隔离、可用性保障及事故响应等责任。拥有一台服务器,本身并不等同于数据主权的保证。 个人推理将模型带到用户本地的机器上运行。NVIDIA DGX Spark 和 RTX 工作站属于这一类别,但二者并非同类产品。DGX Spark 采用基于 Arm 架构的 GB10 平台,配备 128GB 统一内存。RTX 工作站通常使用独立显存,可用容量因显卡型号差异显著。AMD Ryzen AI Max 系统(通称 Strix Halo)提供了另一条高内存本地推理路径。[1][2] 新一代硬件值得精准命名。HP 于 9 月 15 日发布公告,推出与 AMD 联合设计的 ZBook Ultra G3a 16 英寸,最高可配 Ryzen AI Max+ PRO 495 处理器及 192GB 统一内存。GMKtec 的 EVO-X5 Pro 同样搭载 Max+ PRO 495,最高支持 192GB 内存,其中最多 160GB 可分配给图形处理。HP 预计 10 月开始供货;GMKtec 定于 9 月 28 日发布。上述均为已公布规格,并非经独立测试的吞吐量数据。[3][4] 对于那些以"Gorgon"为简称讨论的系统,在采购或部署时请使用制造商的正式产品名称。所引用的公告确立了处理器和系统规格,而非该代号本身。请勿将 Ryzen AI Max PRO 400 与独立的 Ryzen AI 400 系列混淆,也不要将显存分配量叠加到共享内存总量上。 边缘推理在传感器和执行器附近运行:包括摄像头、网关、工业设备和机器人。NVIDIA Jetson Orin 和 Jetson Thor 正是面向这一领域。其关键约束条件包括功耗、散热、传感器带宽、间歇性连接以及响应时限,而不仅仅是参数规模。[5] ## 2. 主权关乎整个数据路径 数据驻留关注的是数据存储或处理的位置。主权还涉及管辖权、行政控制、访问权限、密钥托管、运营依赖关系,以及在受限连接条件下持续运行的能力。加密固然重要,但它并不能回答所有这些问题。 追踪完整路径:源文档、嵌入、检索、提示词、模型执行、工具调用、内存、缓存、日志、备份以及支持诊断。一个本地向量数据库若接着调用云端模型,仍会将检索到的内容发送至云端。一个本地模型若使用云端浏览器或搜索工具,同样可能造成出站信息披露。 微软的部署文档还指出了另一项重要区别:全球及 DataZone 推理处理位置与静态存储承诺并不相同。仅凭 Azure 资源的所在位置,不足以确定每次推理请求实际在何处处理。请核查具体的部署类型和模型条款。[6] 将数据平面与控制平面分开。你可以选择云端管理与本地推理相结合的方式,但需清点哪些管理元数据、诊断信息、凭证及远程访问能力会跨越边界。 Microsoft Foundry Local 在终端用户设备上运行推理。基于 Azure Local 的 Foundry Local 是一条独立的企业部署路径,采用 Kubernetes 原生操作;其当前文档将该产品标注为预览版,且部署访问须按需申请。上述任何一点都不意味着所有托管专有模型均可下载并私有化运行。[7][8] 对于必须保持在已批准边界内的工作负载,应在模型之外强制执行该边界:认证端点、网络策略、受限工具、受控日志以及明确的部署许可名单。请合规和法律负责人对实际设计进行评估,而非仅凭营销标签作出判断。 ## 3. 构建策略路由器,而非仅仅是模型选择器 模型选择器询问的是用户想要哪个模型。策略路由器询问的是:对于这项特定任务,哪些目标端点是被允许的、有能力胜任的、运行健康的,以及经济合理的。 首先确立身份、数据分类、管辖权、允许的接收方以及工具权限,并将其作为硬性约束加以执行。不要仅仅为了判断某份未分类的机密文件是否属于机密,就将其发送给外部模型。对于分类不明的内容,需采用保守路由或进行人工审核。 然后按能力进行筛选:模态、上下文长度、支持的工具 schema、结构化输出行为、所需语言以及任务质量评估结果。最后在符合条件的端点中,依据实测队列延迟、首 token 生成时间、补全延迟、吞吐量、成本及当前健康状态进行选择。 优化目标是:在满足策略、质量和延迟要求的目标端点中,使预期成本最小化。而不是:给隐私赋予一个较小的惩罚权重,然后让更廉价的端点将其抵消。 将回退机制也视为一项策略决策。若组织内部模型不可用,机密工作应进入队列、转移至另一个已批准的端点,或以可见的方式失败。绝不能静默地转变为一次公共 API 请求。摘要化或脱敏处理并不等同于自动授权跨越边界。 在有用的情况下,对任务阶段进行路由分发:本地提取、私有检索、组织托管的综合处理,以及对单独批准的公开材料进行云端分析。在各阶段之间传递有边界的、经授权的工件,而非将完整对话内容转发至各处。 这是工作负载放置问题,而非跨互联网在不相关模型层之间的任意拆分。在不相关模型之间迁移通常需要重新构建上下文。它们的 KV 缓存不是可移植的对话文件。分布式推理与预填充/解码分离需要兼容的运行时和经过精心设计的互连。 ## 4. 模型选择是一种部署契约 OpenAI 的托管模型与其可下载的 gpt-oss 版本是不同的选择。Anthropic 已记录在案的 Claude 产品是托管服务,而非自托管的一揽子授权。xAI 的托管 Grok 服务与已发布的 Grok 2 权重同样具有不同的能力和条款。Grok 2 采用社区许可证;可下载并不意味着不受限制。[9][10][11] DeepSeek、智谱 AI 的 GLM、阿里巴巴的 Qwen 以及 NVIDIA Nemotron 拓宽了开放权重的选择范围。但应选择确切的检查点,而非一个系列的品牌标识。DeepSeek-V3.2、GLM-4.5、Qwen3-235B-A22B 和 NVIDIA Nemotron 3 Nano 是具体的示例,各自拥有独特的架构、许可证、精度和服务要求,这并非对最新或最佳模型的排名。[12][13][14][15] Nous Research 引入了另一项区分:Hermes 模型发布版本与 Hermes Agent 是独立的工件。Hermes 模型具有特定于检查点的条款以及基础模型条款。Hermes Agent 是一款可调用不同推理提供商的软件;在本地运行它并不能证明其推理过程是本地执行的。[16] 维护一份部署清单,其中包含模型/版本、权重来源、许可证、分词器、对话模板、量化方案、运行时、工具解析器、允许的数据类别以及评估结果。固定这些内容以确保可复现性。 兼容 OpenAI 的 API 可减少集成工作量,但并不保证行为完全一致。角色定义、推理字段、工具调用序列化、图像支持、流式传输事件、取消操作以及 JSON Schema 强制执行等方面均可能存在差异。应对完整的客户端-模型-运行时组合进行测试。 ## 5. 内存容量不等于推理性能 一个实用的初步估算方法是:权重内存等于总参数量乘以每个权重的位数,再除以八。然后加上量化元数据、KV 缓存或循环状态、运行时工作空间、激活值以及操作系统开销。 举例来说,以十进制单位计算,3000 亿参数在统一四位精度下,仅原始权重存储约需 150GB,这还未加入上述额外项。因此,厂商所声称的"3000 亿参数可在本地运行"并不等同于承诺支持大上下文、多用户并发或快速输出。混合精度、卸载、模型架构以及运行时实现都会改变最终结果。 专家混合模型还具有总参数量和激活参数量之分。每个 token 激活较少的专家可减少部分计算量,但这并不会使其他专家的权重消失。卸载操作只是将存储和传输负担转移至别处。 对于常规注意力机制,KV 缓存内存随保留的 token 数量、并发序列数、注意力层数、KV 头数、头维度以及缓存精度的增加而增长。分组查询注意力、滑动窗口、缓存量化以及循环/混合架构会改变这一计算方式。 分别对预填充和解码进行基准测试。长提示词预填充、单用户令牌生成和高度批处理的服务对硬件的压力各不相同。测量指标应包括首个令牌时间、令牌间延迟、完整任务延迟,以及在真实负载下的p95排队时间。 DGX Spark、RTX、Ryzen AI Max和Jetson在CPU架构、内存系统、功耗范围和软件路径方面存在差异。在适用情况下,需验证CUDA、ROCm、ONNX执行提供程序、驱动程序及精确的模型内核。NPU的TOPS数字并不能证明大型语言模型会在该NPU上执行。 ## 6. 令牌经济学:优化每次成功任务的成本 此处的"令牌经济学"指的是推理的经济学,而非加密货币激励方案。每百万令牌的美元成本是一个有用的计费单位,但作为单独的业务指标则效果欠佳。 每次成功任务的成本 = 所有可归因的模型、工具、基础设施、运营和审核成本 / 满足验收标准的任务数。 失败的尝试应计入分子。一个更便宜的模型,若频繁输出无效的工具调用、需要更长的提示词或需要代价高昂的修复,其每个完成结果的成本可能反而更高。 对于托管推理,需区分未缓存的输入、缓存写入、缓存读取、输出、适用时单独计费的推理,以及单独计费的工具。在收费时,还需包含搜索、代码执行、网络传输和保留存储的费用。不同的分词器对相同文本可能产生不同的账单。使用实际提供商的用量数据,避免将已作为输出计费的推理重复计算。[17] 对于自有硬件,需计入摊销、电力和冷却、维护、网络、存储、运营及有效利用率。一台已购置的工作站可以具有较低的增量成本,但这并不等于完全免费。一个大部分时间闲置的私有集群可能产生高昂的令牌成本。 一个简单的盈亏平衡模型为 Q = F / (Ccloud - Vlocal),其中F为每周期本地固定成本,Ccloud为每次成功任务的可比云端成本,Vlocal为每次成功任务的本地可变成本。该模型仅在分母为正值,且本地容量能满足相同的质量、延迟和可靠性要求时适用。这是一个会计模型,而非硬件推荐方案。 缓存和批处理可以改善经济性,但两者都受到约束。应按授权范围隔离缓存,使过期结果失效,并避免跨租户信息泄露。批处理可能提高吞吐量,但同时会增加等待时间。衡量用户实际体验到的服务质量,而不仅仅是GPU利用率。 ## 7. 运行时、代理和客户端是不同的层次 Ollama是本地模型服务的便捷入口,但它同样支持云端模型。本地地址(localhost URL)并不能证明推理在本地进行:本地服务可能会将云端模型的请求转发出去。Ollama文档提供了禁用其云端功能的控制选项;但这些控制选项并不能禁用其他应用程序的出站流量。[18] 对于共享服务,应根据支持的模型和硬件来评估vLLM、SGLang、NVIDIA TensorRT-LLM或Triton等技术栈。微软明确区分了面向客户端的Foundry Local运行时与专为并发用户设计的服务器框架。自动硬件加速并不等同于具备主权意识的自动云端路由。[7] OpenClaw 和 Nous Research Hermes Agent 位于推理层之上,负责协调工具和任务。它们的集成方式说明了适配器的重要性:Hermes 通过 OpenAI 兼容端点来使用 Ollama,而 OpenClaw 目前的 Ollama 指南则使用原生 API,并警告不要在该集成中用兼容端点替代原生 API。[19][20] Autonomous 是一家个人 AI 计算机公司,其硬件/软件方案及 Autonomous Grid 与本话题密切相关。Grid 将本地运行的路由与托管中继模式区分开来。拥有推理机器并不意味着中继路径与隐私或可用性无关。[21][22] Cursor 是一个开发客户端与服务,而不仅仅是一个本地推理运行时。其 BYOK 文档指出,请求仍会经过 Cursor 的后端进行最终提示构建。自带密钥与自带离线执行边界并不是同一回事。[23] Grok Bot 也有别于 Grok 模型权重。xAI 文档记录了运行在 Cursor 云端的持久计算机,可通过桌面和移动客户端访问。这是一种有用的云端执行方式,但在个人计算机上安装其应用程序并不会将那些计算机迁移到设备上。[24] 从三个独立维度评估每一个 Agent:界面在哪里运行?推理在哪里运行?工具在哪里执行?再加上第四个维度:持久记忆存储在哪里。 ## 8. 边缘 AI 是部署位置变得具体而物理的地方 摄像头或机器人可能产生的原始数据量,超出了持续传输的合理范围。本地感知可以将该数据流转化为有界事件,从而降低带宽占用,并将选定的原始观测数据保留在靠近数据源的位置。事件和衍生特征同样可能是敏感的;本地预处理并不等同于自动匿名化。 NVIDIA Jetson 为这种近传感器计算提供了平台。Wendy Labs 则解决了另一个关键层:WendyOS 和 Wendy Agent 涵盖开发工具、仿真、设备部署和机队运营。从云端管理边缘机队与在设备上本地运行推理,这两者可以并行,但必须分别进行配置和评估。[5][25] 机器人技术要求在高层推理、感知/规划与有界控制之间实现分离。语言模型可以帮助解释指令或提出计划,但不应被视为唯一的安全控制器。独立的保护机制、受约束的命令、经过测试的运动规划以及定义明确的安全状态,依然不可或缺。 本地模型仍然可能错过截止时间、误读场景或生成无效动作。实时内核并不能为整个系统提供认证。应针对摄像头故障、热降频、电量耗尽、地图过时和连接中断等情况进行设计,而不仅仅是着眼于令人印象深刻的联网演示。 在断网运行之前,应提前部署模型和依赖项。使用经过认证的版本化发布、分阶段推出、回滚机制以及设备健康报告。风险较高的物理动作需要有独立的授权和验证流程,无论推理在哪里运行。 ## 9. 无缝的用户体验不应意味着不透明的数据流动 用户不应该需要记忆模型目录才能完成一项任务。为他们提供一个统一的任务视图,包含进度显示、暂停/取消、可恢复的工作流以及清晰的结果呈现。界面可以对端点的复杂性进行抽象,同时仍然展示有意义的边界:"在此设备上"、"组织自托管"或"已批准的云服务"。 在提供商特定的聊天历史之外维护规范的任务状态:已批准的输入、来源引用、中间产物、待处理操作、已完成操作以及验收检查。以与其内容相同的适当保护级别存储该状态。不要假设切换模型会保留工具状态、隐藏推理或上下文。 对副作用使用幂等键或等效的事务保障措施。如果工具执行后发生网络超时,在另一个模型上重试之前,先核实其执行结果。一个会将电子邮件发送两次的无缝回退,并不是真正的无缝。 记录最少的路由凭据:策略决策、端点与模型版本、执行位置、令牌/工具使用量、延迟以及结果状态。将提示正文和敏感检索内容排除在常规遥测之外;不要将隐藏推理作为审计策略来收集。如果云端使用被阻止,请解释该限制,而非悄然更改策略。 ## 10. 从一个工作流开始,而非一个通用模型 设想一个假想的维护支持工作流。一台配备 Jetson 的设备检测到一个设备事件。一个组织托管的模型审查经许可的维护历史记录。技术人员的计算机准备本地草稿。当需要额外能力时,一个云端模型对经过单独批准的公开手册进行分析。由人员授权重要工作;机器安全性保留在其专用控制系统中。 这不是同一个聊天机器人的四个副本,而是一项根据数据、时序、能力和责任划分的任务。 从一个具有代表性的评估集和负载特征开始。对每条拟议路由测试任务质量、格式错误的操作、隐私边界、p95 延迟、断连行为以及每次成功结果的成本。针对端点故障和工具完成状态不明确的情况运行故障注入演练。仅在证据支持时才进行扩展。 云端智能、组织控制、个人计算和边缘自主性并非互斥的策略。机遇在于将它们结合起来,同时不让用户管理其复杂性或放弃对其数据的控制。 混合推理在以下条件下才能成功:体验感觉是统一的,部署位置保持可问责性,且系统知道何时不应路由。 ## 来源 1. NVIDIA DGX Spark 硬件 (https://docs.nvidia.com/dgx/dgx-spark/hardware.html) 1. AMD:Strix Halo 本地机器人演示 (https://rocm.blogs.amd.com/ecosystems-and-partners/rai-lemonade-agents/README.html) 1. HP:ZBook Ultra G3a 发布公告 (https://www.hp.com/us-en/newsroom/press-releases/2026/hp-redefines-the-mobile-workstation-for-the-era-of-agentic-ai.html) 1. GMKtec:EVO-X5 Pro 及 9 月 28 日发布 (https://www.gmktec.com/blogs/news/gmktec-evo-x5-pro-the-next-generation-agentic-pc-with-192gb-memory-and-local-300b-ai) 1. NVIDIA:Jetson Thor 与物理 AI (https://developer.nvidia.com/blog/introducing-nvidia-jetson-thor-the-ultimate-platform-for-physical-ai/) 1. Microsoft:推理部署类型与处理位置 (https://learn.microsoft.com/azure/ai-foundry/openai/how-to/deployment-types) 1. Microsoft:Foundry Local (https://learn.microsoft.com/azure/foundry-local/what-is-foundry-local) 1. Microsoft:Azure Local 预览版上的 Foundry Local (https://learn.microsoft.com/azure/azure-sovereign-clouds/private/foundry-local/overview) 1. OpenAI:gpt-oss (https://github.com/openai/gpt-oss) 1. Anthropic:Claude 模型概览 (https://platform.claude.com/docs/en/models/overview) 1. xAI:Grok 2 模型卡及许可证 (https://huggingface.co/xai-org/grok-2) 1. DeepSeek-V3.2 模型卡 (https://huggingface.co/deepseek-ai/DeepSeek-V3.2) 1. Z.ai:GLM-4.5 模型卡 (https://huggingface.co/zai-org/GLM-4.5) 1. 阿里巴巴:Qwen3-235B-A22B 模型卡 (https://huggingface.co/Qwen/Qwen3-235B-A22B) 1. NVIDIA:Nemotron 3 Nano 模型卡 (https://huggingface.co/nvidia/NVIDIA-Nemotron-3-Nano-30B-A3B-BF16) 1. Nous Research:Hermes 3 模型卡 (https://huggingface.co/NousResearch/Hermes-3-Llama-3.1-8B) 1. Anthropic:令牌、缓存与工具定价机制 (https://platform.claude.com/docs/en/about-claude/pricing) 1. Ollama:本地操作与云端控制 (https://docs.ollama.com/faq) 1. Hermes Agent:推理提供商 (https://hermes-agent.nousresearch.com/docs/integrations/providers) 1. OpenClaw:Ollama 集成 (https://docs.openclaw.ai/providers/ollama) 1. 自主个人 AI 计算机 (https://github.com/autonomous-ai/autonomous-computer) 1. 自主网格架构(https://github.com/autonomous-ai/autonomous-grid/blob/main/docs/ARCHITECTURE.md) 1. Cursor:自带密钥(BYOK)与请求路由(https://cursor.com/help/models-and-usage/api-keys) 1. xAI:Grok 机器人执行模型(https://docs.x.ai/grok-bot/overview) 1. Wendy Labs:物理 AI 平台(https://wendy.dev/faqs)