成本陷阱（中）：Token工厂难以直面的投产账

文章目录

• • 一、先给结论：从30%到75%
  • 二、六大核心举措
  • • 举措一：换掉vLLM，用SGLang——性价比最高的一步
    • 举措二：集成模厂开源的核心组件
    • 举措三：自研定制算子——追平模厂的关键一步
    • 举措四：Prefill-Decode分离架构
    • 举措五：推测解码——"免费"的1.5-1.8倍加速
    • 举措六：资源调度与混部优化
  • 三、能追平多少？
  • • 可以追到的水平
    • 几乎不可能追平的部分
    • 存在"局部超越"的可能
  • 四、三道绕不过去的坎
  • 五、谁该追，谁该停：按角色拆解决策
  • • 5.1 技术决策者：自建还是调API，看预算说话
    • 5.2 部署/推理工程师：先做哪一步最划算
    • 5.3 AI创业者/独立开发者：不懂GPU也能避开坑
    • 5.4 云厂商/IDC同行：计费与定价怎么设计
    • 5.5 投资/咨询/研究人员：看懂一家MaaS公司的成色
  • 六、国产芯片的机会在哪
  • 结语

上一篇留了一个问题没答：如果真砸钱做深度优化呢？能追平模厂吗？

答案是：能把效率系数η从0.3追到0.7-0.75，达到模厂的80%左右。但最后那15%的差距，不是钱的问题，是身份的结构性限制。

六项核心优化、三道绕不过去的坎、一份按角色拆的决策表——这篇全拆给你看。

一、先给结论：从30%到75%

上一篇我们拆了四笔账：通用框架部署开源模型，推理效率只有模厂的30%，纯API转售在不提价的前提下数学上不可能盈利。

那如果真下决心投入工程团队做深度优化，能追平多少？这篇文章就是回答这个问题的。先给全景结论，再拆过程。业界用"效率系数η"来衡量MoE模型的实际吞吐——η越高，单位token的GPU成本越低（下表以模厂当前生产水平η≈0.85-0.9为对标基准，上一篇给出的0.7-0.9区间含早期版本）：

"月度成本/模厂倍数"这一列是给预算决策者看的：如果你用通用框架部署（η≈0.3），你的GPU月度账单是模厂的3倍；追到η≈0.7，账单降到1.2-1.3倍——此时配合垂直场景溢价或生态交叉补贴，MaaS业务有望盈亏平衡。

下面逐个拆解每个阶段的核心举措。我会按"性价比从高到低"的顺序来讲。

二、六大核心举措

举措一：换掉vLLM，用SGLang——性价比最高的一步

vLLM和SGLang都是开源推理框架——把模型权重变成可调用API的中间层软件，类似"数据库引擎"。vLLM使用最广泛，SGLang是DeepSeek官方推荐框架。

这是整条优化路径上"投入产出比"最高的一步。根据2026年的公开benchmark数据，SGLang在DeepSeek系列模型上的推理速度是vLLM的3.1倍。

为什么差距这么大？

1. 前缀缓存机制的代际差异。 vLLM只做单请求内的缓存复用，SGLang用RadixAttention实现了跨请求的前缀匹配。什么意思？假设100个用户都在问关于同一份文档的问题，vLLM会为每个用户独立处理文档的前缀部分，SGLang则自动识别并复用已计算好的前缀。在多轮对话、RAG检索等场景下，SGLang的吞吐可达vLLM的6.4倍。

2. 调度开销的量级差异。 vLLM每步推理都需要Python层参与调度，这意味着每生成一个词，CPU和GPU之间就要来回通信一次。SGLang通过CUDA Graph（将一系列GPU操作预编译为一张图）和算子重叠，实现了接近零的调度开销。

3. DeepSeek架构的专项适配。 SGLang对MLA注意力、MoE专家并行、MTP多token预测等DeepSeek特有的架构特性做了深度适配，而vLLM的支持相对滞后。

实际收益与成本换算： 仅这一步，就能将推理效率从模厂的30%左右提升到50%-60%。翻译成钱：同样一张H800（2美元/小时），vLLM部署的每百万token GPU成本约0.038美元，切换SGLang后降到约0.019-0.023美元——省了40%-50%的GPU成本，且不需要改一行模型代码。（注：3.1倍为特定场景峰值吞吐，实际生产环境因负载混合，成本下降幅度约40%-50%）

