Cornserve: A Distributed Serving System for Any-to-Any Multimodal Models

Cornserve 是一个基于 Kubernetes 的分布式服务系统，旨在通过灵活的任务抽象、组件解耦及高效的记录与重放执行模型，解决 Any-to-Any 多模态模型在服务中因路径差异和扩展特性不同而面临的挑战，从而显著提升吞吐量并降低尾延迟。

要点

想象一下，未来的 AI 不再只是只会“聊天”的机器人，也不只是只会“画画”的画家，而是一个全能型超级管家。

这个管家不仅能听懂你的话（文本），还能看懂你的照片（图像）、视频，甚至听懂你的语音。更厉害的是，它不仅能用文字回答你，还能根据你的要求，直接生成一段视频、一段音频，或者一张新图片。

这种“输入任意格式，输出任意格式”的 AI 模型，论文里称之为 "Any-to-Any"（任意到任意）模型。

但是，要同时伺候好这位“全能管家”非常困难。这就好比你要开一家超级餐厅，但客人们点的菜千奇百怪：

• 有的客人只点“文字沙拉”（纯文本对话）。
• 有的客人点“图文大餐”（看图说话）。
• 有的客人点“视听盛宴”（看视频并生成语音）。

传统的 AI 服务器（Monolith） 就像是一个大锅炖。不管客人点什么，所有食材（数据）都要扔进同一个大锅里，由同一批厨师（GPU 显卡）按顺序处理。

• 问题 1：效率低。 如果客人只想要“文字沙拉”，厨师却不得不先花时间去切“视频”和“音频”的备料，白白浪费时间和资源。
• 问题 2：瓶颈。 如果“做视频”的环节特别慢，整个厨房就堵住了，后面排队做“文字沙拉”的客人也得跟着干等。
• 问题 3：吃不消。 有些大模型太复杂，一个大锅根本装不下，直接撑爆了（显存溢出）。

---

🌽 Cornserve：AI 界的“乐高式”分布式厨房

这篇论文介绍了一个叫 Cornserve 的新系统，它彻底改变了这种“大锅炖”的模式。我们可以把它想象成一个高度灵活、模块化的“乐高式”分布式厨房。

1. 核心魔法：把大模型“拆”开来（模型裂变）

Cornserve 不再把整个模型塞进一个黑盒子里。它像拆乐高积木一样，把 AI 模型拆成了一个个独立的功能模块：

• 眼睛模块（专门处理图片/视频）
• 大脑模块（专门处理逻辑/文本，即 LLM）
• 嘴巴模块（专门生成语音）
• 画笔模块（专门生成图片）

比喻： 以前是“全能厨师”一个人从切菜到炒菜再到摆盘全包；现在是流水线作业。切菜的只管切菜，炒菜的只管炒菜，装盘的只管装盘。如果今天“切菜”的订单特别多，你就多招几个切菜工；如果“炒菜”很忙，就多加几个炒锅。大家互不干扰，各自发挥最大效率。

2. 聪明的调度员：记录与回放（Record-and-Replay）

这是 Cornserve 最聪明的地方。因为客人的需求千变万化（有的要图，有的要声），系统怎么知道该让哪些模块工作呢？

• 记录阶段（试跑）： 当客人下单时，系统先让模型“空跑”一遍。这时候不真的做菜，只是快速记下：“哦，这位客人点了图文，需要‘眼睛’和‘大脑’，不需要‘嘴巴’"。
• 回放阶段（真做）： 系统根据刚才记下的路线，精准地把任务派发给对应的模块。
• 比喻： 就像餐厅经理先快速看一眼菜单，画出一条“最优上菜路线”，然后指挥后厨：“切菜组准备，切完直接传给炒菜组，跳过摆盘组，直接上菜！”这样就没有任何多余的步骤。

3. 极速传送带：Sidecar 数据搬运工

当模块被拆分到不同的电脑（GPU）上工作时，数据怎么传递？
Cornserve 在每个模块旁边都配了一个专属快递员（Sidecar）。

• 比喻： 以前数据传递像“寄快递”，要打包、填单、走流程，很慢。现在，快递员直接把数据从“切菜组”的案板，通过共享内存（就像在同一个房间递东西）或者高速光纤（RDMA），直接塞到“炒菜组”的手里。
• 结果： 数据在模块间飞得飞快，几乎感觉不到延迟。

