模型推理服务架构：从 vLLM 到 TensorRT-LLM 的生产部署

大语言模型从实验室走向生产环境时，推理服务架构是决定成败的关键环节。模型在单个 GPU 上运行和在大规模生产环境中服务成千上万的并发请求，是完全不同的两个问题。

推理服务架构的演进经历了四个阶段：

第一阶段：单模型单实例。 这是最原始的方案——在服务器上加载一个模型，通过 HTTP 接口提供服务。方案简单但吞吐量低，GPU 利用率差，无法应对高并发场景。

第二阶段：批处理优化。 引入动态批处理（Dynamic Batching）技术，将多个请求合并为一个 GPU 推理批次。这大幅提升了吞吐量，但引入了延迟问题——后来的请求需要等待批次填满。

第三阶段：连续批处理（Continuous Batching）。 vLLM 引入的 PagedAttention 技术实现了连续批处理——每个请求独立调度，无需等待批次填满。这是 2024-2025 年推理服务架构的最大突破。

第四阶段：多引擎协同与分布式推理。 2026 年，随着模型规模持续增长（万亿参数），单 GPU 甚至单节点已无法承载单个模型的推理。分布式推理、多引擎协同和推理编排成为主流方案。

💡 前置收获： 理解推理服务架构，需要先掌握 GPU 推理的基本原理——模型权重加载、KV Cache 管理、批处理机制和内存分配策略。

vLLM 是 2024-2025 年最成功的开源推理引擎，其核心创新 PagedAttention 借鉴了操作系统中虚拟内存的分页管理思想，将 KV Cache 的管理从"连续分配"改为"分页分配"。

传统批处理的痛点： 在传统的动态批处理中，每个请求的 KV Cache 需要在 GPU 显存中连续分配。但由于不同请求的序列长度差异很大，连续分配会导致严重的显存碎片化——大量显存被浪费在无法利用的碎片空间中。研究表明，传统方法的显存利用率通常只有 20-40％。

PagedAttention 的解决方案： 将每个序列的 KV Cache 拆分为固定大小的"页"（Block），这些页可以在显存中非连续分布。当需要访问某个序列的 KV Cache 时，PagedAttention 通过一个"页表"（Block Table）来定位各个页的位置。这与操作系统的虚拟内存分页机制如出一辙——程序的虚拟地址空间是连续的，但物理内存中的页是非连续的。

连续批处理（Continuous Batching） 是 PagedAttention 带来的另一个重大改进。在传统批处理中，一个批次中的所有序列必须同时开始和结束推理——即使有些序列已经生成完毕，也必须等待最长的序列完成。连续批处理允许序列在任何时间点加入或离开批次——当一个序列生成完毕时，它的显存页立即被释放，新的序列可以立即加入。这大幅提升了 GPU 利用率和吞吐量。

性能数据： 在 Llama-2-70B 模型上，vLLM 的吞吐量比 HuggingFace Transformers 高出 24 倍，比 FasterTransformer 高出 3.5 倍。在真实生产场景中，vLLM 能够支撑数千 QPS 的并发请求，同时保持 P99 延迟在秒级以内。

# 安装并启动 vLLM 推理服务
pip install vllm

# 启动单模型 API 服务
python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-3-70B-Instruct \
    --tensor-parallel-size 4 \
    --max-num-batched-tokens 8192 \
    --gpu-memory-utilization 0.95 \
    --port 8000

# 测试推理服务
curl http://localhost:8000/v1/completions \
    -H "Content-Type: application/json" \
    -d '{
        "model": "meta-llama/Llama-3-70B-Instruct",
        "prompt": "解释量子计算的基本原理",
        "max_tokens": 512,
        "temperature": 0.7
    }'

from vllm import LLM, SamplingParams

# 初始化推理引擎
llm = LLM(
    model="meta-llama/Llama-3-70B-Instruct",
    tensor_parallel_size=4,
    gpu_memory_utilization=0.95,
    max_num_batched_tokens=8192
)

# 批量推理请求
prompts = [
    "解释量子纠缠的物理含义",
    "Python 中装饰器的作用是什么",
    "简述 Transformer 的自注意力机制",
    "比较 CNN 和 RNN 的适用场景",
]

sampling_params = SamplingParams(
    temperature=0.7,
    top_p=0.9,
    max_tokens=512
)

# 执行推理（自动连续批处理）
outputs = llm.generate(prompts, sampling_params)

for output in outputs:
    prompt = output.prompt
    generated = output.outputs[0].text
    print(f"Prompt: {prompt}")
    print(f"Generated: {generated}")
    print("---")

