2026 年，AI 的核心挑战已从“模型是否足够智能”转向“基础设施是否可运维、可治理、经济可持续”。随着 AI Agent 从单体演示走向多智能体协作的分布式系统，传统云原生架构在 GPU 利用率、资源隔离、弹性调度和可观测性等方面面临严峻挑战。阿里云 AgentRun 团队基于大规模生产实践，提出以 Agentic Runtime 为核心的 AI 原生基础设施架构，深度融合容器化、XPU 虚拟化、Serverless 弹性与分布式协调能力，支撑高并发、低延迟、强隔离的 Agent 应用运行。

本次分享我将围绕以下关键方向展开：

• Agent 即工作负载：如何将多 Agent 系统建模为云原生工作负载，实现规划、执行、验证等阶段的解耦与编排；
• XPU 资源池化与细粒度调度：通过 GPU/NPU 虚拟化与优先级抢占机制，将集群利用率从 <40% 提升至 70%+，显著降低推理成本；
• 轻量安全沙箱与隔离：结合轻量虚拟机与 eBPF 技术，保障多租户 Agent 在共享集群中的安全边界与性能隔离；
• 高性能数据底座支持 KV Cache 与分布式状态同步：优化 Agent 间通信与上下文缓存，减少冗余计算；
• 与 K8s/Ray 生态融合：基于扩展的 Kubernetes 控制面与 Ray 分布式框架，构建统一的 AI 应用运行时底座。

AI 的下一阶段胜负手不在模型本身，而在基础设施能否承载责任。我将通过金融、电商等真实场景案例，展示 AgentRun 如何支撑日均亿级 Agent 调用，并分享在弹性扩缩容、故障自愈、成本归因等方面的工程实践。

演讲提纲

1、引言：AI 基础设施的范式拐点
当前 AI 应用演进趋势：从单模型调用 → 多 Agent 协作 → 企业级智能体系统

• 核心矛盾：传统 Serverless/容器架构无法满足 Agent 的长生命周期、强状态性与高安全隔离需求
• 提出观点：Agentic Runtime 是 AI 原生基础设施的核心抽象，需重构“如何运行”而非仅“如何编写”Agent

2、挑战：为什么现有云原生架构“不够用”？

• 资源视角：GPU/NPU 利用率低、Token/KV Cache 调度粗放、弹性滞后
• 安全视角：工具调用缺乏沙箱隔离，多租户数据易泄露
• 状态视角：会话状态散落、任务中断不可恢复、协作无统一执行图
• 运维视角：缺乏全链路可观测、成本不可归因、扩缩容依赖人工

3、AgentRun 架构全景：构建 AI 原生运行时底座

• 核心理念：Agent = 可调度、可治理、可审计的 Workload
• 四大支柱能力：
  • 轻量安全沙箱：基于轻量虚拟机 + eBPF 实现会话级隔离，会话结束自动销毁
  • XPU 资源池化与细粒度调度：支持 GPU/NPU 虚拟化、KV Cache 共享、按 Token 精细化计费
  • 分布式 Agent 执行引擎：基于扩展 K8s CRD + Ray 构建多 Agent DAG 执行图
  • AI 原生可观测体系：集成推理轨迹、工具调用链、成本指标，支持回放与调试

4、关键技术实践

• 状态管理：Session State 与 Task State 分离，支持断点续跑与版本快照
• 工具安全调用：MCP 协议集成 + 沙箱内 Sidecar 代理，实现标准化、可审计的工具接入
• 弹性 Serverless Agent：冷启动 <800ms，空闲自动冻结，资源利用率提升 2.1 倍
• 与企业系统打通：通过 AI 网关对接 IAM、消息队列、数据库，赋能核心业务流程

5、落地案例：从 PoC 到规模化生产

• 金融场景：多 Agent 协作完成贷前尽调，效率提升 60%，合规审计全覆盖
• 电商场景：千人千面导购 Agent 集群，日均亿级调用，P99 延迟 <1.2s
• 成本收益：相比裸容器部署，TCO 降低 45%，故障自愈率 >99.5%