4. 资源共享：拼单更划算

如果两个不同的 AI 应用都需要用到同一个“眼睛模块”（比如都用来识别图片），Cornserve 不会重复造轮子。

• 比喻： 就像大家拼单点外卖。两个餐厅如果都要用同一种高级食材，Cornserve 会只买一份，然后分给两家店用。这样省下了大量的显卡（GPU）资源。

---

🚀 效果如何？

论文通过实验证明，Cornserve 这套“乐高式”厨房比传统的“大锅炖”强太多了：

1. 速度快了 3.8 倍： 同样的硬件，Cornserve 能处理的请求量是原来的近 4 倍。
2. 等待时间短了 5.8 倍： 那些排队最久的“长尾”请求（比如复杂的视频生成），等待时间大幅缩短。
3. 能跑更大的模型： 以前因为显存不够跑不起来的大模型（如 Qwen 3 Omni），现在可以拆分部署，顺利运行。

总结

Cornserve 就是为了解决未来 AI 越来越“全能”、越来越“复杂”而设计的超级调度系统。

它不再强迫 AI 模型在一个固定的盒子里运行，而是允许开发者像搭积木一样自由组合，让每个部分都能独立伸缩、独立加速。这就好比把一家拥挤、低效的传统餐厅，升级成了一个自动化、模块化、按需分配的超级美食工厂，让未来的 AI 服务既快又稳，还能处理各种天马行空的需求。

技术摘要

Cornserve：面向任意到任意（Any-to-Any）多模态模型的分布式服务系统技术总结

1. 研究背景与问题定义

背景：
随着多模态大模型（Any-to-Any models）的兴起，模型不仅能理解文本、图像、视频、音频等多种模态的输入，还能生成任意模态的输出。这类模型（如 Qwen Omni、DeepSeek Janus 等）通常被构建为包含异构组件（多模态编码器、LLM、多模态生成器）的计算图。

核心挑战：
现有的大模型服务系统（如 vLLM）主要针对纯文本 LLM 或特定任务（如扩散模型）设计，难以高效服务通用的 Any-to-Any 模型。主要面临两大异构性挑战：

1. 请求类型与计算路径的异构性： 不同的输入/输出模态组合会触发模型计算图中不同的组件和路径。例如，Qwen Omni 模型在处理“文本转音频”请求时，需要调用 Thinker LLM 和 Talker 组件，而“文本转文本”请求则不需要。这导致不同组件的请求速率差异巨大。
2. 组件扩展特性的异构性： 不同组件对计算资源的需求和扩展能力不同。例如，在相同硬件上，文本生成组件的吞吐量可能是音频生成组件的 4 倍。传统的单体部署（Monolithic Deployment）无法针对各组件独立扩展，导致资源浪费或性能瓶颈。

2. 方法论与系统设计

Cornserve 是一个基于 Kubernetes 构建的分布式服务系统，旨在通过组件解耦（Disaggregation）和独立扩展来解决上述问题。其核心设计包括以下三个关键部分：

2.1 灵活的任务抽象（Task Abstraction）

Cornserve 引入了三层抽象来简化模型开发者的工作：

• 单元任务（Unit Tasks）： 代表原子模型组件（如编码器、LLM、生成器），每个单元任务由独立的 Task Manager 管理。
• 复合任务（Composite Tasks）： 开发者使用纯 Python 编写 invoke 方法，将多个单元任务组合成复杂的计算逻辑（支持循环、分支等控制流）。
• 应用（Apps）： 定义服务入口，可实例化多个任务并处理并发请求。
  这种设计允许开发者用 Python 代码灵活描述任意 Any-to-Any 模型的逻辑，同时系统自动识别组件边界。

2.2 模型裂变（Model Fission）

系统允许在任意组件边界将模型“裂变”为独立的、可独立扩展的组件。

• 独立部署： 每个组件（如图像编码器、LLM、音频生成器）可以部署在专用的 GPU 上，并运行专门的执行器（如 Eric 用于编码器，vLLM 分支用于 LLM，Geri 用于生成器）。
• 组件共享： 如果多个应用使用相同的单元任务（如共享同一个视觉编码器），Cornserve 会自动共享其执行器部署，减少 GPU 占用。