举措二：集成模厂开源的核心组件

DeepSeek在2025年"开源周"中发布了多个核心优化组件，云厂商可以直接集成：

各组件解决什么问题？

• FlashMLA解决的是"显存压缩红利打折"问题——它针对MLA架构做了深度优化，能在Hopper架构GPU上实现3000 GB/s的内存带宽利用率和580 TFLOPS的计算性能
• DeepEP解决的是"通信开销吃掉收益"问题——它是第一个专为MoE设计的EP通信库，实现了不占用GPU计算资源的通信-计算重叠，以及原生FP8数据分发
• EPLB解决的是"专家负载不均衡"问题——通过实时监控专家使用频率，动态地将热门专家复制到负载较低的GPU上
• DeepGEMM解决的是"FP8精度支持不完整"问题——一个干净的FP8矩阵运算库，在Hopper架构上达到1350+ TFLOPS

实际收益： 集成FlashMLA+DeepEP+EPLB后，MoE的效率系数η可从0.3提升到0.5-0.6。但需要注意，这些组件对硬件环境有要求（如DeepEP需要NVLink+RDMA网络），集成过程需要专业工程团队进行适配和调试。

举措三：自研定制算子——追平模厂的关键一步

开源组件提供了"及格线"的优化，但要做到"优秀"，需要自研定制算子（Kernel）。算子（Kernel）是运行在GPU上的底层计算程序，可以类比为"为GPU手写的专用指令"。大模型的每一次计算——注意力计算、矩阵乘法、数据搬运——最终都要通过算子来执行。通用推理框架使用标准库提供的算子（类似"通用刀具"，什么都能切但都不够锋利），而定制化算子是为特定模型架构和特定GPU型号手写的专用程序（类似"专用模具"，只为某道菜打造但效率极高）。两者的性能差距可以达到数倍。

这是差距最大的环节，也是技术门槛最高的环节。

模厂的算子并非不可超越。

一个值得关注的案例：美国推理服务商Together AI自研了ThunderMLA——一个将MLA注意力的两次算子启动融合为单次"MegaKernel"的实现。根据其公开数据，ThunderMLA在代表性Decode负载上比DeepSeek自己的FlashMLA还快20%-35%。

这说明一个关键事实：在特定算子层面，第三方完全有可能超越模厂。原因是模厂的算子需要兼容多种场景和配置，而第三方可以针对自己的特定硬件和负载做极致特化。

但要做到这一点，需要什么？

• 深入理解GPU内存层次结构（共享内存、寄存器、L2缓存的协同工作）
• 掌握现代GPU的异步指令（WGMMA矩阵乘法指令、TMA张量内存访问指令）
• 具备全栈性能分析能力（从GPU驱动行为到单个算子的执行时间）
• 能够手写汇编级或PTX级代码，精确控制指令调度

这类工程师在市场上极为稀缺。一个能写出超越模厂算子的团队，至少需要5-10名资深CUDA工程师，培养周期2-3年。

实际收益与成本换算： 自研算子可以将η从0.6推到0.7-0.75。GPU月度成本从模厂的1.5倍降到1.2-1.3倍。但投入门槛极高——10-20人工程团队，12-18个月周期，2000-4000万人力成本。只有年推理预算千万级以上的厂商，这笔投入在经济上才成立。

举措四：Prefill-Decode分离架构

传统推理将"理解输入"（Prefill）和"生成输出"（Decode）放在同一组GPU上执行。但两者的计算特征截然不同：

• Prefill是计算密集型（需要一次性处理整个输入，大矩阵乘法），需要高张量并行（TP）度来降低首字延迟
• Decode是访存密集型（逐字生成，小批量计算），需要高专家并行（EP）度来提升吞吐

PD分离架构将两类任务分配到不同的GPU池，各自独立优化。

实际案例——百度百舸在天池超节点上的实践：

百度百舸基于SGLang推理框架和PD分离架构，对DeepSeek R1模型进行了深度适配：

