过去三年，大模型推理框架百花齐放：vLLM、SGLang、TensorRT-LLM、TGI……每个框架都有自己的内存管理、调度器、算子优化和生态。框架多本来是好事，落到企业部署上却成了麻烦：

• 模型挑框架：同一个模型，换一个框架就要重新做性能验证和调优
• 运维被绑架：不同模型跑不同框架，一套集群要维护多套引擎、多套监控指标、多套升级节奏
• 调优靠老师傅：每个框架的显存配置、调度参数、量化选型都要手工调优，「手工调优 CUDA Kernel」成了核心竞争力，而不是业务本身

这不是技术问题，是产业阶段问题——就像数据库的「百家争鸣」最终走向了标准化，大模型推理也需要自己的「标准化时刻」。

两个主角的来路

框架	出身	核心创新	定位
vLLM	UC Berkeley Sky Computing Lab，2023 年 6 月发布，2025 年 5 月加入 PyTorch 基金会	PagedAttention 分页显存管理	通用工业级平台：适配任意模型（稠密 / MoE / 多模态）与任意硬件
SGLang	UC Berkeley LMSYS.org，2024 年 1 月发布	RadixAttention 前缀缓存、PD 分离等	极致吞吐优化：复杂任务、多轮对话、高并发

一、v3.0：推理基建的「大一统」

在 2026 AI Infra Summit 上，vLLM 与 SGLang 社区联合发布了 Unified Inference Runtime v3.0。与此同时，阿里云 PAI、AWS SageMaker、火山引擎方舟等主流云平台宣布将该运行时作为大模型托管服务的默认底座。

这标志着 LLM 推理正式告别「手工调优 CUDA Kernel」的作坊时代。

所谓「统一」，拆开看是三层：

1. 统一前端：一套 OpenAI 兼容 API，模型怎么换、引擎怎么换，业务代码不变
2. 统一调度与内存管理层：把两家的调度器、KV Cache 管理、显存池化能力收敛成一套可插拔的通用层
3. 可插拔后端：vLLM 引擎、SGLang 运行时（SRT）作为可选的执行后端，按模型特性和业务场景选择，而不必迁移整套框架

对云平台来说，这意味着一个「默认底座」：任何模型上传，都能在这套运行时上开箱即跑，吞吐、延迟、弹性都是默认能力。

二、为什么「能合」：两大引擎的演进路径

统一不是合并代码，而是两家在底层思路上走到了同一套抽象。先看各自的演进。

1. vLLM 的路径：通用主义 + 架构重构

vLLM 的理念是「工业级通用平台」：无论模型多冷门、硬件多异构，都能无缝跑起来。它的演进有两条主线：

• PagedAttention：像操作系统管理内存一样管理 KV Cache。传统方式为每个请求按预估最大长度预分配连续显存，浪费严重；PagedAttention 把 KV Cache 切成固定大小的块（通常 16KB / 32KB）按需分配，配合两级缓存——GPU 显存里的活跃块缓存 + 主机内存里的待命块池，显存利用率大幅提升，单卡并发上限成倍增加
• V1 架构重构：2025 年 1 月发布 v1 alpha，核心是一次「架构大扫除」——把推理核心（EngineCore）与 API 层显式分离、多进程架构隔离；把 Block 管理与调度循环全面向 C++ 迁移，大幅降低主循环的 CPU 调度延迟。这让高并发下「CPU 调度赶不上 GPU 计算」的瓶颈被系统性消解

2. SGLang 的路径：极致优化 + 运行时统一

SGLang 走的是「把一个方向的吞吐榨到极限」的路线，它的运行时（SRT）集成了一整套先进优化：

• RadixAttention 前缀缓存：高并发场景大量请求共享系统提示词、多轮对话历史，命中缓存即免去整个 prefill 计算，TTFT 大幅下降
• 零开销 CPU 调度器：调度决策本身几乎不占 CPU 周期
• Prefill-Decode 分离：计算密集的 prefill 与访存密集的 decode 拆到独立服务，各自独立扩缩容
• 推测解码、连续批处理、分页注意力、TP / PP / EP：一个都没落下

