推理优化

跑 MoE 模型的人都见过一个怪现象：模型总参数巨大，但每个 token 只激活一小部分，GPU 利用率却上不去。NVIDIA 技术博客点破了原因——高交互场景下，MoE 的执行时间被专家权重加载时间卡住，而不是被矩阵乘法本身。这就是 WideEP（Wide Expert Parallel）要解决的问题。 decode 阶段的带宽地狱 生成阶段每一步，路由器只挑出少数几个专家（比如 671B 里激活约 37B）。问题是：被选中的专家权重要从显存里读进来，才能做这一步计算。专家越大、越分散，每一步的权重读取量就越接近「把整个模型读一遍」。 换句话说，MoE 在 decode 阶段退化成了内存带宽问题：算力（FLOPS）严重闲置，时间全花在把专家权重从 HBM 搬到计算单元上。 WideEP 的解法 传统专家并行把所有专家放在一组卡上，每个 decode step 要跨这组卡集体通信。WideEP 反过来：把专家切分到 NVL72 机架内更多节点上并行，缩短单个专家的加载路径，用机架级 NVLink 的高带宽抵消跨卡成本。配合前面提到的 EP64DP3 这类配置，专家被摊得足够开，每步加载时间显著下降。 为什么 2026 年才规模化 这不是算法创新，是基础设施创新。没有 NVL72 这种把几十张卡做成一个统一域的机架、没有 HBM4 的容量、没有 Dynamo 把 prefill/decode 拆开各自配拓扑，WideEP 就是纸上谈兵。MoE 模型（DeepSeek-V4、Qwen3.8 这类）与机架级硬件是同步成熟的。 给实践者的提醒 如果你在自建 MoE 服务，监控面板里别只看 GPU 算力利用率，要看 decode 阶段的显存带宽饱和率。如果带宽先打满、算力空着，说明你需要的不是更多卡，而是更合理的专家切分拓扑。 另一个实务建议是按请求类型分流。计算密集的批量任务与带宽敏感的交互式生成，最好路由到不同拓扑的资源池，而不是挤在同一批卡上互相抢带宽。这与 Dynamo 的分离式思路一脉相承：把负载画像摸清楚，再决定怎么切专家。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：MoE 专家并行

当权重被压到 4bit、prefill 被前缀缓存复用之后，推理显存里最贵的那块往往变成了 KV cache。一个长上下文 Agent 会话，几十路并发挂着，KV cache 能吃掉远超模型权重的显存。2026 年围绕 KV 的优化已经形成一套组合拳，值得按场景对号入座。 第一招：KV 量化，从可选变默认 Qwen3 系列本地部署文档里，KV 缓存已经支持把 K、V 缓存量化到 q8_0 甚至更低，配合 f16/bf16 主权重，显存占用直接腰斩，还因为减少了数据搬运而提速。SGLang 在 Hopper 上的 FP8 后端也默认对 KV 做 FP8 处理。 工程含义：KV 量化的代价远低于权重量化——注意力对 KV 低位宽的容忍度更高，是性价比最高的一刀。 第二招：冷热分层，把不活跃的请出显存 SGLang 的 HiCache 把基数树上冷掉的节点卸到主机内存，命中热前缀时再异步取回；Qwen3.8-Flash-Next 甚至把 N-gram 嵌入整个挪到主机内存，靠异步预取隐藏延迟。长会话里真正被反复访问的往往只有最近若干轮，把冷历史卸到 DRAM 而不是 HBM，等于给昂贵显存扩容。 第三招：前缀命中即驱逐 RadixAttention 体系下，驱逐策略要和复用一起设计：被多个会话共享的公共前缀节点永不驱逐，只有叶子端的私有历史可以被回收。这比 LRU 一刀切聪明——保住了缓存收益，又限制了无限膨胀。 组合决策表 高并发短会话：先上 KV 8bit 量化，命中率靠前缀缓存。 超长上下文（10 万 token 级）：量化 + 冷热分层，配合分块 prefill。 多租户 Agent 平台：公共系统提示强制置顶保证复用，私有历史设 TTL 驱逐。 判断 权重压缩的红利在 FP4 那波吃得差不多了，下一年推理成本的下降主要来自 KV cache 的精细化管理。你的显存监控面板里，该把 KV 占用单列出来了。 ...

