现代大模型推理的核心技术全景

一、为什么要讲这篇文章

大模型推理这个方向，变化速度比很多人想象得快得多。

如果只用 2024 年甚至 2025 年初的视角去理解推理系统，通常会得出一个“半对半错”的印象：
知道 continuous batching、KV cache、quantization、speculative decoding 这些关键词，但对下面这些近一年明显升温、甚至已经进入主线的内容把握不足：

KV cache-aware routing
disaggregated serving / PD 分离
multi-tier KV cache
distributed KV cache
KV cache offloading
guided decoding 与 speculative decoding 的组合
MoE 大规模 expert parallel 与通信优化
结构化输出成为正式生产能力
控制平面开始从“普通 K8s 运维”升级为“推理状态感知型编排”

这说明今天谈“推理”，已经不能只停留在单机引擎视角。
更准确地说：

现代大模型推理 = 单机执行优化 + 缓存体系 + 请求调度 + 分布式并行 + 状态感知路由 + 集群级控制平面。

这篇文章的目标，就是把这几层放在同一张图里讲清楚。

二、先给结论：2026 年最重要的，不是更多名词，而是 8 条主技术主线

如果先不看细节，可以把现代大模型推理压缩成下面 8 条主线：

请求级调度与连续合批
KV Cache 与缓存体系
Attention / Kernel / Runtime 优化
长上下文与前缀复用
Decode 加速
量化与低比特推理
分布式推理与 MoE Serving
状态感知路由、分离式部署与控制平面

这 8 条线不是并列堆出来的，而是顺着 Transformer 的执行路径自然长出来的：

因为生成是自回归的，所以需要 batching 与 decode 优化；
因为 attention 依赖历史上下文，所以需要 KV cache；
因为 KV cache 会膨胀，所以需要 paged / offloading / distributed KV；
因为请求共享前缀越来越常见，所以需要 prefix caching 与 KV-aware routing；
因为模型更大、结构更复杂，所以需要 量化、MoE、expert parallel；
因为单机不够，所以需要 分布式 serving、PD 分离、控制平面与 autoscaling。

也就是说，今天的推理技术虽然看起来很散，但本质上都在回答同一个问题：

如何把 Transformer 的高成本自回归执行过程，改造成一个可并发、可复用、可扩展、可控成本的在线系统。

flowchart TD
    InputLayer["输入与请求层"] --> SchedulerLayer["调度层"]
    SchedulerLayer --> ExecuteLayer["模型执行层"]
    ExecuteLayer --> CacheLayer["缓存层"]
    ExecuteLayer --> DecodeLayer["Decode 加速层"]
    ExecuteLayer --> PerfLayer["低层性能层"]
    CacheLayer --> StateLayer["状态感知系统层"]
    DecodeLayer --> StateLayer
    PerfLayer --> StateLayer
    ParallelLayer["并行与扩展层"] --> StateLayer

三、第一条主线：请求级调度与连续合批

1. 为什么“合批”在大模型时代变得更难了

传统推理服务也讲 batching，但到了大语言模型时代，batching 的难度明显上升。
因为请求不再只是“输入一个张量、输出一个张量”，而是：

到达时间不同；
输入长度不同；
输出长度不同；
生命周期不同；
生成过程逐 token 推进；
一个请求可能还带多轮历史、工具 schema、结构化输出约束。

这意味着静态 batch 很难高效。
如果你还沿用“凑齐一批再跑到底”的思路，通常会遇到：

长请求拖慢整批；
短请求完成后留下空洞；
新请求不能自然插入；
GPU 利用率偏低；
decode 阶段效率尤其差。

2. 为什么 continuous batching 仍然是主线

因此，continuous batching / in-flight batching 依然是主线，而不是过渡技术。

SGLang 当前仍把 continuous batching 和 zero-overhead CPU scheduler 放在核心特性里；其文档首页把连续合批、prefill-decode disaggregation、structured outputs、multi-LoRA batching 等放在同一层级，说明它不是一个局部优化，而是 serving runtime 的骨架之一。
TensorRT-LLM 也把 In-Flight Batching & Paged Attention 明确列为高级优化与生产特性。

3. 这条线在 2026 年的新变化

相较于更早的“动态合批”理解，今天的连续合批已经不再只是吞吐优化，而是越来越和下面这些能力耦合：

