我要投稿

大模型推理上半场收官：单实例优化见顶，迈向低时延×长上下文

发布日期：2025-08-29 06:50:07 浏览次数： 1538

作者：PaperWeekly

微信搜一搜，关注“PaperWeekly”

©作者 | 王磊

过去两年，大模型的焦点几乎都落在“如何更快、更大地训练”，而随着 Llama2、Qwen、Mistral 等开源模型的接连登场，推理优化的战场骤然升温。

2023 下半年起，从算子融合、量化加速到 vLLM 的爆发式迭代，单实例推理的优化一路狂奔，直至 2024 年推理成本已低于一次 Google 搜索。如今，算子与框架的工程红利逐渐被榨干，单实例优化接近尾声。

在这样的背景下，本文结合我对大模型推理技术的理解与市场观察，尝试梳理 LLM 推理优化的演进脉络与未来趋势。这是“三篇系列帖”的开篇，聚焦单实例推理优化的上半场；后续两篇将继续探讨多实例推理的端到端优化（从电力到 token），以及 DiffusionLM 的发展前景。

单推理实例的性能优化逐步成熟

2023下半年：开源模型扎堆发布，推理优化提速

回想 2023 上半年，几乎所有的 AI Infra 工作都在优化大集群训练，没想到到了下半年，多个优秀的开源模型发布，局面急转。

Llama2 在 23 年 7 月开源，包括 7B，13B 和 70B 三种规格的模型，发布后很快被集成到各种推理框架与 benchmark 中，直接推动了推理性能优化加速。

Qwen-7B 随后 8 月 3 日发布，在中文场景和多语种能力方面具有较强竞争力，进一步激发了社区对推理优化的探索与实践。

Mistral-8x7B 于 12 月开源，率先落地 MOE 架构，8 个专家，总参数 47B，激活参数仅 13B。在大部分 benchmark 中优于 Llama2 和 Qwen，是第一个有影响力的开源 MOE 大模型，从此 MOE 架构开始进入主流视野。推理框架也开始针对 MOE 架构兼容与优化。

与此同时，vLLM 的贡献者数从 2023 年底开始呈现爆炸式增长（见下图），与这些开源模型的发布节点高度吻合

▲ vLLM 贡献者数量从 2023 年底爆发增长

2024年：完成主要推理工程优化，LLM 推理成本已低于 Google 搜索成本

LLM 推理的成本在 2024 年大幅下降，DeepSeek 的开源周公布起运营数据可以算出 DeepSeek-V3 的推理成本大约在 0.3 美元/百万 tokens，这也是达到 GPT-4o 级别的能力的大模型推理成本。

如果一次推理输出 1000 个 token，则一次推理成本在 0.0003 美元，而 Google 一次搜索的成本约 0.0005 美元。这意味着 LLM 推理的成本已经低于 Google 的搜索成本，成本已经不是制约 AI 应用发展的关键因素，找到合适的应用场景才是关键。

▲ 大模型推理成本已经下降到 0.1USD/M tokens @ GPQA PhD level，数据源：Epoch.ai

这一成本降幅主要依赖算子性能优化，框架性能优化，以及模型稀疏化。

算子优化的主要目的是充分利用芯片算力，内存带宽和网络带宽资源。常见的优化手段包括：

1. 算子融合：即把多个小算子合并成一个大算子，可以减少显存回写到 HBM 的次数和内核调用开销。现在开源模型商用已经基本收敛到 DeepSeek 和 Qwen，所以一般芯片厂商，包括英伟达和华为昇腾，都会为其芯片定制主流开源模型的融合算子。

DeepSeek 开源的 DeepMLA 就是一个大的融合算子。现在 DeepSeek 的推理已经几乎无小算子，仅需要数个大算子即可完成。