注意力的平方级显存怪兽 回到注意力的计算复杂度：序列里每个 token 要和所有其他 token 算注意力分数，这是 N² 的关系。当序列长度 N 是 1K，还好；但长上下文到 128K，N² 就从百万涨到一百六十亿——中间生成的注意力矩阵大到把显存撑爆。更麻烦的是，传统实现会把整个注意力矩阵物化在显存里，算完才扔掉，显存占用居高不下。这也是为什么长上下文训练和推理都贵得离谱。FlashAttention（2022 年由 Tri Dao 等提出）就是奔着这个瓶颈来的。 FlashAttention 怎么省显存 FlashAttention 的核心不是改变数学结果，而是改变计算的访存顺序。它把注意力分块（tiling）：把长序列切成小块，在 GPU 的高速 SRAM 里逐块算、逐块累加，从不把完整的 N×N 矩阵写到慢的 HBM 显存里。因为数学上等价，输出结果和标准注意力一模一样，但显存占用从 O(N²) 降到约 O(N)，同时因为减少了显存往返，速度还快了两三倍。这是典型的「IO 感知」优化——它赢在少搬数据，而不是少算。后来的 FlashAttention-2、3 继续把并行度和硬件适配做到极致，如今几乎所有大模型推理都默认启用它。 KV Cache：推理时的隐形显存大户 训练靠 FlashAttention 省显存，推理则要对付另一个怪兽：KV Cache。自回归生成时，为了不重复计算历史 token 的 Key 和 Value，会把它们缓存下来。问题是这个缓存随上下文长度 × 并发数 × 层数 × 头维度线性膨胀。一个 70B 模型、8 路并发、32K 上下文，光 KV Cache 就能吃掉二三十 GB——这就是很多服务「单聊流畅、一开并发就 OOM」的根源。vLLM 的 PagedAttention 正是用分页管理 KV Cache 来压碎片，前面文章讲过。 长上下文的真实成本账 理解了这两层，就能算清长上下文的账：上下文从 4K 拉到 128K，KV Cache 涨 32 倍，注意力计算也随长度增长。所以「支持百万上下文」的模型，实际部署成本远不止权重那点钱——它要求你为 KV Cache 预备巨量显存，并发还上不去。这也是为什么业界在搞 KV 量化、MQA/GQA（多查询注意力，让多个查询头共享 KV，直接把 KV Cache 砍到几分之一）这类优化。GQA 已成为现代大模型的标配，本质就是为了在不显著掉质量的前提下，把 KV Cache 这个隐形大户压下来。 ...

成本下降的核心数据 2026年Q2，主流大模型API调用价格较2025年同期下降了60-70%，部分场景降幅超过80%。这一轮成本下降不是短暂的价格战，而是技术进步与市场竞争共同驱动的结构性变化。 主流API价格变化（每百万Token） 模型 2025Q2价格 2026Q2价格 降幅 GPT-4o $5.00 $1.50 70% Claude 3.5 Sonnet $3.00 $0.80 73% DeepSeek-V3 $0.27 $0.07 74% Qwen-Max ¥20.00 ¥4.00 80% Gemini 1.5 Pro $1.25 $0.35 72% 成本下降的四大驱动力 1. 芯片能效飞跃 NVIDIA Blackwell架构的B200芯片在推理场景下的能效比上一代H100提升了3.5倍： # 推理成本计算模型 def inference_cost_per_token( chip_power_watts, # 芯片功耗 tflops, # 算力 model_params_b, # 模型参数量(十亿) electricity_rate, # 电价(美元/度) utilization, # 利用率 batch_size, # 批处理大小 ): # 每Token所需计算量 (约2 * 参数量 FLOPs) flops_per_token = 2 * model_params_b * 1e9 # 每秒可处理Token数 tokens_per_second = (tflops * 1e12 * utilization * batch_size) / flops_per_token # 每小时耗电 kwh_per_hour = chip_power_watts / 1000 # 每百万Token成本 cost_per_million = (electricity_rate * kwh_per_hour * 3600) / (tokens_per_second * 3.6e6) * 1e6 return round(cost_per_million, 4) # H100 vs B200 对比（70B模型推理） h100_cost = inference_cost_per_token(700, 989, 70, 0.12, 0.6, 32) b200_cost = inference_cost_per_token(1000, 9000, 70, 0.12, 0.7, 64) print(f"H100: ${h100_cost}/M tokens") print(f"B200: ${b200_cost}/M tokens") print(f"成本降低: {(1 - b200_cost/h100_cost)*100:.1f}%") 2. 推理优化技术成熟 一系列推理优化技术在2026年趋于成熟并大规模部署： ...

