性能优化

LLM缓存的价值 LLM推理是昂贵的——每次调用消耗GPU算力和API费用。但很多请求是重复或高度相似的。缓存可以让"已经算过的不再重算"，是投入产出比最高的优化手段。 三层缓存架构 请求 → L1: 精确缓存 → L2: 语义缓存 → L3: 前缀缓存 → LLM L1：精确缓存 import redis.asyncio as redis class ExactCache: """精确匹配缓存：相同输入返回相同输出""" def __init__(self, redis_url="redis://localhost:6379"): self.redis = redis.from_url(redis_url) def cache_key(self, model, messages, temperature, max_tokens): """生成缓存键""" content = json.dumps({ "model": model, "messages": messages, "temperature": temperature, "max_tokens": max_tokens, }, sort_keys=True, ensure_ascii=False) return hashlib.sha256(content.encode()).hexdigest() async def get(self, model, messages, **params): key = self.cache_key(model, messages, params.get("temperature", 0.7), params.get("max_tokens", 2048)) cached = await self.redis.get(key) return json.loads(cached) if cached else None async def set(self, model, messages, response, ttl=3600, **params): key = self.cache_key(model, messages, params.get("temperature", 0.7), params.get("max_tokens", 2048)) await self.redis.setex(key, ttl, json.dumps(response, ensure_ascii=False)) 适用场景 temperature=0的确定性输出 常见问题FAQ 系统提示词相同的请求 L2：语义缓存 class SemanticCache: """语义缓存：相似查询命中缓存""" def __init__(self, vector_store, embed_model, threshold=0.95): self.store = vector_store self.embed_model = embed_model self.threshold = threshold async def get(self, query, model="default", **params): # 向量化查询 query_embedding = await self.embed_model.embed(query) # 搜索相似缓存 results = await self.store.search( query_embedding, filter={"model": model}, top_k=1 ) if results and results[0]["score"] >= self.threshold: cached = json.loads(results[0]["document"]) # 检查参数兼容性 if self.params_compatible(cached["params"], params): return cached["response"] return None async def set(self, query, response, model="default", ttl=3600, **params): embedding = await self.embed_model.embed(query) await self.store.add( id=str(uuid.uuid4()), embedding=embedding, document=json.dumps({ "query": query, "response": response, "model": model, "params": params, "timestamp": time.time(), }, ensure_ascii=False), ttl=ttl ) def params_compatible(self, cached_params, request_params): """检查缓存参数是否兼容当前请求""" # temperature差异较大则不兼容 if abs(cached_params.get("temperature", 0.7) - request_params.get("temperature", 0.7)) > 0.1: return False return True 语义缓存的阈值选择 阈值 命中率 准确率 适用场景 0.99 低 极高 严格场景（医疗、法律） 0.95 中 高 通用场景 0.90 高 中 FAQ类场景 0.85 很高 低 不推荐（风险大） L3：前缀缓存（KV Cache共享） class PrefixCacheManager: """前缀缓存：共享相同前缀的KV Cache""" def __init__(self): self.prefix_cache = {} # prefix_hash -> kv_cache def compute_prefix_hash(self, messages): """计算消息前缀的哈希""" # 系统提示 + 历史对话通常构成共享前缀 prefix_text = json.dumps(messages[:-1]) # 除最后一条消息 return hashlib.sha256(prefix_text.encode()).hexdigest() async def get_kv_cache(self, messages): """获取前缀的KV Cache""" prefix_hash = self.compute_prefix_hash(messages) return self.prefix_cache.get(prefix_hash) async def store_kv_cache(self, messages, kv_cache): """存储前缀的KV Cache""" prefix_hash = self.compute_prefix_hash(messages) self.prefix_cache[prefix_hash] = kv_cache vLLM内置前缀缓存支持： ...

