背景概述在基于 Atlas 800I A3 服务器构建的大模型推理解决方案中，Minimax 2.5 等高性能大模型的性能表现至关重要。近期在针对 vLLM-Ascend 0.20 版本进行性能对标与基线复现时，发现在特定高并发场景下，首字延迟（TTFT）出现显著劣化，偏离了预期的性能基线。尽管每 token 生成时间（TPOT）表现正常，但高并发下的请求排队现象导致整体用户体验下降。本文旨在分析该现象的根因，并提供相应的配置优化方案。问题现象在 Atlas 800I A3 单机部署 Minimax 2.5 模型（w8a8 量化）推理服务时，使用 vLLM 0.20 版本。在 128 并发、2k 输入/2k 输出的测试场景下，对比 vLLM 0.18 基线版本，发现 TTFT 劣化约 111s。关键指标表现： ●TTFT（首字延迟）：显著升高，偏离基线。 ●TPOT（每 token 延迟）：优于基线版本，表明 NPU 计算资源并未成为瓶颈。 ●日志现象：服务打屏日志中出现显著的请求排队等待信息。基线环境配置：export OMP_NUM_THREADS=1 echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor sysctl -w vm.swappiness=0 sysctl -w kernel.numa_balancing=0 sysctl kernel.sched_migration_cost_ns=50000 export LD_PRELOAD=/usr/lib/aarch64-linux-gnu/libjemalloc.so.2:$LD_PRELOAD export TASK_QUEUE_ENABLE=1 export VLLM_ASCEND_ENABLE_FLASHCOMM1=1 export VLLM_ASCEND_BALANCE_SCHEDULING=1 export VLLM_ASCEND_ENABLE_NZ vllm serve /mnt/share/weight/MiniMax-M2.5-w8a8-QuaRot \ --served-model-name "minimax" \ --host 0.0.0.0 \ --port 8004 \ --tensor-parallel-size 8 \ --data-parallel-size 1 \ --enable-expert-parallel \ --async-scheduling \ --max-num-seqs 32 \ --max-model-len 196608 \ --max-num-batched-tokens 16384 \ --gpu-memory-utilization 0.85 \ --trust-remote-code \ --quantization ascend \ --no-enable-prefix-caching \ --compilation-config '{"cudagraph_mode": "FULL_DECODE_ONLY"}' \ --additional-config '{"enable_cpu_binding":true}' \ --speculative_config '{"method": "eagle3", "model": "/mnt/share/weight/MiniMax-M2-Eagle3-1/", "num_speculative_tokens": 3}' 原因分析为了定位性能劣化的根本原因，我们从配置一致性、接口路径及并发参数三个维度进行了系统性排查。 1. 基线配置复核首先核对 vLLM 0.20 与基线版本 0.18 的拉起参数，确认两者在 Tensor Parallel、Expert Parallel、异步调度等关键配置上保持一致，排除了因服务配置错误或测试参数偏差导致性能劣化的可能性。 2. 现象复现与日志分析在 128 并发压测下，重新复现了 TTFT 劣化问题。通过观察服务日志，发现大量请求处于“排队等待”状态。 3. 根因定位 TTFT 指标包含从请求到达至首个 token 生成之间的全部时间，其中排队等待时间占据主导。在 vLLM 0.20 版本中，默认的并发调度参数（--max-num-seqs 和 --max-num-batched-tokens）在应对 128 高并发场景时，未能充分匹配当前的负载特征，导致请求在调度层发生积压。虽然 NPU 的计算能力（TPOT）充足，但 CPU 调度层面的排队等待时间增加，直接导致了 TTFT 的显著升高。解决措施为避免由于排队现象造成的 TTFT 偏高，需调整 vLLM 的并发控制参数，以匹配高并发场景下的资源调度需求。优化方案修改启动参数，适当增加最大序列数和最大批量 token 数： ●原配置： --max-num-seqs 32，--max-num-batched-tokens 16384 ●优化后配置： --max-num-seqs 128 --max-num-batched-tokens 32768 验证结果在保持其他配置不变的情况下，应用上述参数调整并重新进行 128 并发压测： 1.TTFT 恢复：首字延迟指标恢复至基线水平，消除了显著的劣化现象。 2.日志检查：服务打屏日志中不再出现明显的请求排队等待信息，调度流程顺畅。 3.性能达标：整体性能表现符合预期基线。总结在 Atlas 800I A3 上部署 vLLM 0.20 版本进行大模型推理时，若遇到高并发场景下 TTFT 劣化但 TPOT 正常的情况，建议优先检查 --max-num-seqs 和 --max-num-batched-tokens 参数配置。适当放宽这些并发限制参数，可以有效减少请求排队时间，从而优化首字延迟表现。