prefix cache 命中情况
chunked prefill
structured outputs
speculative decoding
多 LoRA 并发
MoE 路由与并行
KV-aware routing

也就是说，现代调度器不是“把请求凑一凑”那么简单，而是在做 状态感知的、推理特化的、资源与缓存联合优化。

四、第二条主线：KV Cache 已经从“优化技巧”升级为“系统级资产”

1. 为什么 KV Cache 还是中心问题

今天的大模型推理，如果你只记住一个系统关键词，那大概率就是 KV Cache。

原因不复杂：
大语言模型的 decode 是逐 token 的。如果每一步都把前面所有 token 再完整算一遍，推理成本会高得不可接受。
所以模型会保存历史 token 的 Key / Value，并在后续步骤中复用它们。

这在模型层是一个自然机制，但在系统层，它会立刻变成以下问题：

cache 占多少显存？
cache 如何分配与回收？
cache 能否复用？
cache 是否能跨实例共享？
cache 是否能跨内存层级迁移？
cache 能否跨 prefill / decode 节点传输？
cache 如何参与路由决策？

因此，现代推理很多时候并不是在“管理模型权重”，而是在 管理 cache 生命周期与 cache 命中率。

2. Paged KV / Prefix Caching 仍是基础设施级能力

vLLM 仍然把 Paged Attention 和 Automatic Prefix Caching 作为核心设计内容。
其最新文档继续强调，prefix caching 是通过缓存已处理请求的 KV block，在新请求前缀相同时直接复用，从而避免重复 prompt 计算。

这说明到了 2026 年，prefix caching 并没有“过时”，反而已经被默认视为现代开源 serving 框架的基础能力之一。

3. 缓存体系已经从单层走向多层

更大的变化在于：
KV cache 已经不再只是 GPU 显存里的一块临时状态，而是在往多层存储体系演进。

Hugging Face 现在把 cache 官方拆成多个类型来讲，包括：

dynamic cache
static cache
quantized cache
sliding-window cache
offloaded cache

这说明 cache 管理已经形成一个完整设计空间，而不是“开还是不开”的单选题。

4. 分布式 KV 与跨引擎复用正在从前沿走向实用

近一年最值得注意的，是 distributed KV cache 与 cross-engine reuse 正在从研究概念走向工程实现。

LMCache 的定位就是把 KV cache 复用提升到系统级，强调“prefill once, reuse everywhere”；NVIDIA Dynamo 官方文档也把 LMCache、SGLang HiCache、FlexKV 等列入它支持的 memory management 生态。

AIBrix 也在其 KVCache Offloading 设计中明确强调：为了应对超大规模动态工作负载，单机内存 offloading 已不够，需要 可横向扩展的 L2Cache / distributed KV service，同时支持 cross-engine KV reuse。

5. 为什么这意味着推理系统思路变了

这意味着一个非常重要的变化：

KV cache 正在从“引擎内部细节”演化为“平台级共享状态”。

一旦这一点成立，推理系统的上层设计就会跟着改变：

路由不再只看负载，也要看 cache overlap；
autoscaling 不再只看副本数，也要看 cache 命中与阶段拆分；
serving 不再只是启动多个模型实例，而是要考虑状态共享与状态转移成本。

这正是 2026 年推理系统和早期“部署一个大模型 API”最大的区别之一。

五、第三条主线：Attention / Kernel / Runtime 优化已经从算子级扩展到执行路径级

1. Attention 仍然是热点，但热点已经细化

Attention 依然是推理系统的主战场之一，但今天讨论 attention 已经不能停留在 “FlashAttention 很快” 这一层了。
因为在现代 serving 场景里，attention 优化至少分成三层：

kernel 层优化
cache / 内存布局优化
runtime 路径优化

vLLM 的 Paged Attention 文档仍然强调其 kernel 对内存布局和 shared memory 访问方式做了专门设计；FlashInfer 则已不再只是 attention kernel 的集合，而是面向 serving 的统一 kernel library / generator，覆盖 attention、GEMM 和 MoE 操作，并支持多种 backend。

2. 现在的 runtime 优化，已经不只是“更快执行”

vLLM 的文档首页和 features 页面都持续把 CUDA graph、chunked prefill、automatic prefix caching、speculative decoding、LoRA 等能力列入正式特性矩阵。