TensorRT-LLM 是 NVIDIA 官方推出的大模型推理优化库，它将 TensorRT 的深度神经网络编译优化能力扩展到了大语言模型领域。与 vLLM 的"运行时优化"不同，TensorRT-LLM 采用"编译时优化"策略——将模型图在部署前进行深度优化和编译，生成针对特定 GPU 架构的极致优化推理引擎。

TensorRT-LLM 的核心优化技术包括：

Kernel 融合： 将多个连续的 GPU 算子融合为一个自定义 Kernel，减少 Kernel 启动开销和中间结果的显存读写。例如，将 LayerNorm + GELU + MatMul 三个算子融合为一个 Kernel，可以减少两次显存读写和两次 Kernel 启动。

量化感知推理： TensorRT-LLM 支持 FP8、INT8 和 INT4 量化推理。FP8 量化可以在几乎不损失精度的情况下将显存需求减半，推理速度提升 1.5-2 倍。INT4 量化进一步将显存需求压缩到 FP16 的 1/4，适合在消费级 GPU 上运行大模型。

In-flight Batching： TensorRT-LLM 的 In-flight Batching 技术类似于 vLLM 的连续批处理，但实现方式不同。它使用 CUDA Graph 技术将推理过程固化为可重复执行的计算图，在保持连续批处理灵活性的同时，最大化 GPU 计算单元的利用率。

多 GPU 张量并行： 使用 NVIDIA NCCL 库实现高效的 GPU 间通信，支持从单节点 8 GPU 到多节点数十 GPU 的大规模分布式推理。

TensorRT-LLM vs vLLM 的取舍： TensorRT-LLM 的性能通常比 vLLM 高出 20-40%，但代价是部署复杂度显著增加——需要为每个模型和 GPU 架构单独编译，编译时间可能长达数十分钟。vLLM 则支持"即插即用"，无需编译即可运行任意 HuggingFace 模型。

# TensorRT-LLM 模型构建流程
# 1. 安装 TensorRT-LLM
pip install tensorrt-llm

# 2. 将 HuggingFace 模型转换为 TensorRT-LLM 引擎
python build.py \
    --model_dir meta-llama/Llama-3-70B-Instruct \
    --dtype float16 \
    --use_gemm_plugin float16 \
    --use_gpt_attention_plugin float16 \
    --use_gpt_moe_plugin float16 \
    --parallel_build \
    --tp_size 4 \
    --output_dir engines/llama-70b-tp4

# 3. 运行推理服务
python run.py \
    --engine_dir engines/llama-70b-tp4 \
    --max_output_len 512 \
    --input_text "解释量子计算的基本原理"

import tensorrt_llm
from tensorrt_llm.runtime import ModelRunner

# 加载编译好的推理引擎
runner = ModelRunner.from_dir(
    engine_dir="engines/llama-70b-tp4",
    rank=0,  # 当前 GPU 的 rank
    debug_mode=False
)

# 准备输入
input_text = "解释量子计算的基本原理"
input_ids = runner.tokenizer.encode(input_text)

# 执行推理
output_ids = runner.generate(
    input_ids,
    max_new_tokens=512,
    temperature=0.7,
    top_p=0.9,
    repetition_penalty=1.1
)

# 解码输出
output_text = runner.tokenizer.decode(output_ids[0])
print(output_text)

在生产环境中，单个推理服务实例无法满足高可用性和弹性伸缩的要求。需要引入服务编排层来管理多个推理服务实例的生命周期。

推理服务编排的核心组件包括：

负载均衡器（Load Balancer）： 将客户端请求分发到多个推理服务实例。对于推理服务，负载均衡策略需要特别设计——传统的轮询（Round Robin）可能导致 GPU 负载不均衡，因为不同请求的计算量差异很大。基于 GPU 利用率的动态负载均衡是更优的选择——将新请求分配给当前 GPU 利用率最低的实例。

自动伸缩（Auto Scaling）： 根据请求负载自动调整推理服务实例的数量。水平伸缩（增加/减少实例数）比垂直伸缩（增加单个实例的 GPU 数量）更灵活。KEDA（Kubernetes Event-driven Autoscaling） 是基于 Kubernetes 的主流方案，可以根据自定义指标（如 GPU 利用率、请求队列长度）触发伸缩。

健康检查与故障恢复： 推理服务实例可能因 OOM、GPU 故障或网络问题而异常。健康检查机制需要定期探测每个实例的状态，发现异常后自动将其从负载均衡池移除，并启动新实例替代。

模型热更新： 在生产环境中更新模型版本时，需要实现零停机部署（Zero-downtime Deployment）。蓝绿部署（Blue-Green Deployment）和金丝雀发布（Canary Release）是两种常用策略。蓝绿部署同时运行新旧两个版本，通过负载均衡器切换流量；金丝雀发布逐步将少量流量导入新版本，验证无误后全量切换。

