高效推理与部署
推理与部署的目标是:在可控成本下,把模型能力稳定地交付给真实用户。这里的难点通常不在“跑通一次”,而在:
延迟(latency)可控:P50/P95/P99
吞吐(throughput)最大化:token/s、QPS
成本可预测:显存、算力、带宽、峰值资源
行为可控与可审计:权限、引用、拒答、安全策略
本章聚焦“推理系统工程”的关键杠杆:KV cache、attention 优化、量化、batching、以及服务形态设计。
量化与剪枝
量化:最常见、性价比最高
量化把权重/激活从 fp16/bf16 降到 int8/int4 等,以换取更低的显存与更高吞吐。
常见形式:
权重量化(W4A16 / W8A16):权重低比特,激活仍用 fp16/bf16
KV cache 量化:把 cache 也压低比特,减轻长上下文带宽
工程注意:
量化会改变数值误差分布,可能导致某些任务退化(尤其是长上下文/复杂推理)
量化方案要与推理框架/硬件路径匹配,否则“省了显存没省时间”
剪枝:更依赖结构化与硬件支持
剪枝要真正提速,通常需要结构化稀疏(例如按通道/块稀疏),并依赖硬件/内核对稀疏 GEMM 的支持。相比量化,工程门槛更高。
KV Cache、Attention 优化
KV Cache:decode 阶段的核心
自回归解码每一步只生成一个 token,如果每步都重算历史 (K,V) 会导致大量重复计算。KV cache 的关键是缓存历史 (K,V),每步只计算新 token 并与缓存做 attention(详见 architecture/transformer/kv_cache.md)。
FlashAttention:提升带宽利用率
FlashAttention 的思想是把 attention 计算拆成块,并融合 softmax 与 GEMM,减少中间张量的读写,从而显著提升训练与 prefill 的吞吐(尤其在长序列时)。
GQA/MQA:降低 KV cache 体积
通过让多个 query head 共享 K/V,显著降低 cache 显存与带宽压力,常用于长上下文推理服务。
多模态推理优化策略
多模态推理常见瓶颈在视觉侧:
视觉 encoder(ViT/视频模型)算力重
视觉 token 数量大,cross-attn 成本高
常见工程策略:
视觉特征缓存:多轮对话复用同一张图时非常有效
降低视觉 token 数:更粗的 patch / pooling / token pruning
分阶段推理:先做轻量理解(检索/粗分类),再触发重模型
GPU / CPU / 推理加速库
GPU 推理
优势:吞吐高、生态成熟(TensorRT-LLM、vLLM、FasterTransformer 等)。
关键点:
kernel 融合(fused attention/MLP)
连续 batching / 动态 batching
KV cache 管理(paged cache)
CPU 推理
适合:小模型、低成本、或对 GPU 资源敏感的场景。常见优化:
int8/int4 量化
多线程与 NUMA 绑定
KV cache 的内存布局与带宽优化
你该如何选推理框架
建议按“需求驱动”选:
要长上下文 + 高并发:优先看 paged KV + continuous batching
要极致低延迟:优先看算子融合与批处理策略
要多模态:看视觉侧是否有高效路径(缓存、token 控制)
推理框架:vLLM(原理与使用)
vLLM 是一个面向 LLM 推理服务的高性能框架,核心卖点通常来自两点:
Paged KV Cache(PagedAttention):用分页/块管理 KV cache,减少碎片并提升并发下的显存利用率
Continuous Batching:在请求持续到达时动态拼 batch,提高 GPU 利用率与吞吐
更完整的原理与使用方式见子章节。
API 封装与部署方案
把模型封装成服务时,建议把“模型能力”和“系统能力”分开设计:
模型能力:生成、工具调用、结构化输出能力
系统能力:权限、审计、缓存、路由、灰度、回滚、监控
最小可用的服务组件
请求协议:输入/输出 schema、上下文窗口限制、超时策略
安全:鉴权、限流、敏感内容策略、拒答与降级
可观测:latency、token/s、cache 命中率、失败率、OOM 监控
成本控制:配额、动态 batching、模型路由(不同大小模型/不同策略)
本章小结
推理系统的核心瓶颈常在 KV cache 与带宽,而不是纯 FLOPs。
量化与 attention/KV 优化是最常见的性价比路线;剪枝与稀疏更依赖系统投入。
部署要把“可控性/审计/监控/回滚”当作一等公民,否则模型越强风险越大。