这意味着 runtime 优化正在从 “如何更快执行同一条前向” 扩展到 “如何让不同 workload 在同一引擎里高效共存”。
也就是说，runtime 不只是一个执行器，而是已经开始承担：

批处理调度
cache 生命周期管理
特性组合兼容性
多类型模型 / 多后端支持
硬件适配

3. 一个重要趋势：Attention Backend 和能力矩阵更显性了

vLLM 甚至专门有 attention backend feature support 页面，用于描述不同 attention backend 的特性支持矩阵。
这类文档的出现本身就说明：
现在的推理系统不仅在“做优化”，还在“管理优化组合的兼容性”。

这也是为什么“懂一点 CUDA”已经不够了——你还得理解不同 backend、不同 feature 组合在什么条件下能共存，什么条件下会被降级或关闭。

六、第四条主线：长上下文与前缀复用，已经从“可选优化”变成“默认场景”

1. 为什么长上下文不再是特殊需求

过去长上下文往往被视为高级场景，但现在它越来越接近默认场景。
原因很现实：

多轮对话上下文自然累积；
RAG 场景会带入长文档；
agent 会带长 system prompt、工具 schema 和中间状态；
编程助手会带整段仓库上下文；
多模态输入还会额外引入 image embedding blocks。

这意味着长上下文不再只是“窗口更大”，而是 更频繁、更复杂、更依赖缓存与路由协同。

2. Chunked Prefill 仍然很重要

SGLang 仍然把 chunked prefill 放在核心特性中；vLLM 也在 features 中持续支持 chunked prefill。
它的重要性并没有下降，反而更强了。因为长输入越常见，prefill 对显存和调度的冲击就越突出。

3. 前缀复用正在和路由强耦合

更大的变化是：prefix caching 不再只是“命中了就省一点算力”，而开始进入 路由层。

NVIDIA Dynamo 现在直接把 KV Cache-Aware Routing 做成正式组件与用户指南，明确指出路由需要综合 worker load 和 existing cache hits；它的 Router 文档还明确提到，路由要同时考虑 decode cost 和 prefill cost，并利用 KV overlap 来最小化重复计算。

这意味着“共享前缀”不再只是一种引擎内部的 cache hit 行为，而是在驱动整个平台的请求分配策略。

4. 多模态也已经把这件事推得更远

Dynamo 甚至已经提供 multimodal KV routing 文档，说明它会把图像内容哈希纳入 block-level overlap 计算。

这说明：

在 2026 年，KV-aware routing 已经不再只是文本前缀复用，而是在向更广义的“多模态上下文状态复用”扩展。

七、第五条主线：Decode 加速从 speculative decoding 走向“组合式 decode 优化”

1. Speculative decoding 仍然是主线，但不再只是一个孤立 feature

Speculative decoding 还在，而且比以前更重要。
但现在它的价值不只是“让 decode 更快”，而是开始和其他特性组合起来用。

TensorRT-LLM 最新 release notes 明确提到：

speculative decoding 与 guided decoding 可以协同工作；
支持 2-model 和 draft model chunked prefill 场景；
增加了 Eagle 的多层支持与优化。

这说明 speculative decoding 已经不再是“单独开一个优化选项”，而是在和：

guided decoding
structured outputs
chunked prefill
disaggregated serving

做组合式优化。

2. 为什么这件事很关键

它说明 decode 优化的目标已经变了。
以前更多是在追求 “每 token 更快”；
现在则开始追求：

decode 与结构化输出兼容
decode 与分离式部署兼容
decode 与不同 draft / verifier 路径兼容
decode 与 MoE / 多并行场景兼容

也就是说，decode 加速正在从单点算法优化，走向生产路径组合优化。

3. Structured outputs 成为“正式特性”本身就是变化

SGLang 官方特性里持续列着 structured outputs；TensorRT-LLM 最近也在 guided decoding 方向持续增强。
这件事的重要性在于：

今天很多生产系统不是在生成“自由文本”，而是在生成：

JSON
函数调用参数
工具 schema
固定格式命令
合规的结构化响应

因此，decode 不再只是 sampling 问题，而是越来越成为 受约束的 token 搜索与验证问题。

八、第六条主线：量化仍然重要，但重点已经从“能不能量化”变成“如何和整个系统协同”

1. 为什么量化仍是主战场

模型没有变小，反而越来越大；
多卡和显存仍然昂贵；
MoE 与长上下文进一步拉高了服务成本。
所以量化依然是推理主战场之一。