• Prefill侧：采用16卡作为一个计算单元，TP4+SP4并行策略。通过双流优化（计算和通信交替执行）和通信策略优化（从AllReduce+AllGather改为AllGather+AlltoAll，通信量减少60%），吞吐提升约20%
• Decode侧：采用32卡作为一个计算单元（占满一个超节点），EP32专家并行。通过共享专家与通信算子的并行调度，TPOT降低约7%
• 长序列场景：针对128K输入，通过扩大TP范围到TP16或TP32，TTFT（首字延迟）降至1/5以下，单卡吞吐提高80%

举措五：推测解码——"免费"的1.5-1.8倍加速

大模型正常是逐字生成的——每生成一个词，都要完整跑一遍模型的所有层。推测解码（Speculative Decoding）用一个小模型"猜"接下来几个词，再让大模型一次性验证，从而一次生成多个词。

用通俗的方式理解：

正常情况下，你写文章是一个字一个字写的，每写一个字都要重新思考一遍。推测解码相当于你先快速草拟3-4个字，然后回头检查一遍——如果对了就保留，错了就重写。由于"猜对"的比例通常不低（70%-80%），整体速度大幅提升。

DeepSeek的MTP（Multi-Token Prediction）模块原生支持这一机制。SGLang集成的EAGLE-3推测解码在DeepSeek模型上实现了：

• 单请求场景（batch=1）：Decode速度提升1.8倍
• 批量场景（batch=32）：Decode速度提升1.5倍
• 接受率约78%（猜对的比例）

成本换算： 这是一项"免费"的性能提升——不增加GPU，不改模型权重，纯靠推理引擎的调度优化。1.5-1.8倍加速意味着同样数量的GPU可以多服务50%-80%的用户，单位token成本直接下降33%-44%。

举措六：资源调度与混部优化

这是"非技术性"但影响巨大的优化方向：

1. 推理-训练混部。 借鉴模厂策略，白天全部GPU做推理，夜间释放部分GPU做训练或离线任务。实现这一点需要：

• 精准的流量预测模型（基于历史数据预测各时段请求量）
• 快速的资源切换能力（从推理模式切换到训练模式的时间控制在分钟级）
• 训练任务的弹性调度（能在被抢占时优雅退出）

从计费系统角度：混部能力直接影响你的资源包定价空间。如果你能做到70%以上的GPU利用率，你就可以在"按量计费"上给出更有竞争力的价格，同时保持毛利。反之，55%的利用率意味着你在为45%的空闲时间买单——这部分成本要么自己扛，要么转嫁给客户（但客户会跑）。

2. 跨可用区调度。 利用时区差异，将推理负载在多个地域之间动态迁移，提升整体利用率。

3. KV缓存硬盘存储。 将热门prompt的KV缓存持久化到SSD，命中时跳过Prefill计算。DeepSeek生产环境中56.3%的请求命中了这一缓存——这意味着超过一半的请求省掉了最耗计算量的Prefill阶段。

三、能追平多少？

六大举措讲完了，回到最核心的问题：到底能追平多少？

可以追到的水平

通过前三个阶段的优化（换SGLang→集成开源组件→自研算子），云厂商可以将效率系数η提升到0.7-0.75，即达到模厂的80%左右。 此时同样硬件下的服务成本约为模厂的1.2-1.3倍——虽然仍有差距，但已经进入了"可竞争"的区间。在这个效率水平上，如果配合垂直场景溢价或生态交叉补贴，MaaS业务有望实现盈亏平衡。

几乎不可能追平的部分

要追平到模厂的85%以上，几乎不可能仅靠"部署方"的身份实现。 最后15%的差距来自三个结构性因素：

1. 模型-硬件协同设计（Co-design）。 模厂在设计模型架构时就考虑了特定硬件的特性。例如MLA的压缩维度与GPU Tensor Core的矩阵计算单元尺寸有特定的映射关系，MoE的专家数量与GPU互联带宽有匹配关系。这些"从模型到芯片"的联合优化，部署方拿到的是已经定型的模型架构，无法事后修改。

2. 内部未公开的优化。 模厂开源的是"大部分"而非"全部"。一些涉及商业核心竞争力的工程细节——如特定的缓存淘汰策略参数、调度系统的调优经验——并未完全公开。这些"暗知识"需要在大规模生产环境中长期积累。

3. 规模效应。 模厂的生产流量远大于一般云厂商。大规模流量带来双重好处：一是batch填充效率更高（更多并发请求意味着每个batch更"满"），二是缓存命中率更高（更多用户意味着prompt前缀重复的概率更大）。

