模型跑通 demo 那一步大多数人一晚上就能搞定。真正让人掉头发的是把推理请求从“一次能跑”变成“每次都快、并发不崩、坏的时候能快速定位”。我在这个阶段踩过不少坑第一次压测时首 token 等了快三秒并发一加就爆显存还有那种偶发性的卡一下又恢复查了半天也没个头绪。这篇文章把这段过程按“理论账—故障排查—性能调优—落地验证”串起来适合正在做大模型推理服务部署、或者已经把服务跑起来但总被性能和稳定性问题折磨的人。内容不绕弯子能直接复用的步骤我会直接写出来。1. 算清推理的三本账延时账单、显存账单和带宽账单很多调优做不好是因为不知道瓶颈在哪。一上来就调量化、开批处理、上投机解码看着像在优化其实是在乱打。我在动手之前习惯先把三本账算清楚一次请求的时间花在哪、显存被谁吃了、解码速度的上限被什么卡住。1.1 一次请求里的两个阶段为什么差异巨大大模型推理是自回归生成一个请求可以拆成两个阶段prefill 和 decode。prefill 阶段把用户的整段 prompt 一次性送进模型并行计算所有位置的注意力此时 GPU 的计算单元基本可以拉满属于“计算密集”。decode 阶段是逐个生成 token每一步只能产出下一个 token然后把新 token 拼进上下文再算一次属于“访存密集”。这两个阶段的性能特征完全不同所以优化手段也不一样。如果首 token 慢问题出在 prefill如果 token 之间吞吐慢、每秒产出字数上不去问题出在 decode。调试时最忌讳拿一个笼统的“慢”去查一定要先分清慢在哪个阶段。用个生活类比prefill 像一口气读完一页书decode 像每个字都要停下来翻一次笔记。1.2 显存账权重、KV Cache 和临时激活值的规模感显存爆掉是最常见的推理故障而大多数人等到爆了才去看。其实显存占用可以提前算大头有三个——模型权重、KV Cache、临时激活值与中间缓冲。先说权重。一个 7B 模型用 FP16 精度参数七亿个每个占 2 字节大约 14GB。如果量化成 8 位降到 7GB4 位再砍一半约 3.5GB。这是静态的加载后一直占着。然后是 KV Cache。生成每个 token 时注意力层的历史键值对会被缓存下来避免每步重算。计算公式大致是2 × 层数 × KV 头数 × 头维度 × 字节数算出的结果就是每个 token 占用的显存。以某个常见的 32 层、8 个 KV 头、头维度 128 的模型为例FP16 下每个 token 约 0.125MB。4096 token 的上下文就是约 0.5GB128K 超长上下文直接到 16GB 量级。KV Cache 是动态的和并发数、序列长度成正比也是推理服务显存规划的真正变量。我一般按这个顺序估算一个服务的显存上限静态权重 最大并发数 × 平均序列长度 × 单 token cache 大小 20% 余量。余量是给激活值和临时 buffer 的新手常常漏掉这一块导致显存看起来算得刚好跑起来一压就挂。1.3 带宽账decode 速度的天花板其实写在硬件规格里decode 阶段有个容易被忽略的物理约束每生成一个 token都要把模型权重从显存里完整读一遍。因为每一步都要和全部权重做矩阵运算权重在 HBM 和计算单元之间来回搬运。所以单用户 decode 的上限约等于显存带宽除以权重大小。拿某款显存带宽约 3TB/s 的旗舰卡举例跑 FP16 的 7B 模型权重 14GB理论上限约每秒 210 个 token。注意这是理论值实际还得算上核函数调度、注意力计算、采样开销能跑到一半已经不错了。这条物理规律引出了几个关键结论降精度不只是省显存它能直接减少每步读取的字节数等效提高 decode 速度批量推理能摊薄权重读取的开销因为多个请求共用一次权重搬运投机解码能减少权重读取次数因为它用一个小模型先草拟若干 token大模型只做一次验证。后面调优的所有手段本质上都在围绕“减少权重搬运”或“摊薄权重搬运”做文章。2. 故障排查不靠猜从现象倒推根因的完整链路排查故障最忌讳的是“看着像什么就去调什么”。显存溢出就开量化偶发变慢就加机器结果问题反反复复。我现在的习惯是把现象拆细按链路倒推每一步用数据确认而不是用感觉确认。2.1 显存溢出先分清楚是“真的不够”还是“碎片挤的”显存溢出OOM报错人人都会看但根因未必相同。我把它分成两类一类是静态容量不够另一类是动态碎片化。先看第一种。如果你用 GPU 状态工具查到的显存占用率长期接近 100%并且并发数稍微一抬就报错基本是容量不够。按 1.2 的公式算理论占用如果确实超了优先降量化精度、限制最大序列长度、降低并发上限。这几个动作最直接。第二种情况隐蔽一些显存总占用看起来只有 70%但一加大并发偶尔就报 OOM或者跑一段时间后突然报错。这时候多数是显存碎片化或缓存分配策略的问题。原因是 KV Cache 这类动态显存按需申请反复分配释放会把显存切得支离破碎新的大块申请找不到连续空间。处理办法包括开启显存预分配、改用页式显存管理类似操作系统的内存分页把不连续的小块拼给上层用、或者定时重启进程释放碎片。排查时顺序很重要先看总量够不够再看碎片最后才怀疑框架 bug。我遇到过几次“看起来像 OOM 实际是并发请求把临时缓冲顶爆”的情况把批量上限调低一点就恢复了并没有真正触碰容量红线。2.2 请求慢和偶发卡顿CPU、GPU 和通信三段的排查顺序推理链路不止 GPU 上那段算子还有网络接收、tokenizer 编码、请求排队、采样后处理、结果回传。很多“GPU 没吃满但就是慢”的案例瓶颈根本不在 GPU。我的排查顺序固定为三段先看请求在哪一段耗时最大再看资源使用曲线最后定位具体算子。第一步先看服务日志里的阶段耗时拆解确认慢的是排队、prefill 还是 decode。第二步看 CPU 和 GPU 的利用率曲线如果 GPU 利用率低但 CPU 居高不下问题大概率在前处理、tokenizer、采样逻辑上如果 GPU 利用率高但 token 速度不理想重点查显存带宽和核函数调度如果两者都不高很可能是请求排队等待或网络传输卡住了。偶发卡顿比持续慢更难查因为它往往和某个偶然条件相关比如某个长 prompt 触发了超长序列的 KV Cache 分配或者某次并发峰值把 CPU 打满。我的建议是给服务加“慢请求日志”把所有超过阈值比如 5 秒的请求都记下当时的输入长度、并发数、资源占用跑一两天再来对照通常能找到共同点而不是守在那里瞎猜。2.3 输出质量异常不要急着怀疑模型权重有一种故障容易被归到“玄学”里服务没报错显存正常速度也正常但输出开始乱码、重复、答非所问。这时候我建议先怀疑五个地方。第一tokenizer 词汇表是否和模型匹配加载模型时用了不同的分词配置解码出来的内容会直接变乱码。第二采样参数是否合理温度设得太高、top_k 设得太小都可能让输出在正常词汇里“发疯”。第三最大长度和停止符配置是否有误输出被截断或被停止符提前打断都会表现为对话不完整。第四请求上下文有没有被错误拼接多轮对话时历史消息串了输出自然不对。第五KV Cache 有没有跨请求污染如果缓存复用逻辑有 bugA 请求的上下文会影响 B 请求的输出。我的习惯是遇到输出异常先固定一个极短的标准 prompt用同一随机种子反复跑几遍。如果短 prompt 输出稳定、长对话才出问题优先查上下文拼接和 Cache 复用如果短 prompt 就不对优先查 tokenizer 和采样配置。这个二分法能快速排除一大半可能性而不是先把模型重新下下来。3. 调优不是堆参数量化、批处理、KV Cache 与投机解码的取舍到了调优阶段真正的难点不是“不知道有哪些技术”而是“不知道当前场景该用哪一项、代价是什么”。每一项优化都有副作用以下优先顺序是我实际测试中比较稳的一条路径先量化再开连续批处理再优化 KV Cache最后考虑投机解码。3.1 量化降低精度不只是为了省显存更是为了提速量化是收益最快的优化。FP16 换 BF16 基本无损可以直接开。FP8 在有校准数据的情况下质量损失很小是当前性价比很高的档位。INT4 能把 7B 模型压到 4GB 以内但质量下降开始变得可感知需要任务验证。很多人只把量化当省显存手段其实它对 decode 提速也很关键。按 1.3 的带宽账权重越小每步需要从显存读的数据越少单用户 token 速度越快。同一个 7B 模型从 FP16 换成 INT4decode 理论上限可以提升三到四倍。当然实际收益会打折扣因为 INT4 的反量化也有计算开销但方向是正确的。量化落地有两条路训练后量化PTQ和量化感知训练QAT。推理服务首选 PTQ因为它不需要重新训练模型只需要一小批校准数据来确定量化范围。校准数据的分布越接近线上真实数据越好如果拿通用文本校准上线后遇到领域专有名词多的情况精度掉得会比较明显。我一般会在量化后用一组固定的领域测试问句做对照看看输出质量和耗时变化再决定是否上线。3.2 连续批处理把等待粗糙请求的空档填起来静态批处理的问题在于批大小固定一个慢请求会把整批拖住。连续批处理做得聪明多了每个请求不再等整批结束而是随时插入、随时退出类似餐厅里一桌吃完立刻翻台而不是等所有桌一起吃完才接待下一轮。这项技术对吞吐的提升非常明显在很多推理框架里已经成为默认选项。但连续批处理不是免费的。批大小变大意味着单次 decode 要同时处理多个请求每个 token 的权重搬运被摊薄了整体吞吐涨单个请求的 token 等待时间反而可能变长。如果你做的是对时延极其敏感的场景比如实时对话就要注意控制最大并发批大小不能一味追求吞吐。我实际测试中的做法是先不加并发限制跑一轮看看 P50 时延能不能接受如果不能把最大批大小逐步下调找到一个吞吐和时延的平衡点。这个平衡点跟模型大小、显存带宽、请求长度分布都有关系没有固定值必须用自己的数据压出来。3.3 KV Cache 管理从一次性分配走向显存复用KV Cache 是动态显存的大头也是优化空间最大的地方。最粗暴的做法是按最大序列长度给每个请求一次性分配省事但浪费惊人。如果线上平均请求只有 2K 上下文却按 32K 上限预留显存利用率会惨不忍睹。更合理的方案是让 KV Cache 按需增长类似动态数组用到多少扩多少。再进一步很多推理框架实现了页式管理把 KV Cache 切成小块按需映射到物理显存页既能缓解碎片问题又能把不连续的空闲显存利用起来。这就像操作系统里的内存分页虚拟地址连续不代表物理地址连续反而更容易利用零碎空间。另外还有一些业务层面的 KV Cache 优化比如多轮对话场景复用共用前缀的 KV Cache或者给长时间不活跃的会话做缓存淘汰。这些优化在长对话、Agent 类应用中收益很大但实现复杂度也高。我建议先做按需分配和历史清理这两个是投入产出比最高的前缀缓存、跨请求共享这类高阶玩法等基础稳定了再引入。3.4 投机解码以额外算力换低时延的“取巧”投机解码的思路是先用一个又小又快的小模型草拟 k 个 token再用大模型一次验证这些草稿。如果草稿全部被接受一次大模型前向就产出了 k 个 tokendecode 延迟能降低好几倍如果草稿错了回退到普通生成多花的只是小模型的推理时间。这个策略听起来很理想但有两个现实条件。一是小模型要和目标模型输出分布足够接近否则草稿命中率低反而拖慢速度。二是整体收益在低并发场景更明显因为高并发下大模型本来就已经在批量处理权重搬运被摊薄投机解码省下的那点前向次数意义没那么大。我印象比较深的一次测试是低并发、短输出场景下投机解码把解码时间几乎砍半但把并发提到较高水平后收益缩水到几乎可忽略。所以我的建议是先用量化、批处理、KV Cache 把基础打牢如果还有低时延的业务诉求再专门拉一组压测验证投机解码是否值得开。不要把这项技术当成默认选项。4. 从调优到落地压测基线的建立、观测手段与配置模板调优最怕“自我感觉良好”。你觉得改了配置快了但拿不出数据你觉得线上稳定但出了问题连对比基线都没有。所以我所有的调整都会先落到一套可复现的压测流程和观测清单上宁可多花半天搭也不能凭感觉上线。4.1 建基线固定输入长度和并发测 P50/P95/P99没有基线的优化全是耍流氓。我压测时固定三件事输入长度、输出长度、并发数。不能随便拿几个问题测那样输入长度差异太大数据没法比。我会构造三档 prompt短文本约 100 token、中等约 1K token、长文本约 4K token输出统一固定在一个长度比如 256 token。然后记录四个核心指标首 token 时延TTFT、每 token 生成耗时TPOT、端到端时延、吞吐。并发从 1 开始依次往上加观察 P50、P95、P99 三个分位数。P50 反映大多数用户的体验P95 和 P99 反映最差情况推理服务如果只看平均值会被少数慢请求坑哭。压测过程和结果表格大概是这样的并发输入长度TTFT-P50TTFT-P99TPOT-P50吞吐 tokens/s11K350ms420ms55ms1881K520ms780ms90ms85161K950ms1.8s150ms105这套数据出来之后大约就能判断系统离瓶颈有多远并发加到某个点 TTFT 突然恶化通常说明排队过长TPOT 持续上涨说明批处理摊薄了权重读取也分摊了每个请求的带宽。调整后再跑同一套流程对比才有意义。4.2 单变量对照一次只动一个旋钮用数据说话调优过程中最容易犯的错是“多变量同时改”。开了量化、调大了批处理、又顺手改了采样参数结果变快了你根本不知道是哪个动作起的作用变慢了也没法定位是谁拖的后腿。我严格规定自己一次只动一个变量。比如这一轮只改量化精度FP16 测一轮INT8 测一轮INT4 测一轮所有批处理配置保持不变。下一轮再单独调最大批大小。每次对照同一套压测流程把数据和上一轮放在一起看。这样虽然慢但每一次改动都算得清楚。而且很多优化之间是有相互作用的比如量化减少权重规模后同样显存能容纳的并发批大小会变大这时你再单独调批大小才能看到二级收益。如果同时改你永远搞不清是量化带来的显存空间还是批大小策略本身更优。4.3 一个可参考的推理服务配置模板下面这个配置模板是我在通用场景下反复调出来的一个比较稳的起步点不是标准答案但能给第一次进入这个领域的人一个参照系。按模型规模不同按比例调整。配置项推荐起步值理由模型精度FP8 或 INT8 量化质量损失小显存和省带宽收益明显最大批大小动态初始不设硬上限先用连续批处理看自然表现最大序列长度按业务需求设定不要按模型上限过高的上限会浪费大量 KV Cache 预留KV Cache 分配按需增长 页式管理减少浪费缓解碎片投机解码默认关闭低并发时按需验证后再开输入预处理独立于 GPU 线程池避免 tokenizer 和采样逻辑抢占 GPU 资源请求排队上限设置一个合理值保护服务不被无限积压拖垮如果你跑的是长上下文场景比如几十 K 以上的 Agent 或文档分析建议把最大序列长度和 KV Cache 预规划单独拉出来做一轮专项测试因为长序列对显存的影响远比普通对话夸张。4.4 上线后的监控清单什么指标要盯什么现象要立刻报警调优不是上线那天结束而是上线那天才开始。我维护一份精简的监控清单每天看一遍避免故障在意想不到的时间点冒出来。显存占用率与显存碎片率如果占用率缓慢爬升到高位或者碎片率升高关注 KV Cache 泄漏与复用失效。GPU 利用率曲线利用率长期低于 30% 说明不过载但若伴随高延迟大概率瓶颈在 CPU 侧或排队。TTFT 和 TPOT 分位数P99 持续走高是第一警报它往往比平均值早一步反映问题。请求排队长度接近上限时说明容量不足需要扩容或限流。重启与异常报错次数偶发报错也要记录下来不要因为服务恢复了就当作无事发生。这几项不需要复杂的系统日志里打好点画几张曲线就行。真正重要是坚持看。我吃过好几次亏某个指标只在夜里攻击性升高第二天早上恢复正常等到用户反馈才发现已经抖了一整晚。后来加了定时巡检才把这类问题拦住。5. 我刻意练出来的几个判断习惯最后分享几个我用真金白银换来的判断习惯不算总结算清单。第一先量后调先正确后性能。拿到一个新服务我第一件事不是去调参数而是把旧的一套压测流程跑一遍确认所有功能正确、输出稳定。然后再开始调优。“先调正确性、后调性能”顺序反了会浪费大量时间在假问题上。第二动态显存问题优先查 KV Cache其次是批处理上限最后才怀疑量化。因为 KV Cache 和并发强相关是动态波动最容易踩雷的地方。我碰到过两次“跑着跑着变慢、显存没满但偶发 OOM”的情况最后都落在缓存复用的显存碎片上跟模型精度一点关系都没有。第三不要迷信任何单个优化技术。“上投机解码就快一倍”“INT4 一定能压到 4G”这些结论只在特定条件下成立。我在不同模型、不同并发、不同请求长度下测到的结果差距很大同一个配置换一个模型可能完全失效。唯一稳妥的方式永远是自己的压测数据。第四偶发问题靠日志不要靠肉眼盯屏。给服务打完整的请求级日志记录时长、输入长度、并发、错误码。肉眼盯 GPU 状态只能看到当时的情况而日志能把问题发生前后的上下文完整回放出来。遇到再难查的偶发问题有一份高质量日志至少能帮你排除一半的可能。推理服务调优没有一劳永逸的银弹它更多是“算清账、找瓶颈、做取舍、看数据”的循环。把这个循环跑顺了服务想不稳定都难。
模型跑通 demo 那一步大多数人一晚上就能搞定。真正让人掉头发的是把推理请求从“一次能跑”变成“每次都快、并发不崩、坏的时候能快速定位”。我在这个阶段踩过不少坑第一次压测时首 token 等了快三秒并发一加就爆显存还有那种偶发性的卡一下又恢复查了半天也没个头绪。这篇文章把这段过程按“理论账—故障排查—性能调优—落地验证”串起来适合正在做大模型推理服务部署、或者已经把服务跑起来但总被性能和稳定性问题折磨的人。内容不绕弯子能直接复用的步骤我会直接写出来。1. 算清推理的三本账延时账单、显存账单和带宽账单很多调优做不好是因为不知道瓶颈在哪。一上来就调量化、开批处理、上投机解码看着像在优化其实是在乱打。我在动手之前习惯先把三本账算清楚一次请求的时间花在哪、显存被谁吃了、解码速度的上限被什么卡住。1.1 一次请求里的两个阶段为什么差异巨大大模型推理是自回归生成一个请求可以拆成两个阶段prefill 和 decode。prefill 阶段把用户的整段 prompt 一次性送进模型并行计算所有位置的注意力此时 GPU 的计算单元基本可以拉满属于“计算密集”。decode 阶段是逐个生成 token每一步只能产出下一个 token然后把新 token 拼进上下文再算一次属于“访存密集”。这两个阶段的性能特征完全不同所以优化手段也不一样。如果首 token 慢问题出在 prefill如果 token 之间吞吐慢、每秒产出字数上不去问题出在 decode。调试时最忌讳拿一个笼统的“慢”去查一定要先分清慢在哪个阶段。用个生活类比prefill 像一口气读完一页书decode 像每个字都要停下来翻一次笔记。1.2 显存账权重、KV Cache 和临时激活值的规模感显存爆掉是最常见的推理故障而大多数人等到爆了才去看。其实显存占用可以提前算大头有三个——模型权重、KV Cache、临时激活值与中间缓冲。先说权重。一个 7B 模型用 FP16 精度参数七亿个每个占 2 字节大约 14GB。如果量化成 8 位降到 7GB4 位再砍一半约 3.5GB。这是静态的加载后一直占着。然后是 KV Cache。生成每个 token 时注意力层的历史键值对会被缓存下来避免每步重算。计算公式大致是2 × 层数 × KV 头数 × 头维度 × 字节数算出的结果就是每个 token 占用的显存。以某个常见的 32 层、8 个 KV 头、头维度 128 的模型为例FP16 下每个 token 约 0.125MB。4096 token 的上下文就是约 0.5GB128K 超长上下文直接到 16GB 量级。KV Cache 是动态的和并发数、序列长度成正比也是推理服务显存规划的真正变量。我一般按这个顺序估算一个服务的显存上限静态权重 最大并发数 × 平均序列长度 × 单 token cache 大小 20% 余量。余量是给激活值和临时 buffer 的新手常常漏掉这一块导致显存看起来算得刚好跑起来一压就挂。1.3 带宽账decode 速度的天花板其实写在硬件规格里decode 阶段有个容易被忽略的物理约束每生成一个 token都要把模型权重从显存里完整读一遍。因为每一步都要和全部权重做矩阵运算权重在 HBM 和计算单元之间来回搬运。所以单用户 decode 的上限约等于显存带宽除以权重大小。拿某款显存带宽约 3TB/s 的旗舰卡举例跑 FP16 的 7B 模型权重 14GB理论上限约每秒 210 个 token。注意这是理论值实际还得算上核函数调度、注意力计算、采样开销能跑到一半已经不错了。这条物理规律引出了几个关键结论降精度不只是省显存它能直接减少每步读取的字节数等效提高 decode 速度批量推理能摊薄权重读取的开销因为多个请求共用一次权重搬运投机解码能减少权重读取次数因为它用一个小模型先草拟若干 token大模型只做一次验证。后面调优的所有手段本质上都在围绕“减少权重搬运”或“摊薄权重搬运”做文章。2. 故障排查不靠猜从现象倒推根因的完整链路排查故障最忌讳的是“看着像什么就去调什么”。显存溢出就开量化偶发变慢就加机器结果问题反反复复。我现在的习惯是把现象拆细按链路倒推每一步用数据确认而不是用感觉确认。2.1 显存溢出先分清楚是“真的不够”还是“碎片挤的”显存溢出OOM报错人人都会看但根因未必相同。我把它分成两类一类是静态容量不够另一类是动态碎片化。先看第一种。如果你用 GPU 状态工具查到的显存占用率长期接近 100%并且并发数稍微一抬就报错基本是容量不够。按 1.2 的公式算理论占用如果确实超了优先降量化精度、限制最大序列长度、降低并发上限。这几个动作最直接。第二种情况隐蔽一些显存总占用看起来只有 70%但一加大并发偶尔就报 OOM或者跑一段时间后突然报错。这时候多数是显存碎片化或缓存分配策略的问题。原因是 KV Cache 这类动态显存按需申请反复分配释放会把显存切得支离破碎新的大块申请找不到连续空间。处理办法包括开启显存预分配、改用页式显存管理类似操作系统的内存分页把不连续的小块拼给上层用、或者定时重启进程释放碎片。排查时顺序很重要先看总量够不够再看碎片最后才怀疑框架 bug。我遇到过几次“看起来像 OOM 实际是并发请求把临时缓冲顶爆”的情况把批量上限调低一点就恢复了并没有真正触碰容量红线。2.2 请求慢和偶发卡顿CPU、GPU 和通信三段的排查顺序推理链路不止 GPU 上那段算子还有网络接收、tokenizer 编码、请求排队、采样后处理、结果回传。很多“GPU 没吃满但就是慢”的案例瓶颈根本不在 GPU。我的排查顺序固定为三段先看请求在哪一段耗时最大再看资源使用曲线最后定位具体算子。第一步先看服务日志里的阶段耗时拆解确认慢的是排队、prefill 还是 decode。第二步看 CPU 和 GPU 的利用率曲线如果 GPU 利用率低但 CPU 居高不下问题大概率在前处理、tokenizer、采样逻辑上如果 GPU 利用率高但 token 速度不理想重点查显存带宽和核函数调度如果两者都不高很可能是请求排队等待或网络传输卡住了。偶发卡顿比持续慢更难查因为它往往和某个偶然条件相关比如某个长 prompt 触发了超长序列的 KV Cache 分配或者某次并发峰值把 CPU 打满。我的建议是给服务加“慢请求日志”把所有超过阈值比如 5 秒的请求都记下当时的输入长度、并发数、资源占用跑一两天再来对照通常能找到共同点而不是守在那里瞎猜。2.3 输出质量异常不要急着怀疑模型权重有一种故障容易被归到“玄学”里服务没报错显存正常速度也正常但输出开始乱码、重复、答非所问。这时候我建议先怀疑五个地方。第一tokenizer 词汇表是否和模型匹配加载模型时用了不同的分词配置解码出来的内容会直接变乱码。第二采样参数是否合理温度设得太高、top_k 设得太小都可能让输出在正常词汇里“发疯”。第三最大长度和停止符配置是否有误输出被截断或被停止符提前打断都会表现为对话不完整。第四请求上下文有没有被错误拼接多轮对话时历史消息串了输出自然不对。第五KV Cache 有没有跨请求污染如果缓存复用逻辑有 bugA 请求的上下文会影响 B 请求的输出。我的习惯是遇到输出异常先固定一个极短的标准 prompt用同一随机种子反复跑几遍。如果短 prompt 输出稳定、长对话才出问题优先查上下文拼接和 Cache 复用如果短 prompt 就不对优先查 tokenizer 和采样配置。这个二分法能快速排除一大半可能性而不是先把模型重新下下来。3. 调优不是堆参数量化、批处理、KV Cache 与投机解码的取舍到了调优阶段真正的难点不是“不知道有哪些技术”而是“不知道当前场景该用哪一项、代价是什么”。每一项优化都有副作用以下优先顺序是我实际测试中比较稳的一条路径先量化再开连续批处理再优化 KV Cache最后考虑投机解码。3.1 量化降低精度不只是为了省显存更是为了提速量化是收益最快的优化。FP16 换 BF16 基本无损可以直接开。FP8 在有校准数据的情况下质量损失很小是当前性价比很高的档位。INT4 能把 7B 模型压到 4GB 以内但质量下降开始变得可感知需要任务验证。很多人只把量化当省显存手段其实它对 decode 提速也很关键。按 1.3 的带宽账权重越小每步需要从显存读的数据越少单用户 token 速度越快。同一个 7B 模型从 FP16 换成 INT4decode 理论上限可以提升三到四倍。当然实际收益会打折扣因为 INT4 的反量化也有计算开销但方向是正确的。量化落地有两条路训练后量化PTQ和量化感知训练QAT。推理服务首选 PTQ因为它不需要重新训练模型只需要一小批校准数据来确定量化范围。校准数据的分布越接近线上真实数据越好如果拿通用文本校准上线后遇到领域专有名词多的情况精度掉得会比较明显。我一般会在量化后用一组固定的领域测试问句做对照看看输出质量和耗时变化再决定是否上线。3.2 连续批处理把等待粗糙请求的空档填起来静态批处理的问题在于批大小固定一个慢请求会把整批拖住。连续批处理做得聪明多了每个请求不再等整批结束而是随时插入、随时退出类似餐厅里一桌吃完立刻翻台而不是等所有桌一起吃完才接待下一轮。这项技术对吞吐的提升非常明显在很多推理框架里已经成为默认选项。但连续批处理不是免费的。批大小变大意味着单次 decode 要同时处理多个请求每个 token 的权重搬运被摊薄了整体吞吐涨单个请求的 token 等待时间反而可能变长。如果你做的是对时延极其敏感的场景比如实时对话就要注意控制最大并发批大小不能一味追求吞吐。我实际测试中的做法是先不加并发限制跑一轮看看 P50 时延能不能接受如果不能把最大批大小逐步下调找到一个吞吐和时延的平衡点。这个平衡点跟模型大小、显存带宽、请求长度分布都有关系没有固定值必须用自己的数据压出来。3.3 KV Cache 管理从一次性分配走向显存复用KV Cache 是动态显存的大头也是优化空间最大的地方。最粗暴的做法是按最大序列长度给每个请求一次性分配省事但浪费惊人。如果线上平均请求只有 2K 上下文却按 32K 上限预留显存利用率会惨不忍睹。更合理的方案是让 KV Cache 按需增长类似动态数组用到多少扩多少。再进一步很多推理框架实现了页式管理把 KV Cache 切成小块按需映射到物理显存页既能缓解碎片问题又能把不连续的空闲显存利用起来。这就像操作系统里的内存分页虚拟地址连续不代表物理地址连续反而更容易利用零碎空间。另外还有一些业务层面的 KV Cache 优化比如多轮对话场景复用共用前缀的 KV Cache或者给长时间不活跃的会话做缓存淘汰。这些优化在长对话、Agent 类应用中收益很大但实现复杂度也高。我建议先做按需分配和历史清理这两个是投入产出比最高的前缀缓存、跨请求共享这类高阶玩法等基础稳定了再引入。3.4 投机解码以额外算力换低时延的“取巧”投机解码的思路是先用一个又小又快的小模型草拟 k 个 token再用大模型一次验证这些草稿。如果草稿全部被接受一次大模型前向就产出了 k 个 tokendecode 延迟能降低好几倍如果草稿错了回退到普通生成多花的只是小模型的推理时间。这个策略听起来很理想但有两个现实条件。一是小模型要和目标模型输出分布足够接近否则草稿命中率低反而拖慢速度。二是整体收益在低并发场景更明显因为高并发下大模型本来就已经在批量处理权重搬运被摊薄投机解码省下的那点前向次数意义没那么大。我印象比较深的一次测试是低并发、短输出场景下投机解码把解码时间几乎砍半但把并发提到较高水平后收益缩水到几乎可忽略。所以我的建议是先用量化、批处理、KV Cache 把基础打牢如果还有低时延的业务诉求再专门拉一组压测验证投机解码是否值得开。不要把这项技术当成默认选项。4. 从调优到落地压测基线的建立、观测手段与配置模板调优最怕“自我感觉良好”。你觉得改了配置快了但拿不出数据你觉得线上稳定但出了问题连对比基线都没有。所以我所有的调整都会先落到一套可复现的压测流程和观测清单上宁可多花半天搭也不能凭感觉上线。4.1 建基线固定输入长度和并发测 P50/P95/P99没有基线的优化全是耍流氓。我压测时固定三件事输入长度、输出长度、并发数。不能随便拿几个问题测那样输入长度差异太大数据没法比。我会构造三档 prompt短文本约 100 token、中等约 1K token、长文本约 4K token输出统一固定在一个长度比如 256 token。然后记录四个核心指标首 token 时延TTFT、每 token 生成耗时TPOT、端到端时延、吞吐。并发从 1 开始依次往上加观察 P50、P95、P99 三个分位数。P50 反映大多数用户的体验P95 和 P99 反映最差情况推理服务如果只看平均值会被少数慢请求坑哭。压测过程和结果表格大概是这样的并发输入长度TTFT-P50TTFT-P99TPOT-P50吞吐 tokens/s11K350ms420ms55ms1881K520ms780ms90ms85161K950ms1.8s150ms105这套数据出来之后大约就能判断系统离瓶颈有多远并发加到某个点 TTFT 突然恶化通常说明排队过长TPOT 持续上涨说明批处理摊薄了权重读取也分摊了每个请求的带宽。调整后再跑同一套流程对比才有意义。4.2 单变量对照一次只动一个旋钮用数据说话调优过程中最容易犯的错是“多变量同时改”。开了量化、调大了批处理、又顺手改了采样参数结果变快了你根本不知道是哪个动作起的作用变慢了也没法定位是谁拖的后腿。我严格规定自己一次只动一个变量。比如这一轮只改量化精度FP16 测一轮INT8 测一轮INT4 测一轮所有批处理配置保持不变。下一轮再单独调最大批大小。每次对照同一套压测流程把数据和上一轮放在一起看。这样虽然慢但每一次改动都算得清楚。而且很多优化之间是有相互作用的比如量化减少权重规模后同样显存能容纳的并发批大小会变大这时你再单独调批大小才能看到二级收益。如果同时改你永远搞不清是量化带来的显存空间还是批大小策略本身更优。4.3 一个可参考的推理服务配置模板下面这个配置模板是我在通用场景下反复调出来的一个比较稳的起步点不是标准答案但能给第一次进入这个领域的人一个参照系。按模型规模不同按比例调整。配置项推荐起步值理由模型精度FP8 或 INT8 量化质量损失小显存和省带宽收益明显最大批大小动态初始不设硬上限先用连续批处理看自然表现最大序列长度按业务需求设定不要按模型上限过高的上限会浪费大量 KV Cache 预留KV Cache 分配按需增长 页式管理减少浪费缓解碎片投机解码默认关闭低并发时按需验证后再开输入预处理独立于 GPU 线程池避免 tokenizer 和采样逻辑抢占 GPU 资源请求排队上限设置一个合理值保护服务不被无限积压拖垮如果你跑的是长上下文场景比如几十 K 以上的 Agent 或文档分析建议把最大序列长度和 KV Cache 预规划单独拉出来做一轮专项测试因为长序列对显存的影响远比普通对话夸张。4.4 上线后的监控清单什么指标要盯什么现象要立刻报警调优不是上线那天结束而是上线那天才开始。我维护一份精简的监控清单每天看一遍避免故障在意想不到的时间点冒出来。显存占用率与显存碎片率如果占用率缓慢爬升到高位或者碎片率升高关注 KV Cache 泄漏与复用失效。GPU 利用率曲线利用率长期低于 30% 说明不过载但若伴随高延迟大概率瓶颈在 CPU 侧或排队。TTFT 和 TPOT 分位数P99 持续走高是第一警报它往往比平均值早一步反映问题。请求排队长度接近上限时说明容量不足需要扩容或限流。重启与异常报错次数偶发报错也要记录下来不要因为服务恢复了就当作无事发生。这几项不需要复杂的系统日志里打好点画几张曲线就行。真正重要是坚持看。我吃过好几次亏某个指标只在夜里攻击性升高第二天早上恢复正常等到用户反馈才发现已经抖了一整晚。后来加了定时巡检才把这类问题拦住。5. 我刻意练出来的几个判断习惯最后分享几个我用真金白银换来的判断习惯不算总结算清单。第一先量后调先正确后性能。拿到一个新服务我第一件事不是去调参数而是把旧的一套压测流程跑一遍确认所有功能正确、输出稳定。然后再开始调优。“先调正确性、后调性能”顺序反了会浪费大量时间在假问题上。第二动态显存问题优先查 KV Cache其次是批处理上限最后才怀疑量化。因为 KV Cache 和并发强相关是动态波动最容易踩雷的地方。我碰到过两次“跑着跑着变慢、显存没满但偶发 OOM”的情况最后都落在缓存复用的显存碎片上跟模型精度一点关系都没有。第三不要迷信任何单个优化技术。“上投机解码就快一倍”“INT4 一定能压到 4G”这些结论只在特定条件下成立。我在不同模型、不同并发、不同请求长度下测到的结果差距很大同一个配置换一个模型可能完全失效。唯一稳妥的方式永远是自己的压测数据。第四偶发问题靠日志不要靠肉眼盯屏。给服务打完整的请求级日志记录时长、输入长度、并发、错误码。肉眼盯 GPU 状态只能看到当时的情况而日志能把问题发生前后的上下文完整回放出来。遇到再难查的偶发问题有一份高质量日志至少能帮你排除一半的可能。推理服务调优没有一劳永逸的银弹它更多是“算清账、找瓶颈、做取舍、看数据”的循环。把这个循环跑顺了服务想不稳定都难。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