6、总结与展望

• 核心结论：AI 原生 ≠ 把 LLM 跑在云上，而是重构整个运行时契约
• 未来方向：
  • 支持跨地域、跨模型、跨厂商的 Agentic Federation
  • 探索基于强化学习的自主调度策略

您认为，这样的技术在实践过程中有哪些痛点？

1、模型能力与工程实现严重脱节（研发侧）

• 现象：顶尖大模型具备“博士生”级智能，但工程环境（Prompt、上下文管理、工具集成）仍停留在“小学生”水平，导致能力无法有效释放
• 与基础设施痛点结合：缺乏支持动态上下文注入、多步推理状态跟踪的 Agentic Runtime，使得复杂任务（如金融合规审查、医疗诊断）因上下文断层而失败

2、开发范式碎片化，重复造轮子（研发 & 部署侧）

• 现象：每个团队从零构建 Agent 框架，工具调用、记忆管理、规划模块高度定制，难以复用
• 与基础设施痛点结合：缺少标准化的 MCP 插件协议、统一的 Agent 执行引擎和可组合的模板体系，导致即使有优秀垂直模型，也无法快速集成到可靠运行环境中

3、本地体验差，云端依赖强（研发 & 用户侧）

• 现象：开发者依赖 Ollama、LM Studio 等本地工具测试模型，但其仅提供基础聊天界面，不支持文档分析、多 Agent 协作等生产力场景；普通用户（如律师、投资经理）因数据隐私焦虑拒绝上传敏感信息至云端。
• 与基础设施痛点结合：现有云原生架构未支持“端云协同”的 Agentic Runtime，无法在本地安全沙箱中运行轻量 Agent，同时与云端大模型协同，造成体验割裂。

4、成本不可控，难以规模化（部署 & 运维侧）

• 现象：单次 Multi-Agent 任务消耗百万 Token，费用高达数十美元，高频使用不可持续 1；95% 的企业尚未从生成式 AI 获得实际商业回报
• 与基础设施痛点结合：缺乏对 XPU 资源、KV Cache、Token 流的细粒度池化与弹性调度，导致算力浪费严重，TCO 居高不下

5、安全与信任缺失（全链路）

• 现象：用户不信任 Agent 的“黑箱”决策，仅 15% 企业愿授权关键操作 4；员工担心 AI 替代岗位，产生文化抵触
• 与基础设施痛点结合：运行时缺乏会话级安全沙箱、工具调用审计日志和可解释执行轨迹，加剧了安全与合规风险

6. 技术与业务认知错位（组织侧）

• 现象：业务部门要解决具体问题，技术团队却热衷于“追新模型”，项目脱离真实场景
• 与基础设施痛点结合：若底层 Infra 无法提供“开箱即用”的垂直 Agent 模板（如客服、风控、导览），业务方难以快速验证价值，进一步加深认知鸿沟

演讲亮点

• 直面 AI 应用落地的核心障碍
  • 聚焦企业从 PoC 到生产过程中普遍遇到的“跑不稳、管不住、成本高”问题，不谈概念，只讲工程实践中真实存在的挑战与应对。
• 将 AI Agent 视为可运维的工作负载
  • 借鉴云原生理念，把 Agent 纳入统一的运行时管理体系，支持调度、扩缩容、监控和生命周期管理，使其像微服务一样可靠、可观测。
• 实现切实可行的资源效率提升
  • 通过 GPU/NPU 虚拟化、KV Cache 共享和 Token 级资源计量，在实际业务中将算力利用率提升至 70% 以上，整体推理成本降低约 45%。
• 构建企业级安全隔离机制
  • 采用轻量虚拟机与沙箱技术，实现“一次会话一环境”，确保工具调用和数据访问严格隔离，满足金融、制造等行业的合规要求。