2. 异步操作：内存搬运，网络通信和计算相互掩盖，比如在计算一个矩阵乘法的时候，可以同时加载下一步计算需要的权重，减少计算后数据加载的等待时间。通信也可以采用类似的原理，矩阵乘法算完一部分就可以先传输，不用等待整个计算完成再传输，比如华为昇腾的 CANN 中的 MC2 算子。

为了提升带宽资源利用率，也可以把不同卡的计算结果打包成一个大的数据块传输，减少通信次数，提升通信有效负载比例，比如 DeepSeek 的 DeepEP 就采用了这种策略。

3. 低精度度量化：使用 AWQ 和 GPTQ 等量化算法，使用更低的计算精度（比如 INT8，FP8）替代 FP16/BF16 进行计算，可以减少计算量和数据传输量，从而降低推理时延，减少 HBM 占用。

4. 指令优化：使用更高效的指令，减少指令的数量，或者使用硬件特有的指令。比如 DeepSeek 修改 PTX 指令，将两个独立的单精度浮点指令（乘法和加法）替换为一个 FMA 指令实现矩阵运算加速。

5. 并行优化：提升资源利用率。每个 GPU 使用大量的 SM（stream multiprocessors）计算资源，昇腾芯片也有多个 AICore 并行计算。通过将任务均衡的分解到不同的 SM 或者 AICore 中，可以提升整体的资源利用率，减少硬件等待时间。

3 月，DeepSeek 开源周公布的大量优化技术，2 个月过去了，vLLM 和 SGLang 均已集成了开源周公开的各项优化手段，在上诉几个方面做了非常深入细致的优化，实现了矩阵计算效率，通信效率和 MLA 算子的大幅性能提升。

算子优化的上限是硬件资源利用率达到 100%。现在 DeepSeek 开源的 DeepEP 实现了最高 92% 的通信带宽利用率，其 FlashMLA 算子实现了 89% 的 HBM 带宽利用率（3TB/s / H800 的 3.35TB/s）。

受限于实际业务请求的分布，硬件资源的利用率难以达到 100%。比如长请求和短请求作为一个 batch 进行计算的时候，不可避免的需要将短请求 padding 到长请求的长度，从而导致计算浪费。如何排布接收到的请求，提升系统吞吐，这就是推理框架要做的事情。

计算策略的执行，显存资源管理，请求调度是推理框架的核心功能。框架有点类似 CTO 的角色，负责分配资源和任务执行方式，而具体的执行由算子完成。框架的优化主要包括下面几个方面：

1. 并行策略优化，TP/DP/PP/EP 等多种并行方式可以协同使用，一般需要结合 SLA 的诉求，组合不同的并行策略，寻优并行参数，以达到最佳性能。比如请求中有大量超长文本的话，一般会使用 PP 来减少单卡显存压力。

如果不考虑时延优化吞吐可以使用较大的 TP，因为计算时间长，网络通信可以被掩盖；而为了极低时延，则需要放弃吞吐，使用较小的 TP。

2. 显存资源管理，vLLM 的第一版主打的 PageAttention 特性就是为了管理注意力所需要的显存，米面小块的分配和释放带来的显存碎片化问题，可大幅提升 HBM 的利用率。

而 SGLang 的主打特性 RadixAttention 是对 kv cache 做压缩存储和快速索引，在 kv cache 复用时减少访存时间。可以说当前的主流推理框架都是围绕 kv cache 的存储和调度来设计的。

3. 调度优化，chuncked prefill，continuous batching，PD 分离都属于此类。输入长短差异大的请求放在一起推理就容易相互干扰，chuncked prefill 可以缓解此问题；输出长的和输出短的一起推理，短请求会先结束导致计算空泡，continuous batching 可以解决此问题；prefill 和 decode 放在同一个卡上运行也会出现资源竞争和干扰，则把 P 和 D 分离可以分别优化 P 和 D。

个人认为调度优化才是推理框架的本质，因为请求的不同才使得有了推理框架进行协调的必要性。如果请求都是一样的输入输出长度，可以不需要推理框架也能高效的执行。

