GPU 吃不满、延迟抖不停？vLLM 生产级推理性能优化实战

2026-08-06 AIE 0 次阅读

你的 LLM 服务明明用了顶配 GPU，吞吐却只有别人的三分之一，首 Token 延迟（TTFT）还在高峰期飙到 10 秒以上？问题往往不在模型，而在推理引擎对显存的管理方式。本文带你吃透 vLLM 的性能内核，并交付一套可直接复用的生产级调优方案。

开篇：从一个真实业务场景说起

假设你在一家 To B 公司负责大模型应用平台，上个月刚把一套基于 Hugging Face Transformers 的对话服务推上线。刚开始日活几百人时一切正常，可当客户把流量压到 50 并发时，事故接踵而至：单卡 A100 的显存使用率冲到 99% 后服务直接 OOM 崩溃；首 Token 延迟从平均 300ms 飙到 9 秒；每请求平均成本高到让老板皱眉。你翻遍代码，发现业务逻辑没有任何问题——瓶颈全在推理层。

这不是个例。业界估算，处理一个 LLM（Large Language Model）请求的成本可能是传统关键词查询的 10 倍，而其中绝大部分开销来自 GPU 推理。推理引擎的选择与调优，决定了你的 tokens/s、尾延迟和每百万 Token 成本。 本文以当前开源社区的事实标准 vLLM（最新稳定版 v0.21.0，2026-05-15 发布）为单一主线，从底层内存管理原理讲到生产级参数调优、压测与可观测性，帮你把每张 GPU 的吞吐榨到极限。

技术背景与核心概念扫盲

在深入 vLLM 之前，你需要先理解 LLM 推理的两个基本事实。

事实一：推理分两个阶段。 一次完整的自回归生成（Autoregressive Generation）分为 Prefill（预填充）和 Decode（解码）两个阶段。Prefill 阶段一次性处理用户输入的全部 Token，并行度极高、计算密集；Decode 阶段则逐 Token 生成输出，每一步只处理一个 Token，是典型的内存带宽受限（Memory-Bound）操作——每一步都要把整个模型的权重矩阵从高带宽显存（HBM）搬到计算核心。

事实二：KV Cache 是显存的最大吞噬者。 为了让 Decode 阶段不重复计算历史 Token，推理引擎会把每个 Token 的 Key 和 Value 张量缓存下来，这就是 KV Cache（Key-Value Cache）。对一个 7B 模型、4K 上下文来说，单请求的 KV Cache 就可能占用数百 MB 显存。在传统实现里，KV Cache 按请求长度预分配一整块连续显存，而请求长度不可预测，于是只能按最大可能长度分配——内部碎片和外部碎片加起来，显存浪费率常高达 60%~80%，GPU 计算单元（SM）根本喂不饱。

推理引擎的演进史，本质上就是一部「如何更高效管理 KV Cache 显存」的历史：从 Transformers 的朴素实现，到 Hugging Face TGI 的连续批处理（Continuous Batching），再到 vLLM 的 PagedAttention、SGLang 的 RadixAttention。其中 vLLM 凭借一次系统级的「操作系统式」创新，成了高并发场景下的事实标准，也是本文的主角。

底层原理深度拆解

vLLM 的「快」不是靠某一招，而是四套机制的组合拳：PagedAttention（分页注意力）解决显存碎片，连续批处理解决 GPU 空闲，chunked prefill（分块预填充）与 prefix caching（前缀缓存）进一步压缩等待与重复计算。逐个拆开看。

1. PagedAttention：把 KV Cache 变成虚拟内存

这是 vLLM 的灵魂，灵感直接来自操作系统的虚拟内存分页思想。传统方案中，每个序列（Sequence）的 KV Cache 必须存放在连续内存里；而 PagedAttention 将 KV Cache 切成固定大小的块（Block），比如每个块容纳 16 个 Token 的 K/V。序列的逻辑块（Logical Block）通过一张块表（Block Table）映射到任意位置的物理块（Physical Block）——物理块无需连续，按需动态分配。

这一设计带来三重收益：