• 提供可复用、可集成的技术路径
  • 基于阿里云 AgentRun 的生产实践，开放一套融合 K8s、Serverless 与分布式执行引擎的架构方案，帮助企业平滑演进，缩短从试点到规模化部署的周期。

听众收益

• 理解 AI Agent 系统向分布式架构演进的必然性与技术挑战；
• 掌握构建高可用、高效率 AI 原生基础设施的关键技术路径；
• 获取在资源调度、安全隔离、数据协同等方面的可复用实践经验；
• 明确企业如何基于现有云原生体系平滑演进至 AI 原生时代。

大模型分离式推理、强化学习、AI Agent 等各类 AI 负载对分布式系统软件带来了各种诉求，例如大模型推理服务的快速伸缩/ EPD 分离/历史缓存加速，强化学习的多模型任务高效调度/训推参数异步更新/异步数据流，AI Agent 的快速弹性等。在企业落地实施时，通常一方面对现有的各种系统比如微服务系统进行扩展，另一方面针对具体场景构建各种新的分布式系统软件，最终平台需要构建和维护多个独立的软件，增加了整体方案的复杂度和维护工作量。

本次演讲我将分享 openYuanrong 解决思路，以分层架构构建 AI Infra 分布式基础设施，剖析各类 AI 负载对分布式系统软件的共性功能诉求，并在底层 openYuanrong 统一提供这些功能的高性能实现，上层面向各个场景适配扩展，从而简化了整体系统复杂度，也提升了资源的整体使用效率，在企业落地过程中取得良好的实践效果。

演讲提纲

1. 背景

• 微服务扩展与新系统并建成为常态
• 多软件并存，架构复杂度持续膨胀

2. openYuanrong 整体架构设计

3. 大模型推理实践

• 弹性伸缩
• 分布式 KV Cache
• 分离式推理
• 基于KV Cache 在线迁移的动态负载均衡

3. 强化学习实践

• 分离式异步训推
• 训推参数异步更新
• 样本数据系统
• 多 Agent 异构资源动态调度
• Agentic RL函数/容器统一编排

4. AI Agent 实践

• 快速启动
• 会话弹性

5. 分布式训练实践

• 分片 Checkpoint 的快速保存与恢复

6. 经验总结与 Q&A

您认为，这样的技术在实践过程中有哪些痛点？

• openYuanrong 采用了新的架构方法，需要迁移存量系统，有一定的迁移工作量

演讲亮点

• 业界现有方案是烟囱式架构，需要集成和维护多套中间件系统，openYuanrong 是分层的积木式架构，基础功能完全复用，减少了构建和维护成本，并提升了资源的整体使用效率

听众收益

• 可以深入了解 AI 场景各类负载对分布式系统软件的关键功能需求，以及可参考的解决方法
• 借鉴 openYuanrong 系统架构思路，有助于构建更简单高效的 AI Infra 分布式基础设施

AI 领域的三大核心负载——模型训练、批量推理与模型服务，均面临相似的弹性调度挑战。尽管业界已针对在线和离线场景分别推出了开源解决方案，但这些方案往往各自为战，仅能覆盖单一负载类型。为此，我们联合 openFuyao 社区共同设计并研发了面向 AI 原生工作负载的弹性调度框架 Aether。从业务落地效果来看，训练的 ETTR 达到 97%，千卡级离线推理任务端到端任务处理时间缩短 10%，部署 PD 分离模型服务的端到端效率提升 5%。

本次演讲我将围绕 Aether 的架构设计、关键技术决策与踩坑经验进行展开，分享如何构建一个高性能、高弹性的基础设施用于支撑 AI 原生工作负载。

演讲提纲

1. 背景与挑战生态趋势

• 算力规模指数级增长，但系统稳定性未能同步跟进
• 为了解决“资源永远不够用”与“资源利用率低”并存的矛盾，传统调度缺乏弹性，硬件故障频发导致训练中断、成果归零（ ETTR 低下）的问题，我们构建了一套统一、高效、可靠的弹性调度框架