3. 两家如何协作：内嵌与远程两种模式

SGLang 与 vLLM 的协作早已有实践基础：

• 内嵌模式：把 vLLM 作为 Python 库直接导入 SGLang 运行时进程，延迟最低，适合单机部署
• 远程模式：SGLang 运行时通过 HTTP 或 gRPC 调用独立部署的 vLLM 服务，两者各司其职、资源共享

v3.0 就是把这种「互相调用」升级成「同一套抽象之下的可插拔」——企业不再需要在两个框架之间做二选一，而是让模型自己选最合适的引擎。

三、统一后解决了什么：企业视角

对部署大模型服务的企业，v3.0 的四个直接收益：

1. 一个底座跑所有模型：稠密模型、MoE（DeepSeek 类）、多模态，一套运行时全接住
2. 摆脱框架绑架：换模型不用换框架，升级引擎不用重写业务，运维团队只需要会一套监控与一套升级流程
3. 全局资源池化：推理从「单请求视角」提升到「全局资源池化视角」——显存按块动态分配、请求随到随进，吞吐接近理论极限
4. 云平台默认能力：在阿里云 PAI、AWS SageMaker、火山方舟上，这一切是「开箱即用」的默认项，而不是要自己搭的实验室

四、对部署决策的意义：用 API 还是自建？

v3.0 真正改变的是「自建的门槛」：过去自建推理集群的最大成本是「框架选型 + 调优」，现在这部分被运行时标准化大幅抹平，剩下的是 GPU 成本与运维。于是决策变得更清晰：

• 私有化、强合规、极致定制：自建，用 v3.0 这类统一运行时做底座，团队只需关注业务与模型本身
• 追求成本与体验的平衡：直接使用云厂商托管服务（如火山方舟官方 API），统一运行时是平台的默认底座，企业侧零框架成本，还能叠加平台的冷热分级加载、弹性伸缩、上下文缓存等能力（热模型常驻 GPU / 温模型共享 / 冷模型按需加载，综合成本可降 40% 量级）

五、总结

Unified Inference Runtime v3.0 的意义，不在「某个框架变强」，而在推理基建走向标准化：

1. 终结框架战国：vLLM + SGLang 联合发布统一运行时，阿里云 PAI、AWS SageMaker、火山方舟共同背书为默认底座
2. 统一 = 前端统一 + 调度内存统一 + 后端可插拔：模型挑引擎，而不是企业挑框架
3. 两大引擎各归其位：vLLM 管通用与稳定（V1 架构、C++ 调度），SGLang 管极致吞吐（RadixAttention、PD 分离），可插拔让两者互补
4. 企业侧的最优解：自建用统一运行时做底座，省心用云托管——平台已经把 v3.0 做成了默认能力

一句话：推理框架的「手工调优时代」结束了，LLM 推理正式进入「平台默认能力」时代。对于大多数业务团队，接下来的问题不再是「选 vLLM 还是 SGLang」，而是「用哪个平台的默认底座」——把框架问题交给平台，把精力放回业务。

关于向量云：框架问题，平台消化

向量云（南京）科技有限公司依托字节跳动火山方舟官方授权，专注大模型应用落地：

向量云能力	说明
官方 API 免部署	火山方舟官方 API 与官方 Key 直连，统一推理运行时是平台默认底座
独享接入点	缓存与配额不被公共池挤占，高峰不排队
低折扣 Token	专属折扣价，用量越大越划算
缓存隔离降本	上下文缓存红利稳定落袋
计费灵活	按量计费、即用即扣、注册充值 10 元起
协议兼容	OpenAI 兼容协议，业务代码几乎零改动

接入方式：注册后获取官方 API Key，把 base_url 指向向量云接入点即可直接调用火山方舟官方模型。