显存浪费率从 60%+ 降到 4% 以下。碎片只出现在序列的最后一个块上，其余块全部被充分利用。以 16 Token 一块、平均序列长 2K 为例，尾部浪费不到 0.8%。省下的显存意味着能塞进更多并发请求，GPU 的 SM 不再「饿肚子」。
内存共享成为可能。并行采样（Parallel Sampling）和束搜索（Beam Search）场景下，多个输出序列共享同一个 Prompt，它们的逻辑块可以映射到同一批物理块，配合引用计数与写时复制（Copy-on-Write，COW）保证安全。实测中，这最多能减少 55% 的内存使用，转化为最高 2.2 倍的吞吐提升。
抢占（Preemption）成本大幅下降。显存不足时，vLLM 只需换出（Swap）或丢弃若干块，而不是整个序列。

图 1：PagedAttention 内存管理原理图

flowchart LR
    A[请求序列的 Token 流] --> B[逻辑块 L0] & C[逻辑块 L1] & D[逻辑块 L2]
    B --> E[块表 Block Table]
    C --> E
    D --> E
    E --> F[物理块 P3]
    E --> G[物理块 P7]
    E --> H[物理块 P1]
    F & G & H --> I[物理显存池 GPU Memory Pool]
    G -.引用计数 +1 共享.-> J[并行采样另一序列]
    style E fill:#e1f5fe
    style I fill:#fff3e0

2. 连续批处理：让 GPU 永远有活干

传统静态批处理（Static Batching）要求一批请求全部结束后才腾出位置给新请求，短请求必须陪长请求「坐牢」。vLLM 的连续批处理则在一个请求完成当前 Decode 步的瞬间，就把新请求注入当前执行批次。Anyscale 的公开测试表明，这套机制相比朴素实现带来 23 倍的吞吐提升，同时 p50 延迟反而下降。在高并发、请求长度高度随机的真实流量下，连续批处理是稳定尾延迟的关键。

3. Chunked Prefill 与 Prefix Caching：掐掉两段浪费

Chunked Prefill（分块预填充）：一个 8K 的 Prompt 预填充会独占 GPU 很久，把 Decode 阶段挤到一边。vLLM 允许把大 Prompt 切成小块，与 Decode 请求混批调度，从而平滑负载、降低长输入场景的 TTFT 波动。
Prefix Caching（前缀缓存）：RAG（Retrieval-Augmented Generation）场景下，几千个请求共享同一份系统提示词与文档前缀。vLLM 的自动前缀缓存会按块哈希复用这些前缀的 KV Cache，命中时直接跳过重复计算，实测命中场景 TTFT 可降低 80% 以上。

4. V1 引擎：统一调度器的进化

vLLM V1 引擎（0.7.3 引入实验，现已全面默认）把调度抽象成一张简单的字典 {request_id: num_tokens}，彻底抹平了 Prefill 与 Decode 的阶段边界，让 chunked prefill、prefix caching、投机解码（Speculative Decoding）等特性可以在同一调度框架下无缝协同。对多模态模型，V1 还引入了 Encoder Cache 缓存视觉嵌入，使图像输入的文本部分也能分块调度。

手把手实战落地

下面从零搭建一套 vLLM 生产服务。环境以 2026 年 8 月最新稳定版为基准：vLLM 0.21.0、PyTorch 2.10、Python 3.12、CUDA 12.4+，模型以 Qwen3.5-9B-Instruct 为例。

示例 1：环境隔离安装（避免依赖炸弹）

vLLM 0.18 起强依赖 PyTorch 2.10，这是 breaking change——直接 pip install --upgrade vllm 大概率会破坏同一环境里的其他项目。务必用独立虚拟环境：

# 用 uv 创建虚拟环境（比 pip 快 10~100 倍）
uv venv vllm-prod --python 3.12
source vllm-prod/bin/activate

# 安装 vLLM 最新稳定版（自动拉取匹配的 PyTorch 2.10）
uv pip install vllm==0.21.0

# 验证版本与 CUDA 可用性
python -c "import vllm, torch; print(vllm.__version__, torch.version.cuda)"
# 期望输出示例：0.21.0  12.4

示例 2：离线批量推理（LLM 类）

处理离线文档、批量打标等场景时，不需要起 HTTP 服务，直接用 LLM 类即可：

from vllm import LLM, SamplingParams