推理服务的**可观测性（Observability）**是生产运维的核心。与传统的 Web 服务不同，推理服务的关键指标不仅仅是响应时间和错误率，还包括模型特有的性能指标。

推理服务的核心监控指标分为三层：

基础设施层（Infrastructure Metrics）： GPU 利用率、GPU 显存使用、GPU 温度、CPU 利用率、内存使用、网络 I/O、磁盘 I/O。这些指标反映硬件资源的使用状况，是发现硬件瓶颈的基础。

服务层（Service Metrics）： 请求吞吐量（QPS）、响应延迟（P50/P95/P99）、错误率、批次大小分布、KV Cache 使用率、排队等待时间。这些指标反映推理服务的运行效率和稳定性。

模型层（Model Metrics）： 生成 token 速率（tokens/sec）、平均输出长度、温度/top_p 参数分布、重复率、异常输出检测。这些指标反映模型的推理质量和行为特征。

监控工具链推荐：

• Prometheus + Grafana： 收集和可视化基础设施层和服务层指标的标准方案。
• OpenTelemetry： 统一的遥测数据采集框架，支持 Traces、Metrics 和 Logs 的集成。
• LangSmith / Arize Phoenix： 专为 LLM 应用设计的可观测性平台，提供模型层的深度分析。

告警策略设计： 合理的告警策略应该区分"紧急告警"和"预警通知"。紧急告警（如 GPU OOM、服务不可用）需要立即响应；预警通知（如 GPU 利用率持续高于 85%、P99 延迟逐渐升高）可以延迟处理但需要纳入日常运维计划。

推理服务作为企业 AI 基础设施的核心组件，安全访问控制是不容忽视的环节。推理服务的安全风险不仅包括传统 Web 服务面临的安全威胁，还包括 AI 特有的安全挑战。

传统安全层： API 网关负责身份验证（Authentication）和授权（Authorization）。推荐使用 API Key + JWT Token 的双重认证机制——API Key 用于识别调用方身份，JWT Token 用于验证请求的合法性和时效性。速率限制（Rate Limiting） 防止恶意或异常的请求洪水攻击，请求体大小限制 防止超大请求导致的服务崩溃。

AI 特有风险： 提示注入攻击（Prompt Injection） 通过恶意输入试图绕过模型的安全限制。数据泄露风险 ——如果推理服务处理敏感数据，需要确保请求和响应数据在传输和存储过程中都被加密。模型窃取攻击 ——攻击者通过大量查询试图重建模型权重，这种攻击在 API 暴露的推理服务中尤其需要防范。

安全策略实施： 所有推理服务应该部署在私有网络中，通过 API 网关暴露给外部客户端。API 网关负责 SSL/TLS 终止、身份验证、速率限制和请求过滤。推理服务本身不直接暴露公网端口，只接受来自 API 网关的内部请求。敏感数据在传输过程中使用 TLS 1.3 加密，在存储时使用 AES-256 加密。

💡 前置收获： 理解推理服务安全，可以参考 OWASP API Security Top 10。它列出了 API 安全最常见的 10 个风险，其中多项与推理服务直接相关。

推理服务的成本优化是 AI 生产部署中最实际的挑战。模型推理的成本主要由 GPU 计算资源决定，而 GPU 是 AI 基础设施中最昂贵的组件。

成本优化的核心杠杆：

模型压缩： 量化（Quantization）是最直接的成本优化手段。FP16 量化可以将显存需求和计算量减半，INT8 量化进一步减半，INT4 量化则可以将显存需求压缩到 FP16 的 1/4。代价是模型精度会有所下降——FP16 通常损失 < 1%，INT8 损失 1-3%，INT4 损失 3-8%。对于大多数应用场景，INT8 量化是一个合理的权衡点。

投机推理（Speculative Decoding）： 使用一个小型"草稿模型"快速生成候选 token，然后用大型目标模型验证这些 token。如果草稿模型的预测被验证正确，就跳过了目标模型的推理步骤。对于简单文本生成任务，投机推理可以将推理速度提升 2-3 倍，同时保持大型模型的输出质量。

动态模型选择： 根据请求复杂度动态选择不同规模的模型。简单请求（如问答、摘要）使用小模型（7B），复杂请求（如代码生成、复杂推理）使用大模型（70B）。这种策略可以将平均推理成本降低 40-60%。

预留实例 + 按需实例混合： 对于可预测的基础负载，使用预留实例（价格比按需实例低 30-60%）；对于突发负载，使用按需实例自动伸缩。这种混合策略可以在保证服务质量的同时最大化成本效率。