SGLang 当前特性仍明确包括 FP4 / FP8 / INT4 / AWQ / GPTQ；TensorRT-LLM 也持续把 advanced quantization 放在核心能力中。

2. 2026 年量化思路的变化

现在真正关键的问题，不再是“能不能把模型量化到某个位数”，而是：

量化后的模型和哪些 kernel 最配？
decode / prefill 两阶段收益是否一样？
MoE 下 expert 权重如何量化？
cache 是否也需要量化？
不同硬件的低比特支持是否一致？
量化是否和特定 runtime 特性兼容？

TensorRT-LLM 新版本 release notes 中甚至提到：

对 DeepEP 的低精度（FP4）联合 kernel 与 all-to-all 通信做优化；
支持 KV cache reuse for MLA；
提供 host offloading 示例。

这说明量化已经从“权重量化”进一步和：

通信
offloading
KV reuse
特定模型结构（如 MLA）
特定硬件

紧密耦合。

3. 你应该怎么理解这条线

现在的量化，更像是 系统级成本优化手段，而不是一个单独的模型压缩技术。
它必须和 runtime、kernel、通信、并行策略一起看，才有意义。

九、第七条主线：MoE Serving 已经从“支持一下就行”进入“通信与扩展能力竞争”

1. 为什么 MoE 不只是“更大的模型”

MoE 的关键不是总参数更大，而是 每个 token 要被路由到不同 expert。
这会带来一整套新的系统问题：

dispatch
all-to-all
expert load balance
expert parallel
多机多卡拓扑
prefill / decode 阶段 dispatch 策略不同

所以 MoE serving 一开始看像“模型结构问题”，很快就会变成 通信与集群问题。

2. 2026 年真正值得注意的变化

vLLM 当前已明确支持 Expert Parallel Deployment 与大规模 parallelism scaling，并在并行/扩展文档中明确写出 attention 层与 expert 层可采用不同并行策略。

TensorRT-LLM 则持续把 large-scale expert parallelism 作为其重要方向，并在 release notes 中不断更新与 DeepEP、all-to-all、低精度 combined kernels 相关的优化。

这说明 MoE serving 已经不只是“引擎支持某些模型格式”，而是进入了：

expert parallel 策略
dispatch / load balance
通信库优化
动态 GPU 扩缩
异构配置搜索

这些更偏核心 infra 的竞争点。

3. 一个很明显的信号：专家并行开始走向弹性化

vLLM 最近的 releases 甚至提到 Elastic Expert Parallelism 与 NIXL-EP integration。
这类能力意味着：

MoE expert 不再只是固定绑在一组 GPU 上，而是在尝试进入“可弹性扩缩、可动态调度”的阶段。

这对未来大规模多租户 MoE serving 影响很大。

十、第八条主线：控制平面与状态感知路由，已经成为推理系统的上层骨架

1. 为什么“有引擎”不等于“有系统”

很多人会把 vLLM、SGLang、TensorRT-LLM 当成完整答案。
但在真正的生产环境里，你很快会碰到更高一层的问题：

请求应该路由到哪个副本？
哪个副本已有可复用 cache？
Prefill 和 Decode 是否应该拆开？
如果 SLA 关注 TTFT 与 TPOT，该如何自动扩缩？
长请求与短请求如何共存？
多引擎混合部署时如何统一管理？

这些问题不是单个引擎内部就能解决的。
于是，控制平面开始变成现代推理系统的重要组成部分。

2. Dynamo：把“状态感知推理系统”讲清楚了

NVIDIA Dynamo 的文档非常值得看，因为它把近一年推理系统上层骨架说得很清楚。

其 introduction 直接强调：
Dynamo 做的是 single-GPU engine 之上的 distributed layer，核心包括：

disaggregated serving
smart routing
KV cache management across memory tiers
auto-scaling

并且它把三项核心技术明确概括为：

Disaggregated Serving
KV Cache-Aware Routing
KV Cache Offloading

还强调这些技术不是孤立的，而是 组合后会产生复合收益。

更重要的是，Dynamo 不是只说理念，它把：

Router
KV Router
Planner
AIConfigurator
多模态 KV routing
生态集成（vLLM / SGLang / TensorRT-LLM / LMCache / Mooncake）

都做成了正式组件或文档。
这说明今天的推理控制平面，已经不是“监控 + K8s”那么简单，而是在做 状态感知型推理编排。