引言 Agent的很多操作是独立的——搜索三个不同的关键词、查询多个数据源、分析多个文件。如果串行执行，总时间是所有操作时间的总和；如果并发执行，总时间接近最慢操作的时间。 并发执行是Agent性能优化的重要手段。但并发带来了复杂性：资源竞争、状态同步、错误处理、死锁风险。2026年的Agent并发架构需要在性能和复杂性之间找到最佳平衡。 一、Agent并发场景 1.1 工具调用并发 一个请求需要调用多个独立工具时，可以并发执行： 串行: search_web(3s) → query_db(2s) → call_api(1s) = 6s 并发: search_web(3s) ─┐ query_db(2s) ─┼─ 并行 = 3s call_api(1s) ─┘ 1.2 多Agent并发 多个Agent同时处理不同子任务： 用户: "调研三家公司的市场表现" Agent A: 调研公司甲 ─┐ Agent B: 调研公司乙 ─┼─ 并行 Agent C: 调研公司丙 ─┘ 1.3 批量处理并发 对一批数据并行处理： 100个文档需要摘要 → 分成10批，每批10个文档 → 10个Worker并行处理 → 总时间 ≈ 单个文档的10倍（而非100倍） 1.4 竞争执行 同一任务由多个Agent竞争执行，取最优结果： Agent A → 方案A ─┐ Agent B → 方案B ─┼→ 评估器选择最优 Agent C → 方案C ─┘ 二、并发模型 2.1 异步IO模型 Agent的绝大多数操作是IO密集型（LLM API调用、工具调用），适合异步IO模型： ...

引言 LLM推理是昂贵的——每次调用消耗Token、产生延迟、花费金钱。在Agent系统中，大量请求其实是重复的或高度相似的。缓存是解决这个问题的最有效手段。 一个设计良好的缓存架构可以将LLM调用减少60-80%，将响应延迟降低一个数量级，将运行成本压缩到原来的几分之一。2026年，缓存已经成为Agent系统的标配组件。 一、Agent缓存的多层模型 1.1 L1：响应缓存 缓存完整请求-响应对。当完全相同的请求再次出现时，直接返回缓存结果。 Request: "总结这篇文章" + article_content (hash: a1b2c3) Cache Hit → Return cached summary Cache Miss → Call LLM → Cache result → Return 适用场景：用户重复提问、模板化任务。 注意事项：必须对请求进行标准化处理——“总结这篇"和"帮我总结这篇"应该命中同一缓存。使用请求的语义哈希而非原始字符串作为缓存键。 1.2 L2：前缀缓存 LLM推理中，请求的前缀部分如果与之前请求相同，可以复用已计算的KV Cache。这在多轮对话中特别有效。 对话第1轮: [System Prompt + User Msg 1] → 生成回复1 对话第2轮: [System Prompt + User Msg 1 + Reply 1 + User Msg 2] ↑ 前缀相同，可复用KV Cache 2026年主流推理框架（vLLM、SGLang）都已支持前缀缓存，命中率通常在70%以上。 1.3 L3：语义缓存 即使请求不完全相同，只要语义相似就命中缓存。通过embedding计算请求的向量表示，与缓存中的请求向量比较相似度。 def semantic_cache_lookup(query, cache, threshold=0.95): query_embedding = embed(query) for cached_query, cached_response, cached_embedding in cache: similarity = cosine_similarity(query_embedding, cached_embedding) if similarity > threshold: return cached_response return None 适用场景：用户用不同措辞问同一个问题。 ...

