TGI（Text Generation Inference）处理 Mistral 这类模型时，prefill 阶段延迟过高，经常不是单次计算变慢，而是 continuous batching 调度把多个 prefill 和 decode 请求混在同一个 batch 里，导致某个长序列的 prefill 拖住后续所有请求的首 token 输出。调整方向是限制 prefill 批次的大小和等待时间，让模型更早开始 decode，而不是无限凑 batch。下面给出可操作的参数调整路径和验证方法，所有判断都需要结合你的实际请求长度、并发数和 GPU 显存来确认。
prefill 延迟高时，优先检查 max_batch_prefill_tokens 和 max_batch_total_tokens 的配置。调低 prefill 上限、调短等待时间，通常能降低单次 prefill 的最大耗时，但可能降低整体吞吐。务必通过 TGI 日志中的 prefill/decode 耗时分布和压测来确认，不要盲目照搬参数值。
先确认瓶颈确实在 prefill
调整参数前，先通过 TGI 的日志和请求追踪确认延迟分布。TGI 启动时开启详细日志，或使用带 timing 的推理请求，观察每个请求的 prefill 耗时、decode 每 token 耗时、排队等待时间。如果 prefill 耗时本身不大，但总请求时长主要花在排队上，说明是 batch 调度问题；如果 prefill 耗时随并发数线性上涨，则可能是 batch 内计算资源的瓜分。只有确认前一种情况，continuous batching 参数调整才直接有效。
影响 prefill 延迟的 continuous batching 参数
TGI 中与 prefill 调度直接相关的参数通常有：
`--max-batch-prefill-tokens`：单批 prefill 阶段允许的最大 token 总数。值越大，每次 prefill 能塞进更多序列，但单个请求需要等更久，prefill 单次计算量也更大。`--max-batch-total-tokens`：整个 batch（含 prefill 和 decode）的最大 token 数。如果只调小 prefill 上限，但 total 很大，仍然可能因为有大量 decode 等待而阻塞。`--max-waiting-tokens`：调度器等待新请求加入 batch 的最大长度。值越大，请求可能积压更久后才被处理，导致感知延迟升高。`--max-batch-size`：允许的最大请求数量，也会影响 prefill 并发度。
调整方向通常是在显存允许的前提下，先调低 `--max-batch-prefill-tokens`，让 prefill 更早结束；同时收紧 `--max-batch-total-tokens`，防止 decode 阶段被过大的 batch 拖慢。但这会增加 GPU 空闲，降低吞吐，需要权衡。
可执行的参数调整示例
假设当前 TGI 启动命令是：
tgi-launcher `--model-id` mistralai/Mistral-7B-Instruct-v0.3 `--max-batch-prefill-tokens` 4096 `--max-batch-total-tokens` 8192 `--max-waiting-tokens` 20 `--max-batch-size` 64如果 prefill 延迟过高，可以先做一次缩小调整：
tgi-launcher `--model-id` mistralai/Mistral-7B-Instruct-v0.3 `--max-batch-prefill-tokens` 2048 `--max-batch-total-tokens` 6144 `--max-waiting-tokens` 10 `--max-batch-size` 32执行后观察两点：一是 prefill 单次耗时是否下降，二是首 token 时延是否改善。如果首 token 时延改善但整体吞吐下降过多，可以再逐步回调 `--max-batch-prefill-tokens`，每次增加 512 或 1024，找到延迟和吞吐的平衡点。如果调整后 prefill 时间依然很高，问题可能出在模型加载精度、GPU 显存不足导致 swap，或者输入序列长度本身过长，不是 continuous batching 参数能解决的。
验证方式和风险边界
验证需要自定义压测脚本，固定请求大小和并发数，分别统计 prefill 耗时和首 token 时延。建议构造两类请求：短输入（如 128 token）和长输入（如 2048 token），混合发送，观察长请求是否阻塞短请求。记录不同参数组合下的耗时分布，而不是只比较平均延迟，因为 p90 往往更能反映排队阻塞问题。
风险边界：`--max-batch-prefill-tokens` 调太小会导致 prefill 碎片化，GPU 利用率降低；`--max-waiting-tokens` 调太小会让调度频繁打断，增加额外开销。所有参数值都需要结合请求长度分布和显存容量来设定，不同硬件、不同模型（Mistral-7B 与 Mistral-8x7B）的敏感度差异很大。建议每次只改一个参数，保留基线结果，避免同时多个调整造成无法定位问题。