2. 整体架构设计

3. 关键技术实践

• 动态资源优化与调度
• 动态组网与拓扑自愈
• 自动故障检测与隔离

4. 落地实践

• 模型训练：有效训练时间占比（ETTR）提升至 97%
• 批量推理：端到端任务处理时间缩短 10%，资源成本降低 30%
• 模型服务：部署 PD 分离服务的端到端效率提升 5%

5. 总结与展望

• Aether 将 AI 资源的“不可用”、“不可靠”转变为高效、弹性、可保障的生产力。未来，我们将会持续探索更智能的资源调度策略，并拓展至更广泛的 AI 工程化场景

您认为，这样的技术在实践过程中有哪些痛点？

• “动态组网”与“状态重建”的时间窗口矛盾：当某个节点故障被剔除，新节点加入时，整个通信域必须完全重建。这个过程中，所有其他正常节点必须暂停计算等待重连，如果重建时间过长（分钟级），频繁的微故障会导致系统大部分时间在“重建”而非“训练”
• 故障判定的“误报”与“震荡”：在大规模集群中，偶尔的网络抖动或 GC 停顿是正常的。如果健康探针过于敏感，会将这些“慢节点”误判为“死节点”并强制重启。这不仅浪费了已完成的计算，还可能因为频繁重启导致任务永远无法完成（Live Lock）

演讲亮点

• 分享如何构建一个真正适应AI原生负载的弹性调度系统
• 深入剖析 Aether 框架的核心设计理念与技术实现细节
• 分享在京东零售大规模生产环境中的落地实践

听众收益

• 了解如何设计一个高效、可靠的弹性调度框架来支撑大规模 AI 原生工作负载
• 学习如何设计自适应故障探针、细粒度隔离机制，将运维工作从“ 7x24 小时救火”转变为“自动化防御”
• 获取在大规模生产环境中构建弹性调度系统的实战经验与教训，避免常见的设计陷阱和误区

AI 时代，开发者面临一个悖论：模型能力日趋强大，但基础设施的使用门槛却居高不下。无论是个人开发者想在单机上快速验证 Agent 应用，还是企业团队需要在私有 K8s 集群或公有云上部署生产环境，都不可避免陷入"Build Your Own Cluster"的泥潭——依赖冲突、部署复杂、运维繁重。

AKernel 是一个面向 AI 原生开发者的 Datacenter-Use 框架，核心理念是"像调用本地函数一样使用整个数据中心"。我们采用大库（monorepo）架构，300 万行代码统一维护，通过 AI 辅助开发实现 <=3 人全栈团队的高效协作。AKernel 提供一站式部署方案：无论面对单机、私有 K8s 集群，还是多云环境，均可在 10 分钟内完成部署。

技术层面，AKernel 融合了三大核心能力：基于 openYuanrong 的分布式数据系统，实现跨实例、跨节点的高性能数据共享；AFaaS fork 技术，实现 10ms 级节点侧启动、40ms 端到端延迟的极致弹性；基于 gVisor/Firecracker 的 Checkpoint/Restore 机制，赋能 Agent 的暂停恢复与克隆。在 Agent 长会话、RL 训练任务、Spark 数据处理等场景中，AKernel 显著降低了资源碎片率，提升了任务响应速度与资源利用效率。

本演讲将我将围绕 AKernel 的架构设计、关键技术决策与踩坑经验展开，分享如何在有限人力下构建可扩展、易维护的 AI 原生基础设施。

演讲提纲

1. 引言：AI 开发者正在被基础设施"劝退"

• 现状剖析：个人开发者配置环境耗时数天，小团队陷入重复建设，大企业维护成本高昂
• 核心矛盾：模型能力快速演进 vs 基础设施使用体验停滞不前
• 提出观点：AI 原生基础设施必须回归"开发者友好"本质，实现一键部署、随处运行

2. AKernel 架构：大库治理与 AI 辅助的工程实践

