LLM 推理优化实战：从 10 tokens/s 到 100+ tokens/s 的性能调优指南

2026 年，大模型应用已经从「能不能用」进入了「好不好用」的阶段。根据 a16z 的调研数据，LLM 推理成本占 AI 应用总运营成本的 60%-80%，而用户对响应延迟的容忍阈值仅为 2 秒。这意味着，推理性能不再是「锦上添花」，而是直接决定了产品的生死。本文将从实际部署经验出发，系统性地讲解 LLM 推理优化的四大核心技术，并提供可直接落地的代码示例和性能对比数据。

📌 **记住：**推理优化的本质是在「模型质量」「推理速度」「部署成本」三个维度之间寻找最优平衡点。不存在「万能方案」，只有适合你场景的方案。

🚀 一、量化压缩：用精度换速度的第一刀

什么是量化？为什么它是推理优化的起点？

量化（Quantization）是将模型权重从高精度浮点数（FP32/FP16）压缩到低精度表示（INT8/INT4）的技术。这是大多数推理优化的第一步，因为它的效果最直接：

⚠️ **警告：**低于 INT4 的量化（如 Q2、Q3）在复杂推理任务上质量下降严重，不建议在生产环境使用。测试表明，Q2 量化的模型在数学推理任务上准确率下降可达 15%-20%。

量化实战：用 GPTQ 和 AWQ 压缩模型

以下是使用 AutoGPTQ 进行 INT4 量化的完整流程：

# 使用 AutoGPTQ 对模型进行 INT4 量化
from transformers import AutoTokenizer
from auto_gptq import AutoGPTQForCausalLM, BaseQuantizeConfig

# 1. 配置量化参数
quantize_config = BaseQuantizeConfig(
    bits=4,                    # 量化位数：4bit
    group_size=128,            # 量化分组大小，越大质量越好但速度略慢
    damp_percent=0.01,         # Hessian 矩阵阻尼系数
    desc_act=True,             # 按激活值降序排列，提升质量
    sym=False,                 # 非对称量化，精度更高
)

# 2. 加载模型和分词器
model_id = "meta-llama/Llama-3.1-8B-Instruct"
tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoGPTQForCausalLM.from_pretrained(model_id, quantize_config)

# 3. 准备校准数据（量化质量的关键）
calibration_data = [
    tokenizer("请用中文解释什么是机器学习", return_tensors="pt"),
    tokenizer("Write a Python function to sort a list", return_tensors="pt"),
    # 建议准备 128-256 条代表性样本
]

# 4. 执行量化并保存
model.quantize(calibration_data)
model.save_quantized("./llama3.1-8b-gptq-4bit")
tokenizer.save_pretrained("./llama3.1-8b-gptq-4bit")

但实际项目中，我更推荐使用 AWQ 而非 GPTQ。原因很简单：AWQ 在相同量化位数下质量更好，推理速度也更快（因为它的权重是为推理优化的，而 GPTQ 更侧重训练时的量化误差最小化）。

# ✅ 推荐：使用 AWQ 量化（质量更好、推理更快）
from awq import AutoAWQForCausalLM
from transformers import AutoTokenizer

model_id = "meta-llama/Llama-3.1-8B-Instruct"
quant_path = "./llama3.1-8b-awq-4bit"

# 加载模型
model = AutoAWQForCausalLM.from_pretrained(model_id)
tokenizer = AutoTokenizer.from_pretrained(model_id)

# 配置量化参数
quant_config = {
    "zero_point": True,        # 启用零点量化
    "q_group_size": 128,       # 分组大小
    "w_bit": 4,                # 4-bit 量化
    "version": "GEMM",         # GEMM kernel，推理更快
}

# 执行量化
model.quantize(tokenizer, quant_config=quant_config)
model.save_quantized(quant_path)
tokenizer.save_pretrained(quant_path)

量化方案选型决策树

在实际项目中，选择哪种量化方案取决于你的部署环境：

• ✅ 有 NVIDIA GPU + 需要最高吞吐量 → 使用 vLLM + AWQ INT4
• ✅ 本地 Mac/Linux 部署 → 使用 Ollama + GGUF Q4_K_M
• ✅ 需要最高质量 + 有充足显存 → 使用 FP16 + KV Cache 优化
• ❌ 不要在 CPU 上跑 FP16 模型 → 速度慢到无法使用
• ❌ 不要用 Q2/Q3 量化 → 质量损失不可接受

⚡ 二、KV Cache 与连续批处理：吞吐量的核心引擎

KV Cache：推理优化的隐藏瓶颈

