LLM 推理服务架构 2026：从单机部署到分布式推理的完整技术体系

2026 年 6 月，LLM 推理成本已下降 90%，但推理服务仍是 AI 应用的最大瓶颈。

与训练不同，推理是一个在线服务问题：用户期望毫秒级响应，而模型需要处理数百 GB 的权重。这种矛盾催生了 LLM 推理服务这一专门领域。

推理的两大阶段：

LLM 推理分为两个计算特性完全不同的阶段：

1. Prefill 阶段（预填充）：处理用户输入的所有 token，计算 KV Cache

   • 计算密集型（Compute-bound）
   • GPU 利用率高，适合高算力硬件
   • 一次性处理所有输入 token

2. Decode 阶段（解码）：逐 token 生成输出，每次只处理一个 token

   • 内存带宽密集型（Memory-bandwidth-bound）
   • GPU 利用率低，大部分时间在等待数据搬运
   • 自回归生成，无法并行

这就是「Prefill-Decode 分离」架构的理论基础。

推理服务的三大挑战：

2026 年的推理服务栈：

现代 LLM 推理服务由四层组成：

1. 模型层：量化、蒸馏、剪枝后的模型
2. 引擎层：vLLM、TensorRT-LLM、SGLang 等推理引擎
3. 调度层：请求批处理、动态 batching、负载均衡
4. 服务层：API 网关、限流、监控、弹性伸缩

本文将逐层拆解这个技术栈。

KV Cache 是 LLM 推理的「记忆」，也是内存消耗的大户。

在自回归生成中，每生成一个新 token 都需要用到之前所有 token 的 Key 和 Value 向量。为了避免重复计算，这些向量会被缓存起来，这就是 KV Cache。

KV Cache 的内存消耗：

对于一个 70B 参数的模型：

• 每个 token 的 KV Cache 约 160KB（假设 80 层，每层 128 维）
• 处理 4096 token 的上下文，单个请求的 KV Cache 约 655MB
• 如果要同时服务 100 个并发请求，KV Cache 需要 65GB 显存

这就是为什么 KV Cache 管理是推理优化的核心。

PagedAttention：vLLM 的核心创新

传统方法为每个请求预分配连续的显存空间，导致严重的内存碎片和浪费。vLLM 提出的 PagedAttention 借鉴了操作系统的虚拟内存分页思想：

1. 分页存储：将 KV Cache 切分为固定大小的页（通常 16KB）
2. 按需分配：只在需要时分配新页，避免预分配浪费
3. 动态回收：请求完成后立即回收页面
4. 零拷贝共享：多个请求可以共享相同的 KV Cache 页（如系统 prompt）

效果：

• 内存利用率从 20-40% 提升到 90%+
• 支持的并发请求数提升 2-4 倍
• 吞吐量提升 2-4 倍

Prefix Caching：进一步减少重复计算

对于共享相同前缀的请求（如相同的系统 prompt），可以复用 KV Cache：

1. 首次请求计算并缓存前缀的 KV Cache
2. 后续请求直接加载缓存，跳过前缀计算
3. 对于长系统 prompt（如 2000 token），可以节省 30-50% 的 Prefill 时间

Prefix Caching 的实现：

• 使用哈希表索引前缀
• 支持多级前缀（如 system + user + assistant）
• 自动过期机制（LRU 或 TTL）

推测解码是 2024-2026 年最重要的推理优化技术之一。

核心思想：用一个小模型（草稿模型）快速生成多个 token，然后用大模型（目标模型）一次性验证。如果验证通过，可以一次性接受多个 token；如果验证失败，从失败点重新生成。

为什么推测解码有效？

自回归生成的瓶颈是：每生成一个 token 都要跑一次完整的模型前向传播。对于 70B 模型，这需要 10-50ms。

推测解码的巧妙之处在于：

1. 小模型生成 K 个 token 只需 K × (小模型推理时间)
2. 大模型验证 K 个 token 只需 1 × (大模型推理时间)
3. 如果接受率高（通常 70-90%），可以跳过大量大模型推理

举例：

• 传统方法：生成 10 个 token 需要 10 次大模型推理 = 10 × 20ms = 200ms
• 推测解码（K=5，接受率 80%）：
  • 小模型生成 5 个 token = 5 × 2ms = 10ms
  • 大模型验证 5 个 token = 1 × 20ms = 20ms
  • 接受 4 个 token，拒绝 1 个
  • 重新生成 1 个 token = 小模型 1 × 2ms + 大模型 1 × 20ms = 22ms
  • 总计：10 + 20 + 22 = 52ms
  • 加速比：200ms / 52ms ≈ 3.8x

