大模型推理部署实战：从 GPU 显存管理到高并发服务化的全链路设计
大模型推理部署实战：从 GPU 显存管理到高并发服务化的全链路设计
一、Token 吞吐与显存瓶颈：LLM 部署的工程困境
大模型推理部署的核心矛盾在于：GPU 显存是有限的，而模型参数和 KV Cache 的显存需求几乎是无上限的。一个 70B 参数的模型，仅模型权重就需要约 140GB 显存（FP16），加上 KV Cache 和运行时开销，单卡 A100 80GB 根本无法容纳。
更严峻的挑战来自并发。每个并发请求都需要独立的 KV Cache 空间来存储注意力机制的 Key 和 Value。以 Llama-2-70B 为例，单个请求的 KV Cache 在序列长度 2048 时约占 2GB 显存。10 个并发请求就需要 20GB 额外显存，直接挤占模型权重的存储空间。
推理延迟的尾部效应同样不可忽视。Prefill 阶段（首 Token 生成）需要处理整个 Prompt，计算密集；Decode 阶段（后续 Token 生成）每次只处理一个 Token，访存密集。两个阶段的资源瓶颈完全不同，混合调度会导致 GPU 利用率在 30%-90% 之间剧烈波动。
二、LLM 推理引擎的显存管理与调度机制
现代 LLM 推理引擎（vLLM、TGI、TensorRT-LLM）的核心创新在于显存管理和请求调度策略。理解这些机制是优化部署方案的工程基础。
flowchart TB
A[推理请求到达] --> B[请求调度器]
B --> C{Prefill/Decode 分离?}
C -->|是| D[Prefill 实例]
C -->|否| E[混合调度实例]
D --> F[生成 KV Cache]
F --> G[Transfer KV Cache]
G --> H[Decode 实例]
E --> I[连续批处理 Continuous Batching]
H --> J[Token 输出]
I --> J
J --> K{序列结束?}
K -->|是| L[释放 KV Cache]
K -->|否| M[继续 Decode]
M --> I
subgraph PagedAttention 显存管理
N[虚拟 KV Cache 页表] --> O[物理显存块池]
O --> P[按需分配]
O --> Q[共享 Copy-on-Write]
end
style B fill:#e74c3c,color:#fff
style N fill:#3498db,color:#fff
style I fill:#27ae60,color:#fff
PagedAttention 机制：vLLM 的核心创新，借鉴操作系统的虚拟内存分页思想。将 KV Cache 划分为固定大小的 Block（如 16 个 Token 对应一个 Block），维护虚拟 Block 到物理 Block 的页表映射。请求的 KV Cache 不需要连续的显存空间，按需分配物理 Block，序列结束后整块释放。这解决了传统方案中 KV Cache 必须预分配最大长度的显存浪费问题，显存利用率从 20%-40% 提升至 90% 以上。
Continuous Batching：传统 Static Batching 需要等待 Batch 中最长的序列完成后才能释放资源，短序列被迫等待。Continuous Batching 在每个 Decode Step 检查序列是否生成 EOS Token，已完成的序列立即移出 Batch，新请求立即加入。这使得 GPU 利用率不再受限于 Batch 中最慢的请求。
Prefill/Decode 分离调度：将推理拆分为 Prefill 和 Decode 两个独立阶段，分别调度到不同的 GPU 实例。Prefill 实例专注于计算密集的首 Token 生成，可以大 Batch 处理；Decode 实例专注于访存密集的 Token 生成，需要低延迟响应。分离后，两类实例可以独立扩缩容，资源利用率显著提升。
三、LLM 推理服务的高并发部署实现
3.1 基于 vLLM 的推理服务部署
"""
vLLM 推理服务启动配置
关键参数说明：
- gpu_memory_utilization: GPU 显存使用上限，预留空间给 CUDA 内核
- max_num_seqs: 最大并发序列数，受 KV Cache 显存约束
- enable_prefix_caching: 前缀缓存，相同 Prompt 前缀可复用 KV Cache
"""
from vllm import LLM, SamplingParams
from vllm.entrypoints.openai.api_server import run_server
# 推理引擎配置
ENGINE_ARGS = {
"model": "/models/llama-2-70b-chat-hf",
"tensor_parallel_size": 4, # 4 卡张量并行
"gpu_memory_utilization": 0.92, # 显存使用上限 92%
"max_num_seqs": 64, # 最大并发序列数
"max_model_len": 4096, # 最大序列长度
"enable_prefix_caching": True, # 开启前缀缓存
"block_size": 16, # PagedAttention Block 大小
"swap_space": 16, # CPU 交换空间大小（GB）
"dtype": "float16", # 推理精度
}
# 采样参数模板
DEFAULT_SAMPLING = SamplingParams(
temperature=0.7,
top_p=0.9,
max_tokens=2048,
# 为什么设置 frequency_penalty：防止长文本生成中的重复循环
frequency_penalty=0.1,
)
3.2 Kubernetes 上的 GPU 推理服务部署
# GPU 推理服务 Deployment
# 为什么使用 StatefulSet 而非 Deployment：
# 张量并行需要稳定的 Pod 网络标识，Pod 之间通过 RDMA 通信
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: llm-inference
namespace: ai-inference
spec:
replicas: 2 # 2 组 4 卡实例
selector:
matchLabels:
app: llm-inference
template:
metadata:
labels:
app: llm-inference
spec:
# GPU 拓扑感知调度：确保 4 张卡在同一 NUMA 节点
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: gpu-topology
operator: In
values:
- "4x-a100-nvlink"
containers:
- name: vllm-server
image: vllm/vllm-openai:latest
command:
- python
- -m
- vllm.entrypoints.openai.api_server
args:
- --model=/models/llama-2-70b-chat-hf
- --tensor-parallel-size=4
- --gpu-memory-utilization=0.92
- --max-num-seqs=64
- --enable-prefix-caching
resources:
limits:
nvidia.com/gpu: 4
memory: "128Gi"
cpu: "16"
requests:
nvidia.com/gpu: 4
memory: "64Gi"
cpu: "8"
ports:
- containerPort: 8000
# 健康检查：推理服务就绪需要加载模型（约 2 分钟）
readinessProbe:
httpGet:
path: /health
port: 8000
initialDelaySeconds: 120
periodSeconds: 10
livenessProbe:
httpGet:
path: /health
port: 8000
initialDelaySeconds: 180
periodSeconds: 30
---
# HPA：基于 GPU 利用率和请求队列深度自动扩缩容
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: llm-inference-hpa
namespace: ai-inference
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: StatefulSet
name: llm-inference
minReplicas: 2
maxReplicas: 8
metrics:
# 自定义指标：GPU SM 利用率
- type: Pods
pods:
metric:
name: gpu_sm_utilization
target:
type: AverageValue
averageValue: "70"
# 自定义指标：推理队列深度
- type: Pods
pods:
metric:
name: inference_queue_depth
target:
type: AverageValue
averageValue: "10"
3.3 推理请求网关与负载均衡
package gateway
import (
"context"
"sync/atomic"
)
// LLMGateway 大模型推理网关
// 核心职责：请求路由、负载均衡、流式响应转发
type LLMGateway struct {
backends []*InferenceBackend
// 轮询计数器，使用原子操作避免锁竞争
rrCounter uint64
}
// InferenceBackend 推理后端实例
type InferenceBackend struct {
Address string
ActiveConns int64 // 当前活跃连接数
MaxConns int64 // 最大并发连接数
AvgLatencyMs int64 // 平均推理延迟
QueueDepth int64 // 推理队列深度
IsHealthy bool // 健康状态
}
// SelectBackend 选择推理后端
// 为什么不用简单轮询：推理延迟差异大，轮询会导致长尾请求堆积
// 采用最少活跃连接 + 队列深度加权的策略
func (g *LLMGateway) SelectBackend() (*InferenceBackend, error) {
var best *InferenceBackend
minScore := int64(math.MaxInt64)
for _, b := range g.backends {
if !b.IsHealthy {
continue
}
// 评分 = 活跃连接数 * 2 + 队列深度 * 3
// 队列深度权重更高：排队中的请求对延迟影响更大
score := atomic.LoadInt64(&b.ActiveConns)*2 +
atomic.LoadInt64(&b.QueueDepth)*3
if score < minScore {
minScore = score
best = b
}
}
if best == nil {
return nil, ErrNoHealthyBackend
}
return best, nil
}
// StreamInference 流式推理请求
// 使用 SSE 协议将 Token 逐个推送给客户端
func (g *LLMGateway) StreamInference(ctx context.Context,
prompt string) (<-chan Token, error) {
backend, err := g.SelectBackend()
if err != nil {
return nil, err
}
// 增加后端活跃连接计数
atomic.AddInt64(&backend.ActiveConns, 1)
defer atomic.AddInt64(&backend.ActiveConns, -1)
tokenCh := make(chan Token, 64)
go func() {
defer close(tokenCh)
// 调用后端推理服务的流式接口
stream, err := backend.StreamComplete(ctx, prompt)
if err != nil {
tokenCh <- Token{Error: err}
return
}
for token := range stream {
select {
case tokenCh <- token:
case <-ctx.Done():
// 客户端断开连接，停止接收
return
}
}
}()
return tokenCh, nil
}
四、LLM 部署的代价：显存、延迟与成本的三角约束
显存与并发的零和博弈：GPU 显存是固定资源，模型权重、KV Cache 和运行时开销三者竞争。增加并发数意味着更多 KV Cache，挤占模型权重的显存空间。当显存不足时，推理引擎会触发 Swap（将 KV Cache 换出到 CPU 内存），延迟从毫秒级飙升至秒级。生产环境中，必须根据业务 QPS 和平均序列长度精确计算 KV Cache 需求，避免 Swap 触发。
张量并行的通信开销：4 卡张量并行时，每个 Decode Step 需要一次 All-Reduce 通信。NVLink 互联的通信延迟约 20-50us，PCIe 互联则高达 100-200us。对于 Decode 阶段（单步计算量小），通信开销占比可达 30%-50%。如果模型规模允许，优先选择单卡部署（如量化后的 70B 模型），避免通信开销。
前缀缓存的命中率代价：Prefix Caching 通过复用相同 Prompt 前缀的 KV Cache 来加速推理，但缓存管理本身有开销。Block 的哈希计算和页表查找在每个请求的 Prefill 阶段都需要执行。如果 Prompt 前缀的重复率低于 10%，缓存命中率低，管理开销反而拖慢推理速度。启用前需要分析业务流量的 Prompt 分布特征。
适用边界：上述方案适用于 7B-70B 规模模型的在线推理服务。对于 7B 以下的小模型，单卡部署即可满足大多数场景，无需复杂的并行策略。对于 175B 以上的超大模型，需要引入流水线并行和专家并行，架构复杂度显著提升。对于离线批处理场景，吞吐优先于延迟，应采用大 Batch + Static Batching 策略。
五、总结
LLM 推理部署的核心挑战是 GPU 显存管理和高并发调度。PagedAttention 解决了 KV Cache 的显存碎片问题，Continuous Batching 提升了 GPU 利用率，Prefill/Decode 分离优化了延迟分布。但这些优化都有其适用前提和代价。
落地路线建议：第一步，根据模型规模和 QPS 需求计算 GPU 资源需求，确定并行策略；第二步，部署 vLLM 推理引擎，配置 PagedAttention 和 Continuous Batching；第三步，实现推理网关的负载均衡和流式转发；第四步，配置基于 GPU 利用率的 HPA 自动扩缩容。每一步都需要在真实推理负载下验证参数，特别是显存利用率和 Swap 触发阈值。
汇聚全球AI编程工具，助力开发者即刻编程。
更多推荐
8
0- 0
已为社区贡献152条内容
所有评论(0)