生产环境中LLM 推理延迟是影响用户体验的核心瓶颈。本文系统梳理从模型层到工程层的推理加速技术给出可落地的优化路径。推理延迟的构成分析优化之前先搞清楚延迟在哪里。LLM 推理的延迟主要由三部分构成TTFTTime To First Token从发送请求到收到第一个 Token 的时间。这主要取决于 Prefill 阶段的计算量与输入 Prompt 长度正相关。TPOTTime Per Output Token每生成一个 Token 的时间。这由 Decode 阶段的计算效率决定与并发请求数、显存带宽密切相关。端到端延迟 TTFT TPOT × 输出 Token 数理解这个公式很重要如果你的场景是短输出摘要、分类TTFT 占比高优化 Prefill 是关键如果场景是长文生成优化 TPOT 才有效果。## 量化最高性价比的加速方案量化是最直接有效的推理加速手段核心思路是用更低精度的数值类型替代 FP16/BF16。### INT8 量化python# 使用 bitsandbytes 进行 INT8 量化加载from transformers import AutoModelForCausalLM, AutoTokenizerimport torchmodel AutoModelForCausalLM.from_pretrained( meta-llama/Llama-3-8B-Instruct, load_in_8bitTrue, # INT8量化 device_mapauto, torch_dtypetorch.float16,)tokenizer AutoTokenizer.from_pretrained(meta-llama/Llama-3-8B-Instruct)INT8 量化可以将显存占用减少约 50%推理速度提升 1.5-2x精度损失通常在 1% 以内。### GPTQ训练后量化GPTQ 是一种更精细的量化方案通过 Hessian 矩阵来最小化量化误差pythonfrom auto_gptq import AutoGPTQForCausalLMmodel AutoGPTQForCausalLM.from_quantized( TheBloke/Llama-2-13B-GPTQ, model_basenamemodel, use_safetensorsTrue, trust_remote_codeFalse, devicecuda:0, use_tritonFalse, quantize_configNone,)GPTQ 4-bit 量化可以将 13B 模型压缩到 7GB 显存在单张 3090 上运行而精度损失通常低于 2%。### AWQActivation-aware Weight QuantizationAWQ 在 GPTQ 的基础上考虑了激活值分布是目前精度-速度最佳的量化方案pythonfrom awq import AutoAWQForCausalLMmodel AutoAWQForCausalLM.from_quantized( TheBloke/Llama-2-7B-AWQ, fuse_layersTrue, trust_remote_codeFalse, safetensorsTrue,)AWQ 4-bit 在大多数 benchmark 上的表现优于 GPTQ同时推理速度更快是 2026 年的主流工业选择。## KV Cache 优化KV Cache 是 LLM 推理中最关键的内存优化技术它缓存注意力层的 Key 和 Value 矩阵避免重复计算。但原始实现存在显存碎片化问题。### PagedAttentionvLLM 核心技术vLLM 引入的 PagedAttention 借鉴操作系统内存分页思想将 KV Cache 分割为固定大小的 Block按需分配显著提升显存利用率pythonfrom vllm import LLM, SamplingParams# vLLM 自动启用 PagedAttentionllm LLM( modelmeta-llama/Llama-3-8B-Instruct, gpu_memory_utilization0.90, # 显存利用率 max_model_len8192, tensor_parallel_size1, # 单卡)sampling_params SamplingParams( temperature0.7, top_p0.95, max_tokens512,)outputs llm.generate( [请解释什么是向量数据库], sampling_params)vLLM 的吞吐量通常是 HuggingFace 原始推理的 3-5 倍是生产部署的首选框架。### Prefix Caching当多个请求共享相同的 System Prompt 时Prefix Caching 可以缓存这部分的 KV 计算python# vLLM 启用 prefix cachingllm LLM( modelmeta-llama/Llama-3-8B-Instruct, enable_prefix_cachingTrue, # 开启前缀缓存)对于有固定 System Prompt 的生产应用Prefix Caching 可以将 TTFT 降低 40-60%。## 推测性解码Speculative Decoding推测性解码是一种巧妙的算法优化核心思想是用一个小模型Draft Model快速生成候选 Token 序列再用大模型Target Model并行验证。python# 使用 medusa 实现推测性解码from medusa.model.medusa_model import MedusaModelmodel MedusaModel.from_pretrained( FasterDecoding/medusa-vicuna-7b-v1.3, medusa_num_heads4, medusa_num_layers1, torch_dtypetorch.float16,)推测性解码在实践中可以加速 1.5-3x特别适合输出内容高度可预测的场景代码补全、翻译等。## 批处理策略优化### 连续批处理Continuous Batching传统静态批处理会等待一批请求全部完成才开始处理下一批导致 GPU 利用率低。连续批处理允许在生成过程中动态插入新请求python# TGIText Generation Inference默认启用连续批处理# 启动命令示例docker run --gpus all \ -p 8080:80 \ -v $PWD/models:/data \ ghcr.io/huggingface/text-generation-inference:latest \ --model-id meta-llama/Llama-3-8B-Instruct \ --max-concurrent-requests 128 \ --max-batch-prefill-tokens 4096### 请求优先级调度生产环境中不同请求有不同优先级付费用户 免费用户交互式 批处理pythonclass PriorityRequestQueue: def __init__(self): import heapq self.queue [] self.counter 0 def push(self, priority: int, request: dict): # 负优先级越小越优先 heapq.heappush(self.queue, (-priority, self.counter, request)) self.counter 1 def pop(self): if self.queue: _, _, request heapq.heappop(self.queue) return request return None## 模型并行多卡推理当单卡显存不足时需要模型并行策略### 张量并行Tensor Parallelismpython# vLLM 多卡张量并行llm LLM( modelmeta-llama/Llama-3-70B-Instruct, tensor_parallel_size4, # 4卡并行 gpu_memory_utilization0.90,)### 流水线并行Pipeline Parallelismpython# 使用 DeepSpeed 进行流水线并行import deepspeedengine deepspeed.init_inference( modelmodel, mp_size2, # 模型并行度 dtypetorch.float16, replace_methodauto, replace_with_kernel_injectTrue,)## 推理框架选型指南| 框架 | 最适场景 | 核心优势 | 注意事项 ||------|---------|---------|---------|| vLLM | 高并发在线服务 | PagedAttention吞吐量最高 | 内存占用较高 || TGI | 企业级部署 | 稳定可靠Hugging Face 生态 | 定制化难度高 || Ollama | 本地开发调试 | 简单易用支持多种格式 | 吞吐量有限 || llama.cpp | CPU/边缘设备 | 支持GGUF纯CPU可运行 | GPU利用率低 || TensorRT-LLM | NVIDIA GPU优化 | 极致性能 | 部署复杂 |## 工程实践中的性能监控优化需要数据驱动建立完整的推理指标监控体系pythonimport timefrom prometheus_client import Histogram, Counter, start_http_server# 定义指标TTFT_HISTOGRAM Histogram( llm_ttft_seconds, Time to first token, buckets[0.1, 0.25, 0.5, 1.0, 2.5, 5.0])THROUGHPUT_COUNTER Counter( llm_tokens_generated_total, Total tokens generated)async def monitored_generate(prompt: str): start time.time() first_token False token_count 0 async for token in stream_generate(prompt): if not first_token: ttft time.time() - start TTFT_HISTOGRAM.observe(ttft) first_token True token_count 1 yield token THROUGHPUT_COUNTER.inc(token_count)# 启动 Prometheus 指标服务start_http_server(9090)## 分级优化策略根据资源投入和收益推荐按以下优先级实施优化第一优先低成本高收益- 开启 Prefix CachingSystem Prompt 固定的场景必开- 量化部署AWQ 4-bit 是首选- 合理设置 max_tokens 上限避免不必要的长输出第二优先中等成本- 迁移到 vLLM 或 TGI 框架- 启用连续批处理- 输出流式返回改善用户感知延迟第三优先高成本- 推测性解码需要额外的 Draft Model 资源- 多卡并行需要多 GPU 资源- TensorRT-LLM 编译优化部署复杂度高## 总结LLM 推理优化是一个系统工程没有单一银弹。实践中的建议是先建立监控再用数据定位瓶颈然后针对性地应用优化技术。量化 vLLM Prefix Caching 这个组合对于大多数在线服务场景可以带来 3-5x 的综合加速效果是 2026 年工程实践的最优起点。推理优化的终极目标不是技术炫耀而是在给定成本约束下为用户提供足够快的响应体验。