运行关键任务推理所需的一切(嘉宾:DeepSeek v3 + SGLang)
摘要
DeepSeek V3 让前沿级质量的开放权重模型具备了商业意义,但前提是运营方能消化一个6710亿参数的系统工程难题。 录制时,它在 LM Arena 以1319分排名第7,超过 Claude 3.5 Sonnet 和 o1-mini;Yineng Zhang 认为,256专家 MoE 是「开源 AI 的游戏规则改变者」(“a game changer for open-source AI”)。
需求与其说来自 Llama 用户升级,不如说来自希望降低价格、减少限流、缩短首 token 时间,或掌控模型而非依赖可能改变模型的 API 供应商的 Claude 客户。 因此,DeepSeek V3 服务的是有明确生产约束的专有模型用户,而不只是开放模型试验者。
眼下的瓶颈是内存和精度。 Yineng 表示,8张 H100 提供640GB显存,仍无法服务该模型;在同一解释中,他估算 FP8 权重为「我觉得是71GB」,另需为 KV-cache 留出内存。Baseten 因此选择 H200 或多节点部署,而块级 FP8 需要普通 CUDA 或 cuBLAS 路径不支持的内核。
Baseten 的商业差异化在于按用量计费的专属推理服务,而非共享式 token 端点。 客户指定的是延迟、吞吐、P95/P99、安全、合规和地域,而不是某个偏好的 GPU SKU;Baseten 表示,在质量必须保持不变时,不会背着客户量化模型。
SGLang 在常见场景下性能优于 vLLM,同时比 TensorRT-LLM 更易用。 其针对 DeepSeek 的 MLA、数据并行注意力和块级 FP8 工作,使其成为 DeepSeek 推荐的推理引擎;radix caching 与缓存感知路由则通过应对重复 prompt 和多副本来压低延迟。
Amir Haghighat 的核心判断是,关键任务推理需要3根各自不可或缺的支柱:模型级性能、快速跨地域横向扩容,以及面向工作流的开发者工具。 “vLLM 等于生产环境”是误解;生产环境还意味着从崩溃中恢复、承接流量突增、守住尾部延迟、规避 noisy neighbor,并在不同云上找到 GPU 容量。
仅仅因为框架暴露了 speculative decoding 或 fine-tuning 功能,并不意味着它们可以开箱即用。 Draft model 以及 Medusa、EAGLE 头仍需训练才能获得较高接受率;Amir 对 fine-tuning 的判断是「短期内不行,长期来看也许吧」,主持人则怀疑推理模型是否会消除定制需求。
精读
1. DeepSeek V3 让开放权重成为可信的专有模型替代品
DeepSeek V3 在圣诞节后不久发布,是一个6710亿参数、256专家的细粒度 MoE,使用15万亿 tokens 训练,采用原生 FP8 混合精度训练、多 token 预测、源自 DeepSeek V2 的多头潜在注意力,以及从 DeepSeek R1 蒸馏的合成推理数据。Yineng 表示:「我觉得这是开源 AI 的游戏规则改变者」(“I think it’s a game changer for open-source AI.”)。
录制时,其 LM Arena 得分为1319,排名全球第7,低于 full o1、Gemini 2 和最新 GPT-4o,但高于 o1-mini、Grok 2、Gemini 1.5 Pro 和 Claude 3.5 Sonnet。主持人将其称为2025年1月最领先的开放权重模型。
主持人将这次发布放在中国开放权重模型扩张的大趋势中观察:Tencent 的 Hunyuan Large 于11月发布,Hailuo 的 MiniMax Text 于1月发布,两者参数量都超过4000亿。
Amir 的关键商业观察是,市场兴趣通常不是来自正在从某个特定开源模型升级的团队,而是来自 Claude 用户:他们面临限流、价格高、延迟或首 token 时间要求,以及担心 API 供应商可能改变底层模型等问题。
主持人认为,Llama 405B 的推理性能提升往往不足以覆盖其成本。Amir 回应称,对 DeepSeek 的兴趣主要来自遭遇这些生产痛点的专有模型用户,但其中一部分需求仍停留在探索阶段,尚未部署。
2. 6710亿参数 MoE 把内存、精度和内核变成产品约束
Baseten 被描述为首家将 DeepSeek V3 上线的推理云初创公司,这得益于其 H200 集群、与 DeepSeek 团队的合作,以及早期的 SGLang 支持。主持人表示,8张 H200、每张配备141GB显存和4.8TB/s带宽,在计入 KV-cache 需求后可以运行 FP8 推理。
Yineng 表示,8张 H100 提供640GB显存,但仍无法服务该模型。在同一解释中,他估算 FP8 权重为「我觉得是71GB」,并称还需要为 KV cache 预留额外内存。因此,Baseten 选择了 H200 或多节点部署;DeepSeek V3 是他们此前遇到的首个这一规模的模型。
发布的权重采用块级 FP8,而默认路径是 BF16。Yineng 表示,即便 CUDA 或 cuBLAS 也不支持这种块级格式,实施者因此需要转向 Triton 或 CUTLASS 内核;他还称当时 TensorRT-LLM 尚不支持 FP8。由于加载这个超大模型耗时极长,调试非常困难,不过 Amir 认为问题在于速度慢,而非概念复杂。
Yineng 报告称,FP8 版本的 GSM8K 得分接近94.6;在他的比较中,这一成绩高于包括 Llama 405B 在内的其他开源 LLM。Amir 预计原生低精度训练会逐渐普及,并试探性提到一项消融实验:收益在接近6-bit精度时仍然存在,但更小的格式可能就会走得太远。
主持人没有放弃对 MoE 的反例:Mixtral 一度被视为 MoE 浪潮的先声,但随后一年大部分时间仍由 dense 模型主导。Yineng 预计 MoE 推理优化将变得不可或缺,并提到 Baidu 和 ByteDance 内部存在类似架构。他推测 Llama 团队曾尝试训练 MoE 但失败了,并称其基准分数低于 dense 模型,这解释了为什么没有 Llama MoE 发布。
3. 专属推理定价服务的是服务保障,而非 token
Baseten 有意不为热门模型销售共享端点。其典型客户带来定制权重或开放权重,但需要专属资源、可预测延迟、地域灵活性,以及不受 noisy neighbor 影响的环境。对热门模型采用按 token 计费的 API,服务的是另一类客户;如果产品依赖专属推理,需求完全不同。
客户通常指定质量、延迟、吞吐、首 token 时间和成本,而不是点名要求 H200。GPU SKU 是实现每百万 tokens 或每张图片价格、并在流量突增时维持 P95/P99 性能的工具,而不是为了宣传库存本身。
模型保真度也是这份契约的一部分。Amir 表示,Baseten 不会背着用户量化模型;量化工具和评测会与客户工程师共同使用。Baseten 的 speculative decoding 方法之所以有吸引力,在于它能保证输出不变,而量化做不到这一点。
定价按照资源消耗执行,具体有两种形态:由 Baseten 在多个公有云上托管基础设施,或在客户的 AWS、GCP 等云环境内提供托管推理。客户可以跨云组合承诺容量,将同一个模型横向复制到不同云上,并在承诺额度用尽时选择溢出到 Baseten 的容量。
4. SGLang 正在赢得那些既要性能、又要可改造性的场景
SGLang 约在2023年8月起步,最初是用于编写 LLM 程序的前端语言。Radix caching 于2024年1月推出,约束解码和 jump-forward 于2月推出,团队在6月或7月左右开始推动其成为完整推理引擎。Yineng 用一句话概括其节奏:「我们就是边做边发」(“We just built and shipped.”)。
产品设计上的差距很清楚:vLLM 易于使用,但团队认为它难以干净地扩展,之后速度也更慢;TensorRT-LLM「快得惊人」,却不易进行二次开发。SGLang 试图把性能和可维护性结合起来;据称,2024年年中的一次对比中,其吞吐量约为 vLLM 的3倍,之后 vLLM 完成了重构。
针对 DeepSeek,SGLang 加入了 MLA 优化、0.4版本的数据并行注意力、零开销 CPU 调度、缓存感知路由,以及后来被 vLLM 采用的块级 FP8 内核。这些投入让 SGLang 成为 DeepSeek 团队推荐的引擎,而不只是另一个兼容后端。
Yineng 对框架的排序仍然取决于场景:极度看重延迟的工作负载选择 TensorRT-LLM;既需要定制又需要优化时选择 SGLang;看重成熟社区时选择 vLLM。SGLang 在7月后从约2000颗 GitHub stars 增长到超过7000颗;其创建者在 xAI 任职,也部分解释了它在那里获得的采用。
Baseten 的 Truss 可以在 TensorRT-LLM、vLLM 和 SGLang 之间打包并部署模型。Amir 表示,Baseten 还构建了自己的 Triton Inference Server 变体,以提升性能和可靠性;他们把这些框架当作可以互换的工具,而不是将客户锁定在某一个框架上。
5. 缓存复用与约束解码把重复结构转化为速度
RadixCache 是 SGLang 的前缀缓存机制,使用大小为1的 block,而 vLLM 和其他框架使用的 block 大小为32。Yineng 的因果判断很直接:更细粒度的匹配能提高缓存命中率,尤其适用于专属客户反复发送有限组 system prompt 或共享前缀的场景。
当同一个模型拥有几十个副本、每个副本持有不同的 KV-cache 状态时,单纯缓存已经不够。Baseten 因此增加了缓存感知负载均衡:路由请求时同时参考可能的前缀复用、队列深度和副本位置。Amir 表示,这实质性改善了客户延迟。
对于结构化输出,SGLang 可以通过 Outlines 或 XGrammar 将 JSON schema 转换为有限状态机。如果允许的路径使多个 token 变得可预测,jump-forward 就能用一次 prefill 替代多个解码步骤。Yineng 基于性能偏好 XGrammar,并指出 TensorRT-LLM 也已集成该工具。
主持人追问:如果 jump-forward 同时提升速度和结构合法性,为什么不是普遍配置?答案涉及维护复杂度。它与 CPU overlap 及其他优化交互不佳,因此 SGLang 默认将其关闭。其 API speculative-execution 功能是前端的控制流抽象,而不是后端解码优化。
6. 生产级推理建立在3根彼此独立的支柱上
Amir 的第一根支柱是模型级性能:内核、服务框架、MLA,以及 draft model、Medusa 或 EAGLE 等 speculative decoding 技术。框架选择在这里很重要,但它只覆盖一组硬件上的一个模型。「每一项单独来看都是必要条件,但都不是充分条件。」
当流量压垮单个副本时,第二根支柱才开始发挥作用。从1个实例扩展到5个、10个或100个,「不是 ML 问题」,也「不是 PyTorch 问题」,而是基础设施问题。单个模型可能需要200个副本,每个副本消耗2张或4张 H100,甚至占用整台节点,超出单一区域的可用容量。
因此,Baseten 在单个 Kubernetes 集群之外构建了跨地域、跨云复制。Amir 描述过这样的模型部署:GCP East 有50个副本,AWS West 有80个,Oracle 的伦敦区域还有更多副本。他认为,仅靠 Kubernetes 自动扩缩容无法提供这些工作负载所需的速度或可靠性。
第三根支柱是通过强大的开发者体验,支持复杂、多步骤、多模型的工作流。Amir 表示,市场正在转向这类工作负载,而框架只是第一根支柱的一部分。
7. 单个库不是关键任务推理产品
Yineng 明确区分了 vLLM、SGLang、LightLLM 和 TensorRT-LLM 等开源库与完整产品方案。Amir 的概括是:「vLLM 等于生产环境」是错的(“vLLM equals production”);生产环境还需要可靠地从崩溃中恢复、快速扩容,并在流量突增时持续维持 P95/P99 延迟。
Amir 以 AI 电话呼叫为例,说明这是一种需要低延迟协调的多步骤、多模型工作负载。更广泛地说,客户关心推理是否持续可靠、可重复、安全,在需要时符合 HIPAA,位于规定地域内,并且不受另一客户流量影响。
他对关键任务的定义很严格:如果推理变慢或宕机,「客户的主要产品就会变慢或宕机」。在新兴的实时应用中,路由决策很重要,因为50或100毫秒都很关键;因此,基础设施、合规和地域都会成为模型产品特性。
8. 优化仍需训练,fine-tuning 或许不会消失
EAGLE、Medusa 和 draft-target speculative decoding 都不是打开一个开关就能完成的加速。Yineng 表示,SGLang 和其他开源框架支持业界领先的 EAGLE 性能,而 TensorRT-LLM 支持 EAGLE-1,但不支持 EAGLE-2。客户仍需训练 draft model 或新增的头,使其模仿目标模型;最终吞吐增益取决于 token 接受率。
传统定制在生产环境中仍然存在:Amir 提到针对医疗术语进行 fine-tuning 的 Whisper,以及利用 human-in-the-loop 数据训练、用于医疗文档提取的 LLM。能力更强的推理模型或许能从少量示例中复现这类行为,但他尚未看到当前 fine-tuning 需求下降。
Amir 的不确定性仍未改变:推理能力可能降低 fine-tuning 的需求,但「短期内不行,长期来看也许吧」,其成本效益仍未解决。主持人更为怀疑,认为 prompt 更容易修改,并不意味着完整 fine-tuning 或参数高效 fine-tuning 会消失。
运营结论是务实的,而非预测性的:「先解决今天的问题。」即便某个市场在2年后消失,为其客户完成接入也能让供应商了解未来需求,并获得提前构建相应能力的机会。
核验说明
- 访谈文字同时记录了 Yineng 关于8张 H100 无法服务该模型的说法,以及他对 FP8 权重「我觉得是71GB」的估算。本摘要保留了这两项说法,没有用推导出的数值替换访谈中的原始数字。