4. 投机推理，使用小模型快速生成多个 draft tokens，由大模型通过一次推理全部确认，保留确认正确的 tokens。如果 draft tokens 的接收率很高，则可以大幅降低推理时延。

DeepSeek 使用一个 MTP 模块，一次推理生成 2 个 tokens，实现了 1.8 倍的推理加速。由于每个输出的 token 的验证都需要进行一次大模型的前向传播，每个生成 token 的计算量并没有减少，只是从一次计算一个 token，到一次计算多个 tokens，提升了计算密度，把带宽 bound 的 decode 变成了计算 bound。

投机推理的这个特性尤其适合 HBM 带宽不足的国产芯片，应该作为重点突围的方向。

5. 图模式替代但算子模式（eagler mode），可以降低算子调度开销，计算逻辑可以在 GPU/NPU 上完成，而不用返回到 CPU 端。

模型稀疏化，由于模型参数量不断增加，导致推理成本越来越高，通过稀疏化可以实现增大模型总参数量，同时保持激活的参数量很少，实现大幅降低计算量。

DeepSeek 率先采用了大量小专家的 MOE 结构，是一个高度稀疏化的模型，DeepSeek-V3 有 671B 的总参数量，但单 token 的激活参数仅 37B，是 Llama2-70B 模型的 50%。

▲ DeepSeek-V3 的 MOE 架构

DeepSeek 官方给出的推理方案采用了 EP320 的部署策略，即需要使用 320 张卡并行推理，一卡一专家。如果一张卡上放多个专家，需要将多个专家的矩阵乘法拼接起来，计算效率不高。

而如果一张卡只计算一个专家，则一次只需要执行一个矩阵乘法，比一组矩阵乘法拼接的效率更高，同时需要加载的参数量减少，可以实现更低的推理时延。

大量小专家的 MOE 结构已经成为事实主流，从闭源的 GPT-4o，到开源的 Qwen3 都采用了这种模型架构。在可以预见的未来，模型的稀疏化程度会越来越高。

PS：Attention 的线性化也是当前模型推理优化发展的方向之一。但是个人对 Linear Attention 及其变种，比如 Mamba 持保留意见，因为这些策略或多或少会损失模型的通用表现力。

在如今性能持续优化的格局下，提升模型能力，减少思维链长度，提升模型本身的稀疏行收益更高。比如月之暗面的 Kimi k1.5 提出的思维链压缩技术，相信后续会成为开源大模型的标准能力。

“低时延+长输入”两条主线

2025 年被视为 Agent 应用爆发的一年。这与大模型推理能力（尤其是推理链，Chain-of-Thought，CoT）的增强密切相关。

相比仅限对话的场景，真正意义上的 Agent 需要具备更强的任务规划和多轮执行能力。比如，当让一个 Agent 解决“如何把大象放进冰箱”的问题时，LLM 会先将任务拆分成若干子步骤（如：打开冰箱门 → 把大象引入冰箱 → 关上冰箱门），然后依次生成并执行每个步骤，最后再对执行结果进行校验。

每一步都要调用一次 LLM 来生成文本，再调用一次 LLM 来检查可行性，这样下来仅一个小任务就可能需要数次到十余次的推理调用。

其次，CoT 模式下，模型在生成每个子步骤时往往会输出数百到上千个 tokens 的思考链。如果一个步骤平均输出 300–500 tokens，那么一个三步任务需要额外输出 3000 个 tokens。

任务复杂度提升往往意味着输入数据量的增加，比如综合搜索，案件文档，医疗历史的完整分析涉及同时输入多个长文档。多媒体数据的分析也需要消耗大量的 tokens。Gemini 2.5 近期计划支持到 2M tokens。

▲ 闭源大模型支持的 context 长度越来越高

另外，test-time-scaling 意味着 scale up 推理开销可以提升推理精度，提升任务完成率（CoT 也是 test-time-scaling 的一种）。如果采用 best-of-N 的模式，推理次数需要增加 N 倍。