引言：为什么需要量化？ 大语言模型的参数量和计算量呈指数级增长。一个72B模型在FP16精度下需要约144GB显存，而通过INT4量化可压缩至约36GB——单卡A100 80GB即可运行。量化已成为大模型部署的必经环节，但不同的量化方案在精度、速度和硬件兼容性上差异显著。 三大量化方案原理 INT8量化 INT8将FP16的权重映射到[-128, 127]的整数范围。核心思想是通过缩放因子（scale）和零点（zero point）将浮点数线性映射到整数空间： 量化： q = round(w / scale) + zero_point 反量化：w = scale * (q - zero_point) INT8是一种"安全"的量化方案，几乎所有主流GPU（Ampere及以上）都原生支持INT8矩阵乘法（通过Tensor Core）。 INT4量化 INT4将权重压缩到4位整数，范围仅为[-8, 7]。这意味着每个参数仅占0.5字节，相比FP16压缩了8倍。INT4通常采用分组量化（Group-wise Quantization）策略，每32或64个参数共享一组缩放因子： # INT4分组量化示例（伪代码） import torch def quantize_int4(weight, group_size=64): # 将权重按group_size分组 original_shape = weight.shape weight = weight.reshape(-1, group_size) # 计算每组的缩放因子 w_max = weight.abs().max(dim=-1, keepdim=True).values scale = w_max / 7.0 # INT4范围: [-8, 7] # 量化 q_weight = torch.round(weight / scale).clamp(-8, 7).to(torch.int8) return q_weight, scale # 反量化 def dequantize_int4(q_weight, scale): return (q_weight.float() * scale).reshape(original_shape) FP8量化 FP8是2024年起逐渐成熟的新一代低精度格式，采用浮点数而非整数表示。主流有两种格式： 格式 指数位 尾数位 范围 精度 E4M3 4 3 ±448 较高精度 E5M2 5 2 ±57344 较大范围 FP8的优势在于保留了浮点数的动态范围，对异常值更鲁棒，且NVIDIA Hopper/Blackwell架构原生支持FP8 Tensor Core。 ...

