将qwen3.5-35B的token有18w调整为26w会影响并发量吗

结论会而且是明显下降。在同一张卡、同一种部署方式下把 Qwen3.5-35B 的上下文从18 万 → 26 万 token最大并发量大致会降到原来的70% 左右。一、为什么会影响并发核心原理在 vLLM 等推理引擎里显存主要分两块模型权重固定 KV Cache动态。KV Cache 是按max_model_len上下文长度× 并发数线性增长。简化公式单卡、同精度、同模型最大并发数 ≈ 可用KV显存总量 ÷ 单请求最大上下文长度你把max_model_len从 18w → 26w分母变大 → 并发数直接被 “挤掉”。二、对你这个模型的具体影响Qwen3.5-35BQwen3.5-35BA3B是混合注意力只有一部分层做标准注意力、占显存大部分是线性注意力、不随上下文变长而涨显存。所以它比传统模型友好很多但依然不是零影响。参考社区实测80GB 级显卡、fp8/bf16、vLLM18 万上下文大约可跑810 路并发长文档场景26 万上下文同卡同配置大约5.57 路并发简单估算26w / 18w ≈ 1.44 → 并发 ≈ 原来的 1/1.44 ≈ 70%三、除了并发还会带来什么变化单请求显存占用↑每个请求 KV 缓存多了44%更容易触发 OOM。首包延迟TTFT↑长文本 prefill 更慢尤其是批量长请求时。吞吐token/s略降并发少了整体吞吐跟着降但单请求生成速度基本不变Qwen3.5 长上下文优化好。四、如果你必须开到 26w怎么尽量保住并发用 fp8 量化 KV强烈推荐vLLM 加--kv-cache-dtype fp8KV 显存直接减半并发能拉回接近 18w 时的水平。降低 gpu_memory_utilization谨慎从 0.9 → 0.850.8减少碎片、避免 OOM但会少一点 KV 空间。控制 max_num_seqs不要设太大和预估并发匹配避免无效占用 KV。五、一句话总结18w → 26w并发大致降 3 成左右用 fp8 可大幅缓解。