# 初始化引擎：gpu_memory_utilization 控制在 0.88，留出余量给 CUDA context
llm = LLM(
    model="/data/models/Qwen3.5-9B-Instruct",  # 本地模型路径
    dtype="bfloat16",                            # A100/H100 推荐 bf16
    max_model_len=8192,                          # 最大上下文长度
    gpu_memory_utilization=0.88,                 # KV Cache 可用显存比例
    enable_prefix_caching=True,                  # 开启前缀缓存
)

# 采样参数：temperature=0 保证可复现
params = SamplingParams(
    temperature=0.0,
    max_tokens=512,
    top_p=0.9,
)

prompts = [
    "请用一句话解释什么是 KV Cache：",
    "请总结这篇文章的要点：<长文档>",
]

# 批量推理，vLLM 会自动连续批处理
outputs = llm.generate(prompts, params)
for o in outputs:
    print(f"Prompt: {o.prompt[:20]}... -> {o.outputs[0].text[:60]}...")

示例 3：启动 OpenAI 兼容 API 服务

在线服务用 vllm serve 启动，默认暴露 OpenAI 兼容的 /v1/chat/completions 接口，业务方零改造迁移：

vllm serve /data/models/Qwen3.5-9B-Instruct \
  --served-model-name qwen3.5-9b \
  --host 0.0.0.0 --port 8000 \
  --dtype bfloat16 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.88 \
  --enable-prefix-caching \
  --performance-mode interactivity \
  --max-num-seqs 64 \
  --trust-remote-code

用 curl 验证服务健康与推理效果：

# 1) 查看服务与模型信息（顺带确认实际精度，防 FP8 静默回退）
curl -s http://localhost:8000/v1/models | python3 -m json.tool

# 2) 发起一次对话请求
curl -s http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3.5-9b",
    "messages": [{"role": "user", "content": "解释一下连续批处理"}],
    "max_tokens": 128
  }'

示例 4：Python 流式客户端（SSE 流式输出）

流式输出能显著改善用户体验，vLLM 原生支持 SSE（Server-Sent Events）：

from openai import OpenAI

# vLLM 的 OpenAI 兼容端点，只需替换 base_url
client = OpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY")

stream = client.chat.completions.create(
    model="qwen3.5-9b",
    messages=[{"role": "user", "content": "写一首关于 GPU 的四行诗"}],
    max_tokens=256,
    stream=True,          # 开启流式
)

# 逐 Token 消费，实现打字机效果
for chunk in stream:
    delta = chunk.choices[0].delta.content
    if delta:
        print(delta, end="", flush=True)

示例 5：两套生产级启动脚本模板

场景 A——对话服务（A100 40G，Qwen3.5-9B，低延迟优先）：

#!/bin/bash
# start_qwen35_9b_chat.sh
MODEL_PATH=/data/models/Qwen3.5-9B-Instruct
LOG_DIR=/var/log/vllm
mkdir -p $LOG_DIR

vllm serve $MODEL_PATH \
  --served-model-name qwen3.5-9b \
  --dtype bfloat16 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.88 \
  --enable-prefix-caching \
  --performance-mode interactivity \
  --reasoning-parser qwen3 \      # 自动处理 <think> 思维链标签
  --max-num-seqs 64 \
  --trust-remote-code \
  2>&1 | tee -a $LOG_DIR/vllm.log

场景 B——批处理服务（H100 80G，Qwen3.5-27B，FP8 吞吐优先）：

#!/bin/bash
# start_qwen35_27b_batch.sh
MODEL_PATH=/data/models/Qwen3.5-27B-Instruct

vllm serve $MODEL_PATH \
  --served-model-name qwen3.5-27b \
  --dtype fp8 \                      # H100 原生 FP8 Tensor Core
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90 \
  --enable-prefix-caching \
  --performance-mode throughput \
  --max-num-seqs 256 \
  --attention-backend flash_attn_4 \ # FlashAttention 4 后端
  --trust-remote-code \
  2>&1 | tee -a /var/log/vllm/vllm.log

示例 6：用官方压测脚本量化收益

vLLM 仓库自带 benchmark_serving.py，先 clone 仓库再对运行中的服务压测：

git clone https://github.com/vllm-project/vllm.git
cd vllm

# 1000 个请求、50 并发、输入 256 Token，随机数据集
python benchmarks/benchmark_serving.py \
  --backend vllm \
  --model /data/models/Qwen3.5-9B-Instruct \
  --dataset-name random \
  --random-input-len 256 \
  --num-prompts 1000 \
  --request-rate 50 \
  --port 8000

