Mistral 私有部署跑不满吞吐——是量化拖慢还是批处理没开？

本地单请求感觉还行，一上并发吞吐就上不去，通常不是单一原因。比较稳的判断顺序是先固定单请求基线，再确认批处理是否真的生效，然后对比量化等级，最后才逐级抬并发看调度排队。量化确实会拖慢推理，但很多情况下它只是次要因素；如果批处理没开、最大并发序列数被限制，或者请求在队列里排住，换更小的量化格式并不会解决吞吐问题。下面按这个顺序给出可执行步骤。

本地单人可用、并发上不去，优先怀疑批处理配置和调度排队，而不是量化。先固定单请求的首 token 时间与每秒 token 数，再对照启动日志确认批大小、最大并发序列数是否生效，然后同一脚本、同一批输入对比两种量化，最后逐级抬并发找排队临界点。边界：每一步都只能用同一脚本和同一批输入，日志里看不到批大小、排队数和吞吐字段时，先把日志打出来再下结论，不要靠体感判断。

先固定单请求测出首 token 时间和输出速率

先用流式请求建立基线，所有后续对比都以它为参照。首 token 时间反映预填充和排队，输出速率反映解码阶段速度，两者要分开记。

curl -N -s http://127.0.0.1:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"mistral","messages":[{"role":"user","content":"用三句话说明批处理的作用"}],"max_tokens":256,"stream":true}' \
  -w '\nconnect:%{time_connect} total:%{time_total}\n' -o /tmp/one.txt
# 统计首 token 时间与总时长后，用 输出token数 / (总时长-首token时间) 得到每秒 token 数

如果嫌 curl 不好统计，用一个最小脚本记录字段即可，字段固定为：首 token 时间、总时长、输出 token 数、每秒 token 数、输入长度、max_tokens。温度设为 0、max_tokens 固定、输入固定，否则不同轮次没有可比性。同一配置重复跑几次取中位数，避免单次波动误判。

逐项对照服务端的批处理相关参数

这一步只做一件事：确认批处理是不是真的打开了。常见推理服务（vLLM 类）的关键参数通常是 `--max-num-seqs`（最大并发序列数）、`--max-num-batched-tokens`（单批 token 上限）、`--enable-chunked-prefill`、`--gpu-memory-utilization`；TGI 类常见为 `--max-batch-total-tokens`、`--max-concurrent-requests`，部分版本有 `--max-batch-size`。

确认生效不要只看改没改配置文件，要看启动日志和运行日志：启动日志一般会打印实际生效的 max_num_seqs、max_num_batched_tokens；运行日志里会有 Running、Waiting 请求数以及平均生成吞吐字段。如果日志里没有这些字段，先把日志级别调到能输出调度的程度。

改一项测一轮：每次只改一个参数，重启服务，用第 1 节的同一脚本跑同样的并发，记录吞吐和排队数。这样可以判断吞吐不动是因为参数没生效，还是因为参数生效了但硬件已经到顶。

对比不同量化等级下的吞吐曲线

量化是否在拖慢，要和未量化或另一种量化对照着看，不是凭单次结果下判断。方法是用同一压测脚本、同一批输入、同一 max_tokens 和温度，只替换量化配置，分别启动服务。

记录字段：量化方式、首 token 时间、每秒 token 数、并发下的总吞吐、显存占用、请求失败数。
对照方式：先看单请求速率差距，再看并发下的吞吐差距。若单请求差别很小、并发下吞吐差别明显，问题更可能在批处理或调度；若量化后单请求就明显变慢，量化才是主要嫌疑。
注意反量化开销：某些量化格式在特定 GPU 和内核上未必更快，需要结合硬件和推理后端确认。

把并发数逐级抬高观察排队与超时

用同一脚本把并发从 1、2、4、8 这样逐级抬高，每级跑足够长的时间，记录日志中的 Waiting 请求数、超时和错误码（如 500、504），以及客户端侧的首 token 时间变化。

识别点：Waiting 持续非零说明请求在排队；总吞吐不再随并发上升、而首 token 时间继续变大，说明已经撞到调度或显存上限；开始出现超时则说明临界点已过。把“吞吐不再增长且排队持续出现”的那一级记为临界并发数，作为调参和限流的依据。

按定位结果给出一组参数调整建议

量化瓶颈：换回未量化或换更匹配当前硬件的量化格式，用第 3 节同一脚本重测单请求和并发吞吐；若两者同步改善，量化就是主因。
批处理未生效：确认启动日志里的 max_num_seqs、max_num_batched_tokens 已生效，再逐步抬高这两个值并观察显存；显存吃紧时配合 chunked prefill 和 gpu-memory-utilization 调整。每改一项重跑一轮。
调度排队：在客户端侧限制并发到临界并发数以内，配置排队和超时，减少长输入对短请求的抢占；单实例到顶时，考虑多实例部署并在前面做请求分发。验证方式仍然是同一脚本、同一批输入重跑并对比排队日志。