目录
- 一、先给结论：推荐的生产级调优顺序（修正版）
- ✅ 推荐顺序（你可以直接照这个跑）
- Step 1：确定业务级
max-model-len（你这一步是对的） - Step 2：单参数扫
max-num-batched-tokens（不是 seq）- 为什么优先 batch_token？
- Step 3：在 batch_token 固定下，扫
max-num-seqs - Step 4：小规模二维组合搜索（你第 3 步，保留但缩小）
- Step 5：加入生产级“行为参数”，做最终确认
- 二、你原始 4 步方案的逐条点评
- 三、为什么“不要一开始就全参数组合”
- 四、工程级一句话总结
你的这个调优顺序思路是“方向正确的”，而且已经明显是工程化思维，不是“拍脑袋调参”。
但我需要做两件事：
- 肯定你的主线逻辑
- 对顺序和粒度做一次“生产级校正”（否则会浪费大量时间）
下面我会先给 结论版顺序，再逐步对比你提出的 4 步，说明哪些要保留，哪些要调整。
一、先给结论：推荐的生产级调优顺序（修正版）
核心原则：先“约束空间”，再“局部最优”，最后“组合搜索”。
✅ 推荐顺序（你可以直接照这个跑）
Step 0（固定前提，不参与调优）
- 模型 / 量化方式
- GPU 类型
- 是否在线服务
- 基本稳定性参数
Step 1：确定业务级 max-model-len（你这一步是对的）
这是架构决策，不是性能调参。
-
目的：定义 KV Cache 的“天花板”
-
决定：
- 单模型服务能支持的上下文长度
- 后续所有并发 / batch 的上限空间
建议做法：
| 测试值 | 观察指标 |
|---|---|
| 1024 / 2048 / 4096 | 是否 OOM / KV 利用率 |
| 2048 / 4096 / 8192 | TTFT 稳定性 |
✔ 选一个“业务刚好够 + 留余量”的值
✔ 不追求吞吐最优
⚠️ 一旦确定，后面所有步骤都不要再动它
Step 2：单参数扫 max-num-batched-tokens（不是 seq）
这里你原方案需要校正的关键点
为什么优先 batch_token？
- 它是 Decode 吞吐的第一决定因子
- seq 只是 batch_token 的“切分方式”
推荐：
batch_tokens = [4096, 8192, 16384, 32768]
max-num-seqs = 固定一个安全值（如 32 / 64）
观察：
- tokens/s
- step latency
- GPU 利用率
- 是否出现调度抖动
✔ 先找到 batch_token 的“甜点区”
Step 3：在 batch_token 固定下，扫 max-num-seqs
这一步才是你说的 “seq 微调”。
max-num-seqs = [8, 16, 32, 64, 128]
batch_token = Step 2 的最优值
目标：
-
找到：
- tokens/s 不再明显上升
- P95 latency 开始恶化的拐点
✔ 这个值往往 不是越大越好
Step 4：小规模二维组合搜索（你第 3 步，保留但缩小）
你原来是：
seq=[8,16,32] × batch_token=[4096,8192,12288]
修正建议：
只在“拐点附近”做组合
例如：
seq = [32, 64]
batch_token = [8192, 16384]
共 4 组
已经足够接近全局最优
Step 5：加入生产级“行为参数”，做最终确认
这一步你说得非常对，但要明确目的不是“再提速”，而是“稳态验证”。
加入：
--enable-prefix-caching
--enable-chunked-prefill
--scheduling-policy fcfs
验证：
- P95 / P99 TTFT
- 长短请求混合下的稳定性
- tokens/s 是否有可接受下降
二、你原始 4 步方案的逐条点评
| 你的步骤 | 评价 | 调整建议 |
|---|---|---|
| Step 1：扫 max-model-len | ✅ 非常正确 | 保留 |
| Step 2：单参数 seq & batch | ⚠️ 顺序需调 | batch_token 优先 |
| Step 3：二维组合 | ✅ 但范围过大 | 只扫局部 |
| Step 4：加生产参数 | ✅ 正确 | 作为“验证”，非调参 |
三、为什么“不要一开始就全参数组合”
这是很多团队踩的坑。
假设：
- seq 6 个值
- batch_token 6 个值
- model_len 4 个值
👉 144 次服务启动
而实际上：
- 80% 的组合在 Step 2 就可以被淘汰
- 真正值得看的不超过 6–8 组
四、工程级一句话总结
你的调优方向是对的，但生产调优不是“穷举搜索”，
而是：先确定 KV 空间 → 再拉满 Decode 吞吐 → 最后稳住尾延迟。
如果你愿意，下一步我可以：
- 给你一份 自动化调优脚本结构（不用每次手动重启）
- 帮你定义 “停止调参”的量化条件
- 把这个流程画成 一张调参决策流程图
你选一个，我继续。
