推理吞掉80%算
以下是修改后的版本：
2025年终总结：推理系统，终于成了主角
2025年最后一天，我坐在电脑前，脑子里翻江倒海。这一年，我最深的感受不是模型又多强，而是——推理系统，它终于从幕后走到了台前，成了主角。
两周前，我在华为稼先社区做了个技术分享，讲我们团队这一年的推理系统创新。台下有个同学问了一个直击灵魂的问题：“你们这些工作，到底解决了什么问题？”我愣了一秒，然后笑了。是啊，技术文章铺天盖地，凭什么我的值得你看？
所以，我干脆趁着元旦假期，把这一年最扎心的思考、最反直觉的洞察，还有我们踩过的坑，统统倒给你。
先抛三个你可能最关心的问题，咱们一个一个说：
1. 为什么2025年大家都在喊“推理太贵”？贵在哪？别告诉我只是算力贵。
2. Agent应用这么火，为什么部署起来总翻车？你以为是模型问题，其实是系统在拖后腿。
3. 开源框架这么多，vLLM、SGLang、Mooncake……到底选哪个？我直接告诉你，没有银弹，但有组合拳。
一、推理：从“小透明”到“成本黑洞”
2025年最大的变化，不是哪个模型又屠榜了，而是——推理压过了训练，成了真正的“千亿成本之战”。
我手头有组数据，你看完肯定吓一跳：现在云上绝大多数GPU/NPU资源，都被推理业务占着。服务于推理的加速卡规模，比训练卡高好几倍，有些公司甚至高一个数量级。这意味着什么？对于任何一家AI公司，最大的成本中心，已经从“训练”变成了“推理”。
说到这儿，我给你算笔账。我们团队测过一个场景：在相同硬件规模下，通过系统架构创新，把推理吞吐提升1倍。对于一个算力投入巨大的科技公司，这直接对应着数十亿人民币的成本节省。
几十亿。不是几百万。你想想，这是什么概念？
所以2025年的推理系统创新，不是技术极客的自我挑战，而是生死存亡的问题。谁能在推理上省下钱，谁就能活到下一年。
二、四大趋势：为什么传统方案扛不住了
好，既然推理这么重要，那为什么传统方案扛不住了？我看到了四个关键变化，这些变化决定了我们为什么要做这些研究。
趋势一：应用层从Chatbot走向Agent——内存管理成了新瓶颈
2025年之前，大多数推理系统是为“一问一答”设计的。用户发个请求，模型生成一段文字，完事。简单，粗暴。
但Agent应用完全不一样！一个Agent可能先调用工具查天气，然后根据结果决定要不要发邮件，再根据邮件回复调整后续动作。整个过程可能持续几十轮对话，每轮的prompt都在变，KV cache的管理复杂度呈指数级上升。
我踩过一个坑，说出来都是泪：用vLLM部署一个Agent应用，结果发现随着对话轮数增加，响应延迟从200ms飙升到3秒。查了半天，发现是KV cache的复用出了问题——不同轮次的prompt有大量重复前缀，但系统没有识别出来。
这事儿让我意识到：Agent场景下，推理系统的瓶颈已经从“计算”变成了“内存管理和调度”。这就像你家里本来只有一个水龙头，现在突然要同时给几十个花园浇水，水管不炸才怪。
趋势二：模型层MoE成为标配——负载均衡成了大麻烦
2025年，MoE（混合专家模型）已经成了模型的标准组件。DeepSeek-V3系列把MoE推向了极致，Qwen3-Next也用了GDN架构。
MoE的好处很明显：相同参数量的模型，推理成本更低。但代价是系统复杂度大幅上升。
我们测试过：一个MoE模型，如果调度器没优化好，负载均衡问题会导致30%以上的性能损失。说白了，就是有些专家模块被打爆了，有些还在闲置。这就像一家公司，有的部门忙得飞起，加班到深夜，有的部门却闲得喝茶看报，效率能高才怪。
趋势三：系统层PD分离成为主流——KV传输成了新痛点
2025年最火的推理架构是什么？PD分离——把Prefill（预填充）和Decode（解码）拆成两个独立的服务。
为什么这么做？因为Prefill和Decode对资源的需求完全不同：
- Prefill：计算密集型，需要高算力
- Decode：内存密集型，需要大显存
把它们拆开，就可以独立扩缩容，避免资源浪费。这就像把做饭和上菜分开——厨师只管炒菜，服务员只管端菜，厨房和餐厅都能高效运转。
但这个架构有个新问题：KV cache的传输延迟。Prefill节点产出的KV cache要传给Decode节点，如果网络不够快，反而会拖慢整体性能。
我们团队在部署Mooncake的时候就遇到过：因为RDMA网络配置不对，KV传输延迟比预期高了3倍。后来调了Layer-wise Pipeline才解决。有时候不是架构不好，是你没玩对。
趋势四：硬件层架构升级——不能等下一代芯片了
2025年，硬件增长速度开始放缓。这意味着我们不能指望靠“等下一代芯片”来解决问题。
Linear Attention、Sparse Attention这些新架构开始出现在旗舰模型里。它们用更高的工程复杂度换来了推理效率的提升。但说实话，这些新架构对推理系统提出了全新挑战——传统的Attention优化方法不再适用。
这就像你开惯了手动挡，突然换了一辆自动驾驶的车，虽然更省油，但你要重新学怎么开。
三、五项代表作：我们这一年做了什么
上面说的都是趋势，接下来聊聊我们团队的具体工作。2025年我们做了五项工作，我挑三个重点说说，每一个都让我拍大腿。
SparseServe：把MoE的“稀疏性”用到极致
MoE模型有个特点：对于不同的输入，激活的专家模块不同。但传统的推理系统没有利用这个特性——它把所有专家都加载到显存里。
SparseServe的思路是：只加载当前请求需要的专家。
听起来简单，但实现起来坑很多。最大的问题是：你怎么知道下一个token需要哪些专家？我们试过用预测模型，但效果不理想。后来换了个思路：用历史统计信息做预判。
测试结果：在相同硬件上，吞吐提升了40%。但有个代价——如果请求的pattern变化太大，预判准确率会下降。这就像你提前猜朋友想吃什么，猜对了皆大欢喜，猜错了就尴尬了。
Adrenaline：给Decode阶段加速——用小模型当“侦察兵”
Decode阶段是推理的瓶颈。传统做法是一步一步生成token，每步都要访问完整的KV cache。
Adrenaline用了投机推理（Speculative Decoding）的思路：用小模型先猜几个token，然后用大模型验证。
这事儿挺有意思的。2025年投机推理能成熟，不是因为算法新，而是因为系统条件终于允许了：小模型足够便宜，验证路径足够短，调度器可以容忍不确定性。
我们测试了Qwen2.5-7B作为草稿模型，配合Qwen3-72B作为目标模型。在代码生成场景下，速度提升了1.8倍。这就像让一个实习生先写个初稿，然后让专家去审核，效率自然高。
TaiChi：处理长上下文的调度难题——像操作系统的虚拟内存
2025年，长上下文成了标配。128K、256K甚至1M的上下文窗口已经不算新鲜事。
但长上下文带来了新问题：KV cache放不下了。
TaiChi的解决方案是：把KV cache分片存储，按需加载。有点像操作系统的虚拟内存——不是所有数据都在物理内存里，但程序感觉不到。
这个方案有个关键点：预取策略。我们测试了好几种：LRU、LFU、基于注意力的预测。最后发现，结合请求的历史访问模式做预取效果最好。这就像你看书时，提前把下一章的内容翻到旁边，省得回头找。
四、几个你可能没想到的问题
1. 开源框架怎么选？直接给答案
2025年，vLLM、SGLang、Mooncake、LMCache各有千秋。我的建议是：
- **vLLM**：适合传统Chatbot场景，生态最成熟。你如果只是做问答机器人，选它没错。
- **SGLang**：RadixAttention对Agent场景更友好，缓存命中率高。你如果做Agent，试试它。
- **Mooncake**：PD分离架构，适合大规模部署。你如果公司大，GPU多，用它。
- **LMCache**：跨实例KV共享，适合多节点场景。你如果有多台机器，用它。
但说实话，没有银弹。我们团队的做法是：用SGLang做引擎层，Mooncake做调度层，LMCache做缓存层。组合起来效果不错。这就像炒菜——酱油、盐、糖各司其职，缺一不可。
2. 推理系统是不是已经到了瓶颈期？
2025年之前，单点优化（Kernel Fusing、Quantization）的边际效应确实在递减。但系统级的架构重构还有很大空间。
我觉得2026年的方向是：软硬件协同设计。比如，能不能让硬件直接支持PD分离？能不能在芯片层面做KV cache的预取？这就像盖房子——砖瓦的质量已经到顶了，但怎么搭结构，还有无限可能。
3. 最后说点个人感受
2025年是我做Infra以来最累也最爽的一年。累是因为节奏太快，几乎每个月都有新框架、新架构出现。爽是因为终于看到推理系统从“算得动”走向“用得起”。
有个同事问我：“你觉得2026年最大的机会在哪？”
我说：做正确且难的事。别追热点，把基本功打扎实。手撕各种Infra算法，把一块块砖瓦搭建成坚固的城堡。
2026年，愿找到正确的方向，马不停蹄。
最后一句话，你带走：
当所有人都盯着模型参数时，真正的护城河，藏在推理系统的每一行代码里。
读者评论 2