技术原理

1. 注意力机制的数学基础 1.1 从信息检索到注意力 注意力机制源于信息检索的直觉：给定查询 Query，在键值对 (Key-Value) 集合中检索相关信息。注意力是软检索——不是返回最匹配的一项，而是对所有项加权求和。 1.2 Scaled Dot-Product Attention 推导 给定 $Q \in \mathbb{R}^{n \times d_k}$, $K \in \mathbb{R}^{m \times d_k}$, $V \in \mathbb{R}^{m \times d_v}$： $$\text{Attention}(Q,K,V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V$$ 逐步分解： 相似度计算：$S = QK^T \in \mathbb{R}^{n \times m}$，每个元素 $S_{ij} = \sum_{l=1}^{d_k} Q_{il} K_{jl}$ 是点积相似度 缩放：$\hat{S}{ij} = S{ij} / \sqrt{d_k}$，控制方差 归一化：$A_{ij} = \frac{e^{\hat{S}{ij}}}{\sum{j’} e^{\hat{S}_{ij’}}}$，每行 softmax 加权聚合：$O = AV \in \mathbb{R}^{n \times d_v}$ 方差分析：假设 $Q, K$ 各分量独立同分布，均值为 0，方差为 1，则 $S_{ij} = \sum_{l=1}^{d_k} Q_{il}K_{jl}$ 的均值为 0，方差为 $d_k$。当 $d_k=64$ 时，$S_{ij}$ 标准差为 8，softmax 输入范围 $[-24, 24]$，梯度几乎为零。除以 $\sqrt{d_k}=8$ 后方差恢复为 1。 ...

推理优化的三个维度 显存优化 ↑ | 计算优化 ←──→ 通信优化 LLM 推理的瓶颈不是计算，而是显存带宽。7B 模型生成 1 个 Token 需要读取全部 7B 参数，但只做 1 次矩阵乘法。 显存分析 7B 模型显存分布 模型权重 (FP16): 14 GB KV Cache (2K ctx): 1 GB KV Cache (8K ctx): 4 GB KV Cache (32K ctx): 16 GB ← 比模型还大！ KV Cache (128K ctx): 64 GB 总显存 (8K ctx): 18 GB → A100 40G 可以跑 总显存 (32K ctx): 30 GB → A100 40G 勉强 总显存 (128K ctx): 78 GB → 需要 A100 80G KV Cache 计算 def kv_cache_size( num_layers: int, # 层数 num_heads: int, # 注意力头数 head_dim: int, # 每头维度 seq_len: int, # 序列长度 batch_size: int, # 批大小 dtype_size: int = 2, # FP16 = 2 bytes ): """计算 KV Cache 显存""" # K 和 V 各一份 return 2 * num_layers * num_heads * head_dim * seq_len * batch_size * dtype_size # Qwen3-7B 示例 size = kv_cache_size( num_layers=32, num_heads=32, head_dim=128, seq_len=8192, batch_size=1, ) print(f"{size / 1024**3:.2f} GB") # 4.00 GB 优化技术一：量化 INT8 量化 # 权重 INT8：14GB → 7GB # KV Cache INT8：显存减半 # 性能损失：1-3% from transformers import AutoModelForCausalLM import torch model = AutoModelForCausalLM.from_pretrained( "Qwen3-7B-Instruct", load_in_8bit=True, # 权重 INT8 device_map="auto", ) INT4 量化 # 权重 INT4：14GB → 3.5GB # 性能损失：3-8% # 适合消费级 GPU model = AutoModelForCausalLM.from_pretrained( "Qwen3-7B-Instruct", load_in_4bit=True, bnb_4bit_compute_dtype=torch.float16, bnb_4bit_quant_type="nf4", ) AWQ 量化 # AWQ：比 INT4 更好的量化方案 # 保护重要权重，精度损失更小 # vLLM 原生支持 # 量化模型 python -m awq.quantize \ --model-path /models/Qwen3-7B \ --output-path /models/Qwen3-7B-AWQ \ --w-bits 4 # vLLM 加载 llm = LLM(model="/models/Qwen3-7B-AWQ", quantization="awq") 优化技术二：KV Cache 优化 PagedAttention（vLLM） # 传统：预分配最大长度的连续显存 # 浪费率：60%（大量预分配空间未使用） # PagedAttention：按需分配，像操作系统的分页机制 # 浪费率：<5% # vLLM 默认启用 llm = LLM( model="...", gpu_memory_utilization=0.9, # 95% 显存用于 KV Cache ) KV Cache 量化 # KV Cache 用 INT8 存储，显存减半 llm = LLM( model="...", kv_cache_dtype="int8", # 或 "fp8" ) KV Cache 共享 # 多个请求共享相同的 system prompt KV Cache # vLLM 的 prefix caching llm = LLM( model="...", enable_prefix_caching=True, ) # 效果： # Request 1: "You are a helpful assistant. [Q1]" → 生成 KV Cache # Request 2: "You are a helpful assistant. [Q2]" → 复用 KV Cache # 节省：system prompt 部分的计算和显存 优化技术三：计算优化 Flash Attention # Flash Attention：减少 GPU 显存读写 # 标准 Attention：O(n²) 显存 # Flash Attention：O(n) 显存，速度提升 2-4x # vLLM 默认启用 llm = LLM( model="...", enforce_eager=False, # 启用 CUDA Graph + Flash Attention ) CUDA Graph # CUDA Graph：预编译计算图，减少 kernel launch 开销 # 适合：固定形状的推理（批处理） llm = LLM( model="...", enforce_eager=False, # 启用 CUDA Graph ) # 延迟降低 10-20% Continuous Batching # 传统批处理：等所有请求完成才处理下一批 # Continuous Batching：每个 step 动态加入/移除请求 # vLLM 默认使用 continuous batching # 效果：吞吐量提升 3-10x # 原理： # Time 0: [A, B, C] 开始生成 # Time 5: A 完成，D 加入 → [B, C, D] # Time 8: B 完成，E 加入 → [C, D, E] # GPU 始终满载 优化技术四：Speculative Decoding # 原理：用小模型猜，大模型验 # 小模型生成 5 个 token → 大模型一次验证 5 个 # 如果全部正确：5x 加速 # 如果 3 个正确：3x 加速 llm = LLM( model="/models/Qwen3-7B-Instruct", speculative_model="/models/Qwen3-0.5B-Instruct", num_speculative_tokens=5, ) # 实测效果： # 简单任务（翻译、摘要）：2.0x 加速 # 复杂任务（推理、创作）：1.3x 加速 # 代码生成：1.8x 加速 优化技术五：模型架构优化 GQA（Grouped Query Attention） # MHA：每个 head 有独立的 K, V → KV Cache 大 # MQA：所有 head 共享 K, V → KV Cache 小，但质量降 # GQA：折中，g 个 head 共享 K, V # Qwen3 使用 GQA，KV Cache 减少为 MHA 的 1/4 # 显存节省 75%，质量损失 <1% 模型蒸馏 # 大模型蒸馏到小模型 # Teacher: Qwen3-72B → Student: Qwen3-7B # 保留 90% 能力，推理快 10x，显存省 10x # 适用场景：固定任务，不需要通用能力 基准测试 测试方法 import time import asyncio async def benchmark(llm, prompts, max_tokens=512): start = time.time() results = await asyncio.gather(*[ llm.generate(p, SamplingParams(max_tokens=max_tokens)) for p in prompts ]) elapsed = time.time() - start total_tokens = sum(len(r.outputs[0].token_ids) for r in results) return { "total_time": elapsed, "total_tokens": total_tokens, "throughput": total_tokens / elapsed, # tokens/s "avg_latency": elapsed / len(prompts), } 参考数据 配置 模型 吞吐量 延迟 A100 80G Qwen3-7B 5000 tok/s 50ms A100 80G Qwen3-72B 800 tok/s 200ms 4090 24G Qwen3-7B (AWQ) 3000 tok/s 80ms 4090 24G Qwen3-7B (FP16) OOM - 2x 4090 Qwen3-72B (AWQ) 400 tok/s 250ms 生产环境配置建议 # 配置决策树 def recommend_config(gpu, model_size, concurrency): if gpu == "A100 80G": if model_size <= 7: return {"tp": 1, "quant": "fp16", "max_seqs": 256} elif model_size <= 72: return {"tp": 1, "quant": "awq", "max_seqs": 64} elif gpu == "4090 24G": if model_size <= 7: return {"tp": 1, "quant": "awq", "max_seqs": 32} elif model_size <= 72: return {"tp": 2, "quant": "awq", "max_seqs": 16} return {"error": "configuration not supported"} 结论 LLM 推理优化的核心原则： ...

工具使用：Agent 的双手 没有工具的 LLM 是一个"只会说话的大脑"——它知道很多，但什么都做不了。工具使用让 Agent 从"问答机器"变成"行动者"。 演进路径 2023: Hard-coded Functions（硬编码函数） 2024: Function Calling（OpenAI 标准化） 2025: Tool Use API（Anthropic 扩展） 2026: MCP + 自主工具发现（工具市场） 第一阶段：Function Calling 基本用法 from openai import OpenAI client = OpenAI() tools = [ { "type": "function", "function": { "name": "get_weather", "description": "获取指定城市的天气", "parameters": { "type": "object", "properties": { "city": { "type": "string", "description": "城市名称，如北京、上海" }, "unit": { "type": "string", "enum": ["celsius", "fahrenheit"], "description": "温度单位" } }, "required": ["city"] } } } ] response = client.chat.completions.create( model="gpt-4o", messages=[{"role": "user", "content": "北京今天多少度？"}], tools=tools, ) # LLM 返回工具调用 tool_call = response.choices[0].message.tool_calls[0] # {"name": "get_weather", "arguments": {"city": "北京", "unit": "celsius"}} # 执行工具 result = get_weather(**json.loads(tool_call.function.arguments)) # 把结果返回给 LLM response = client.chat.completions.create( model="gpt-4o", messages=[ {"role": "user", "content": "北京今天多少度？"}, response.choices[0].message, {"role": "tool", "tool_call_id": tool_call.id, "content": result} ], tools=tools, ) 多工具并行调用 # 现代 LLM 支持一轮调用多个工具 response = client.chat.completions.create( model="gpt-4o", messages=[{"role": "user", "content": "北京和上海今天天气怎么样？"}], tools=tools, ) # 返回两个 tool_calls: get_weather(北京) + get_weather(上海) # 并行执行 results = await asyncio.gather(*[ execute_tool(tc) for tc in response.choices[0].message.tool_calls ]) 第二阶段：工具设计原则 原则一：描述要精确 # ❌ 差：描述模糊 { "name": "search", "description": "搜索内容" } # ✅ 好：描述精确 { "name": "search_web", "description": "在互联网上搜索给定查询，返回前10个结果的标题、URL和摘要。适用于查找最新信息、新闻、技术文档。", "parameters": { "properties": { "query": { "type": "string", "description": "搜索关键词，30字以内，去除无意义词" }, "time_range": { "type": "string", "enum": ["day", "week", "month", "year", "all"], "description": "时间范围过滤" } } } } 原则二：参数要简洁 # ❌ 差：参数太多 { "name": "send_email", "parameters": { "properties": { "to": {}, "cc": {}, "bcc": {}, "subject": {}, "body": {}, "attachments": {}, "priority": {}, "format": {}, "encoding": {}, "reply_to": {}, "sender_name": {} } } } # ✅ 好：只保留必要参数 { "name": "send_email", "parameters": { "properties": { "to": {"type": "string", "description": "收件人邮箱"}, "subject": {"type": "string", "description": "邮件主题"}, "body": {"type": "string", "description": "邮件正文"} }, "required": ["to", "subject", "body"] } } 原则三：错误信息要友好 async def execute_tool(tool_call): try: result = await tool_registry[tool_call.name](**tool_call.args) return {"status": "success", "data": result} except ValidationError as e: return { "status": "error", "error": f"参数错误：{e}", "hint": "请检查参数格式和必填项" } except Exception as e: return { "status": "error", "error": str(e), "hint": "如果重试仍失败，请尝试其他方法" } 第三阶段：MCP（Model Context Protocol） MCP 是 Anthropic 提出的工具标准协议，让工具可以跨模型使用： ...

Agent 的本质是循环 所有 Agent 都在做同一件事：感知 → 推理 → 行动 → 观察结果 → 重复。这个循环怎么设计，决定了 Agent 的能力上限。 第一代：ReAct 循环 ReAct（Reasoning + Acting）是最经典的 Agent 模式： Thought: 用户想了解今天的天气，我需要搜索 Action: search_weather("北京 今天") Observation: 北京今天晴，最高温32°C Thought: 搜索结果已获得，可以回答用户 Answer: 北京今天晴天，最高温度32°C。 核心代码 def react_loop(query, max_iterations=5): messages = [{"role": "user", "content": query}] for i in range(max_iterations): response = llm.invoke(messages + [ {"role": "system", "content": REACT_PROMPT} ]) if "Final Answer:" in response: return parse_answer(response) action = parse_action(response) observation = execute_tool(action) messages.append({"role": "assistant", "content": response}) messages.append({"role": "user", "content": f"Observation: {observation}"}) return "达到最大迭代次数" ReAct 的问题 短视决策：每一步只考虑当前最优，缺乏全局规划 Token 浪费：每轮都把完整历史发给 LLM 容易跑偏：一旦某步出错，后续步骤连锁偏移 无法并行：严格串行，效率低 第二代：Plan-and-Execute Plan-and-Execute 将循环拆为两个阶段： 阶段一：规划 def plan(query): prompt = f"""将以下任务分解为具体步骤： 任务：{query} 输出JSON格式的步骤列表。""" plan = llm.invoke(prompt) return json.loads(plan) # 输出示例 { "steps": [ {"id": 1, "action": "search", "params": {"query": "2026年AI Agent市场规模"}}, {"id": 2, "action": "search", "params": {"query": "主要Agent框架市场份额"}}, {"id": 3, "action": "analyze", "params": {"source": "step1+step2"}}, {"id": 4, "action": "write_report", "params": {"source": "step3"}} ] } 阶段二：执行 def execute_plan(steps): results = {} for step in steps: result = execute_step(step, results) results[step["id"]] = result # 动态重规划 if step.get("replan"): new_steps = replan(query, results) steps = merge_plan(steps, new_steps) return results 优势对比 维度 ReAct Plan-and-Execute 全局视野 无 有 可并行 ❌ ✅（无依赖步骤） 错误恢复 依赖LLM自行纠正 可重新规划 Token 效率 低（重复发送历史） 高（只发当前步骤） 复杂任务 容易失败 表现稳定 第三代：自适应循环 2026 年最新的研究趋向于动态选择策略： ...

ReAct（Reasoning + Acting）是 Agent 最经典的推理范式。本文从原理拆解到代码实现，深入分析 ReAct 的优势、局限和进化方向。

LLM 本身只能生成文本。工具调用赋予了 AI 操作真实世界的能力。本文梳理从 Function Calling 到 MCP 的完整技术演进。

2026 年的多模态 Agent 不再是「文本+图片」的简单组合，而是文本、图像、音频、视频、代码的统一理解与生成。

Model Context Protocol 正在统一 AI 工具调用的接口标准。本文深入解析 MCP 的设计理念、协议细节和生态现状。