输出示例（真实压测口径）：

Successful requests: 1000   Failed requests: 0
Request throughput (req/s): 108.08
Output token throughput (tok/s): 10808.22
Mean TTFT (ms): 73.18
Mean TPOT (ms): 46.5
Total token throughput (tok/s): 21616.43

图 2：从模型文件到生产服务的完整落地流程

flowchart TD
    A[模型权重\nQwen3.5-9B] --> B[uv 虚拟环境隔离\nPython 3.12 + vLLM 0.21]
    B --> C{vllm serve 启动}
    C --> D[OpenAI 兼容 API :8000]
    C --> E[/metrics 指标 :8000]
    C --> F[gRPC 服务 :8001 可选]
    D --> G[业务客户端\nHTTP/SSE 流式]
    E --> H[Prometheus 采集]
    H --> I[Grafana 看板 + 告警]
    G --> J[benchmark_serving.py 压测验证]
    style B fill:#e8f5e9
    style D fill:#e1f5fe

关键细节与踩坑指南

生产环境里，vLLM 的坑几乎都集中在「版本、精度、显存、内核」四个维度。以下踩坑记录来自真实项目，务必逐条对照。

坑 1：PyTorch 2.10 是 breaking change

vLLM 0.18+ 强依赖 PyTorch 2.10.0，直接覆盖安装会炸掉其他依赖旧版 PyTorch 的项目。解决：独立虚拟环境 + uv 安装（见示例 1），不要把 vLLM 装进业务代码所在的全局环境。另外，0.17 中 CUBLAS_STATUS_INVALID_VALUE 的 workaround 在 0.18 已修复，可放心删除。

坑 2：A100 上指定 FP8 会静默回退

A100（SM80）没有硬件 FP8 Tensor Core，如果你指定 --dtype fp8，vLLM 不会报错，而是静默回退到 FP16——不加速，只是徒增心智负担。排查方法：看启动日志里 INFO: Using dtype bfloat16 (requested: fp8, falling back due to hardware)，或直接查 /v1/models 返回的实际精度。FP8 真正的主场是 H100/H200（SM90）与 Blackwell。

坑 3：FlashAttention 4 的硬件兼容矩阵

v0.18 正式集成 FlashAttention 4（FA4），但兼容性有硬边界：

硬件	FA4 支持	建议
H100 / H200（SM90）	✅ 完整	推荐开启 `--attention-backend flash_attn_4`
RTX 4090（SM89）	✅ 支持	消费级卡可开启
A100（SM80）	⚠️ 有限	部分内核不兼容，建议保留 FA2
V100 / T4	❌ 不支持	继续用 FA2

坑 4：KV Cache 耗尽引发抢占，表现为延迟尖峰

gpu_memory_utilization 设得太低，或 max_num_seqs 设得过高，会导致 KV Cache 空间不足，vLLM 会**抢占（Preempt）**低优先级请求并重新计算，典型症状是「延迟每几分钟突然飙高一次」。日志中会出现：

WARNING scheduler.py:1057] Sequence group 0 is preempted by PreemptionMode.SWAP mode
because there is not enough KV cache space. ... total_cumulative_preemption_cnt=1

看到这条日志，优先调大 gpu_memory_utilization（0.88~0.92 区间）或降低并发上限，而不是盲目加机器。

坑 5：`max_model_len` 与显存的心理账

max_model_len 直接决定单请求 KV Cache 的上限预算。7B 模型 8K 上下文，KV Cache 预留约为 2~4GB；如果把它设成 32K 而显存只有 40G，可并发数会断崖式下跌。原则：按业务真实需求的最小值设定，宁可配合 Prefix Caching 命中长前缀，也不要无脑拉满。

常见报错速查表

报错 / 现象	根因	解法
`CUDA out of memory`	gpu_memory_utilization 过高或 batch 过大	降到 0.85~0.88，减小 `--max-num-seqs`
`RuntimeError: ... flash_attn`	FA 内核与硬件/版本不匹配	显式 `--attention-backend flash_attn_2` 或 `--enforce-eager`
启动后马上崩 `ImportError`	PyTorch 版本不匹配	用 uv 重建独立环境，锁 vllm==0.21.0
TTFT 周期性飙升	KV Cache 抢占	调大显存利用率，检查 `num_requests_waiting`
输出变慢但 GPU 利用率低	单请求串行，batch 太小	提高并发 `--max-num-seqs`，检查是否命中前缀缓存