推理瓶颈在哪里？ 大模型推理的核心瓶颈是自回归生成的串行性：每生成一个token都需要将之前所有token的KV对参与注意力计算。随着序列变长，计算量和显存占用呈线性甚至二次增长。 推理优化的目标可以归纳为三个维度： 降低延迟（首token延迟TTFT + 每token延迟TPOT） 提升吞吐（每秒生成token总数） 减少显存（KV Cache占用） KV Cache：标准但不够 KV Cache是现代推理引擎的标配。在生成阶段，避免重复计算历史token的Key和Value向量，而是缓存复用。但KV Cache的显存占用非常大：以Llama-70B为例，单条请求的KV Cache在4K序列长度下约占2GB显存。 优化方向： PagedAttention（vLLM）：将KV Cache分为固定大小的block，通过页表管理，显著减少碎片 量化KV Cache：将FP16的KV对压缩为INT8甚至INT4，显存减半甚至1/4 稀疏KV Cache：基于注意力分数剪枝，丢弃不重要的KV对 连续批处理（Continuous Batching） 传统static batching需要等待批次内所有请求完成才能释放资源，短请求被长请求拖累。连续批处理（也叫iteration-level batching）在每个forward pass级别动态加入新请求、移除已完成请求： 时间步1: [req_A(token5), req_B(token3), req_C(token1)] 时间步2: [req_A(token6), req_B(token4), req_D(token1)] # C完成，D加入 vLLM和TGI都实现了这一机制，实测吞吐量可提升3-5倍。 投机解码（Speculative Decoding） 投机解码利用一个小模型（draft model）快速生成候选token序列，再由大模型一次性验证。如果小模型的猜测正确率足够高，就能以接近小模型的速度输出大模型质量的token： 小模型生成N个候选token（并行，很快） 大模型对这N个token做一次forward（并行验证） 接受正确的前缀，拒绝处重新采样 Medusa在此基础上扩展，在单次forward中同时预测多个位置的token（多头预测），进一步提升加速比。 量化推理 训练时用FP16/BF16，推理时降低精度： 精度 方法 性能损失 INT8 W8A8 / SmoothQuant <1% INT4 W4A16 / GPTQ / AWQ 1-3% 2-bit BitNet / 1.58bit 训练时需特殊设计 AWQ和GPTQ是目前最流行的4bit权重量化方案，配合Marlin内核可达极高吞吐。需注意，4bit量化在70B以上模型上表现好，但7B级别可能有明显精度下降。 ...

推理优化的核心矛盾 大模型推理面临一个核心矛盾：用户需要低延迟和高吞吐，但自回归生成天然是串行的。每生成一个token都需要完整的前向传播，而KV Cache的显存占用随序列长度线性增长。本文系统梳理当前主流的推理优化技术。 KV Cache优化 KV Cache的工作原理 在自回归生成中，前面token的Key和Value可以缓存复用，避免重复计算。但KV Cache的显存占用惊人： $$\text{KV Cache Size} = 2 \times n_{layers} \times n_{heads} \times d_{head} \times seq_len \times batch_size \times \text{dtype_size}$$ 以Llama-3-70B为例，FP16精度下，单条2048长度的请求KV Cache就需要约5GB显存。 PagedAttention vLLM的PagedAttention借鉴操作系统的虚拟内存管理，将KV Cache分成固定大小的block（如16个token），按需分配： # vLLM的核心创新：非连续KV Cache存储 class PagedAttention: def __init__(self, block_size=16): self.block_size = block_size self.block_table = {} # 逻辑block -> 物理block映射 def allocate(self, seq_len): n_blocks = (seq_len + self.block_size - 1) // self.block_size return [self._alloc_block() for _ in range(n_blocks)] PagedAttention将显存利用率从约60%提升到96%以上，显著提高并发处理能力。 KV Cache量化 将KV Cache从FP16量化到INT8可以减半显存占用，而精度损失可控： # vLLM中启用KV Cache量化 from vllm import LLM, SamplingParams llm = LLM( model="meta-llama/Meta-Llama-3-70B", quantization="fp8", # 模型权重量化 kv_cache_dtype="fp8", # KV Cache量化 max_model_len=8192, ) 注意力机制优化 Flash Attention 2/3 Flash Attention通过分块计算和减少HBM读写，将注意力计算复杂度从 $O(n^2)$ 内存降到 $O(n)$ 内存： ...

大模型越来越大，但部署环境千差万别。不是每台设备都有A100，不是每个场景都能容忍秒级延迟。模型压缩技术就是连接"大模型能力"和"有限部署资源"的桥梁。本文将系统梳理剪枝、量化、蒸馏三大压缩技术的原理与工程实践。 一、模型压缩的必要性 1.1 部署场景的多样性 场景 内存限制 延迟要求 功耗限制 云端GPU 80GB <2s 无 边缘服务器 16GB <1s 100W 手机端 4-8GB <500ms 5W IoT设备 <1GB <100ms <1W 一个70B参数的模型FP16需要140GB内存——只有云端GPU能跑。要部署到手机，需要压缩20-40倍。 1.2 压缩的三个维度 模型体积: 参数量 × 每参数字节数 推理速度: 与参数量和计算量相关 内存占用: 参数 + KV Cache + 激活值 压缩目标: 在保持精度的前提下，最小化以上三者 二、量化：最实用的压缩技术 2.1 量化原理 将高精度浮点数（FP16/FP32）映射到低精度整数（INT8/INT4）： FP16: 0.1234, 0.5678, -0.2345 (16 bit/参数) INT8: 映射到 [-128, 127] (8 bit/参数) → 压缩2倍 INT4: 映射到 [-8, 7] (4 bit/参数) → 压缩4倍 2.2 量化方法对比 PTQ（Post-Training Quantization）：训练后量化，无需重新训练 ...