推测解码的实现方式：

1. 独立草稿模型：使用一个独立的小模型（如 Llama-7B 为 Llama-70B 做草稿）
2. 自推测（Self-Speculative）：使用目标模型的早期退出层作为草稿模型
3. Medusa：在目标模型上添加多个预测头，并行预测多个 token

Medusa：无需草稿模型的推测解码

Medusa 在目标模型上添加 3-5 个额外的预测头，每个头负责预测不同位置的 token：

• Head 1：预测下一个 token
• Head 2：预测下下个 token
• Head 3：预测下下下个 token
• ...

推理时，所有头并行预测，然后一次性验证。

优势：

• 无需额外的草稿模型
• 内存开销小（只增加几个预测头）
• 适合无法加载两个模型的场景

2026 年的推测解码生态：

from vllm import LLM, SamplingParams

# 配置推测解码
llm = LLM(
    model="meta-llama/Llama-3.1-70B-Instruct",
    speculative_model="meta-llama/Llama-3.1-8B-Instruct",
    num_speculative_tokens=5,  # 每次推测 5 个 token
    tensor_parallel_size=4,    # 4 GPU 张量并行
    gpu_memory_utilization=0.9,
)

# 推理参数
sampling_params = SamplingParams(
    temperature=0.7,
    top_p=0.9,
    max_tokens=1024,
)

# 生成
outputs = llm.generate(
    ["请解释量子计算的基本原理"],
    sampling_params
)

for output in outputs:
    print(output.outputs[0].text)

量化是 LLM 部署的必备技术，可以在几乎不损失精度的情况下大幅降低内存和计算需求。

量化的核心思想：将模型权重从高精度（FP32/FP16）转换为低精度（INT8/INT4），减少内存占用和计算量。

量化方法分类：

1. 训练后量化（PTQ）：无需重新训练，直接在训练好的模型上量化

   • 优点：快速、简单
   • 缺点：精度损失相对较大

2. 量化感知训练（QAT）：在训练过程中模拟量化误差

   • 优点：精度损失小
   • 缺点：需要重新训练，成本高

2026 年主流的 PTQ 方法：

AWQ（Activation-aware Weight Quantization）：

AWQ 是 2024-2026 年最流行的 INT4 量化方法，核心创新是：

1. 激活感知：识别对输出影响大的「显著权重」
2. 保护显著权重：对显著权重使用更高的精度或缩放因子
3. 等价变换：通过数学变换减少量化误差

AWQ 的效果：

• 70B 模型从 140GB（FP16）压缩到 35GB（INT4）
• 在 MMLU 等基准测试上精度损失 <1%
• 推理速度提升 1.5-2x

FP8 量化：H100/B200 的原生支持

H100 和 B200 GPU 原生支持 FP8 精度，这是精度和性能的最佳平衡：

• 相比 FP16，内存节省 50%，速度提升 1.5x
• 精度损失几乎为零（<0.1%）
• 无需复杂的量化算法

FP8 是 H100/B200 用户的首选。

GGUF：CPU 推理的标准格式

GGUF 是 llama.cpp 的原生格式，专为 CPU 推理优化：

• 支持 INT4/INT8/FP16 混合精度
• 针对 CPU 指令集优化（AVX2/AVX512/ARM NEON）
• 支持内存映射（mmap），无需全部加载到内存

GGUF 是 CPU 推理和边缘部署的标准选择。

# 安装 AutoAWQ
pip install autoawq

# 量化脚本
from awq import AutoAWQForCausalLM
from transformers import AutoTokenizer

model_path = "meta-llama/Llama-3.1-70B-Instruct"
quant_config = {
    "zero_point": True,
    "q_group_size": 128,
    "w_bit": 4,
    "version": "GEMM"
}

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

# 量化
model.quantize(tokenizer, quant_config=quant_config)

# 保存
model.save_quantized("Llama-3.1-70B-Instruct-AWQ")
tokenizer.save_pretrained("Llama-3.1-70B-Instruct-AWQ")

# 安装 llama.cpp
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
make -j