存在"局部超越"的可能

不过有一个有意思的反例。Together AI的ThunderMLA比DeepSeek自己的FlashMLA快20%-35%——这说明：在特定算子层面，第三方完全有可能超越模厂。 但这种超越是"点状"的——单个算子快了，不代表整体系统快了。模厂的优势在于全链路协同优化，而非单个算子的极致。

四、三道绕不过去的坎

上面说的都很美好，但实际干起来，有三道绕不过去的坎：

约束一：人才稀缺。 能写出高性能CUDA算子的工程师，全球可能不超过数千人。资深者年薪通常在百万元级。即使不追求自研算子，仅完成第二阶段（集成开源组件）也需要熟悉GPU编程、分布式系统和网络优化的工程团队。

约束二：投入回报周期。 从零做到第三阶段（η≈0.7），需要10-20人工程团队，12-18个月周期，2000-4000万人力成本。如果MaaS业务的年收入做不到这个量级，这笔投入在经济上不成立。

约束三：模厂在持续迭代。 你在追赶的同时，模厂也在进步。DeepSeek从V2到V3到V4，每一代都在架构和工程上迭代。你追的是"移动的靶"——当你追到V3的70%时，V4已经发布了，新的架构特性又带来了新的优化空间和新的差距。

说完约束，接下来我想按角色分别说几句。不同位置的人，从这套分析里拿走的结论应该不一样。

五、谁该追，谁该停：按角色拆解决策

5.1 技术决策者：自建还是调API，看预算说话

作为CTO/技术VP/基础架构负责人，你的核心决策是**“我的团队应该做到哪个优化阶段”**。这个决策取决于你的月度推理预算和工程团队能力：

关键判断标准：如果自建的推理效率达不到模厂的50%（月预算5万以下、无工程团队），加上运维和隐性成本后，自建的总成本几乎必然高于直接调API。此时应该将工程资源投入到业务差异化——行业知识、数据处理、应用层体验——而不是在推理基础设施上与模厂硬碰硬。

5.2 部署/推理工程师：先做哪一步最划算

如果你是MLOps/AI Infra工程师，日常与GPU显存和吞吐打交道，以下是最具性价比的优化优先级——按"单位工时换来的吞吐提升"排序：

实操建议：P0-P4是"中等门槛"举措，一名有经验的MLOps工程师在1-2个月内可以全部落地，η可到0.5-0.6。P5需要一定的监控基础设施。P6是"高门槛"举措，只有大型厂商才值得投入。

5.3 AI创业者/独立开发者：不懂GPU也能避开坑

如果你是AI产品创始人或独立开发者，预算有限，怕选错卡浪费钱——以下是一个不需要理解任何技术细节的决策框架：

第一步：算清楚你的月推理预算

• 月预算<5000元：直接调模厂API（如DeepSeek V4-Flash，输出2元/百万token），5000元可以买25亿输出token，够中小应用用很久
• 月预算5000-5万：继续调API。自部署的隐性成本（运维+闲置+调试）会吃掉你以为省下的钱
• 月预算5万以上：开始考虑自部署，但前提是你有数据隐私、定制化、离线运行等API无法满足的刚需

第二步：如果决定自部署，记住三个数字

• 用SGLang不要用vLLM（快3倍，同样配置）
• H800单卡可跑70B模型（INT4量化下），671B模型至少需要4节点32卡
• GPU利用率低于50%就是在亏钱，夜间流量不到白天的20%就考虑混部

第三步：避坑清单

• 不要买H20跑MoE模型——通信带宽不够，稀疏激活的收益会被吃掉
• 不要用vLLM默认配置上生产——调度开销大，缓存不跨请求
• 不要忽视闲置成本——GPU不是"不用就不花钱"，包月制的卡24小时都在计费
• 不要只算GPU租金——存储、网络、运维至少加15%-20%

5.4 云厂商/IDC同行：计费与定价怎么设计

作为同行，你可能更关心的是：这些技术差距如何反映到计费系统和定价策略中？

计费粒度的选择：大模型推理的流量波动远大于传统云服务。按秒计费看似对客户友好，但实际上让云厂商承担了全部的闲置风险——客户用完就释放，GPU空着还在计费。资源包（承诺消费量换折扣）是对冲这个风险的工具，但MaaS场景下客户也不愿意签长期承诺，因为他们的下游收入也不确定。