前言：RAG从Demo到生产的鸿沟 写一个RAG Demo只需要30分钟——加载文档、Embedding、存向量库、检索、生成，完成。但把它放到生产环境，你会发现： 幻觉：LLM明明拿到了正确文档，还是编造了不存在的信息 漏检：库里明明有相关文档，检索就是找不到 延迟：用户等了8秒还没返回，体验崩溃 这三个问题构成了RAG生产环境的"不可能三角"。本文分享2026年我们在生产环境中踩过的坑和解决方案。 难题一：幻觉问题 幻觉的三种形态 类型 表现 根因 忠实性幻觉 答案与检索文档矛盾 LLM忽略上下文，依赖自身参数知识 编造型幻觉 答案包含文档中不存在的信息 LLM"脑补"细节 来源混淆 将多个文档的信息错误组合 多文档检索时上下文混淆 解决方案矩阵 方案1：强约束Prompt # ❌ 容易幻觉的Prompt prompt = f"""基于以下资料回答问题： {context} 问题：{question} """ # ✅ 抗幻觉的Prompt prompt = f"""你是一个严格的信息提取助手。请遵循以下规则： 1. **只使用**以下参考资料回答问题 2. 如果参考资料中没有相关信息，直接回答"根据现有资料无法回答此问题" 3. 不要添加任何参考资料中未提及的信息 4. 不要进行推理、猜测或补全 5. 回答中需要引用具体的资料来源 参考资料： --- {context} --- 问题：{question} 回答格式： [来源：文档名] 回答内容... """ 方案2：置信度校准 def answer_with_confidence(question, retrieved_docs): """带置信度的回答""" # 第一步：评估检索质量 relevance_prompt = f"""评估以下文档与问题的相关性(0-10): 问题: {question} 文档: {retrieved_docs[0].page_content[:500]} 只返回数字。""" relevance_score = int(llm.invoke(relevance_prompt).strip()) if relevance_score < 4: return { "answer": "抱歉，知识库中没有找到与您问题相关的信息。", "confidence": 0.2, "should_answer": False, } # 第二步：生成回答并自我验证 answer = rag_chain.invoke(question) # 第三步：验证回答是否忠于上下文 verify_prompt = f"""判断以下回答的每个陈述是否能在参考资料中找到支撑。 参考资料: {retrieved_docs} 回答: {answer} 返回JSON: {{"faithful": true/false, "unsupported_claims": [...]}}""" verification = json.loads(llm.invoke(verify_prompt)) return { "answer": answer if verification["faithful"] else "无法确认回答准确性", "confidence": relevance_score / 10.0, "should_answer": verification["faithful"], } 方案3：Citation机制 def generate_with_citations(question, retrieved_docs): """强制引用来源的生成""" # 给每个文档编号 numbered_context = "\n\n".join([ f"[{i+1}] {doc.page_content}" for i, doc in enumerate(retrieved_docs) ]) prompt = f"""基于以下编号的参考资料回答问题。每个陈述后必须标注来源编号[1]。 参考资料： {numbered_context} 问题：{question} 要求： - 每个事实陈述后标注来源编号，如"GraphRAG由微软提出[1]" - 如果某个陈述来自多个文档，标注所有来源，如"[1][3]" - 无法找到来源的陈述不要写出 回答：""" return llm.invoke(prompt) 幻觉抑制效果实测 方案 幻觉率↓ 答案完整度↓ 延迟增加 强约束Prompt 45% 15% +0s 置信度校准 68% 8% +1.5s Citation机制 72% 5% +0.8s 三者结合 85% 22% +2.3s 建议组合：强约束Prompt + Citation机制，性价比最高。 ...