# 转换为 GGUF 格式
python convert_hf_to_gguf.py \
    ../Llama-3.1-70B-Instruct-AWQ \
    --outfile Llama-3.1-70B-Instruct-AWQ.gguf \
    --outtype f16

# 量化为 Q4_K_M（推荐的 INT4 量化）
./llama-quantize \
    Llama-3.1-70B-Instruct-AWQ.gguf \
    Llama-3.1-70B-Instruct-Q4_K_M.gguf \
    Q4_K_M

# 运行推理
./llama-cli \
    -m Llama-3.1-70B-Instruct-Q4_K_M.gguf \
    -p "请解释量子计算的基本原理" \
    -n 512 \
    -t 8  # 使用 8 个 CPU 线程

当模型太大无法放入单个 GPU 时，分布式推理是唯一选择。

分布式推理有三种主要模式：

1. 张量并行（Tensor Parallelism）：将单层模型切分到多个 GPU
2. 流水线并行（Pipeline Parallelism）：将不同层分配到不同 GPU
3. 数据并行（Data Parallelism）：复制模型，每个 GPU 处理不同的请求

张量并行（TP）：

将矩阵乘法切分到多个 GPU 上并行执行。

例如，一个 [4096, 4096] 的矩阵乘法可以切分为 4 个 [4096, 1024] 的乘法，分别在 4 个 GPU 上执行。

优势：

• 延迟低（所有 GPU 同时计算）
• 适合 Prefill 阶段（计算密集）

劣势：

• 需要高速互联（NVLink）
• GPU 数量必须是 2 的幂（2/4/8）

流水线并行（PP）：

将模型的不同层分配到不同 GPU。

例如，一个 80 层的模型可以分配到 4 个 GPU：

• GPU 0：层 0-19
• GPU 1：层 20-39
• GPU 2：层 40-59
• GPU 3：层 60-79

优势：

• 对互联要求低（只需传递激活值）
• 可以跨机器部署

劣势：

• 延迟高（串行执行）
• 存在「气泡」（部分 GPU 空闲）

2026 年的最佳实践：TP + PP 混合

对于超大模型（如 Llama-405B），通常使用 TP + PP 混合：

• 机器内使用 TP（NVLink 高速互联）
• 机器间使用 PP（以太网/InfiniBand）

例如，8 机器 64 GPU 部署 405B 模型：

• 每台机器 8 GPU，使用 TP=8
• 8 台机器，使用 PP=8
• 总并行度：TP=8, PP=8

序列并行（Sequence Parallelism）：

对于超长序列（如 128K 上下文），可以将序列切分到多个 GPU。

这是 2025-2026 年的研究热点，代表工作包括：

• Ring Attention：环形传递 KV Cache
• Ulysses：将序列切分到不同 GPU，使用 All-to-All 通信

序列并行是处理超长上下文的关键技术。

from vllm import LLM, SamplingParams

# 张量并行：8 GPU 部署 Llama-3.1-405B
llm = LLM(
    model="meta-llama/Llama-3.1-405B-Instruct",
    tensor_parallel_size=8,      # 8 GPU 张量并行
    pipeline_parallel_size=1,    # 不使用流水线并行
    gpu_memory_utilization=0.9,
    max_model_len=32768,         # 最大上下文长度
    dtype="bfloat16",
    trust_remote_code=True,
)

# 对于超大模型，使用 TP + PP 混合
llm_hybrid = LLM(
    model="meta-llama/Llama-3.1-405B-Instruct",
    tensor_parallel_size=8,      # 每台机器 8 GPU
    pipeline_parallel_size=8,    # 8 台机器
    gpu_memory_utilization=0.9,
)

# 推理
outputs = llm.generate(
    ["解释量子计算的原理"],
    SamplingParams(max_tokens=1024)
)

2026 年，三大主流推理引擎各有特色。

vLLM：开源社区的首选

vLLM 是 2024-2026 年最流行的开源推理引擎，核心优势：

1. PagedAttention：高效的 KV Cache 管理
2. 易用性：API 兼容 OpenAI，开箱即用
3. 模型支持：支持几乎所有主流模型
4. 社区活跃：更新频繁，文档完善

适用场景：

• 通用 LLM 服务
• 研究和原型开发
• 中小规模部署

TensorRT-LLM：NVIDIA 官方方案

TensorRT-LLM 是 NVIDIA 的官方推理引擎，核心优势：

