随着搜索系统逐步引入多模态理解能力（如图文混合搜索），模型 serving 的复杂度急剧上升。Cornserve 的组件解耦设计使不同模态的编码器和解码器可以独立扩缩容，避免了 GPU 资源浪费。其基于 Kubernetes 的架构意味着可以直接融入现有云原生基础设施。对于正在规划多模态搜索能力的团队，这套架构设计思路具有很强的参考价值。
问题与动机
现有 serving 系统仅提供针对特定模型类型的「点方案」：vLLM 针对纯文本 LLM，xDiT 针对扩散模型。没有统一系统能高效处理 Any-to-Any 多模态模型（接受和生成文本/图像/视频/音频）。这类模型的关键挑战：不同请求调用不同计算路径，组件具有截然不同的扩展特性（如文本生成吞吐量是音频的 4 倍）。
方法概述
Cornserve 引入三层任务抽象（unit task/composite task/app），允许开发者用纯 Python 表达任意模型计算。通过「模型裂变」将模型在组件边界解聚，独立部署各组件。分布式运行时采用 record-and-replay 执行来动态确定请求调用的组件，同时通过共享内存（节点内）和 RDMA（跨节点）转发中间张量。
核心技术贡献
- 任务抽象与模型裂变：composite task 在纯 Python 中组合 unit task，通过裂变参数控制部署配置
- Record-and-Replay 执行：record 阶段返回占位符并记录调用；replay 阶段用真实结果执行，支持循环/分支等复杂控制流
- 高效数据转发：Sidecar 直接在生产者和消费者间转发张量，绕过控制平面。节点内使用共享内存避免占用 NVLink 带宽；跨节点使用 UCX RDMA
- 组件共享：多个 app 部署等效 unit task 时自动共享执行器副本，减少 GPU 消耗
实验结果分析
- 硬件：两台 8×A100-80GB 节点，NVSwitch + 400 Gbps 跨节点 RDMA
- Qwen 2.5 Omni：8 GPU 上 3.09× 吞吐量提升；16 GPU 上 3.81× 提升
- Qwen 3 Omni：单体部署 OOM 失败；Cornserve 从 8→16 GPU 实现 2.68× 提升（超线性）
- 延迟降低（Qwen 2.5 Omni，16 GPU）：P50 降 3.24×，P95 降 5.3×，P99 降 5.79×
- Sidecar 开销：跨节点 RDMA 转发 8MB 张量仅增加 5-10ms
局限与未来方向
Record-and-replay 要求确定性控制流；数据依赖分支需在 app 层处理；评测主要集中在 Qwen Omni 系列；跨节点开销在带宽敏感场景下可能成为瓶颈。
工业实践意义
随着搜索系统集成多模态能力（图文搜索、视频理解、语音交互），Cornserve 的解聚式 serving 方案具有前瞻价值。模型裂变使得不同组件可独立扩缩容——文本理解和图像处理可按各自流量比例配置资源。来自密歇根大学和 Cisco Research 的研究。