在 Transformer 推理过程中，每个 token 的生成都依赖于之前所有 token 的 Key 和 Value 向量。KV Cache 就是将这些中间结果缓存起来，避免重复计算。但问题在于，KV Cache 是推理过程中最大的显存消耗者。

以 Llama 3.1 8B 模型为例，FP16 精度下：

• 模型权重：~16 GB
• KV Cache（4K 上下文）：~1 GB
• KV Cache（32K 上下文）：~8 GB
• KV Cache（128K 上下文）：~32 GB

💡 **提示：**当上下文长度超过 8K 时，KV Cache 的显存占用可能超过模型本身。这就是为什么长上下文推理特别消耗资源。

连续批处理：从「排队」到「流水线」

传统批处理（Static Batching）的问题是：一个请求必须等整个批次的所有请求都生成完毕才能返回。如果某个请求只需要生成 10 个 token，而另一个需要生成 1000 个，前者就要白白等待。

连续批处理（Continuous Batching，也叫 In-flight Batching）解决了这个问题：

# vLLM 连续批处理配置示例
from vllm import LLM, SamplingParams

# 初始化 vLLM 引擎 - 自动启用连续批处理
llm = LLM(
    model="meta-llama/Llama-3.1-8B-Instruct",
    quantization="awq",           # 使用 AWQ 量化
    tensor_parallel_size=1,        # 单卡推理
    gpu_memory_utilization=0.90,   # GPU 显存利用率（推荐 0.85-0.95）
    max_model_len=8192,            # 最大上下文长度
    max_num_batched_tokens=16384,  # 每批最大 token 数
    max_num_seqs=64,               # 最大并发请求数
    dtype="auto",                  # 自动选择精度
    enforce_eager=False,           # 使用 CUDA Graph 加速
)

# 采样参数
sampling_params = SamplingParams(
    temperature=0.7,
    top_p=0.9,
    max_tokens=512,
    repetition_penalty=1.1,
)

# 批量推理 - vLLM 自动进行连续批处理
prompts = [
    "用一句话解释什么是量子计算",
    "Write a haiku about programming",
    "Python 和 JavaScript 的主要区别是什么？",
    "Explain REST API in simple terms",
    "什么是微服务架构的优缺点？",
]

# 所有请求并发处理，先完成的先返回
outputs = llm.generate(prompts, sampling_params)

for output in outputs:
    print(f"Prompt: {output.prompt[:30]}...")
    print(f"Generated: {output.outputs[0].text[:100]}...")
    print(f"Tokens/s: {len(output.outputs[0].token_ids) / output.metrics.finished_time:.1f}")
    print("---")

PagedAttention：显存管理的革命性突破

vLLM 的核心创新是 PagedAttention，它借鉴了操作系统虚拟内存的思想，将 KV Cache 分成固定大小的「页」（Page），按需分配和释放：

# PagedAttention 的核心思想（简化示意）
# ❌ 传统方式：为每个请求预分配最大长度的连续显存
class TraditionalKVCache:
    def __init__(self, max_seq_len, num_heads, head_dim):
        # 预分配完整显存 - 浪费严重
        self.cache = torch.zeros(
            max_seq_len, num_heads, head_dim,
            device="cuda", dtype=torch.float16
        )
        self.current_len = 0

# ✅ PagedAttention：按需分配页
class PagedKVCache:
    def __init__(self, page_size=16, num_pages=1000):
        self.page_size = page_size
        # 页表：逻辑页号 -> 物理页号
        self.page_table = {}
        # 物理页池
        self.free_pages = list(range(num_pages))
        # 每页存储的 KV 数据
        self.physical_cache = torch.zeros(
            num_pages, page_size, num_heads, head_dim,
            device="cuda", dtype=torch.float16
        )

    def allocate_page(self):
        """按需分配一个物理页"""
        if not self.free_pages:
            raise MemoryError("KV Cache 显存不足")
        return self.free_pages.pop()

    def free_page(self, page_id):
        """释放一个物理页"""
        self.free_pages.append(page_id)

PagedAttention 的效果是惊人的：在相同显存下，vLLM 的吞吐量比传统实现高 2-4 倍，因为它几乎消除了显存碎片和浪费。

🔧 三、投机解码与 Speculative Decoding

核心原理：用「小弟」预测「大哥」

投机解码（Speculative Decoding）的核心思想非常巧妙：用一个小而快的「草稿模型」（Draft Model）先快速生成多个候选 token，然后用大模型一次性验证这些 token 是否正确。如果猜对了（通常 70%-85% 的概率），就直接采用，省去了大模型逐个生成的时间。