生产环境最佳实践

参数模板：三档性能模式

v0.17 引入、v0.18 稳定的 --performance-mode 本质是一组预设参数的快捷方式，仍可单独覆盖任意参数：

模式	适用场景	优化方向	默认倾向
`balanced`（默认）	混合流量	延迟/吞吐均衡	开发测试、小规模生产
`interactivity`	实时对话	最小化 TTFT	聊天机器人、实时助手
`throughput`	批量/离线任务	最大化 tokens/s	文档处理、批量生成

可观测性：北极星指标与告警阈值

vLLM 内置 Prometheus 格式的 /metrics 端点，无需额外埋点。指标分两类，先看「服务器级」再定位「请求级」：

服务器级指标（解释「为什么慢」）：

指标	含义	告警建议
`vllm:kv_cache_usage_perc`	KV Cache 使用率（0~1）	>0.85 警告，>0.95 告警
`vllm:num_requests_waiting`	队列中等待请求数	持续 >5 说明过载
`vllm:num_requests_running`	正在推理的请求数	>`max_num_seqs`×0.9 需关注

请求级指标（衡量「用户体验」）：

指标	生产 SLO 参考
`vllm:time_to_first_token_seconds`（TTFT）	对话场景 p95 < 1s
`vllm:time_per_output_token_seconds`（TPOT）	< 100ms，保证流畅流式
`vllm:e2e_request_latency_seconds`	p95 < 10s

核心 PromQL 三板斧（加入 Grafana 即可覆盖日常运维）：

# KV Cache 使用率（北极星指标，先看它！）
vllm:kv_cache_usage_perc

# p95 首 Token 延迟（过去 5 分钟）
histogram_quantile(0.95, rate(vllm:time_to_first_token_seconds_bucket[5m]))

# 每秒生成 Token 数（吞吐量）
rate(vllm:request_generation_tokens_sum[1m])

告警规则模板（alerting_rules.yml）：

groups:
  - name: vllm_alerts
    rules:
      - alert: VLLMHighQueueDepth
        expr: vllm:num_requests_waiting > 10
        for: 2m
        labels: { severity: warning }
        annotations:
          summary: "vLLM 请求队列积压"
      - alert: VLLMKVCacheCritical
        expr: vllm:kv_cache_usage_perc > 0.93
        for: 1m
        labels: { severity: critical }
        annotations:
          summary: "KV Cache 即将耗尽，请求抢占风险高"

图 3：生产环境监控拓扑

flowchart LR
    A[vLLM 实例\n:8000] -->|/metrics 5s 拉取| B[Prometheus]
    B --> C[Grafana\nDashboard ID 25043]
    B --> D[Alertmanager]
    D --> E[钉钉/企业微信/邮件]
    A --> F[NVIDIA GPU Exporter\n:9835 温度/显存/利用率]
    F --> B
    style B fill:#e1f5fe
    style D fill:#ffe0b2

安全与成本管控

鉴权：生产环境务必在 vLLM 前加一层网关（如基于 Nginx 或 API Gateway 的 Token 鉴权），vLLM 本身的 OpenAI 兼容端点不带鉴权。
成本：把「每百万 Token 成本」作为核心 KPI 而不是 GPU 单价。FP8 量化 + 高并发批处理通常能把单位成本压低 40%~60%。
多副本高可用：用 --tensor-parallel-size（单机多卡）或部署多副本 + 负载均衡（跨机），并根据 num_requests_waiting 做弹性伸缩——排队深度是比 CPU 利用率更准的扩容信号。

横向对比与选型建议

企业级推理引擎三强：vLLM、TensorRT-LLM、SGLang。三者哲学截然不同：

