作者 / 来源：中智凯灵 / AiDD
【篇首语｜企业 AI，正在从“会用”走向“能交付” 】
第四日，把视线转向 Agent 真正运行的物理世界：云端大模型越来越强，企业为什么还要做本地闭环？
国庆七日谈·第四日｜云边端运行底座
▼
不少前沿大模型能力主要通过云服务提供，推理能力越来越强，调用也越来越方便。于是，一个很自然的问题出现了：企业为什么还要在设备、产线、门店、园区或机器人上部署本地能力？
答案不在模型排行榜里，而在任务链路里。
一台机器人遇到障碍时，不能把每一次避让都交给远端模型；一条质检产线发现异常时，也不能等网络恢复后再决定是否停机。相反，跨部门知识查询、复杂规划、模型训练和全局优化，又很难只靠一台设备上的有限算力完成。
所以，生产级 AI 真正要做的，不是选择“全部上云”还是“全部本地”，而是回答三个更具体的问题：哪些任务必须在现场立刻闭环，哪些能力适合放到云端集中处理，哪些状态需要在云、边、端之间持续同步。
2026 年 AiDD 上海站、北京站和成都站的三场分享，恰好从推理服务、IaaS 性能和端侧具身智能三个方向，拼出了一张完整的运行底座图：模型能力决定“能做什么”，任务约束决定“在哪里做”，端到端证据决定“这样分工是否可靠”。
第一个问题：现场任务能不能等？
在 AiDD 成都站《从云端大模型到本地闭环：端侧AI驱动具身智能产品落地实践》中，阿加犀生态技术总监龙胜海把讨论拉回了一次现场任务。
端侧系统面对的不是一个干净的模型输入，而是持续变化的环境：传感器噪声、人员进入、设备抖动、网络波动、电量下降、动作失败都可能同时发生。任务是否需要本地闭环，首先取决于这些现场约束，而不是团队是否愿意“拥抱云”。
图 1：龙胜海《从云端大模型到本地闭环：端侧AI驱动具身智能产品落地实践》：在现场任务中，时延、网络、数据边界、环境变化与成本共同影响运行位置（演讲 PPT 第 10 页）
所谓本地闭环，不是简单地把一个大模型压缩后塞进设备。它至少要把感知、状态判断、任务调度、动作执行和结果校验连起来：设备发现变化，形成可执行状态，选择动作技能，执行后再次感知，并判断任务是否真的完成。
这条链路里，实时性和可靠性往往比模型参数量更重要。避障、急停、视觉定位、现场告警等任务对响应时间和网络可用性非常敏感；当通信时间或断网风险超过任务预算时，远端模型就不能独自承担最后一步控制责任。
但“本地”也不天然等于更安全、更稳定或更便宜。端侧算力有限，模型更新、设备异构、散热功耗、故障诊断和大规模运维都会增加复杂度。真正的工程问题不是“能否在端侧跑起来”，而是“在规定预算内能否持续完成任务”。
第二个问题：要优化的是性能，还是生产结果？
运行位置不是一道单目标选择题。
在 AiDD 北京站《被忽略的胜负手，IaaS层如何决定AI大模型训推的性能上限》中，阿里云技术专家刘小杨用“性能—成本—稳定”三角说明：极限性能决定能力上限，成本决定能否规模化，稳定性决定业务能否连续运行。生产系统需要做的，是寻找与业务阶段相匹配的平衡点。
图 2：刘小杨《被忽略的胜负手，IaaS层如何决定AI大模型训推的性能上限》：性能、成本与稳定共同决定运行底座的可持续性（PPT 第 7 页）
这意味着，企业不能只比较“云端模型更强”或“端侧响应更快”。一个方案即使单次推理很快，如果成本无法支撑任务规模，仍然不能进入生产；一个方案即使单位成本低，如果网络抖动或故障恢复让关键任务频繁中断，也不是真正可用。
同样，端侧芯片价格低于云端账单，并不等于总体成本更低。设备部署、模型适配、版本升级、现场维护和故障更换都会进入全生命周期成本。反过来，云端按调用付费也不等于一定更省，长链路 Agent 的连续推理、缓存和并发调度同样需要精细核算。
第三个问题：云端是不是只要“调用一次 API”？
从 Chatbot 到 Agent，推理负载已经发生变化。
过去的在线模型服务主要面对人发起的问答。请求频率受人的阅读和输入速度限制，一次回答结束，任务往往也随之结束。Agent 则可能连续拆解任务、调用工具、检索资料、生成结果并再次验证；一个目标会变成多轮、链式、带状态的推理过程。
在 AiDD 上海站《面向 AI Agent 时代的下一代推理基础设施：AI Serving Stack 架构解析与生产级实践》中，阿里云高级技术专家、CNCF Fluid 项目联合发起人车漾提出，Agent 时代的推理基础设施需要同时关注状态、调度、弹性与成本。
车漾课件给出的 Cost per Token 核算框架，把推理成本拆到 GPU 单位时间成本、吞吐量和利用率几个杠杆。这里重要的不是照搬某一个公式，而是把成本从“买了多少算力”改成“单位推理工作消耗多少资源”。模型越大、任务链越长，这种核算越不能只看一次 API 的标价。
图 3：车漾《面向 AI Agent 时代的下一代推理基础设施：AI Serving Stack 架构解析与生产级实践》：课件从单位时间成本、吞吐和利用率拆解推理成本（演讲 PPT 第 5 页）
更细一层看，同一次模型推理内部也可能有不同瓶颈。刘小杨的课件以一组 LLaMA-70B 示例说明，Prefill 更偏计算密集，Decode 则更容易受到显存带宽与历史 KV 读取影响。这里的配置和数值不能外推到所有模型，但它提醒企业：不能用一张 GPU 利用率报表笼统判断整条链路。
图 4：刘小杨《被忽略的胜负手，IaaS层如何决定AI大模型训推的性能上限》：课件示例显示 Prefill 与 Decode 可能呈现不同资源瓶颈（PPT 第 21 页）
云端推理因此也不是“给模型分配一块 GPU”那么简单。车漾展示的 AI Serving Stack 把网关、推理引擎、工作负载编排、模型权重与 KV Cache、监控、性能分析、基准测试和弹性伸缩放在同一套架构中。这是一个具体方案视角，但它揭示了生产运行的共同要求：模型服务必须被当成持续运转的系统，而不是一次性的调用接口。
图 5：车漾《面向 AI Agent 时代的下一代推理基础设施：AI Serving Stack 架构解析与生产级实践》：AI Serving Stack 将路由、推理、编排、缓存、监控与弹性纳入同一运行体系（演讲 PPT 第 7 页）
云端仍然适合承载大模型、集中算力、多租户调度、模型版本管理和跨设备的全局优化。但当 Agent 进入真实业务，云端能力必须与任务的时间、网络和数据约束一起设计，而不是默认所有步骤都绕远路到云上完成。
云、边、端不是三套孤岛，而是三种不同责任
龙胜海的课件把端、边、云分成不同职责：关键任务在端侧完成，边缘承担近场的多设备协调、任务队列、本地知识、数据汇聚与局域服务，云端提供训练、知识与持续升级。
图 6：龙胜海《从云端大模型到本地闭环：端侧AI驱动具身智能产品落地实践》：端、边、云按关键任务、近场协同和持续升级分工（演讲 PPT 第 13 页）
这不是所有系统都必须照搬的固定拓扑，却给出了一个清楚的分工原则。
端侧守住不能等待的关键路径。包括现场感知、低时延控制、断网可用、基础安全动作和必要的数据预处理。它解决的是“任务不能停”。
边缘侧承担近场协调。在设备资源不足、多个设备需要共享局部状态，或者远端往返超出预算时，边缘节点可以承接区域内的任务队列、缓存、数据汇聚和局域服务。
云端承载高算力、全局性和持续演进。包括训练微调、复杂规划、跨设备数据与知识聚合、模型版本管理、全局评估和批量运营。它解决的是“单个现场做不了，或者不该重复做”。
完整系统还要明确：哪些状态留在本地，哪些结果可以上送；云端返回的是建议、计划、模型还是必须执行的命令；网络异常时如何降级，恢复后怎样同步状态。云边端协同的核心，不是把同一套模型复制到三个位置，而是让三种责任彼此衔接。
没有可观测，就没有可靠的跨层协同
当任务跨越云、边、端，问题定位会更难。一次响应变慢，可能来自网络、排队、缓存、模型阶段、设备负载或下游动作。只看最终成功率，很难知道应该把能力移到哪里、资源加在哪一层。
车漾的课件把推理可观测分成几类：TTFT、TPOT、吞吐等服务指标，Waiting/Running Requests、KV Cache 使用等系统指标，以及 GPU、显存和 SM 等资源指标。图中的仪表盘来自具体方案，不能当作行业基线，但这种分层观察思路值得保留。
图 7：车漾《面向 AI Agent 时代的下一代推理基础设施：AI Serving Stack 架构解析与生产级实践》：推理运行需要同时观察服务、队列缓存与 GPU 资源指标（演讲 PPT 第 22 页）
刘小杨则从计算、网络、GPU 与存储四侧给出可观测指标清单，区分常规利用率和更深层的延迟、重传、通信、显存带宽、数据加载与 Checkpoint 指标。这个清单不意味着所有系统都要采集每一项，而是说明：优化之前，要先知道瓶颈到底发生在哪一层。
图 8：刘小杨《被忽略的胜负手，IaaS层如何决定AI大模型训推的性能上限》：计算、网络、GPU 与存储指标共同支撑跨层瓶颈定位（PPT 第 16 页）
对云边端架构而言，可观测的最终目的不是做一张更复杂的大盘，而是获得迁移和分工的证据：这个步骤放到本地后是否真的缩短了端到端时间？缓存是否降低了重复推理？断网降级是否仍能完成关键任务？云端升级后，端侧任务质量有没有退化？
最后一个问题：如何证明这种分工是对的？
龙胜海在模型选型环节强调“从任务基线开始”：先定义任务数据、板卡与负载条件，再比较候选方案的质量、时延、内存等结果，满足任务要求后才进入下一步。
图 9：龙胜海《从云端大模型到本地闭环：端侧AI驱动具身智能产品落地实践》：模型与部署方案要在同板卡、同负载、同任务数据下回到任务基线验证（演讲 PPT 第 21 页）
这也是云边端选型最容易被忽视的一步。架构图可以很漂亮，但只有同条件任务测试，才能说明这种分工是否真的可靠。
企业可以先回答五个问题：
第一，任务最晚多久必须响应？要把采集、传输、排队、推理、工具调用、动作执行和确认全部计入。
第二，断网时任务能否继续？如果必须继续，本地就要保留最小可行闭环，并定义降级模式。
第三，哪些数据不能离开现场？数据边界同时决定上传、脱敏、存储、权限与审计方式。
第四，单位任务真正消耗多少资源？云端看推理与缓存成本，边缘看节点利用率，端侧看算力、内存、功耗和维护成本。
第五，哪一层对最终动作负责？遇到冲突、超时和异常时，必须提前定义谁能覆盖谁、谁触发停止、谁保留证据。
答案可能随场景变化：同一台设备在稳定网络下使用云端增强，断网时切换本地策略；复杂规划放在云端，低时延控制留在端侧；原始数据在现场完成筛选，只上送必要特征和异常片段。
因此，云边端协同不是一次架构选型，而是一套持续验证的运行策略。
结语：最强模型，不一定在最后一米做决定
企业选择运行底座时，很容易从模型能力出发：哪个模型更聪明，就让它处理更多任务。但真实业务首先受时间、网络、数据、算力和责任约束。
上海站的推理服务实践说明，Agent 时代的云端基础设施需要同时管理成本、编排与可观测；北京站的 IaaS 分析说明，不同推理阶段和基础设施层可能出现不同瓶颈，最终要在性能、成本与稳定之间取平衡；成都站的端侧实践则提醒我们，现场任务要从约束出发划分端、边、云职责，并回到任务基线验证。
本地闭环不是对云端大模型的否定，云端增强也不是对端侧能力的替代。生产级 AI 的答案，是把最合适的能力放在最合适的位置，并让状态、证据和策略能够在云、边、端之间连续流动。
模型越来越强，企业更需要问的不是“能不能都放到云上”，而是：在哪一层做决定，才能让任务在真实世界里持续完成。
国庆七日谈·第五日，我们继续讨论：测试会自动生成之后，谁来验证测试 Agent？
主要参考演讲
下一站
北京营销中心
北京通州北京ONE国际广场10层
上海研究中心
上海市浦东软件园
厦门研究中心
厦门观音山国际商务运营中心
海外市场中心
香港中环香港站国际金融中心
加入智库
成为客户