# 投机解码的简化实现原理
import torch

def speculative_decode(target_model, draft_model, prompt, num_speculative=5):
    """
    投机解码核心流程
    target_model: 大模型（准确但慢）
    draft_model: 小模型（快但可能不准）
    num_speculative: 每次投机的 token 数
    """
    tokens = tokenize(prompt)
    generated = []

    while len(generated) < max_tokens:
        # 1. 草稿模型快速生成 N 个候选 token
        draft_tokens = []
        draft_probs = []
        current = tokens + generated

        for _ in range(num_speculative):
            logits = draft_model.forward(current + draft_tokens)
            prob = torch.softmax(logits, dim=-1)
            next_token = torch.multinomial(prob, 1)
            draft_tokens.append(next_token)
            draft_probs.append(prob[next_token])

        # 2. 大模型一次性验证所有候选 token（并行，快！）
        # 这一步是关键：大模型一次前向传播就能验证多个 token
        all_logits = target_model.forward(current + draft_tokens)
        target_probs = torch.softmax(all_logits, dim=-1)

        # 3. 逐个验证，接受或拒绝
        accepted = 0
        for i in range(num_speculative):
            draft_prob = draft_probs[i]
            target_prob = target_probs[len(current) + i][draft_tokens[i]]

            # 接受概率 = min(1, target_prob / draft_prob)
            accept_ratio = target_prob / draft_prob
            if torch.rand(1) < accept_ratio:
                generated.append(draft_tokens[i])
                accepted += 1
            else:
                # 从修正后的分布中采样一个 token
                corrected_prob = torch.clamp(target_prob - draft_prob, min=0)
                corrected_prob = corrected_prob / corrected_prob.sum()
                new_token = torch.multinomial(corrected_prob, 1)
                generated.append(new_token)
                break  # 后续 token 全部丢弃

        # 平均每次循环生成 accepted + 1 个 token
        # 而传统解码每次只生成 1 个 token

    return generated

💡 **提示：**投机解码的关键在于草稿模型的选择。理想情况下，草稿模型应该是目标模型的「蒸馏版」或同系列的小模型。例如，Llama 3.1 70B 用 Llama 3.1 8B 作为草稿模型，命中率可达 75%+。

投机解码的实际效果

⚠️ **警告：**投机解码在「高不确定性」任务（如数学推理、创意写作）上加速效果有限，因为草稿模型的命中率较低。在这些场景下，连续批处理的优化更重要。

使用 vLLM 启用投机解码

# vLLM 投机解码配置
from vllm import LLM, SamplingParams

# 方式 1：使用独立的草稿模型
llm = LLM(
    model="meta-llama/Llama-3.1-70B-Instruct",  # 目标大模型
    speculative_model="meta-llama/Llama-3.1-8B-Instruct",  # 草稿小模型
    num_speculative_tokens=5,     # 每次投机的 token 数
    speculative_max_model_len=2048,  # 草稿模型最大上下文
    quantization="awq",
    gpu_memory_utilization=0.92,
)

# 方式 2：使用 Medusa 头（无需额外模型）
llm = LLM(
    model="meta-llama/Llama-3.1-70B-Instruct",
    speculative_model="ibm-ai-platform/llama3-70b-instruct-medusa",  # Medusa 头
    num_speculative_tokens=3,
    quantization="awq",
)

# 使用方式与普通推理完全相同
sampling_params = SamplingParams(temperature=0.7, max_tokens=512)
output = llm.generate(["解释什么是向量数据库"], sampling_params)
print(output[0].outputs[0].text)

📊 四、部署方案对比与选型建议

主流推理框架性能对比

我们使用 Llama 3.1 8B AWQ-4bit 模型，在单张 A100 80GB GPU 上进行了基准测试（输入 512 tokens，输出 256 tokens）：

⚠️ **警告：**以上数据基于特定硬件和配置，实际性能会因 GPU 型号、驱动版本、CUDA 版本、模型大小等因素而不同。建议在你的目标硬件上进行基准测试。

不同场景的推荐方案

场景 1：个人开发 / 本地测试

# ✅ 推荐：Ollama - 最简单的本地部署方案
# 安装 Ollama
curl -fsSL https://ollama.ai/install.sh | sh

# 拉取量化模型（自动选择最优量化方式）
ollama pull llama3.1:8b

# 运行推理
ollama run llama3.1:8b "用 Python 写一个快速排序"