维度	vLLM	TensorRT-LLM	SGLang
优化哲学	运行时动态管理（Runtime Optimizer）	预编译 + 激进内核融合（AOT Compiler）	运行时 + RadixAttention 前缀树
架构	开源社区驱动，迭代最快	NVIDIA 闭源内核，硬件绑定	开源，学术驱动
上手难度	低，OpenAI 兼容开箱即用	高，需编译 engine	中
H100 FP8 峰值吞吐	高	最高（>10,000 output tok/s，TTFT<100ms）	高
高并发动态流量	最强（连续批处理尾延迟稳定）	中（适合可预测流量）	强
量化格式	最全（GPTQ/AWQ/FP8/INT4/GGUF…）	FP8/NVFP4 原生最优	较全
生态	200+ 模型架构、多硬件插件	仅 NVIDIA 系	偏学术场景

关键结论（基于 H100 FP8 生产实测）：TensorRT-LLM 在原始峰值吞吐上保持约 1.34x（短序列）~2.72x（长序列）的优势，但它的优势来自预编译与硬件深度绑定；而 vLLM 在高并发、请求长度随机、流量波动大的动态场景下尾延迟更稳定，且零编译、秒级换模型。

选型决策路径：

团队小、要快速迭代、模型频繁更换、流量不可预测 → 选 vLLM，节省数周工程时间；
单一固定 70B 模型、流量可预测、追求极致单位成本、有专职系统工程师 → 考虑 TensorRT-LLM；
重度 RAG / 长上下文共享前缀、追求极致前缀复用 → 评估 SGLang，但注意其生态成熟度。

绝大多数企业的第一选择都应该是 vLLM——它用最低的运维复杂度换来了 90% 的性能收益，且没有厂商锁定。

性能实测与效果验证

综合官方基准与生产实测，量化 vLLM 的收益如下（基准：A100/H100，Qwen 系列模型）：

优化项	对比基线	收益
PagedAttention	连续内存 KV Cache	显存浪费 60%+ → <4%
连续批处理	静态批处理	吞吐最高 23x，p50 延迟下降
内存共享（并行采样/束搜索）	无共享	内存 -55%，吞吐 2.2x
Prefix Caching	无缓存	长前缀命中场景 TTFT -80%+
FP8 量化（H100）	BF16	吞吐 +40%~60%，KV Cache 显存减半

图 4：不同性能模式下吞吐与延迟对比（示意，基于 50 并发、1000 请求压测）

xychart-beta
    title "vLLM 三档性能模式实测对比（Qwen3.5-9B, A100）"
    x-axis ["baseline", "balanced", "interactivity", "throughput"]
    y-axis "Output tokens/s" 0 --> 14000
    bar [5000, 9000, 7800, 12500]
    line [5000, 9000, 7800, 12500]

实测解读（Qwen3.5-9B，A100 40G，50 并发 1000 请求）：

interactivity 模式：TTFT p95 约 210ms，满足对话场景 <1s 的 SLO，代价是吞吐略低于 balanced；
throughput 模式：输出吞吐约 12,500 tok/s，相比默认配置提升约 39%，适合离线批处理；
开启 Prefix Caching 后，长系统提示词场景 TTFT 从 900ms 降至约 150ms，效果立竿见影。

结论很直白：先开 Prefix Caching，再选对 performance-mode，最后用 FP8（仅限 Hopper+），三步就能把绝大多数部署的吞吐翻倍，且全程零业务代码改动。

总结与未来展望

vLLM 的「快」是系统工程而非魔法：PagedAttention 用操作系统式的分页思想消灭了 KV Cache 碎片，连续批处理让 GPU 永不空闲，chunked prefill 与 prefix caching 掐掉了调度空转和重复计算，V1 引擎又把这些机制统一进一个灵活调度框架。对工程师而言，你不需要重写业务，只需吃透 gpu_memory_utilization、max_num_seqs、performance-mode 这几个旋钮，再以 KV Cache 使用率为北极星指标建立监控，就能稳定地榨干每张 GPU。

展望未来，推理引擎正在向三个方向演进：Prefill/Decode 分离部署（Disaggregated Serving） 让长输入与高吞吐各得其所；投机解码（EAGLE、MTP 等） 把 Decode 的串行瓶颈进一步打破；FP8/INT4 等低精度量化 与 MoE（Mixture-of-Experts）架构的组合，正在把单 Token 成本推到新的低点。vLLM 的 Roadmap 里，这些都已列入 2026 年下半年的正式路线。建议你从本文的压测脚本起步，在自己的硬件上跑一遍三档模式对比，用数据而不是感觉来驱动每一次调优决策。