为什么 max_model_len 越大，可用并发可能越低？

面试时怎么答

max_model_len 影响并发要从 KV Cache 预算解释：容量与层数、KV Head、Head 维、元素字节、序列长度和并发近似成正比。分页只能减少过度预留和碎片，不能消除真实长序列占用；因此把所有请求统一开到极长上限，会让短请求也承担容量代价。

可以这样答：

max_model_len 越大，服务需要允许单请求占用更长的 KV Cache，因此同一张卡可安全容纳的并发通常更低。KV 容量与层数、KV Head、Head 维、元素字节、序列长度和并发近似成正比。分页可以减少提前预留和碎片，却不能消除真实长序列的占用，所以更合理的做法是按长度分服务档位。

核心回答

max_model_len 表示单条序列允许的 Prompt 与输出总长度上限。若系统按最坏情况做准入或容量估算，KV Cache 最多可容纳 \(C_{\mathrm{KV}}\) 个 token，则长度为 \(L_{\max}\) 的理想最坏情况并发上界近似为 \(\left\lfloor C_{\mathrm{KV}} / L_{\max} \right\rfloor\)；实际还要扣除 Block 取整、运行时保留空间并服从调度策略。上限翻倍，能同时保证的满长度请求自然可能下降。真正增加单请求执行时间的是实际处理的上下文变长；只改配置上限不等于每条请求都会变慢。

但在 PagedAttention 这类按实际 token 动态分配块的引擎中，设置更大的上限 不一定立即为每个请求预留整段 KV Cache。实际并发主要取决于当前活跃序列的真实长度、KV 总容量和调度策略；因此正确说法是“更大的上限降低最坏情况可保证并发，并可能影响资源规划”，不是“配置一改大，并发必然按比例下降”。

展开说明

整个模型的单 token KV Cache 逻辑总量可近似为：

\[2 \times \text{层数} \times \text{KV Head 数} \times \text{Head Dimension} \times \text{每元素字节数}\]

总占用再乘所有活跃序列当前保存的 token 数；张量并行下单卡占用还取决于 KV Head 是分片还是复制。max_model_len 还必须处于模型真正支持的位置编码和训练长度范围内；服务能启动只说明配置与显存检查通过，不代表模型在该长度上仍有可靠的检索、推理或生成质量。

某些引擎会根据最大长度报告“最大并发”或拒绝无法满足的请求，另一些引擎更依赖动态块和抢占/重算。回答时应区分 配置上限、实际请求长度、物理 KV 容量和模型能力上限。

工程实践

不要为了宣传数字统一把上限设到最大。先统计 P50/P95/P99 输入与输出长度，为少量超长请求设置独立队列、模型池或更严格配额；压测时扫描长度与并发二维矩阵，观察 KV 使用率、抢占、重算、TTFT、TPOT 和 OOM。若业务只偶尔需要长上下文，可用路由避免拖累普通会话的容量保障。

常见追问

最大上下文长度与实际输入长度有什么区别？ 前者是允许的 Prompt 加输出上限；缓存通常随实际已处理 token 增长，但准入和容量承诺可能按上限考虑。
把配置从 32K 改成 128K，模型就具备 128K 能力了吗？ 不一定，还要看位置机制、训练长度、推理 kernel，并用长文本任务验证质量。
PagedAttention 为什么不能消除长度与并发的矛盾？ 它减少碎片和过度预留，却不能创造额外显存；真实 KV token 总量仍受物理容量限制。

一句话复习

max_model_len 决定最坏情况长度承诺，分页分配能减少预留，但 KV 总 token 容量仍决定长上下文与并发的基本取舍。