1. 极致性能：针对 NVIDIA GPU 深度优化
2. FP8 支持：原生支持 H100/B200 的 FP8 精度
3. Inflight Batching：动态批处理，最大化 GPU 利用率
4. C++ 后端：低延迟、高吞吐

适用场景：

• 大规模生产部署
• 追求极致性能
• NVIDIA GPU 专属环境

劣势：

• 配置复杂，学习曲线陡峭
• 模型支持不如 vLLM 广泛
• 需要手动优化

SGLang：结构化生成的专家

SGLang 专注于结构化生成（JSON、代码、表格等），核心优势：

1. RadixAttention：针对结构化生成的 KV Cache 优化
2. 约束解码：保证输出符合指定格式
3. 高效批处理：针对结构化生成的特殊批处理策略

适用场景：

• 需要 JSON/代码输出的应用
• Agent 工具调用
• 数据提取和转换

2026 年推理引擎对比：

选择建议：

• 快速上手、通用场景：选择 vLLM
• 追求极致性能、大规模部署：选择 TensorRT-LLM
• 结构化生成、Agent 应用：选择 SGLang

# 安装 vLLM
pip install vllm

# 启动 OpenAI 兼容服务
vllm serve meta-llama/Llama-3.1-70B-Instruct \
    --tensor-parallel-size 4 \
    --max-model-len 32768 \
    --gpu-memory-utilization 0.9 \
    --port 8000

# 使用 OpenAI SDK 调用
import openai

client = openai.OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="not-needed"
)

response = client.chat.completions.create(
    model="meta-llama/Llama-3.1-70B-Instruct",
    messages=[
        {"role": "user", "content": "解释量子计算的原理"}
    ],
    max_tokens=1024
)

print(response.choices[0].message.content)

# 安装 SGLang
pip install sglang

# 启动服务
python -m sglang.launch_server \
    --model-path meta-llama/Llama-3.1-70B-Instruct \
    --tp 4 \
    --port 30000

# 结构化生成示例
import sglang as sgl

@sgl.function
def extract_info(sgl, text):
    sgl += "从以下文本提取信息，输出 JSON 格式：\n"
    sgl += text + "\n"
    sgl += sgl.gen(
        "json_output",
        max_tokens=1024,
        temperature=0,
        # 约束输出为 JSON 格式
        regex=r'\{.*\}'
    )

# 运行
result = extract_info.run(text="张三，男，30岁，工程师")
print(result["json_output"])

将 LLM 推理服务部署到生产环境需要考虑更多因素。

1. 容量规划

确定需要的 GPU 数量和配置：

1. 估算峰值 QPS：每秒请求数
2. 估算平均输出长度：每个请求生成的 token 数
3. 计算所需吞吐量：峰值 QPS × 平均输出长度 = tokens/秒
4. 选择 GPU 配置：根据吞吐量选择 GPU 数量和并行策略

示例计算：

• 峰值 QPS：100
• 平均输出长度：512 token
• 所需吞吐量：100 × 512 = 51200 tokens/秒
• Llama-70B（INT4）在 A100 上的吞吐量：约 2000 tokens/秒/GPU
• 所需 GPU 数量：51200 / 2000 = 25.6 → 26 GPU

2. 弹性伸缩

使用 Kubernetes + GPU Operator 实现自动伸缩：

1. HPA（Horizontal Pod Autoscaler）：根据 QPS 自动增减 Pod
2. KEDA（Kubernetes Event-Driven Autoscaling）：根据队列长度伸缩
3. GPU 共享：使用 MIG（Multi-Instance GPU）或 MPS（Multi-Process Service）

3. 监控指标

关键监控指标：

• 延迟：P50/P95/P99 延迟
• 吞吐量：tokens/秒、requests/秒
• GPU 利用率：计算利用率、内存利用率
• KV Cache 命中率：Prefix Caching 的效果
• 错误率：超时、OOM、其他错误

4. 成本优化

降低推理成本的方法：

1. 使用更小的模型：如果 7B 模型能满足需求，不要用 70B
2. 量化部署：INT4/INT8 量化可以大幅降低 GPU 需求
3. 推测解码：用小模型加速大模型
4. 批处理：合并多个请求，提高 GPU 利用率
5. 缓存：缓存常见请求的结果
6. 竞价实例：使用云厂商的竞价实例（Spot Instance）

5. 高可用

确保服务的高可用性：