首token延迟（TTFT, Time To First Token）是大模型推理体验的关键指标。用户可以容忍生成速度慢一些，但等待3秒才出第一个字是不可接受的。Prefix Cache是降低TTFT最有效的技术之一——对于共享system prompt的场景，可以将TTFT降低50%-80%。本文深入解析这项技术。 一、为什么首token延迟高 1.1 Prefill阶段的计算瓶颈 大模型生成回复的第一步是处理输入prompt（prefill阶段）。对于1000 token的输入，prefill需要一次性计算所有token的KV Cache。 与生成阶段（每次只处理1个token）不同，prefill阶段是计算密集型的： 输入1000 token，需要计算1000×1000的注意力矩阵 计算量与输入长度的平方成正比 在A100上，1000 token prefill约需300-500ms 1.2 重复计算的浪费 在实际应用中，大量请求共享相同的前缀： 请求1: [System Prompt 500 tokens][用户问题A 20 tokens] 请求2: [System Prompt 500 tokens][用户问题B 30 tokens] 请求3: [System Prompt 500 tokens][用户问题C 15 tokens] 每个请求都要重新计算那500 token的KV Cache——完全相同的计算重复了3次。如果有1000个请求，就是1000次重复计算。 Prefix Cache的核心思想：缓存共享前缀的KV Cache，后续请求直接复用。 二、Prefix Cache的技术原理 2.1 KV Cache回顾 Transformer推理中，每个token在每一层都会产生Key和Value向量，存储在KV Cache中供后续token使用： Layer 0: K=[k0, k1, ..., kn], V=[v0, v1, ..., vn] Layer 1: K=[k0, k1, ..., kn], V=[v0, v1, ..., vn] ... Layer L: K=[k0, k1, ..., kn], V=[v0, v1, ..., vn] Prefix Cache就是在请求完成后，不丢弃这些KV Cache，而是按前缀哈希存储，供后续请求复用。 ...

大模型推理的性能瓶颈不是计算，而是内存。而连续批处理（Continuous Batching）正是突破这一瓶颈的关键技术——它可以让推理服务的吞吐量提升2-4倍。本文将深入解析这项技术的原理与实现。 一、传统批处理的困境 1.1 静态批处理的问题 传统批处理将多个请求组成一个batch一起推理。问题在于：大模型生成是自回归的，每个请求的生成长度不同。 请求A: 输入50 token, 生成200 token (总时长: 3秒) 请求B: 输入30 token, 生成20 token (总时长: 0.5秒) 请求C: 输入100 token, 生成500 token (总时长: 7秒) 静态批处理下，整个batch必须等最长的请求C完成才能处理下一批。请求B在0.5秒就完成了，但GPU资源被空占了6.5秒。GPU利用率可能低至20-30%。 1.2 内存碎片化 更深层的问题在KV Cache的内存管理。每个请求需要预分配最大生成长度的KV Cache空间，即使实际只生成了很少的token，预分配的空间也无法被其他请求使用。 二、连续批处理的核心思想 2.1 动态插入与驱逐 连续批处理的核心：不等整个batch完成，而是在每一步推理后动态调整batch组成。 Step 1: batch = [A, B, C] → 各生成第1个token Step 2: batch = [A, B, C] → 各生成第2个token Step 3: batch = [A, B, C] → B完成！B退出batch Step 4: batch = [A, D, C] → D是新请求，加入batch Step 5: batch = [A, D, C] → A完成！A退出 Step 6: batch = [E, D, C] → E加入 ... 这样GPU始终满载运行，没有空等。 ...