线上服务一上量，最常见的抱怨就是「首字慢、吐字卡、并发一高就排队」，于是有人上来就换框架、换卡、换模型，钱花了不少，速度没快多少。这篇不聊概念，只给一套动手顺序：先量出基线，再判断瓶颈在显存、批处理还是调度，然后按投入产出比逐项调，最后用同一套指标回测。每一步都告诉你什么情况下不用做。
线上服务一上量，最常见的抱怨就是「首字慢、吐字卡、并发一高就排队」。于是有人上来就换框架、换卡、换模型，钱花了不少，速度没快多少。问题往往不在硬件，而在于没人量过基线、没人分清瓶颈在哪一环。
这篇不聊概念，只给一套动手顺序：先量出基线，再判断瓶颈在显存、批处理还是调度，然后按投入产出比逐项调，最后用同一套指标回测。每一步都告诉你什么情况下不用做，省得你把时间花在无效改动上。
先量基线，别凭感觉优化
优化的第一步不是改配置，而是让现状可复现。没有基线，改完之后你连「快了没有」都说不清，只能靠体感吵架。基线要固定测试条件，否则前后数据没法比。
- 记录三类指标：首 token 延迟、单请求输出速度、固定并发下的总吞吐，缺一个都会误判
- 固定测试条件：同一提示词长度、同一输出长度、同一并发数，每次都用同一套输入
- 先用工具摸清接口侧延迟，区分是网络、网关还是模型本身慢
- 把结果存成一份可对比的记录，改动前先跑一遍，改动后照着跑
接口侧延迟排查可以到 /tools/speed-test 跑一轮，先看响应是不是卡在模型之外的环节。如果工具测出来的延迟和你在业务里感知的差很远，多半问题出在调用链路上，而不是推理本身。
| 指标 | 怎么测 | 误判风险 |
|---|---|---|
| 首 token 延迟 | 固定输入长度，连续请求取中位数 | 只测一次容易被冷启动干扰 |
| 单请求输出速度 | 固定输出长度，看 token 出速 | 输入长度不同会污染对比 |
| 固定并发总吞吐 | 同一并发数压测，看队列变化 | 并发一变，前后数据不可比 |
什么情况下不用做：离线批处理任务只看总耗时，首 token 延迟可以不测。你要是跑的是夜间批量任务，盯着首字时间没有意义。
定位瓶颈：显存、批处理还是调度
量完基线，接下来是判断卡在哪。不同瓶颈的表现差别很大，看错了方向，后面所有调整都是白费。显存吃紧会被迫降低并发或频繁卸载，表现是并发一上去速度反而掉。
- 显存瓶颈
- 并发一升速度反而降，或者显存告警频繁出现，先算清需求再谈优化
- 批处理瓶颈
- GPU 利用率长期偏低而请求队列在涨，说明批没攒起来
- 调度瓶颈
- 单请求不慢，并发一多就排队，多半是调度策略和并发上限没配好
- 算力瓶颈
- GPU 打满、队列也满，这才是真的卡不够
要算清显存需求，可以到 /compute/sizing 按你的模型规模和并发目标估一遍，避免盲目加卡。输入长、输出短的场景瓶颈常在预填充阶段，输入短输出长的则在逐 token 解码阶段，两者的优化方向不一样。
- 第一步 查显存看显存占用曲线和告警，确认是不是被显存压住了并发；先去 /compute/sizing 核对需求
- 第二步 查批处理与队列看 GPU 利用率与队列长度，利用率低而队列涨，优先调批处理参数
- 第三步 查调度单请求正常但并发排队，检查调度策略和并发上限
- 第四步 最后才考虑换框架或换硬件前三步都确认没问题、指标仍然上不去，再评估大改
什么情况下不用做：如果你的服务本身并发很低、请求稀疏，批处理和调度基本不是瓶颈，直接看单请求路径更省事。
能拧的几个旋钮，按性价比排序
旋钮不少，但投入产出比差很多。建议从改动最小、见效最直观的开始，大改留到最后。下面这张表按性价比排列。
| 旋钮 | 改什么 | 先决条件 | 什么时候别动 |
|---|---|---|---|
| 批处理与并发上限 | 开启连续批处理、限制最大并发数 | 基线已量清 | 请求极稀疏、并发本来就低 |
| 量化档位 | 换更低比特权重，换显存和吞吐 | 小样本效果回归通过 | 对精度敏感的生成任务 |
| KV 缓存与显存分配 | 调整预留比例，减少换入换出 | 显存已算清 | 显存本就宽裕，调了无感 |
| 上下文与输出上限 | 裁掉不必要的历史和超长输出 | 有请求日志可分析 | 业务确实依赖长上下文 |
| 并行与分片 | 张量并行、多卡拆分 | 前面几步都做完仍不够 | 单卡能撑住就别上 |
- 调批处理与并发上限：连续批处理、限制最大并发数，通常改动最小收益最直观
- 调量化档位：在精度可接受的前提下换更低比特权重，先做小样本效果回归
- 调 KV 缓存与显存分配比例：预留太多浪费显存，预留太少频繁换入换出
- 调上下文与输出上限：把不必要的历史塞进请求，等于每次都在为无用 token 付算力
- 上并行与分片：张量并行、多卡拆分属于大改，前面几步都做完再评估
想对比不同方案的实际价格和吞吐表现，可以到 /price-watch 看当时的数字，再到 /sites 核对你正在用的中转或服务商当前状态，避免拿过时信息做决策。
什么情况下不适用：量化这一步在精度敏感的场景要谨慎，比如结构化输出、需要严格格式的任务，先小样本回归再决定；如果业务对输出质量要求极高，宁可保留精度、从批处理和上下文裁剪上找空间。
回测与回退：改完必须能证伪
改完参数不等于优化成功。速度上去了，但格式开始错乱、截断变多、拒答变频繁，这种提速是负债。回测的意义就是让你能证明「这次改动是安全的」。
- 每次只改一个变量，改完用第一节那三个指标重测，记录改动前后的对照
- 质量必须同步回归：格式、截断、拒答率都要看，不能只看速度
- 准备回退方案：保留上一版参数与配置，出问题能在一次发布内切回去
- 把每次改动的变量、指标变化、结论记一条，下次遇到类似问题直接查
- 固定测试集准备一组固定输入，覆盖长短输入和典型业务场景
- 单变量改动一次只动一个参数，避免多个变量混在一起无法归因
- 三项指标重测首 token 延迟、输出速度、并发吞吐都比一遍
- 质量回归检查输出格式、截断比例、异常拒答是否变多
- 决定保留还是回退速度与质量都达标才保留，否则切回上一版配置
什么情况下不适用：一次性离线任务、内部测试环境可以放宽回测要求，只要结果在可接受范围内就行，不必走完整流程。
如果你还在选型阶段，想先看看不同接入方式的稳定性与价格走势，可以到 /rankings 翻一翻，再到 /sites 逐家核对当前状态，比拍脑袋选要稳。
下一步先跑一轮基线，再按本文顺序排查瓶颈，把结论存下来。→常见问题
不换显卡，光靠调参数能提速多少？
取决于当前是不是「没配好」。如果显存吃紧或批处理闲置，调参数往往能有明显改善；如果卡本身已经打满、显存也宽裕，那说明算力到顶了，再调只是小修小补，这时候要谈的是换卡、换量化或者换更小的模型。先按瓶颈定位走一遍再下结论。具体规格对照可以去 /compute/gpus 和 /compute/sizing 看当时的口径。
量化到底会不会让效果变差？
会，但差多少取决于任务和档位。分类、抽取、翻译这类结构化任务通常比较耐受，长链推理、数学和需要严格格式输出的任务更容易露馅。稳妥做法是拿你自己的真实业务样本做一轮对照，而不是只看别人的结论。档位取舍的通用思路可以到 /models/deploy 按当时的模型规格核对。
推理速度慢，是不是框架选错了？
框架确实有影响，但排在显存、批处理、调度之后。很多「换了框架就快」的案例，其实是换框架时顺带把并发和缓存配置改了。建议先把现有框架的批处理和并发调到合理区间再测一次，还是不行再考虑迁移，迁移的验证和回退成本比调参高得多。