定价锚定效应：模厂的定价成为了市场的"天花板"。任何高于模厂的定价都会流失客户。这意味着云厂商的定价空间 = 模厂定价 – 自身成本。如果自身成本是模厂的3倍（η≈0.3），定价空间是负的——必须靠补贴。追到η≈0.7，自身成本降到模厂的1.2-1.3倍：按模厂价格定价仍会亏损20%-30%，按更低定价亏损进一步扩大；只有把成本压到接近模厂水平（η≈0.85以上），按模厂价格定价才能接近盈亏平衡，而要拿到10%-20%毛利则必须配合垂直场景溢价或生态交叉补贴。

混合计费策略：建议采用"按量计费+资源包+预留实例"的三层结构。按量计费覆盖弹性需求（高单价低承诺），资源包覆盖稳定需求（中单价中承诺），预留实例覆盖大客户（低单价高承诺）。这比纯按量计费能提升15%-20%的GPU利用率。

5.5 投资/咨询/研究人员：看懂一家MaaS公司的成色

对于关注大模型赛道的投资人和分析师，本文的分析提供了一个评估MaaS公司竞争力的结构化框架：

核心判断：纯API转售的MaaS公司（收入100%来自token计费、无自研优化能力、η≤0.4）在当前市场定价下几乎不可能盈利。具有投资价值的MaaS公司，必须具备"API以外的收入来源"或"显著高于行业平均的推理效率（η≥0.7）"。

六、国产芯片的机会在哪

最后说一个跟主线相关但角度不同的话题。

当前国产AI芯片在生态适配方面正在快速进步，但仅做到"能跑开源模型"是不够的。模厂的超低成本不仅来自芯片性能，更来自模型架构与芯片特性的深度协同设计。

国产芯片厂商面临的挑战是：开源推理框架（vLLM、SGLang）的优化主要集中在NVIDIA GPU上，国产芯片需要额外投入大量工程来做适配。如果只是通过翻译层"兼容"运行，推理效率会大打折扣。

真正的机会在于：与模厂联合设计，实现"模型架构-芯片特性-推理引擎"的三层协同优化。谁能在国产芯片上跑出接近NVIDIA生态的推理效率，谁就能在国产替代浪潮中获得最大的市场份额。

结语

回到梁文锋那句话——“要把成本做到同样低更是难上加难”——这篇文章算是给出了一个量化验证：

难，但没有难到不可能。 通过系统性的深度优化，云厂商可以将效率系数η从0.3追到0.7-0.75。代价是一支专业工程团队、12-18个月持续迭代、数千万级研发投入。回报是：进入"可竞争"区间，让自建推理在经济上成立。

但追平模厂，确实难上加难。 最后15%的差距——模型-硬件协同设计、内部未公开优化、规模效应——是"部署方"身份的结构性限制，不是砸钱能解决的。

我自己的最终判断是：不是所有云厂商都需要追平模厂。更理性的策略是根据自己的业务定位和工程能力，选择适合自己的效率水平——

• 月推理预算<5万：直接调API，别碰推理基础设施
• 月推理预算5-50万：轻量自建到η≈0.5，靠场景差异化获得溢价
• 月推理预算50-500万+有工程团队：深度优化到η≈0.6，做垂直MaaS
• 月推理预算500万以上+有CUDA团队：追求η≈0.75，做通用MaaS

选择比努力更重要。 认清自己的能力边界，选对自己的位置——是做差异化竞争者、生态集成商还是算力提供商——比盲目追求"追平模厂"更有战略意义。

但一个更深层的问题随之而来：既然怎么算都亏，为什么大厂还在拼命部署？中小厂商又为什么不能停下来？Token生意的未来到底往哪走？这是下一篇要聊的。

下一篇预告：《亏钱也要部署：开源大模型的真实逻辑与Token的未来》

关注本系列，下篇继续拆。 觉得有用的话，转发给你身边正在做大模型部署决策的朋友。

本文为系列第三篇。 系列第二篇《成本陷阱（上）：开源模型的蜜糖，Token工厂的砒霜！》系统分析了四大性能损失和MaaS"死亡螺旋"。

文中数据和性能指标基于2026年公开资料，技术迭代很快，请以各平台最新披露为准。欢迎同行交流拍砖。