TGI 2026：HuggingFace 的推理引擎 Text Generation Inference（TGI）是 HuggingFace 推出的大模型推理服务框架。与 vLLM 并列为开源推理引擎双雄。2026 年，TGI 在企业级特性方面持续强化，成为 HuggingFace 生态（Hub + Inference Endpoints + TGI）的核心组件。 2026 架构概览 ┌──────────────────────────────────────────────────┐ │ Client Layer │ │ REST API │ gRPC │ WebSocket │ Python/JS SDK │ ├──────────────────────────────────────────────────┤ │ Router Layer │ │ ┌────────────┐ ┌──────────┐ ┌────────────────┐ │ │ │ Load │ │ Queue │ │ Response │ │ │ │ Balancer │ │ Manager │ │ Aggregator │ │ │ └────────────┘ └──────────┘ └────────────────┘ │ ├──────────────────────────────────────────────────┤ │ Inference Layer │ │ ┌────────────┐ ┌──────────┐ ┌────────────────┐ │ │ │ Continuous │ │ Flash │ │ Speculative │ │ │ │ Batching │ │ Attention│ │ Decoding │ │ │ └────────────┘ └──────────┘ └────────────────┘ │ │ ┌────────────┐ ┌──────────┐ ┌────────────────┐ │ │ │ Tensor │ │ Pipeline │ │ Quantization │ │ │ │ Parallel │ │ Parallel │ │ (AWQ/GPTQ/FP8) │ │ │ └────────────┘ └──────────┘ └────────────────┘ │ ├──────────────────────────────────────────────────┤ │ Model Layer │ │ Safetensors │ GGUF │ Tokenizer │ Config │ └──────────────────────────────────────────────────┘ TGI vs vLLM 定位差异 维度 TGI vLLM 核心优势 HF 生态集成 极致吞吐量 部署方式 Docker 优先 灵活部署 模型格式 Safetensors 优先 GGUF/多种 企业特性 完善 基础 社区 HF 社区 独立社区 推理速度 快 最快 模型支持 跟随 HF 跟随社区 部署指南 Docker 部署 # 基础部署 docker run --gpus all -p 8080:80 \ -v /data/models:/models \ ghcr.io/huggingface/text-generation-inference:3.0 \ --model Qwen/Qwen2.5-32B-Instruct \ --quantization awq \ --max-total-tokens 32768 \ --max-batch-size 256 \ --max-concurrent-requests 512 高级配置 # 完整生产配置 docker run --gpus all -p 8080:80 \ -v /data/models:/models \ -v /data/cache:/data \ -e HUGGING_FACE_HUB_TOKEN=$HF_TOKEN \ ghcr.io/huggingface/text-generation-inference:3.0 \ --model Qwen/Qwen2.5-72B-Instruct \ --model-auto-config \ --revision main \ --quantization awq \ --dtype float16 \ --max-total-tokens 65536 \ --max-batch-size 128 \ --max-concurrent-requests 256 \ --max-batch-prefill-tokens 8192 \ --max-waiting-tokens 20 \ --max-waiting-batches 4 \ --waiting-served-ratio 1.2 \ --cuda-memory-fraction 0.90 \ --tensor-parallel-size 2 \ --num-shard 2 \ --sharded true \ --enable-flash-attention \ --enable-prefix-caching \ --enable-chunked-prefill \ --disable-custom-kernels false \ --json-output \ --google-service-account /data/gcp.json Python SDK 使用 from text_generation import Client, AsyncClient # 同步客户端 client = Client("http://localhost:8080") # 简单生成 response = client.generate( prompt="解释量子纠缠", max_new_tokens=512, temperature=0.7, top_p=0.9, repetition_penalty=1.1, stop=["<|im_end|>"], ) print(response.generated_text) # 流式生成 for token in client.generate_stream( prompt="写一首诗", max_new_tokens=200, ): print(token.token.text, end="", flush=True) # 批量生成 responses = client.generate_batch( prompts=["你好", "Hello", "Bonjour"], max_new_tokens=50 ) # 异步客户端 async_client = AsyncClient("http://localhost:8080") response = await async_client.generate("Hello", max_new_tokens=100) OpenAI 兼容 API from openai import OpenAI # TGI 兼容 OpenAI API client = OpenAI( base_url="http://localhost:8080/v1", api_key="tgi" ) response = client.chat.completions.create( model="Qwen/Qwen2.5-32B-Instruct", messages=[ {"role": "system", "content": "你是助手"}, {"role": "user", "content": "Hello"} ], stream=True, tools=[{ "type": "function", "function": { "name": "get_time", "parameters": {"type": "object", "properties": {}} } }] ) 核心优化 1. 连续批处理 TGI 的连续批处理（Continuous Batching）是其高吞吐量的核心： ...