现在我们将前面学到的概念整合为一个完整的推理服务集群部署方案。这个方案基于 Kubernetes + vLLM + Prometheus + Grafana 的技术栈，适用于中等规模（10-50 GPU）的生产环境。

架构概述：

• API 网关层： Kong 或 Nginx，负责 SSL 终止、身份验证、速率限制和负载均衡。
• 推理服务层： vLLM 实例运行在 Kubernetes Pod 中，每个 Pod 分配 1-4 个 GPU。
• 监控层： Prometheus 采集指标，Grafana 可视化，Alertmanager 发送告警。
• 存储层： 模型权重存储在对象存储中，推理服务启动时按需加载。

部署流程：

第一步，准备 Kubernetes 集群，配置 GPU 节点池。每个 GPU 节点需要安装 NVIDIA 驱动和 Device Plugin。

第二步，部署 vLLM 服务。使用 Helm Chart 或自定义 YAML 定义 Deployment 和 Service。

第三步，配置 Prometheus 和 Grafana。导入 vLLM 的 Prometheus metrics，设置监控面板和告警规则。

第四步，配置自动伸缩。使用 KEDA 根据 GPU 利用率和请求队列长度触发水平伸缩。

第五步，配置 CI/CD 流水线。模型更新通过 CI/CD 自动部署，使用蓝绿部署策略实现零停机更新。

💡 前置收获： 了解 Kubernetes 的基本概念（Pod、Deployment、Service、HPA）是理解本部署方案的前提。如果你不熟悉 Kubernetes，建议先学习其核心概念。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-llama-70b
spec:
  replicas: 4  # 初始 4 个实例
  selector:
    matchLabels:
      app: vllm-llama-70b
  template:
    metadata:
      labels:
        app: vllm-llama-70b
    spec:
      containers:
      - name: vllm
        image: vllm/vllm-openai:latest
        command: ["python", "-m", "vllm.entrypoints.openai.api_server"]
        args:
        - "--model"
        - "meta-llama/Llama-3-70B-Instruct"
        - "--tensor-parallel-size"
        - "2"
        - "--max-num-batched-tokens"
        - "8192"
        - "--gpu-memory-utilization"
        - "0.90"
        resources:
          limits:
            nvidia.com/gpu: 2
            memory: "64Gi"
            cpu: "16"
          requests:
            nvidia.com/gpu: 2
            memory: "32Gi"
            cpu: "8"
        ports:
        - containerPort: 8000
        readinessProbe:
          httpGet:
            path: /health
            port: 8000
          initialDelaySeconds: 60
          periodSeconds: 10
        livenessProbe:
          httpGet:
            path: /health
            port: 8000
          initialDelaySeconds: 120
          periodSeconds: 30

# KEDA 自动伸缩配置
kubectl apply -f - <<EOF
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: vllm-autoscaler
spec:
  scaleTargetRef:
    name: vllm-llama-70b
  minReplicaCount: 2    # 最小 2 个实例（高可用）
  maxReplicaCount: 16   # 最大 16 个实例
  triggers:
  - type: prometheus
    metadata:
      serverAddress: http://prometheus:9090
      metricName: vllm_gpu_utilization
      threshold: '80'    # GPU 利用率超过 80% 触发扩容
      query: |
        avg(vllm:gpu_utilization)
  - type: prometheus
    metadata:
      serverAddress: http://prometheus:9090
      metricName: vllm_request_queue_length
      threshold: '50'    # 排队请求超过 50 触发扩容
      query: |
        sum(vllm:request_queue_length)
EOF

推理服务架构是 AI 从实验室走向生产的关键环节。从 vLLM 的连续批处理到 TensorRT-LLM 的编译优化，从单服务实例到高可用集群，每个环节都需要认真设计和实施。

关键要点总结：

1. 连续批处理（PagedAttention）是推理性能的基础突破。 它将显存利用率从 20-40% 提升到 80-95%，吞吐量提升 24 倍。
2. TensorRT-LLM 提供极致性能但牺牲了灵活性。 在对性能有极致要求且模型变更不频繁的场景下优先选择。
3. 服务编排和高可用性是生产部署的标配。 负载均衡、自动伸缩、健康检查和蓝绿部署缺一不可。
4. 可观测性覆盖三层指标。 基础设施、服务、模型三个层面的监控指标共同构成完整的可观测性体系。
5. 成本优化应该从量化开始。 FP16/INT8 量化是性价比最高的优化手段，实施成本低且效果显著。

AI Master 的立场： 推理服务架构的选择没有"最好"，只有"最适合"。对于创业公司，vLLM 的即插即用和快速迭代能力比极致性能更重要。对于大型企业，TensorRT-LLM 的性能优势和 NVIDIA 的官方支持可能更有价值。关键是根据自身的团队能力、业务需求和预算约束做出理性选择。