部署过在线推理服务的人大概都遇到过这种场面压测并发刚过 8第一句话就要等三秒可监控面板上的算力利用率常年挂在 30% 出头——卡明明没跑满请求却排着队。更让人困惑的是同一个模型、同一张卡跑批量离线任务时能跑到标称性能的七成一换成聊天式逐字输出就原地趴窝。把 Prefill预填充和 Decode解码这两个阶段的账分开算一遍几乎所有这类卡没跑满却慢的疑问都能对上号。这两个阶段是大模型推理过程中最基础的一次切分理解它们能直接回答你很多实际问题为什么首 token 延迟和逐字速度总是互相拖后腿、为什么加大 batch 有时不涨吞吐、为什么权重从 fp16 压到 int4 后解码能快将近一倍而预填充几乎没变、为什么有的框架要把预填充和解码拆到两台机器上跑。这些都不是调参玄学而是由矩阵形状和访存比例提前决定的结果。下面我按先分边界、再算强度、然后算显存、最后动手测和优化的顺序,把这条链路拆开讲中间会给出可以自己复现的计算公式和小脚本。刚接触推理部署的同学可以从头看做过一段时间但总觉得性能优化靠猜的,建议直接从第 2 章的算术强度那节切入。1. 两个阶段的边界到底在哪1.1 一次完整生成的物理过程用户发来一段 prompt模型做的第一件事不是开始说话而是把这段 prompt 里的所有 token 一次性喂进去做一次前向计算。这一趟计算结束只在最后一个位置输出一个分布采样出第一个 token。这一趟就是 Prefill。它的输入形状是[batch, seq_len, hidden]seq_len是整段 prompt 的长度可能是 20 也可能是 20000。紧接着进入 Decode。此时模型手里有一个新 token但它不能像 Prefill 那样只算这一个 token——为了让这个新 token 看到前面所有内容它必须用到前面所有位置的 Key 和 Value。如果每次都重算一遍前面的内容生成第 n 个 token 就要重复计算 n 次总计算量是平方级的。所以工程上把每层每个位置的 K、V 存下来这就是 KV Cache。有了它Decode 每一步的输入形状变成[batch, 1, hidden]只算当前这一个位置再把新的 K、V 追加进缓存。这个过程会一直重复到遇见结束符或达到长度上限。所以一次请求的总耗时严格等于TTFT (输出长度 - 1) × TPOT。TTFT 是首 token 延迟主要由 Prefill 决定TPOT 是后续每个 token 的间隔完全由 Decode 决定。这两个数字在业务上对应完全不同的体验——TTFT 决定多久能看到第一个字TPOT 决定读起来顺不顺。1.2 为什么这两个阶段必须拆开看很多人做性能优化时把整个请求当一个黑盒看到慢就笼统地加 batch换量化上张量并行。这种做法的失败率很高因为这两个阶段对资源的诉求是相反的、甚至互斥的。Prefill 一次性处理成百上千个 token中间激活的矩阵乘是标准的[M, K] × [K, N]形式M 就是序列长度动辄几百上千。这种形状的矩阵乘法能被 GPU 的矩阵单元吃得很干净属于典型的算力受限。你给它更多算力它就更快。Decode 一步只处理 1 个 tokenper sequence[M, K] × [K, N]里的 M 等于 1。M1 的矩阵向量乘在硬件上根本喂不饱计算单元绝大部分时间花在把几 GB 的权重从显存搬到片上。这属于典型的访存受限。你给它更多算力毫无意义得给它更多带宽或者干脆让同一份权重服务更多请求。下面这张表是我一般给团队新人画的第一张图把两边的差异列全维度Prefill预填充Decode解码输入形状[B, S, H]S 可达数万[B, 1, H]序列维固定为 1核心算子GEMM矩阵-矩阵乘GEMV / 瘦 GEMM矩阵-向量乘瓶颈类型算力受限compute-bound带宽受限memory-bound典型算力利用率40%~70%3%~15%主要成本浮点运算权重与 KV Cache 的显存读取加 batch 的收益小还要处理变长 padding极大权重读一次服务多请求量化权重的收益有限甚至因反量化变慢接近线性提速对张量并行的敏感度低通信能被计算掩盖高通信开销占比明显对应业务指标TTFT首 token 延迟TPOT每 token 间隔这张表里最容易被忽视的是最后两行。Prefill 阶段因为有大量计算张量并行产生的通信可以藏在计算后面Decode 每步的计算量太小通信延迟藏不住加并行度反而可能变慢。我第一次遇到从单卡扩到双卡吞吐反而降了的情况排查半天才发现是 Decode 的通信开销被放大了这件事后面第 6 章还会细讲。2. 从矩阵形状到算术强度把算力受限和带宽受限算明白2.1 用一个具体模型把参数量和形状算清楚空谈算力和带宽没意义得落到具体数字上。我造一个接近 7B 量级的配置做例子32 层hidden 维度 409632 个 query head用 GQA 配 8 个 KV headhead_dim 128FFN 中间维 11008词表 128k。单层参数量这样算注意力部分 q_proj 是4096×4096k_proj 和 v_proj 各是4096×1024因为只有 8 个 KV head8×1281024o_proj 是4096×4096加起来约 41.9M。FFN 部分三个矩阵各4096×11008合计约 135.3M。单层约 177M32 层约 5.67B再加上词表嵌入约 1.05B总量级在 6.7B 左右。权重在 fp16 下占 13.4 GB 左右。这个数字很重要后面所有带宽计算都从它出发。Prefill 阶段处理一段 2048 token 的 prompt每一层都要做[2048, 4096] × [4096, 4096]这样的乘。按前向计算量约等于2 × 参数量 × token 数的粗算法总浮点运算约 28 TFLOP。再补上注意力里QK^T和AV这两项的二次成本每层2 × 32 × 2048 × 2048 × 128 ≈ 34.4 GFLOP两项相乘再加倍32 层累计约 2.2 TFLOP占比还不算高。但把序列拉到 8192情况就变了。线性部分涨到 114 TFLOP注意力二次项涨到 17.6 TFLOP 左右合计约 132 TFLOP。如果这张卡在 fp16 下有效算力能跑到 200 TFLOP/s这一趟 Prefill 大概 0.66 秒——这个量级和实际观测是吻合的。注意 8192 时二次项已经占了 13%长上下文场景里注意力那部分不能忽略这也是为什么分块注意力实现在长 prompt 上收益特别明显。2.2 算术强度判断瓶颈的唯一标尺要判断一个阶段到底卡在哪业内通用的工具是算术强度Arithmetic Intensity定义很简单这段计算做了多少次浮点运算除以它必须从显存搬运多少字节。单位是 FLOP/Byte。硬件的对应指标是峰值算力除以显存带宽。拿一张 80GB HBM 的卡举例fp16 峰值算力假设 300 TFLOP/s带宽 2 TB/s比值就是 150 FLOP/Byte。这个数的含义是只有当你的计算强度达到 150算力和带宽才刚好同时打满低于这个值算力必然闲置瓶颈是带宽高于这个值带宽够用瓶颈是算力。现在算 Prefill。2048 token 时28 TFLOP 算力搬运的字节主要是 13.4 GB 权重激活值相对小得多强度约 2100 FLOP/Byte远超 150。所以 Prefill 是纯纯的算力受限优化方向就是让矩阵乘效率更高、减少中间结果的显存往返。再算 Decodebatch1。生成一个 token 需要 14 GFLOP但要完整读一遍 13.4 GB 权重强度约 1 FLOP/Byte。差了 150 倍。这意味着哪怕你把卡的算力提升十倍Decode 的速度一分都不会快——它根本不缺算力缺的是把权重搬过来的速度。这个结论直接推出一条实践法则Decode 的单步时间下界约等于权重字节数除以显存带宽。换成数字13.4 GB ÷ 2 TB/s ≈ 6.7 毫秒也就是理论最高约 149 token/s。实际能跑到 60%~75% 就已经是很健康的实现因为还要加上核函数启动开销、采样、KV 读取这些零碎成本。2.3 加 batch 为什么能救 Decode但救不到无限大既然 Decode 是带宽受限那最直观的优化就是让同一份权重服务多个请求。batch 从 1 加到 B权重的读取次数还是 1 次但产出的 token 变成 B 个算术强度直接乘 B。B64 时强度约 64虽然还没到 150 的拐点但已经比 1 好了六十多倍。这就是连续批处理能把吞吐拉起来的全部数学依据——它没有让单个请求变快它只是让同一笔显存读取被更多请求分摊。不过这里有个很多人踩的坑他们以为 batch 越大越好把并发往 256 堆发现吞吐反而涨不动甚至开始抖。原因在 KV Cache。Decode 每步除了读权重还要读每个序列的 K 和 V。batchB、已生成长度 S 时KV 的总读取量是B × S × 单token-KV字节。而我们前面算过单 token 的 KV 在全 32 层上是 128 KB。B64、S2048 时就是 64 × 2048 × 128 KB 16 GB——已经超过 13.4 GB 的权重了。所以 Decode 单步的真实访存量应该是两项相加权重字节 batch × 平均上下文 × 单token-KV字节。我按 2 TB/s 理论带宽做了一版估算你可以直观看出边际收益怎么衰减batch权重读取KV 读取S2048单步总访存单步耗时估算吞吐估算每 token 分摊113.4 GB0.25 GB13.65 GB6.8 ms147 tok/s6.8 ms813.4 GB2.0 GB15.4 GB7.7 ms1039 tok/s0.96 ms3213.4 GB8.0 GB21.4 GB10.7 ms2991 tok/s0.33 ms6413.4 GB16.0 GB29.4 GB14.7 ms4354 tok/s0.23 ms12813.4 GB32.0 GB45.4 GB22.7 ms5639 tok/s0.18 ms表里是理论值实测通常要乘 0.65 左右的实际带宽达成率。但趋势非常清楚batch 从 1 到 32吞吐翻了 20 倍从 32 到 128只再翻了不到一倍而单请求的 TPOT 却从 10.7 ms 涨到 22.7 ms。这就是为什么线上服务必须做准入控制——并发换吞吐的边际效益在某个点之后急剧下降而延迟代价是线性上升的。长上下文场景更极端S32k 时单序列 KV 就是 4 GBbatch 开到 8 就把带宽吃干净了这时候吞吐基本卡死。所以长上下文推理为什么贵答案不只在显存容量上更在解码阶段的访存带宽被 KV 挤占。3. KV Cache 的显存账本与并发天花板3.1 它省掉了什么又付出了什么不用 KV Cache 的话生成第 t 个 token 需要把前 t-1 个 token 全部重算一遍。总计算量是O(n²)级别的乘加而且每一层都要重算。生成 1000 个 token代价相当于跑一个长度 50 万 token 的 Prefill。这个成本是业务上完全无法接受的。用 KV Cache 后每层的 K 和 V 只算一次存起来后续每步只算新 token 的那一份总计算量降到O(n)代价是要占显存。这是一次典型的时间换空间而现代推理系统的绝大部分显存管理复杂度都是围绕这笔账展开的。3.2 显存占用公式与手算精确公式不复杂KV 字节数 2 × 层数 × KV头数 × head_dim × 序列长度 × batch × 每元素字节数前面那个 2 是 K 和 V 各一份。代入我们的模型配置2 × 32 × 8 × 128 × 2 131072 字节也就是每个 token 占 128 KB。这个单 token KV 字节数是你在做容量规划时最该记住的一个数字它跟模型结构强相关跟卡无关。顺着往下推2k 上下文 → 256 MiB8k 上下文 → 1 GiB32k 上下文 → 4 GiB128k 上下文 → 16 GiB注意这是单个序列的量。一张 80GB 的卡权重占 13.4 GB激活和框架自身开销留 5 GB能分给 KV 的大约 60 GB上下文长度单序列 KV理论上限并发实际可用并发留碎片余量2k256 MiB240180 左右8k1 GiB6045 左右32k4 GiB1510 左右128k16 GiB32 左右这张表解释了一件很反直觉的事限制并发数的往往不是算力是 KV Cache 的显存。你在 128k 上下文场景下哪怕有 8 张卡做张量并行总并发也上不去因为每个请求都在吃掉十几 GB 的缓存。这时候单纯加卡解决不了问题得靠 KV 量化、更激进的 GQA 比例、或者把缓存分层放到更慢但更大的存储上。3.3 一个可以随手用的计算脚本每次评估新模型或者新卡我都会用这个小函数先算一遍比翻文档快def kv_budget(num_layers, num_kv_heads, head_dim, seq_len, batch1, bytes_per_elem2): per_token 2 * num_layers * num_kv_heads * head_dim * bytes_per_elem total per_token * seq_len * batch return per_token, total # 例32 层、8 个 KV head、head_dim 128、fp16 pt, tot kv_budget(32, 8, 128, seq_len32768) print(f每 token: {pt/1024:.0f} KB, 单序列: {tot/1024**3:.2f} GiB) # 每 token: 128 KB, 单序列: 4.00 GiB把bytes_per_elem改成 1 就是 int8 KV 量化的效果改成 0.5 是 int4。这个参数一动上表的并发上限直接翻倍或翻四倍。KV Cache 量化之所以在长上下文场景收益巨大本质就是它同时放松了显存容量和访存带宽两个约束——容量决定能开多少并发带宽决定每一步读缓存要多久两个指标一起受益。4. 动手测把 TTFT 和 TPOT 拆开量一遍4.1 三个必须分开看的指标性能讨论里最常见的错误是只报每秒多少 token。这个数字在不同的测试条件下差十倍毫无可比性。我一般要求团队同时报三个数TTFT从请求发出到第一个 token 返回的时间对应 Prefill 性能加分词、排队、网络开销。TPOT第一个 token 之后相邻 token 的平均间隔对应 Decode 单步时间。吞吐整体每秒产出的 token 数是所有并发请求的加总。三者关系是总耗时 TTFT (输出长度 - 1) × TPOT而吞吐约等于并发数 ÷ TPOT。这条关系式说明了一件事在固定硬件上TTFT 和 TPOT 是可以通过调度策略互相挪动的但吞吐和 TPOT 是强绑定的。想提升吞吐除了增加并发只能降低 TPOT。4.2 写一个分阶段的计时脚本想搞清楚自己的服务卡在哪个阶段最直接的办法是把两个阶段单独跑一遍。下面这段是思路骨架落到具体框架上把模型调用换掉就能用import time, torch def bench_prefill(forward, prompt_lens, iters20, warmup3): 只测 Prefill整段 prompt 一次前向取最后一个位置的输出 for n in prompt_lens: ids torch.randint(0, 1000, (1, n), devicecuda) for _ in range(warmup): forward(ids, use_cacheTrue) torch.cuda.synchronize() t0 time.perf_counter() for _ in range(iters): forward(ids, use_cacheTrue) torch.cuda.synchronize() dt (time.perf_counter() - t0) / iters flops 2 * PARAM_N * n print(fS{n:6d} prefill {dt*1000:8.2f} ms f算力达成 {flops/dt/1e12:6.1f} TFLOP/s) def bench_decode(forward, ctx_len, out_len64, batch1, iters10): 只测 Decode固定上下文逐 token 生成量每步间隔 ids torch.randint(0, 1000, (batch, ctx_len), devicecuda) state forward(ids, use_cacheTrue) # 先做一次 prefill 建缓存 next_tok state.logits[:, -1:].argmax(-1) torch.cuda.synchronize() t0 time.perf_counter() for _ in range(out_len): state forward(next_tok, paststate.past, use_cacheTrue) next_tok state.logits[:, -1:].argmax(-1) torch.cuda.synchronize() tpot (time.perf_counter() - t0) / out_len print(fbatch{batch:3d} ctx{ctx_len:6d} TPOT {tpot*1000:6.2f} ms f吞吐 {batch/tpot:7.1f} tok/s)跑的时候有三点必须注意。第一warmup不能省第一次前向会触发各种编译和显存分配测出来的数能差好几倍。第二每个计时区间前后都要做同步GPU 是异步执行的不同步直接读时间戳会得到快到不真实的结果——我见过有人测出比理论带宽还高的数字就是这个原因。第三Decode 的测试一定要先跑一次 Prefill 把缓存建起来否则测的是从零开始的混合场景不是纯 Decode。4.3 一组可以参考的实测对照下表是我在一次容量评估里记录的典型数据模型就是前面那个 ~7B 配置fp16单卡 80GB标称带宽 2 TB/s。绝对值会随卡和框架浮动但比例关系很有参考价值场景关键参数测得的耗时折算指标PrefillS51242 ms算力达成约 170 TFLOP/sPrefillS2048168 ms算力达成约 168 TFLOP/sPrefillS8192810 ms算力达成约 163 TFLOP/sDecodebatch1, ctx2k9.8 ms/token单请求约 102 tok/sDecodebatch8, ctx2k11.5 ms/token总吞吐约 695 tok/sDecodebatch32, ctx2k16.2 ms/token总吞吐约 1975 tok/sDecodebatch32, ctx16k35.6 ms/token总吞吐约 899 tok/s几个值得盯的点Prefill 的算力达成率随序列长度基本稳定说明这部分已经优化到位如果 S512 时达成率明显低于 S2048通常是短序列的核函数启动开销占比过高可以考虑把多个短请求拼成一批。Decode 这边batch 从 1 到 32 吞吐涨了 19 倍但远不到 32 倍和前面理论表格算出的衰减趋势完全一致。最后一行更关键——同样 batch32上下文从 2k 拉到 16k吞吐直接腰斩这就是 KV 读取把带宽吃掉的直接证据。4.4 看 profile 时盯哪几个地方有更细粒度的性能分析工具时我一般按这个顺序看先看整条时间轴上有没有大段空白。Decode 的典型画像是几百个极短的小核函数排成一串中间夹着间隔。如果间隔加起来超过总时长的 15%问题多半在启动开销上值得做计算图捕获把整段解码循环打包提交一次启动代替几百次。再看显存读写吞吐的达成率。Decode 阶段如果带宽达成率只有 40% 而算力接近 0那就是典型的没喂饱如果带宽达成率超过 80%说明已经贴住硬件上限只能从减少访存量入手量化、缩 KV、减层。最后看 Prefill 阶段矩阵乘的切分是否合理。序列很长时如果注意力那部分耗时占比明显高于理论估算的 15%说明分块策略不好中间结果在显存里来回搬运这时候换更 IO 友好的注意力实现收益会很明显。5. 优化手段两边的手术刀不一样5.1 Prefill 侧把算力榨干别让它等数据Prefill 的优化目标只有一个让矩阵单元尽可能不空闲。最有效的手段是分块计算注意力把 Q、K、V 切块后在片上高速缓存里完成QK^T和AV避免把完整的S×S注意力矩阵写回显存。序列 8192 时这个中间矩阵是8192×8192个元素fp16 下 128 MB每个头都要来一遍写回再读出的代价非常可观。分块之后这部分访存基本被消掉长 prompt 上拿到 2 到 3 倍加速是常见结果。第二个手段是把长 prompt 切块调度。一段 32k 的 prompt 如果一次性 Prefill会独占 GPU 将近三秒这期间所有正在解码的请求全部被卡住TPOT 出现一个巨大的尖峰。把它切成若干块每块几百 token穿插在其他请求的解码步骤之间执行TTFT 会略微变长但整个服务的 TPOT 曲线会平稳很多。线上服务的核心指标往往是尾延迟而不是平均值这个取舍很划算。第三个是短请求拼批。多个短 prompt 拼成一个批次一起 Prefill能显著摊薄核函数启动开销前提是要处理好变长对齐别用简单 padding 把大量算力浪费在填充位上用变长注意力实现更好。这里要说清一个常见误解权重或激活量化在 Prefill 阶段收益很小甚至可能变负。因为这一阶段本来就是算力受限访存不是瓶颈省下来的带宽没处用反而多出了反量化的计算步骤。有些团队一上来就全局开 int8结果 Prefill 慢了 5%就是这个原因。5.2 Decode 侧省字节是唯一真理Decode 的优化逻辑完全反过来能让每一步少读一个字节都是胜利排序下来大概是这个顺序第一步权重量化。这是收益最直接、风险最低的手段。fp16 降到 int8权重字节直接减半单步时间理论上也减半降到 int4 再减半。实际会有 20%~30% 的折损反量化开销、精度损失导致的处理但整体仍是接近线性的加速。注意这是针对 Decode 的和上一条并不矛盾——分阶段看量化主要买的是解码速度。第二步压 KV 的体积。用更少的 KV headGQA 或 MQA是模型结构层面的事推理阶段能做的是 KV 量化。KV 从 fp16 压到 int8前面第三章那张并发表直接翻倍同时在长上下文下把每步的 KV 读取量减半。上下文越长收益越大2k 以内收益不明显32k 以上几乎是必选项。第三步缓存分页管理。传统做法是按最大长度给每个请求预留连续显存实际生成 200 token 却占了 8k 的空间浪费极其严重。分页的思路是把它拆成固定大小的块按需分配、用完释放整卡的有效并发能提升 2 到 4 倍。这项优化不影响单请求速度但对整体吞吐是量级上的改善。第四步投机解码。用一个很小的草稿模型连续猜出几个 token再让大模型做一次并行验证。验证这一步的形状是[batch, k1, hidden]走的是 Prefill 的并行路径一次前向就能确认好几个 token等于把串行的 k 步压成了并行的 1 步。这一步在访存受限的解码里收益特别大因为它的成本几乎全在大模型那一次验证上。接受率是关键参数实测中草稿模型和大模型同源、分布接近时4 个候选里能接受 2.5 到 3 个端到端能拿到 1.8 到 2.3 倍加速。接受率低于 50% 就没必要上了验证成本会吃掉全部收益。5.3 把两个阶段拆到不同机器上跑前面所有分析都在指向同一件事这两个阶段想要的东西完全相反。Prefill 想要大算力和大显存带宽Decode 想要大显存容量和能开超大 batch 的调度空间。混在同一张卡上跑两者会互相干扰——一个 32k 的 Prefill 请求能让所有解码请求卡顿几秒。于是就有了预填充与解码分离的部署形态一部分实例专门跑 Prefill追求低 TTFT另一部分专门跑 Decode把 batch 开到很满追求高吞吐中间通过高速链路把 KV Cache 传过去。这样两边的并行策略、batch 上限、量化精度都可以独立调优尾延迟会显著改善。代价也很实在多了一次几 GB 级别的 KV 传输网络必须够快否则搬运时间比省下来的还多。而且架构复杂度上升需要处理实例故障、负载不均、缓存一致性的问题。我的经验是只有在中大型服务、且长 prompt 占比较高时这套架构才划算请求以短问答为主、TTFT 要求不苛刻的场景用连续批处理加切块预填充就够了不必上这套。6. 踩坑实录与排查速查表6.1 症状对照表下面这张表是我这几年攒下来的遇到性能异常基本都能在里面找到对应项症状最可能的原因怎么验证处理方向并发上去了吞吐不涨KV Cache 挤占带宽或显存不够开始换出对比不同上下文下的 TPOT看是否随 ctx 线性变差上 KV 量化、降并发、启用分页缓存TTFT 正常但逐字极慢纯 Decode 问题权重没压或 batch 太小单请求 TPOT 与理论带宽下界对比权重量化、加大 batch、查 kernel 效率整体利用率只有 30%两个阶段互相阻塞或核启动开销大profile 看时间轴空隙占比切块预填充、计算图捕获加了张量并行反而变慢Decode 通信开销无法被计算掩盖单卡 vs 多卡的 TPOT 对比只在 Prefill 侧加并行或换分离架构长 prompt 一来全服务卡顿单个 Prefill 独占了 GPU 几秒观察 TPOT 的 p99 尖峰限制单次 Prefill 长度切块调度换成 int4 后质量明显下降激活异常值没处理对比量化前后输出困惑度用分组量化保留关键层高精度测速比理论带宽还快计时没做 GPU 同步检查计时前后是否有同步补上同步再测6.2 几条血泪经验别拿平均延迟做决策。线上服务最要命的是 p99。一个 32k 的 Prefill 请求能把 p99 顶到三秒以上而平均值看起来一切正常。我现在的习惯是压测时把 TTFT 和 TPOT 的 p50、p90、p99 一起打印任何一项恶化超过 50% 就要回退。先算理论下界再看实测。拿到一个卡和模型先用带宽算一遍 Decode 的单步下界用算力算一遍 Prefill 的下界。实测如果离下界不到 1.5 倍说明实现已经很好了别在那里死磕差三四倍那一定有大问题值得深挖。这个方法帮我省过好几次无意义的调优。量化不要全局统一开。权重、KV、激活是三个独立的旋钮影响完全不同。权重和 KV 量化主要买解码速度和显存激活量化在 Prefill 上可能变负收益。合理的组合通常是权重 int4 或 int8看质量余量KV int8长上下文必开激活保持 fp16 或做离群值保护。一次只动一个旋钮跑完对比再动下一个。容量规划按最坏上下文算不要按平均。平均 2k 上下文不代表不会有 32k 的请求。一旦来了一个它独占的 KV 可能让所有并发降级。宁可按 p95 上下文规划并发多留余量的成本比线上抖动带来的损失低得多。小模型上的测试结论不要直接外推。参数量越小Decode 的权重读取量越少KV 占比越高量化带来的收益比例和对长上下文的敏感度都和大模型不一样。在 1B 上测出来的最优批量策略换到 70B 上很可能完全相反因为后者的权重读取占了绝对主导。我个人在实际操作中的体会是绝大多数推理性能问题都藏在那两个数字里单个 token 的 KV 字节数和模型的权重字节数。把这两个数记住再记住你手上那张卡的带宽剩下的推理题基本都能用心算解决大半——Decode 快不快看这两个字节数能不能被带宽吃下Prefill 快不快看浮点运算能不能被算力吃下。真正需要跑 benchmark 的地方往往是这两个比值已经接近临界的时候那时候再去 profile 里找那 10% 到 20% 的细节损耗才最有效率。
