一句话定义
max_num_seqs（最大并发序列数）是推理引擎里的一个调度参数，用来规定同一时刻最多允许多少条“序列”一起在 GPU 上运行。序列（sequence）指一条请求从读入 prompt 到生成结束的完整过程。
原理：一口锅下几份菜
大模型是逐 token 生成的，每一步每条序列只多吐出一个字。单条序列这一步的计算量很小，真正的瓶颈往往在于把模型权重从显存搬进计算单元，而非计算本身——跑 1 条要搬一次，跑 32 条也是搬一次。于是引擎把多条序列凑成一批（batch）一起计算，摊薄这笔固定开销。
就像一口炒锅：如果一次只下一份菜，火和锅都空烧着；如果一次下二十份，锅温骤降，每份都熟得慢，最后出锅的那份等得最久。max_num_seqs 就是你定的“一锅最多几份”。
它还有一个硬性约束：每条序列都要占用自己的 KV cache，序列条数越多，显存越吃紧，所以这个值不能随便往大调。
别搞混的几个数
| 概念 | 管什么 |
|---|---|
| max_num_seqs | 同时并存的序列条数上限，相当于调度器放行的闸门 |
| max_num_batched_tokens | 单步计算涉及的 token 总数上限，主要限制 prefill 阶段的长 prompt |
| 实际 batch size | 当前实际进入这一批的条数，通常小于上限 |
| 用户并发数 | 可以远大于 max_num_seqs，多出来的请求会在等待队列中排队 |
还要注意AI 词典：连续批处理">连续批处理（continuous batching）：谁的任务先完成谁就先退出，排队的请求立刻补位。所以它是一道流动的闸门，而不会把一批乘客固定下来。
对实际使用的人意味着什么
- 调大：吞吐上去、单位 token 成本下来，但单条延迟，尤其是尾延迟，会变差，还有显存溢出（OOM）的风险。
- 调小：单条响应更快更稳，但 GPU 吃不饱，相当于花钱买空闲。
- 怎么选：在线对话这类延迟敏感场景往小调，离线批量摘要、数据清洗往大调。真正的上限由显存和模型规模决定，默认值与显存估算以官方文档为准。
- 一个排查信号：等待队列长期排着、GPU 利用率却不高，多半是这个值把请求卡住了；反过来，尾延迟飙升、显存见顶，就该把它调小。
一句话记住：它不改变模型算得多快，只决定你把多少条请求塞进同一个“现在”。