▲ GPT-o1 test-time scaling 可以提升 3x 推理 accuracy

Agent 的工作模式下，调用次数增加，推理上下文扩张，test-time-scaling 推理质量提升，等因素综合作用，使得 Agent 任务端到端的响应时间如果没有针对性的软硬件优化，将难以保证任务完成时间和用户体验。

（月之暗面是对的，从创立开始就瞄准长文本推理能力的优化。但是长文本推理诉求的前提是 reasoning 能力，但当时 reasoning 的能力并不成熟，所以 2024 年，Mooncake 一度没有什么声量。随着 Agent 应用爆发，“长上下文+低时延”将成为主流需求，感觉月之暗面值得期待）。

提到低时延推理就不得不提大 EP 并行。2024 年 12 发布的 DeepSeek-V3，其大 EP 集群推理方案可以大幅降低推理时延，推理 TPOT 可以达到 10ms 级别，相比 2024 年 LLM 推理普遍要求的 100ms 标准提升了 10 倍。

DeepSeek 掀起了一波集群推理优化的热潮，大 EP 的推理高度依赖低时延网络，这正是华为昇腾超节点的核心优势。

目前，主流推理框架开销已经可以做到几 ms 以内，框架侧时延优化的空间有限，接下来主要优化点在提升 HBM 带宽的利用率，这需要在算子调度上做深度优化、进行更大粒度的算子融合，以及更加精细的显存管理，随之而来的工程难度也不断攀升。

最近 MegaKernel 实现了一个大融合算子，一次执行完整模型的前向计算，使 TPOT 时延降低 50%，令人叹为观止（MegaKernel，2025）。

突破算子优化瓶颈就不得不提“算子自动优化”，这是当前算子优化最重要的突破口，通过 AI 自动发现高效的算子实现。

最近 Stanford 的 CRFM 实验室发布了一个算子自动生成的工作，使用 OpenAI o3 和 Gemini 2.5 Pro 通过 test-time scaling 和优化的搜索方式，就可以生成高性能算子，性能堪比甚至优于 pytorch专家优化过的算子（Stanford CRFM）。

由于算子性能非常容易验证，结合 reasoning 的能力和 RL，是很适合大模型求解的任务。

总结

2025 年以来，大模型推理优化持续深入，除了大 EP 并行以外，并没有逃出主流的推理加速优化的思路框架，目标逐步收敛到“超长文本+超低时延”推理。在框架做好资源管理和调度的同时，极低时延需要在更底层进行算子优化，整网融合算子，以及 AI 自动算子优化看上去是比较有前景的两条路径。

参考文献

[1] Liu, A., Feng, B., Xue, B., Wang, B., Wu, B., Lu, C., ... & Piao, Y. (2024). Deepseek-v3 technical report.arXiv preprint arXiv:2412.19437.

[2] Snell, C., Lee, J., Xu, K., & Kumar, A. (2024). Scaling LLM Test‐Time Compute Optimally can be More Effective than Scaling Model Parameters. arXiv:2408.03314.

[3] MegaKernel，Look Ma, No Bubbles! Designing a Low-Latency Megakernel for Llama-1B（https://hazyresearch.stanford.edu/blog/2025-05-27-no-bubbles）

[4] Qin, R., Li, Z., He, W., Zhang, M., Wu, Y., Zheng, W., & Xu, X. (2024). Mooncake: A kvcache-centric disaggregated architecture for llm serving.arXiv preprint arXiv:2407.00079.

[5] Team, Kimi, et al. "Kimi k1. 5: Scaling reinforcement learning with llms."arXiv preprint arXiv:2501.12599(2025).

[6] Anne Ouyang，Azalia Mirhoseini，Percy Liang， Surprisingly Fast AI-Generated Kernels We Didn’t Mean to Publish (Yet)， Stanford CRFM（https://crfm.stanford.edu/2025/05/28/fast-kernels.html），2025

更多阅读