vLLM 2026：推理引擎的事实标准 vLLM 在 2026 年已经成为大模型推理部署的事实标准。根据社区统计，全球超过 70% 的开源大模型生产部署使用 vLLM 作为推理引擎。它的核心优势在于 PagedAttention 技术带来的高吞吐量和低延迟，以及对各类开源模型的广泛支持。 2026 核心特性 版本演进 特性 vLLM 0.3 (2024) vLLM 0.8 (2026) PagedAttention v1 v3（内存效率+40%） 连续批处理 支持 支持 + 动态批大小 张量并行 支持 支持 + 专家并行 量化 AWQ/GPTQ AWQ/GPTQ/FP8/INT4 多模态 实验性 原生支持 Speculative Decoding 不支持 支持 长上下文 32k 1M+ 分离式推理 不支持 Prefill/Decode 分离 安装与环境准备 基础安装 # 创建虚拟环境 python -m venv vllm-env source vllm-env/bin/activate # Linux # vllm-env\Scripts\activate # Windows # 安装 vLLM（CUDA 12.1+） pip install vllm==0.8.5 # 验证安装 python -c "import vllm; print(vllm.__version__)" GPU 环境检查 # 检查 CUDA 版本 nvidia-smi # 需要 CUDA 12.1+，驱动 535+ # 检查 GPU 内存 nvidia-smi --query-gpu=name,memory.total,memory.free --format=csv 模型内存需求参考 模型 参数量 FP16 显存 INT8 显存 INT4 显存 推荐 GPU Qwen2.5-7B 7B 14 GB 8 GB 5 GB RTX 4090 Llama-4-8B 8B 16 GB 9 GB 5 GB RTX 4090 Qwen2.5-32B 32B 64 GB 34 GB 20 GB A100 80GB Llama-4-70B 70B 140 GB 75 GB 42 GB 2×A100 80GB Qwen3-72B 72B 145 GB 78 GB 44 GB 2×A100 80GB DeepSeek-V3 671B (MoE) 1.3 TB 700 GB 400 GB 8×H100 80GB 基础部署 单 GPU 部署 from vllm import LLM, SamplingParams # 加载模型 llm = LLM( model="Qwen/Qwen2.5-32B-Instruct", quantization="awq", # 使用 AWQ 量化 max_model_len=32768, # 最大上下文长度 gpu_memory_utilization=0.90, # GPU 内存利用率 tensor_parallel_size=1, # 张量并行度 dtype="float16", # 数据类型 trust_remote_code=True, enforce_eager=False, # 使用 CUDA Graph 优化 swap_space=4, # CPU 交换空间 (GB) max_num_seqs=256, # 最大并发序列数 ) # 配置采样参数 sampling_params = SamplingParams( temperature=0.7, top_p=0.9, top_k=50, max_tokens=2048, repetition_penalty=1.05, ) # 批量推理 prompts = [ "解释量子计算的基本原理", "写一首关于春天的诗", "用 Python 实现快速排序算法", ] outputs = llm.generate(prompts, sampling_params) for output in outputs: print(output.outputs[0].text) 多 GPU 张量并行 # 2×A100 80GB 部署 70B 模型 llm = LLM( model="meta-llama/Llama-4-70B-Instruct", tensor_parallel_size=2, # 2 路张量并行 pipeline_parallel_size=1, # 流水线并行 gpu_memory_utilization=0.92, max_model_len=65536, dtype="float16", enable_prefix_caching=True, # 前缀缓存 enable_chunked_prefill=True, # 分块预填充 ) OpenAI 兼容 API 服务 # 启动 API 服务器 python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-32B-Instruct \ --quantization awq \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.90 \ --max-model-len 32768 \ --port 8000 \ --host 0.0.0.0 \ --api-key sk-your-api-key \ --served-model-name qwen-32b \ --enable-prefix-caching \ --enable-chunked-prefill \ --max-num-seqs 256 \ --uvicorn-log-level info # 客户端调用（兼容 OpenAI SDK） from openai import OpenAI client = OpenAI( api_key="sk-your-api-key", base_url="http://localhost:8000/v1" ) response = client.chat.completions.create( model="qwen-32b", messages=[ {"role": "system", "content": "你是专业翻译"}, {"role": "user", "content": "Translate: Hello World"} ], temperature=0.3, max_tokens=100, stream=True # 支持流式输出 ) for chunk in response: if chunk.choices[0].delta.content: print(chunk.choices[0].delta.content, end="") 性能优化 1. 量化策略 # FP8 量化（H100 专用，吞吐量最高） llm = LLM( model="Qwen/Qwen2.5-72B-Instruct", quantization="fp8", dtype="bfloat16", gpu_memory_utilization=0.92, ) # INT4 AWQ 量化（最省显存） llm = LLM( model="Qwen/Qwen2.5-72B-Instruct", quantization="awq", quantization_config={ "bits": 4, "group_size": 128, "zero_point": True, }, ) # GPTQ 量化 llm = LLM( model="TheBloke/Llama-4-70B-GPTQ", quantization="gptq", dtype="float16", ) 2. Speculative Decoding（投机解码） # 使用小模型加速大模型推理 llm = LLM( model="Qwen/Qwen2.5-72B-Instruct", speculative_model="Qwen/Qwen2.5-1.5B-Instruct", # 草稿模型 num_speculative_tokens=5, # 每次投机 5 个 token speculative_draft_tensor_parallel_size=1, gpu_memory_utilization=0.92, ) # 效果：吞吐量提升 2-3x，延迟降低 40-60% # 代价：草稿模型需要共享词表 3. 分离式推理（Prefill-Decode 分离） # 2026 新特性：将 Prefill 和 Decode 分离到不同 GPU # 适合高并发场景 # Prefill 节点（计算密集） python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-72B-Instruct \ --disaggregation-mode prefill \ --disaggregation-port 5001 \ --port 8000 # Decode 节点（内存密集） python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-72B-Instruct \ --disaggregation-mode decode \ --disaggregation-port 5001 \ --port 8001 # 路由层（自动分发请求） python -m vllm.entrypoints.disagg_router \ --prefill-endpoint http://gpu1:8000 \ --decode-endpoint http://gpu2:8001 \ --port 8080 4. 长上下文优化 # 1M 上下文部署 llm = LLM( model="Qwen/Qwen2.5-32B-Instruct-1M", max_model_len=1048576, # 1M tokens gpu_memory_utilization=0.95, # 长上下文优化 enable_chunked_prefill=True, # 分块预填充 max_num_batched_tokens=8192, # 每批最大 token 数 max_num_seqs=32, # 降低并发数以容纳长序列 # KV Cache 优化 block_size=16, # PagedAttention 块大小 swap_space=16, # CPU 交换空间 # 滑动窗口注意力（适用于超长上下文） sliding_window=131072, # 128K 滑动窗口 ) 生产部署架构 Kubernetes 部署 apiVersion: apps/v1 kind: Deployment metadata: name: vllm-qwen-32b spec: replicas: 2 selector: matchLabels: app: vllm-qwen-32b template: metadata: labels: app: vllm-qwen-32b spec: containers: - name: vllm image: vllm/vllm-openai:v0.8.5 args: - --model=Qwen/Qwen2.5-32B-Instruct - --quantization=awq - --tensor-parallel-size=2 - --gpu-memory-utilization=0.90 - --max-model-len=32768 - --port=8000 resources: limits: nvidia.com/gpu: 2 memory: 128Gi requests: nvidia.com/gpu: 2 memory: 64Gi ports: - containerPort: 8000 readinessProbe: httpGet: path: /health port: 8000 initialDelaySeconds: 120 periodSeconds: 10 livenessProbe: httpGet: path: /health port: 8000 initialDelaySeconds: 300 periodSeconds: 30 --- apiVersion: v1 kind: Service metadata: name: vllm-service spec: selector: app: vllm-qwen-32b ports: - port: 8000 targetPort: 8000 type: LoadBalancer 负载均衡配置 # Nginx 负载均衡 upstream vllm_backend { least_conn; # 最少连接策略 server gpu-node-1:8000 weight=1 max_fails=3 fail_timeout=30s; server gpu-node-2:8000 weight=1 max_fails=3 fail_timeout=30s; server gpu-node-3:8000 weight=1 max_fails=3 fail_timeout=30s; keepalive 32; keepalive_timeout 60s; } server { listen 80; location /v1/ { proxy_pass http://vllm_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; # 流式响应支持 proxy_buffering off; proxy_cache off; chunked_transfer_encoding on; # 超时设置 proxy_connect_timeout 10s; proxy_read_timeout 300s; proxy_send_timeout 60s; } location /health { proxy_pass http://vllm_backend/health; } } 性能基准 吞吐量对比（Qwen2.5-32B AWQ，2×A100 80GB） 配置 吞吐量 (tok/s) P50 延迟 P99 延迟 并发数 基础配置 2,800 0.8s 3.2s 64 + 前缀缓存 3,500 0.6s 2.5s 64 + 分块预填充 4,200 0.5s 2.1s 128 + Speculative 6,800 0.3s 1.2s 128 + FP8 (H100) 8,500 0.25s 0.9s 256 与其他推理引擎对比 引擎 吞吐量 延迟 显存效率 易用性 vLLM 0.8 4,200 tok/s 0.5s 92% ⭐⭐⭐⭐⭐ TGI 3.0 3,100 tok/s 0.7s 85% ⭐⭐⭐⭐ SGLang 0.3 4,800 tok/s 0.4s 90% ⭐⭐⭐⭐ TensorRT-LLM 5,200 tok/s 0.3s 95% ⭐⭐⭐ Ollama 1,800 tok/s 1.2s 70% ⭐⭐⭐⭐⭐ 监控与运维 Prometheus 指标 # vLLM 内置 Prometheus 指标 # 访问 http://localhost:8000/metrics # 关键指标： # vllm:num_requests_running - 正在运行的请求数 # vllm:num_requests_waiting - 等待队列长度 # vllm:gpu_cache_usage_perc - GPU 缓存使用率 # vllm:time_to_first_token - TTFT（首 Token 延迟） # vllm:time_per_output_token - TPOT（每 Token 延迟） # vllm:e2e_request_latency - 端到端延迟 # Prometheus 采集配置 scrape_configs: - job_name: 'vllm' static_configs: - targets: ['gpu-node-1:8000', 'gpu-node-2:8000'] metrics_path: /metrics scrape_interval: 10s 常见问题排查 问题 原因 解决方案 OOM 显存不足 降低 gpu_memory_utilization 或使用量化 首Token延迟高 Prefill 慢 启用 chunked_prefill 吞吐量低 批处理不足 增加 max_num_seqs 请求排队 并发过高 增加副本数或降低 max_model_len 模型加载慢 磁盘 I/O 使用本地 SSD 缓存模型 总结 vLLM 在 2026 年仍然是开源 LLM 推理部署的最佳选择。它的 PagedAttention v3、Speculative Decoding、分离式推理等特性让它在性能上保持领先，同时 OpenAI 兼容 API 降低了使用门槛。 ...