• 统一代码库架构与依赖治理
  • 采用大库（Monorepo）模式，300 万行代码集中管理，通过 submodule 机制实现外部依赖的版本锁定与按需集成
  • 端到端组件自主可控：从 SDK/API 层、控制面到运行时，完整掌控技术栈演进节奏
  • 消除分布式版本管理的依赖冲突问题，实现跨模块原子化变更与一致性构建
• AI 辅助开发模式
  • 5-10 人全栈团队，无需求/研发/测试/运维分工，80% 代码工作由 AI 辅助完成
  • 从代码生成、测试用例生成到运维决策的全链路 AI 赋能
  • 工程效率提升背后的组织变革与技术债管理
• 开发者 API 与 CLI 设计
  • Remote Function 调用接口：采用 Ray-like 的 Python 装饰器设计，开发者通过简单注解即可将本地函数转换为可跨节点调用的远程函数，屏蔽底层资源类型与位置
  • CLI 工具链：支持集群和实例管理，包含一键部署、实例查询、任务提交、日志追踪的完整运维闭环
  • 监控与日志自助化：无需手动配置，自动生成监控仪表盘和日志网站，用户可直接访问网址查看任务状态、资源使用与日志输出

3. 一站式部署：从单机到多云

• 部署场景全覆盖
  • 单机模式：个人开发者在 server 上一键启动完整环境
  • 私有集群：对接现有 K8s，10 分钟完成资源接入与组件部署
  • 公有云：支持阿里云、AWS、Google Cloud 的标准化部署
• 极简部署机制
  • 单命令启动：自动探测环境、完成组件初始化、建立控制面
  • 从资源就绪到集群可用：10 分钟内完成，无需手动配置依赖
  • 统一认证、监控、日志服务开箱即用

4. Agent 时代的三大技术支柱

• 高性能数据共享：openYuanrong 分布式数据系统
  • 痛点：传统方案跨节点数据拷贝延迟高、带宽利用率低
  • 方案：参数传输面优化，支持跨节点、跨资源类型的零拷贝数据流动
  • 踩坑经验：早期过度依赖 BaaS 导致接入成本高，后统一为 openYuanrong 数据系统
• 极致冷启动：AFaaS 安全沙箱
  • 性能指标：10ms 节点侧启动（AFaaS 纯节点方案），40ms 端到端延迟
  • 技术实现：基于 gVisor/Firecracker 的轻量虚拟化，细粒度网络控制
  • 应用场景：Agent Sandbox 快速创建、RL Reward 任务高并发执行、自定义镜像 Lazy Load
• 状态持久化：Checkpoint/Restore 全链路支持
  • 架构设计：从 SDK、调度器到节点端的全栈实现
  • 核心价值：Agent 长期待机资源释放、特定节点状态恢复执行、任务故障自愈
  • 踩坑经验：固定资源规格阻碍空闲资源利用，通过 DaemonSet 动态上报解决

5. 实践验证与典型场景

• Agent 多智能体协作
  • 每个 Agent 运行在独立沙箱，秒级启动与销毁
  • Checkpoint/Restore 支持长会话状态迁移与资源弹性
• RL 训练与 SWE 任务
  • 高并发实例快速创建，数据在 openYuanrong 系统内高效流通
  • 避免中间落盘，端到端延迟降低 60%+
• Spark/Flink 大数据处理
  • 精准识别空闲资源，避免离线任务与在线任务互相压制
  • 资源利用率显著提升

6. 总结与展望

• 核心价值：让 AI 开发者专注于模型与应用，而非基础设施搭建
• 未来演进：更细粒度 XPU 支持（NPU/TPU）、强化学习驱动的自主调度

您认为，这样的技术在实践过程中有哪些痛点？

• "Build Your Own Cluster" 门槛过高
  • 从资源接入、调度器构建到监控体系，需要大量工程投入
  • 小团队难以独立完成，大团队易陷入重复建设陷阱