# 通过 API 调用
curl http://localhost:11434/api/generate -d '{
  "model": "llama3.1:8b",
  "prompt": "Explain async/await in JavaScript",
  "stream": false
}'

场景 2：团队内部 API 服务

# ✅ 推荐：vLLM - 最佳吞吐量和易用性平衡
# 安装
pip install vllm

# 启动 OpenAI 兼容的 API 服务
python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-3.1-8B-Instruct \
    --quantization awq \
    --max-model-len 8192 \
    --gpu-memory-utilization 0.90 \
    --port 8000 \
    --served-model-name llama3.1-8b

# 调用方式与 OpenAI API 完全兼容
curl http://localhost:8000/v1/chat/completions -d '{
  "model": "llama3.1-8b",
  "messages": [{"role": "user", "content": "Hello!"}],
  "max_tokens": 100
}'

场景 3：高并发生产环境

# ✅ 推荐：vLLM + 多卡张量并行 + 投机解码
python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-3.1-70B-Instruct \
    --tensor-parallel-size 4 \
    --quantization awq \
    --speculative-model meta-llama/Llama-3.1-8B-Instruct \
    --num-speculative-tokens 5 \
    --max-model-len 16384 \
    --gpu-memory-utilization 0.95 \
    --port 8000

💰 成本对比：自建 vs 云 API

以每天处理 100 万 token 为例（输入 + 输出）：

⚠️ **警告：**自建方案的隐性成本不容忽视：GPU 折旧、电费、运维人力、故障恢复。如果日均请求量低于 50 万 token，使用云 API 通常更划算。

✅ 五、最佳实践与避坑指南

推理优化检查清单

在部署 LLM 推理服务之前，按以下清单逐项检查：

1. ✅ 模型量化 — 是否使用了 AWQ INT4 或 GGUF Q4_K_M？
2. ✅ 连续批处理 — 推理框架是否支持 Continuous Batching？
3. ✅ KV Cache 管理 — 是否配置了合理的显存利用率（85%-95%）？
4. ⚠️ 上下文长度 — 是否限制了最大上下文长度？（不要设置超过实际需要的长度）
5. ✅ 流式输出 — 是否启用了 Streaming？（降低用户感知延迟）
6. ⚠️ 温度参数 — temperature=0 时可以启用 CUDA Graph 加速
7. ✅ 模型并行 — 多卡环境是否启用了 Tensor Parallelism？

常见坑点

坑点 1：显存 OOM（Out of Memory）

# ❌ 错误：显存利用率设太高
llm = LLM(model="llama3.1-70b", gpu_memory_utilization=0.98)  # 容易 OOM

# ✅ 正确：留出安全余量
llm = LLM(model="llama3.1-70b", gpu_memory_utilization=0.90)  # 留 10% 缓冲

坑点 2：上下文长度设置不合理

# ❌ 错误：设置 128K 上下文但实际只用 2K
llm = LLM(model="llama3.1-8b", max_model_len=131072)  # 显存浪费严重

# ✅ 正确：根据实际需求设置
llm = LLM(model="llama3.1-8b", max_model_len=4096)  # 够用就好

坑点 3：忽略首 Token 延迟（TTFT）

💡 **提示：**如果你的应用场景是对话系统，首 Token 延迟（Time To First Token）比吞吐量更重要。启用 Streaming + 减小 max_tokens 可以显著改善用户体验。

性能调优参数速查表

💡 总结

LLM 推理优化是一个系统工程，没有银弹。但如果你只记住三件事：

⚡ 关键结论：

1. 先量化，再优化 — AWQ INT4 是性价比最高的起步方案，能在几乎不损失质量的情况下将推理速度提升 2-3 倍、显存需求降低 75%。

2. 选对框架比调参更重要 — vLLM 是目前综合最优的推理框架，内置连续批处理和 PagedAttention，开箱即用就能获得接近最优的性能。

3. 投机解码是免费午餐 — 如果你的场景以代码生成、结构化输出为主，投机解码可以额外获得 1.5-2.5 倍加速，几乎零成本。

📌 **记住：**优化之前先做基准测试（benchmark），优化之后再做基准测试。不要凭感觉调参，用数据说话。

相关工具推荐：

• 🔧 vLLM — 高性能推理引擎，推荐首选
• 🔧 Ollama — 本地部署最简方案
• 🔧 llama.cpp — CPU 推理首选
• 🔧 TensorRT-LLM — NVIDIA GPU 极致性能
• 🔧 SGLang — 结构化生成优化
• 🔧 AutoGPTQ — GPTQ 量化工具
• 🔧 AutoAWQ — AWQ 量化工具