推理性能是大模型从实验室走向生产环境的关键瓶颈。随着Agent应用对实时性和成本的要求日益提高，推理加速技术在2026年成为行业关注的核心方向。本文系统梳理大模型推理加速的技术栈，从算法优化到系统工程，提供全面的技术指南。 KV Cache：推理加速的基石 KV Cache是大模型自回归推理的基础优化。在生成第t个token时，前t-1个token的Key和Value矩阵可以复用，无需重复计算。这一优化将推理复杂度从O(t²d)降至O(td)。 KV Cache的内存挑战 KV Cache的主要挑战是内存占用。以Llama 70B为例，FP16精度下每个token的KV Cache约160KB，128K上下文需要约20GB内存——超过了模型权重本身。这一挑战催生了多种KV Cache优化技术。 PagedAttention vLLM框架提出的PagedAttention借鉴了操作系统的虚拟内存管理。KV Cache被分成固定大小的block，通过block table映射到物理位置。这种设计解决了KV Cache碎片化问题，将显存利用率从约60%提升至95%以上。 PagedAttention还支持"copy-on-write"机制，使得同一prompt的多个生成共享大部分KV Cache，大幅降低了批量推理的内存开销。 KV Cache量化 将KV Cache从FP16量化至INT8可以将内存占用减半，而对生成质量的影响极小。2026年的最新进展是KV Cache的INT4量化，通过分组量化和敏感度自适应技术，在4倍压缩比下保持了近乎无损的质量。 KV Cache Eviction 对于超长上下文场景，主动驱逐不重要的KV Cache条目是一种有效策略。基于注意力分数的LRU算法——保留高频被访问的KV条目、驱逐低频条目——可以将有效上下文长度扩展数倍而内存不变。 模型量化：降低精度换取速度 模型量化是推理加速最直接有效的手段之一。 权重量化 将模型权重从FP16量化至INT8或INT4可以成倍减少内存占用和访存带宽需求。2026年主流的权重量化方法包括： GPTQ：基于二阶信息的逐层量化，INT4量化后性能损失<1% AWQ：激活感知权重量化，对重要权重保持高精度 SmoothQuant：通过平滑激活值分布使权重和激活都易于量化 混合精度量化 并非所有层对量化的敏感度相同。混合精度量化策略对敏感层保持FP16、对非敏感层使用INT4/INT8，在整体压缩比和模型质量之间取得最优平衡。2026年的自适应混合精度方法可以自动确定每层的最优精度配置。 投机解码：用小模型加速大模型 投机解码（Speculative Decoding）是2026年最受关注的推理加速技术之一。其核心思想是：用一个小的草稿模型快速生成多个候选token，再用大模型并行验证这些token，接受正确的、拒绝错误的。 基本流程 草稿模型自回归生成k个token（快速但可能不准确） 大模型对这k个token进行单次前向传播验证（并行计算） 接受与草稿模型一致的token，在第一个不一致的位置重新生成 加速效果 投机解码的加速比取决于草稿模型的接受率。当接受率达到80%时，推理速度可提升约2.5倍。2026年的改进方向包括： 草稿模型蒸馏：从大模型蒸馏专用草稿模型，提高接受率 自适应草稿长度：根据接受率动态调整k值 多级投机：使用多个不同规模的草稿模型级联 推测式注意力 投机解码的变体——推测式注意力（Speculative Attention）——将投机思想扩展到注意力计算。使用稀疏注意力快速生成近似结果，再用全注意力精炼。这种方法在长上下文场景中将注意力计算加速3-5倍。 连续批处理：动态调度提升吞吐 传统批处理要求同一批的请求同时开始、同时结束，导致GPU利用率低下。连续批处理（Continuous Batching）打破了这一限制——新请求可以在任何时刻加入批处理，已完成的请求可以随时退出。 连续批处理的核心是"迭代级调度"——在每个生成步骤后重新评估批处理组合。这种动态调度使GPU利用率从传统批处理的约40%提升至80%以上，在不增加延迟的情况下将吞吐量提升2-3倍。 2026年的连续批处理技术进一步演进，引入了"优先级调度"——高优先级请求可以抢占低优先级请求的计算资源，满足不同SLA级别的需求。 算子融合与内核优化 算子融合 将多个独立的计算操作融合为单个操作可以减少内存访问和内核启动开销。Flash Attention是算子融合的经典案例——将QK^T计算、Softmax和加权求和融合为单个内核。2026年的融合范围进一步扩大，包括： RMSNorm与注意力计算的融合 门控线性单元与激活函数的融合 多层感知机的全部计算融合 自定义内核 针对特定硬件编写的高度优化内核可以充分发挥硬件性能。2026年，Triton和CUDA内核库的成熟使得开发者无需深入理解GPU架构也能编写高性能内核。多家公司推出了专门优化的大模型推理内核库，在特定硬件上实现了接近理论峰值的性能。 分布式推理 对于超大模型（>100B参数），单卡推理不可行，需要分布式推理策略。 张量并行 将模型权重沿特征维度切分到多个GPU上，每个GPU计算一部分，通过All-Reduce通信汇总结果。张量并行的通信开销较大，通常只在同一节点内使用。 ...