• 跨团队依赖管理灾难
  • 多仓库架构下版本冲突、接口不兼容频发
  • 开发者 30%+ 时间消耗在环境配置与依赖解决
• 数据与计算的绑定难以优化
  • 缺乏跨任务类型的数据共享机制
  • Agent 会话间重复加载相同数据，造成算力浪费
• Agent 状态管理缺失
  • 长生命周期 Agent 长期占用资源但大部分时间空闲
  • 任务中断后无法从特定节点恢复执行，只能重启
• 多环境部署碎片化
  • 单机、私有云、公有云需要维护多套部署脚本
  • 配置漂移导致"在我机器上能跑"问题频发

演讲亮点

• 大库治理 + AI 辅助的工程模式创新
  • 300 万行代码、<=3 人全栈团队、80% AI 辅助开发，展示了一种可持续的基础设施维护范式
  • 打破"基础设施必须大团队维护"的固有认知，为中小团队提供可借鉴路径
• 从 10ms 启动到 Checkpoint/Restore 的全链路 Serverless 能力
  • AFaaS 实现 10ms 节点侧启动、40ms 端到端延迟，相较传统容器方案（秒级启动）提升 2 个数量级
  • Checkpoint/Restore 与调度系统深度集成，实现 Agent 状态的真正可迁移、可恢复

听众收益

• 掌握 AI 原生基础设施的轻量化构建方法
  • 学习如何通过大库架构与 AI 辅助开发，以有限人力维护大规模代码库
  • 获得从单机到十万节点集群的统一部署实践经验，可直接应用于团队基础设施建设
• 理解 Serverless AI 运行的关键技术决策
  • 深入理解极速冷启动（10ms 级）、Checkpoint/Restore、高性能数据共享的设计取舍
  • 避免在自建 Agent 运行环境时重复踩坑
• 获取可复用的开发者体验优化策略
  • 了解如何通过"一键部署"理念降低 AI 应用开发门槛
  • 学习在组织内推动 AI 辅助开发落地的方法与组织模式

随着大模型预训练和后训练的发展，Ray 已经逐步在 AI Infra 领域占据重要的生态位。K8s 作为云原生技术的核心系统，在 AI Infra 领域几乎是必选的算力基座。 本次演讲我将从调度的视角分析 K8s 和 Ray 的差异以及在技术栈上的协同，同时分享 K8s + Ray 在腾讯内部的万卡落地实践。

演讲提纲

1. AI Infra 技术栈与发展趋势

• AI Infra 主流技术栈
• K8s 与 Ray 生态位分析

2. Ray 的调度视角

• Ray 调度内核介绍
• Ray 调度提效案例分享

3. K8s + Ray 在腾讯内的落地实践

• 云原生异构联邦架构
• K8s + Ray 跨层融合调度
• 落地案例分享

您认为，这样的技术在实践过程中有哪些痛点？

• 对人才有一定的技术要求，一方面要熟悉云原生技术，另一方面要熟悉 Python Native 的调度引擎和 AI 框架
• K8s + Ray 从系统优化层面看，优化上限更高，但同时如果姿势不对，系统性能的下限也更低

演讲亮点

• 将总结 K8s + Ray 技术栈相关领域发展趋势
• 将解惑 K8s 和 Ray 两个生态定位的差异和协同方式
• 将分享腾讯内部真实的落地案例

听众收益

• 了解 Ray 项目发展现状，从调度的视角了解 Ray 的内核
• 了解 K8s + Ray 落地相关的技术挑战
• 了解 Ray 在业内主流的应用场景和预期收益

vLLM 一直专注于为大语言模型（LLM）提供高吞吐、低显存的推理能力。但今天的生成式模型已经远不止“文本输入、文本输出”：新的模型可以同时理解和生成文本、图像、音频、视频，背后也不再是单一自回归架构，而是由编码器、语言模型、扩散模型等异构组件拼接而成。vLLM-Omni 是最早一批支持“omni-modality”模型推理的开源框架之一，它把 vLLM 在文本推理上的性能优势，扩展到了多模态和非自回归推理领域。这是 vLLM 生态向“全模态（omni-modality）”时代迈出的关键一步，专门为新一代看得见、听得懂、会说话、能生成多种媒介的模型设计的推理框架。