2.3 分布式运行时与记录 - 重放机制（Record-and-Replay）

为了处理动态的计算路径，Cornserve 采用了一种高效的**记录 - 重放（Record-and-Replay）**执行模型：

1. 记录阶段（Record Phase）： 接收请求后，系统先调用复合任务的 invoke 方法，但单元任务仅返回占位符结果并记录调用顺序和数据依赖。此阶段不进行实际计算，速度极快。
2. 调度阶段： 根据记录到的子图，Task Dispatcher 将具体的组件调用分发给对应的 Task Executors。
3. 重放阶段（Replay Phase）： 再次调用 invoke 方法，此时单元任务从 Dispatcher 获取真实结果，生成最终响应。
   这种机制使得系统能够支持包含复杂控制流（如基于 LLM 输出的动态分支）的模型，同时保持开发体验简单。

2.4 高效的数据转发

• Sidecar 机制： 每个 GPU 运行一个 Sidecar 守护进程，负责在组件间转发张量数据。
• 传输优化：
  • 节点内： 使用 Linux 共享内存（/dev/shm）直接读写，避免干扰 NVLink/NVSwitch 带宽。
  • 节点间： 通过 RDMA（UCX 库）进行传输，降低延迟。

3. 关键贡献

1. 首个通用 Any-to-Any 服务系统： 提出了第一个支持通用 Any-to-Any 多模态模型的分布式服务系统，打破了现有系统仅针对特定模态或架构的限制。
2. 组件解耦与独立扩展： 通过模型裂变技术，允许不同组件根据各自的负载和计算特性独立扩展（例如，为音频生成器部署更多副本，而 LLM 使用张量并行），显著提升了资源利用率。
3. 灵活的 Python 原生抽象： 提供了基于 Python 的任务抽象和记录 - 重放执行机制，使开发者能够用简单的代码表达复杂的计算图，同时系统自动处理数据依赖和调度。
4. 开源实现： 系统基于 Kubernetes 构建（约 2.3 万行 Python 代码），并集成了 OpenTelemetry 进行端到端请求追踪，已开源。

4. 实验结果

系统在两个 8 卡 NVIDIA A100-80GB 节点（支持 NVSwitch 和 RDMA）上进行了评估，对比基线为单体部署（Monolith）。

• 吞吐量提升：

  • 在 8 卡和 16 卡配置下，Cornserve 使 Qwen 2.5 Omni 的吞吐量分别提升了 3.09 倍 和 3.81 倍。
  • 对于 Qwen 3 Omni（30B 参数），单体部署因显存溢出（OOM）无法运行，而 Cornserve 通过组件解耦成功实现了高效服务。
  • 从 8 卡扩展到 16 卡时，吞吐量提升了 2.68 倍（超过线性扩展的 2 倍），这得益于更好的组件间负载均衡。

• 延迟降低：

  • 在 16 卡配置下，Cornserve 显著降低了 Qwen 2.5 Omni 的请求延迟。
  • P50、P95 和 P99 延迟分别降低了 3.24 倍、5.3 倍 和 5.79 倍。
  • 原因分析： 单体部署中组件串行执行导致阻塞，而 Cornserve 通过解耦消除了组件间的相互干扰，并允许音频生成器利用连续批处理（Continuous Batching）技术。

• 开销分析：

  • Sidecar 的数据转发开销并非主要瓶颈。跨节点 RDMA 传输 8MB 张量仅需 5-10ms，节点内共享内存传输开销类似。

5. 意义与展望

Cornserve 为 Any-to-Any 多模态模型的部署提供了强大的基础设施支持。它证明了通过组件解耦和动态路径调度，可以有效解决多模态模型中复杂的资源异构性和路径异构性问题。

• 对开发者的意义： 降低了构建和部署复杂多模态系统的门槛，开发者只需关注 Python 逻辑，无需手动处理复杂的分布式调度。
• 对研究的意义： 为未来更高效、更强大的 Any-to-Any 模型设计提供了基础平台，使得模型架构可以更加灵活地根据任务需求进行定制和扩展。

综上所述，Cornserve 不仅显著提升了多模态模型的推理性能和资源效率，也为下一代多模态 AI 系统的工程化落地奠定了重要基础。