3. AIBrix：另一条很有代表性的路线

AIBrix 现在同样把自己定义成用于构建可扩展 GenAI 推理基础设施的 cloud-native building blocks，强调：

gateway and routing
autoscaling
distributed inference
KV caching

AIBrix 在 KVCache Offloading Framework 中还进一步强调：

多级 KV cache
distributed L2 cache backend
cross-engine KV reuse
massive-scale dynamic workloads

这说明 AIBrix 代表的是另一种很现实的趋势：
把推理问题视为 Kubernetes / 云原生环境中的状态化服务编排问题。

4. 一个很重要的认识

过去我们会说“推理系统 = 模型引擎 + GPU 优化”。
现在更准确的说法应该是：

推理系统 = 引擎层 + 状态层 + 路由层 + 控制层。

这也是为什么 AIBrix、Dynamo、llm-d 一类项目会越来越频繁地进入讨论中心。

十一、一个持续升温的交叉热点：PD 分离与分离式部署

1. 为什么 PD 分离在 2026 年更重要了

Prefill 和 Decode 的资源特征本来就不同：

Prefill 更像大吞吐计算；
Decode 更像低延迟、小步推进、重缓存读取。

当请求更复杂、长上下文更常见、MoE 更普遍以后，这种差异会被进一步放大。
因此，Prefill / Decode Disaggregation（PD 分离） 在 2026 年显得比早期更重要。

SGLang 仍把 prefill-decode disaggregation 放在核心特性中；TensorRT-LLM 当前文档与博客也持续提供 Disaggregated Serving 的说明与调优内容。

2. PD 分离带来的系统挑战也更明确了

一旦分离，你必须解决：

KV cache 如何跨节点传输；
prefill 与 decode worker 如何调度而不互相干扰；
uneven pipeline parallelism 下的 cache transfer 如何做；
TTFT 与 TPOT 如何重新平衡；
哪些流量适合走 PD 路径，哪些不适合。

TensorRT-LLM 最近 release notes 中就明确提到：

新的 KV Cache Connector API，用于 disaggregated serving 的 state transfer；
对 KV cache transfer for uneven pipeline parallelism 的优化；
在 disaggregated mode 下支持 guided decoding。

这说明 PD 分离已经不只是理念，而是在落地过程中不断暴露并解决细粒度工程问题。

十二、Mooncake、HiCache、NIXL 这类名字为什么越来越值得关注

1. 因为它们代表的是“推理状态基础设施化”

Mooncake 的定位已经非常明确：它不是通用缓存系统，而是 面向 LLM inference 场景的 distributed KV cache / transfer engine。
其文档与示例明确展示了：

SGLang 官方支持 Mooncake Transfer Engine 用于 disaggregated prefilling 和 KV cache transfer；
Mooncake Store 是专门为 LLM 推理设计的分布式 KV 存储引擎；
SGLang HiCache with Mooncake backend 可以让 KV cache 在集群实例之间共享，提升在同等内存预算下的 cache hit rate。

2. 这类项目意味着什么

它意味着推理系统已经越来越像数据库和分布式存储系统：

有状态；
有冷热层级；
有跨实例共享；
有 transfer / replication / prefetch；
有命中率与容量的系统权衡。

一旦你接受这一点，就会发现：

未来的推理 infra，不只是“更好的 GPU 利用率”，而是“更成熟的状态管理能力”。

结语：2026 年的推理，不再只是“让模型更快”，而是在构建“有状态的生成系统”

如果把这篇更新版压缩成一句话，我会这样总结：

2026 年的大模型推理，已经从“单机算子加速”升级为“状态感知、缓存驱动、分离式部署、分布式协同、控制平面统筹”的系统工程。

过去我们说推理优化，更多在想：

attention 快不快；
量化省不省；
batch 大不大。

现在则必须同时思考：

cache 命中率高不高；
路由是否感知状态；
prefill 与 decode 是否要拆开；
KV 是否可以跨实例共享；
MoE 通信是否是主要瓶颈；
SLA 下如何自动扩缩；
多层内存和多种引擎如何协同。

也正因为如此，推理方向不再只是“部署岗位”或者“应用岗位”的延伸，而越来越像一个独立的、技术密度极高的系统工程方向。

这也是它为什么会持续成为大厂核心组重点投入的原因。