本次演讲将从推理系统视角出发，解析全模态（Omni）模型给基础设施带来的新挑战，并结合 vLLM-Omni 的架构设计，分享如何在多模态输入输出、异构算子和多阶段生成链路下实现高效推理与工程优化。

演讲提纲

1. Omni 时代与系统挑战

• 全模态输入输出
• 非传统 LLM 推理框架
• 异构链路与生成流程复杂

2. vLLM-Omni 的统一架构

• OmniStage 统一抽象
• Encoder / LLM Core / Generator
• AR 模块 + Diffusion 模块
• Any-to-Any 全模态生成

3. 性能优化与解耦部署

• qwen3-omni 等模型案例展示
• Native Disaggregation
• Async Chunk
• Streaming Output
• 多阶段独立扩缩容

4. 能力边界与演进方向

• Diffusion Acceleration
• Cache / Parallel / Quantization
• CPU Offloading
• OmniConnector / OmniRouter
• 大规模部署与持续优化

您认为，这样的技术在实践过程中有哪些痛点？

全模态模型仍在快速发展，模型结构、生成路径和部署形态都没有完全收敛，框架设计需要避免过早绑定特定范式。相比传统文本 LLM 推理，全模态场景需要同时处理多模态输入输出、异构算子和多阶段流水线协同，系统复杂度显著增加。与此同时，解耦部署、异步 chunk、流式输出等优化虽然能够改善时延和资源利用率，但也会带来新的通信、调度、状态管理和运维复杂度，因此实践中一定存在明显 tradeoff。

演讲亮点

本次分享的亮点在于，从推理系统视角讨论 Omni 模型带来的新挑战，以及为什么它不是传统 LLM 推理框架的简单延伸。分享将结合 vLLM-Omni 的架构设计，介绍其如何基于 vLLM 生态扩展到全模态场景，并重点展开 Native Disaggregation、Async Chunk、Streaming Output、IO-Compute Overlap 等关键优化机制背后的设计思路与工程取舍。

听众收益

听众可以理解 Omni 模型对推理框架提出的新要求，建立对全模态推理系统的整体认识；同时获得一套分析解耦部署、流式传输、跨阶段调度和性能优化 tradeoff 的工程视角。对于正在关注多模态/全模态推理基础设施的团队，也能借此了解 vLLM-Omni 的适配路径和未来演进方向。

具身智能与自动驾驶的智能涌现高度依赖高质量数据闭环的转动。本次演讲我将深度剖析一套复用自百 PB 级自动驾驶经验、现已主导落地于具身智能场景的 AI 原生基础设施架构。

问题背景

• 存储挑战：海量小文件对存储元数据的极限压力：自动驾驶和具身智能应用产生的海量数据中，大量为小文件，这对存储系统的元数据管理提出了极高的要求。传统的存储架构在处理海量小文件时容易遇到性能瓶颈，导致数据存取延迟和存储资源浪费。
• 真机数据采集难度：在具身智能应用中，数据的采集通常面临困难，特别是高质量、真实环境下的数据采集（即“真机数据”）。这使得模型训练无法依赖足够多的真实场景数据，进而影响了模型的泛化能力和准确性。
• 调度挑战：
  • 算力资源碎片化：在分布式环境，尤其是多GPU和混合云环境中，算力资源常常出现碎片化，导致任务无法高效利用现有的计算资源。例如，GPU资源可能无法根据任务需求被充分调度，造成算力资源的浪费。
  • 任务抢占与死锁问题：在高并发、复杂的任务调度场景中，任务之间由于资源竞争可能导致抢占死锁现象，影响整体系统的稳定性和计算效率。
  • 混合云资源调度问题：在混合云环境中，不同云平台之间的资源调度和管理变得更加复杂，如何实现算力的高效调度、负载均衡和弹性扩展，成为确保高效计算和成本优化的难点。