1. 多副本：至少 2 个副本，避免单点故障
2. 健康检查：定期检查服务状态
3. 自动重启：OOM 或崩溃时自动重启
4. 灰度发布：新版本先在小流量验证

6. 安全

保护推理服务的安全：

1. 认证：API Key 或 OAuth
2. 限流：防止滥用
3. 输入过滤：防止 prompt 注入
4. 输出过滤：过滤敏感信息
5. 审计日志：记录所有请求

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-llama-70b
spec:
  replicas: 3  # 3 副本保证高可用
  selector:
    matchLabels:
      app: vllm-llama-70b
  template:
    metadata:
      labels:
        app: vllm-llama-70b
    spec:
      containers:
      - name: vllm
        image: vllm/vllm-openai:latest
        args:
        - --model
        - meta-llama/Llama-3.1-70B-Instruct-AWQ
        - --tensor-parallel-size
        - "4"
        - --max-model-len
        - "32768"
        - --gpu-memory-utilization
        - "0.9"
        - --port
        - "8000"
        resources:
          limits:
            nvidia.com/gpu: 4  # 每个 Pod 4 GPU
            memory: 64Gi
            cpu: 16
          requests:
            nvidia.com/gpu: 4
            memory: 64Gi
            cpu: 16
        livenessProbe:
          httpGet:
            path: /health
            port: 8000
          initialDelaySeconds: 60
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /health
            port: 8000
          initialDelaySeconds: 30
          periodSeconds: 5
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: vllm-llama-70b-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: vllm-llama-70b
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Pods
    pods:
      metric:
        name: gpu_utilization
      target:
        type: AverageValue
        averageValue: "70"  # GPU 利用率超过 70% 时扩容

LLM 推理技术正在快速演进，以下是 2026 年的关键趋势。

1. Prefill-Decode 分离架构

将 Prefill 和 Decode 部署在不同的 GPU 上，针对各自的计算特性优化：

• Prefill 节点：高算力 GPU（如 A100），计算密集
• Decode 节点：高带宽 GPU（如 H100），内存带宽密集

效果：

• 整体 TCO 降低 15-25%
• 资源利用率提升 30%+

代表工作：

• Meta 的 Splitwise
• Microsoft 的 DeepSpeed-MII

2. 异构推理

使用不同类型的 GPU 混合部署：

• 高端 GPU（H100/B200）处理复杂请求
• 中端 GPU（A10/L40）处理简单请求
• 根据请求复杂度动态路由

3. 边缘推理

在边缘设备（手机、PC、IoT）上运行 LLM：

• 量化技术（INT4/INT8）
• CPU 推理优化（llama.cpp）
• NPU 加速（Apple Neural Engine、Qualcomm AI Engine）

4. 多模态推理优化

针对多模态模型（文本+图像+音频）的特殊优化：

• 视觉编码器的批处理
• 跨模态注意力的优化
• 流式处理（边接收边处理）

5. 推理即服务（Inference-as-a-Service）

云厂商提供托管的推理服务：

• 按 token 计费
• 自动伸缩
• 无需管理 GPU

代表服务：

• OpenAI API
• Anthropic API
• AWS Bedrock
• Azure AI
• Google Vertex AI

6. 开源推理引擎的崛起

vLLM、SGLang、TensorRT-LLM 等开源引擎的性能逐渐接近甚至超过闭源方案：

• 社区驱动的快速迭代
• 开放的架构便于定制
• 避免供应商锁定

7. 硬件专用优化

针对不同硬件的专用优化：

• NVIDIA：TensorRT-LLM、CUDA Graph
• AMD：ROCm、AITER
• Intel：OneDNN、OpenVINO
• Apple：Metal、Core ML

8. 绿色推理

关注推理的能耗和碳排放：

• 更高效的硬件（如 Tensordyne Napier）
• 更优化的算法（推测解码减少计算）
• 可再生能源供电的数据中心

总结：

LLM 推理服务是一个快速发展的领域，2026 年的关键技术包括：

1. KV Cache 管理：PagedAttention、Prefix Caching
2. 推测解码：用小模型加速大模型
3. 量化部署：INT4/INT8/FP8 量化
4. 分布式推理：张量并行、流水线并行
5. 推理引擎：vLLM、TensorRT-LLM、SGLang

掌握这些技术，可以构建高性能、低成本的 LLM 推理服务。