• 闭环支柱挑战：
  • 数据回灌中的版本一致性问题：在闭环系统中，数据回灌的过程中常常会面临版本不一致性的问题，尤其是涉及到多个数据源和多个模型版本时，这种不一致性会影响数据的质量和模型的准确性。
  • 生成式仿真与数据补充挑战：在数据采集困难的情况下，**生成式仿真（World Models）**技术被用来弥补数据缺口，但这种仿真数据的质量、有效性和与真实数据的一致性问题仍然是一个亟待解决的挑战。
  • 模型量化与精度损失问题：在具身智能系统中，模型量化用于提升计算效率，但这种技术可能带来精度损失。如何平衡模型的计算效率与精度，以及如何保证模型的稳定性，是在量化部署过程中必须解决的问题。

演讲提纲

1. 背景：AI 原生基座的“第一性原理”

• 自动驾驶与具身智能的数据悖论：Corner Case 挖掘 vs. 真机数采瓶颈
• 基础设施如何驱动模型 Scaling Law 的跃迁

2. 存储支柱——PB 级多模态数据的存储演进

• JuiceFS 生产级实践
• 降本增效： 多级缓存策略与内核优化，突破海量小文件管理的性能瓶颈

3. 调度支柱——数百张 GPU 卡的混合云精细治理

• Volcano 调度增强：解决分布式训练中的资源碎片与任务抢占死锁
• 基于 KServe 的推理服务优化：实现板端部署与云端服务的弹性扩缩容

4. 闭环支柱——差异化路径下的全链路数据治理

• 业务赋能：利用生成式仿真（World Models）补齐具身智能的真机数据缺口
• 避坑指南： 模型量化部署的精度损失与数据回灌中的版本一致性挑战

5. 小结：反思——如何做一个“懂业务”的 Infra 架构师？

• 从“管理算力”到“驱动闭环”：以产品思维对齐模型交付周期

您认为，这样的技术在实践过程中有哪些痛点？

• 技术迁移有适配壁垒：JuiceFS 引擎迁移、Volcano 调度定制化等核心组件升级，面临数据兼容、系统对接冲突、业务无感知割接等落地风险，且需大量定制化调试，试错成本高。
• 跨模块 / 团队协同：存储、调度、训推等模块技术标准不统一、接口不兼容，且基建与业务团队认知偏差大（基建重技术稳定性，业务重实际指标提升），跨领域沟通与适配成本高。
• 资源成本短期矛盾：方案虽以降本提效为目标，但落地初期需投入大量采购、开发、重构成本，且算力精细化管控、在离线混部的实际效果难达设计预期，短期投入与长期价值实现存在矛盾。
• 场景化落地难度：生成式仿真与真机数据融合无通用模板、模型量化需适配不同端侧硬件与业务精度要求、数据回灌版本管控需对接多套系统，均需结合业务做定制化开发，无成熟方法论可复用。

演讲亮点

• 跨领域基建迁移实战： 展示如何将 100PB 级的自动驾驶成熟架构降维打击应用到具身智能领域，论证了标准化基建的长期价值
• 硬核存储演进历程： 详细拆解 JuiceFS 在真实生产环境下实践和挑战，以及 30% 成本削减的底层逻辑
• 全链路自动化闭环： 不仅限于存和调，更涵盖了针对“真机数据难采”所构建的生成式仿真与自动化回灌体系，具有极强的行业参考性

听众收益

• 实战模版： 获得一套支撑百卡规模、PB 级数据的具身智能标准 AI 基建参考架构
• 避坑经验： 掌握在混合云环境下处理多模态 AI 任务时，关于存储引擎迁移、Volcano 任务编排及推理扩缩容的真实失败案例
• 思维升维： 学习 Infra 架构师如何主动介入数据挖掘与仿真生成等业务层，从底层直接驱动业务迭代