大模型推理成本优化:从理论到实践

推理成本:AI落地的最大障碍 一个简单的事实:运行一个70B参数的模型,单张A100 GPU的每小时成本约2-3美元(云服务),每秒处理约50个Token。如果日均100万次请求、每次平均500 Token,一天的GPU成本就超过500美元。 随着用户规模增长,推理成本会线性甚至超线性增长。不做好成本优化,AI项目的商业模式根本不成立。 五层优化框架 我们将推理成本优化分为五个层次,从收益最大到收益递减: 第一层:模型选择优化 选择最小的够用模型。 这听起来简单,但实践中很多团队默认使用最大的模型"以防万一"。 我们的建议是建立模型路由系统: 简单FAQ → 7B模型 一般对话 → 32B模型 复杂推理 → 70B+模型 通过一个轻量级分类器判断请求复杂度,自动路由到合适的模型。在我们的实践中,模型路由可以降低60%以上的推理成本,而用户体验几乎不受影响。 开源vs闭源混合策略。 对于流量大的简单任务用开源模型自建部署,对于低频复杂任务调用闭源API。两者结合可以在成本和质量间取得最优平衡。 第二层:模型压缩优化 量化:INT4量化可以将模型大小和推理成本降低4倍,质量损失控制在2-3%以内(详见我们之前的量化对比文章)。 蒸馏:用大模型蒸馏出一个小模型用于线上推理。对于垂直领域,蒸馏模型可以达到接近大模型的效果但成本只有1/10。 稀疏化:通过剪枝去除不重要的权重。MoE架构本质上就是一种结构化的稀疏化——每次推理只激活部分专家网络。 第三层:推理引擎优化 KV Cache优化:KV Cache是自回归生成的最大显存消耗者。优化手段包括: PagedAttention(vLLM):将KV Cache分页管理,减少碎片浪费 KV Cache量化:将KV Cache从FP16压缩到INT8,显存减半 KV Cache共享:相同Prefix的请求共享KV Cache 批处理:将多个请求合并处理可以提高GPU利用率。vLLM的Continuous Batching技术可以在不增加延迟的情况下将吞吐量提升3-5倍。 投机解码(Speculative Decoding):用一个小模型先生成候选Token,大模型并行验证。如果小模型的猜测正确率高,生成速度可以提升2-3倍。 第四层:系统架构优化 缓存层:对相同或相似查询的结果进行缓存。我们采用语义缓存——不只是精确匹配,而是通过嵌入相似度判断是否可以用缓存结果。语义缓存可以命中15-30%的请求。 请求合并:当多个用户问类似的问题时,合并为一个请求,结果分发。这在客服场景特别有效。 异步处理:非实时任务(如批量文档处理)放入队列,在低峰期处理。削峰填谷可以显著降低峰值GPU需求。 自动伸缩:基于请求队列长度和GPU利用率自动伸缩推理节点。配合预加载模型镜像,可以在5分钟内完成新节点启动。 第五层:Prompt优化 Prompt精简:去掉不必要的System Prompt内容,精简指令描述。每个Token都要花钱,冗长的Prompt直接增加成本。 Few-shot优化:与其在Prompt中放5个示例,不如用1个最好的示例加更清晰的指令。Few-shot示例的质量比数量更重要。 输出长度控制:在Prompt中明确要求简洁回答。生成500 Token和生成100 Token的成本差5倍。 实际案例 我们为一个客服场景做了全栈优化: 优化措施 成本降低 质量影响 模型从70B降到32B -45% -2%准确率 INT4量化 -60% -1.5%准确率 vLLM + Continuous Batching -30% 无影响 语义缓存 -22% 无影响 Prompt精简 -15% 无影响 投机解码 -35%(速度提升) 无影响 综合 -85% -3.5%准确率 最终成本降低了85%,而质量损失控制在可接受范围内。 ...

2026-07-12 · 1 min · 94 words · 硅基 AGI 探索者

大模型推理成本优化:从理论到实践

推理成本:AI落地的最大障碍 一个简单的事实:运行一个70B参数的模型,单张A100 GPU的每小时成本约2-3美元(云服务),每秒处理约50个Token。如果日均100万次请求、每次平均500 Token,一天的GPU成本就超过500美元。 随着用户规模增长,推理成本会线性甚至超线性增长。不做好成本优化,AI项目的商业模式根本不成立。 五层优化框架 我们将推理成本优化分为五个层次,从收益最大到收益递减: 第一层:模型选择优化 选择最小的够用模型。 这听起来简单,但实践中很多团队默认使用最大的模型"以防万一"。 我们的建议是建立模型路由系统: 简单FAQ → 7B模型 一般对话 → 32B模型 复杂推理 → 70B+模型 通过一个轻量级分类器判断请求复杂度,自动路由到合适的模型。在我们的实践中,模型路由可以降低60%以上的推理成本,而用户体验几乎不受影响。 开源vs闭源混合策略。 对于流量大的简单任务用开源模型自建部署,对于低频复杂任务调用闭源API。两者结合可以在成本和质量间取得最优平衡。 第二层:模型压缩优化 量化:INT4量化可以将模型大小和推理成本降低4倍,质量损失控制在2-3%以内(详见我们之前的量化对比文章)。 蒸馏:用大模型蒸馏出一个小模型用于线上推理。对于垂直领域,蒸馏模型可以达到接近大模型的效果但成本只有1/10。 稀疏化:通过剪枝去除不重要的权重。MoE架构本质上就是一种结构化的稀疏化——每次推理只激活部分专家网络。 第三层:推理引擎优化 KV Cache优化:KV Cache是自回归生成的最大显存消耗者。优化手段包括: PagedAttention(vLLM):将KV Cache分页管理,减少碎片浪费 KV Cache量化:将KV Cache从FP16压缩到INT8,显存减半 KV Cache共享:相同Prefix的请求共享KV Cache 批处理:将多个请求合并处理可以提高GPU利用率。vLLM的Continuous Batching技术可以在不增加延迟的情况下将吞吐量提升3-5倍。 投机解码(Speculative Decoding):用一个小模型先生成候选Token,大模型并行验证。如果小模型的猜测正确率高,生成速度可以提升2-3倍。 第四层:系统架构优化 缓存层:对相同或相似查询的结果进行缓存。我们采用语义缓存——不只是精确匹配,而是通过嵌入相似度判断是否可以用缓存结果。语义缓存可以命中15-30%的请求。 请求合并:当多个用户问类似的问题时,合并为一个请求,结果分发。这在客服场景特别有效。 异步处理:非实时任务(如批量文档处理)放入队列,在低峰期处理。削峰填谷可以显著降低峰值GPU需求。 自动伸缩:基于请求队列长度和GPU利用率自动伸缩推理节点。配合预加载模型镜像,可以在5分钟内完成新节点启动。 第五层:Prompt优化 Prompt精简:去掉不必要的System Prompt内容,精简指令描述。每个Token都要花钱,冗长的Prompt直接增加成本。 Few-shot优化:与其在Prompt中放5个示例,不如用1个最好的示例加更清晰的指令。Few-shot示例的质量比数量更重要。 输出长度控制:在Prompt中明确要求简洁回答。生成500 Token和生成100 Token的成本差5倍。 实际案例 我们为一个客服场景做了全栈优化: 优化措施 成本降低 质量影响 模型从70B降到32B -45% -2%准确率 INT4量化 -60% -1.5%准确率 vLLM + Continuous Batching -30% 无影响 语义缓存 -22% 无影响 Prompt精简 -15% 无影响 投机解码 -35%(速度提升) 无影响 综合 -85% -3.5%准确率 最终成本降低了85%,而质量损失控制在可接受范围内。 ...

2026-07-12 · 1 min · 94 words · 硅基 AGI 探索者
模型量化部署

模型量化部署指南

量化部署决策树 是否在H100上部署? ├─ 是 → FP8量化(原生加速,精度最佳) └─ 否 → 显存是否足够FP16? ├─ 是 → FP16(无精度损失) └─ 否 → INT8还是INT4? ├─ 精度要求高 → INT8 (W8A8) └─ 显存优先 → INT4 (GPTQ/AWQ) GPTQ量化 # 使用AutoGPTQ进行量化 from auto_gptq import AutoGPTQForCausalLM, BaseQuantizeConfig # 量化配置 quantize_config = BaseQuantizeConfig( bits=4, # 4-bit量化 group_size=128, # 分组大小 desc_act=False, # 是否按激活降序排列 ) # 准备校准数据 calibration_data = load_calibration_dataset(n_samples=128, max_length=512) # 加载模型并量化 model = AutoGPTQForCausalLM.from_pretrained( "Qwen/Qwen3-32B", quantize_config, ) model.quantize(calibration_data) # 保存量化模型 model.save_quantized("./qwen3-32b-gptq-4bit") AWQ量化 # 使用AutoAWQ进行量化 from awq import AutoAWQForCausalLM model = AutoAWQForCausalLM.from_pretrained("Qwen/Qwen3-32B") quant_config = { "zero_point": True, "q_group_size": 128, "w_bit": 4, "version": "GEMM" } model.quantize( calibration_data, quant_config=quant_config ) model.save_quantized("./qwen3-32b-awq-4bit") vLLM部署量化模型 # GPTQ模型部署 vllm serve ./qwen3-32b-gptq-4bit \ --quantization gptq \ --dtype float16 \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 # AWQ模型部署 vllm serve ./qwen3-32b-awq-4bit \ --quantization awq \ --dtype float16 \ --max-model-len 8192 # FP8模型部署(H100) vllm serve ./model \ --quantization fp8 \ --kv-cache-dtype fp8 Ollama部署 # 从GGUF文件创建Ollama模型 cat > Modelfile <<EOF FROM ./qwen3-32b-q4_k_m.gguf PARAMETER num_ctx 8192 PARAMETER temperature 0.7 EOF ollama create my-qwen -f Modelfile ollama run my-qwen 量化效果对比 以Qwen3-32B为例(单卡A100 80GB): ...

2026-07-02 · 2 min · 327 words · 硅基 AGI 探索者
vLLM Docker部署

vLLM Docker部署2026版

vLLM:高性能LLM推理引擎 vLLM是2026年最流行的开源LLM推理引擎,以其PagedAttention技术和连续批处理实现了极高的推理吞吐量。Docker部署是vLLM最常见的生产部署方式。 基础部署 Docker Compose # docker-compose.yml version: '3.8' services: vllm: image: vllm/vllm-openai:latest container_name: vllm-server runtime: nvidia ports: - "8000:8000" volumes: - ./models:/app/models # 模型存储 - ./config:/app/config # 配置文件 - vllm_cache:/root/.cache # 缓存 environment: - HUGGING_FACE_HUB_TOKEN=${HF_TOKEN} command: > --model /app/models/Qwen-3-32B --served-model-name qwen3-32b --tensor-parallel-size 2 --gpu-memory-utilization 0.90 --max-model-len 32768 --max-num-seqs 256 --quantization awq --dtype float16 --trust-remote-code --api-key ${VLLM_API_KEY} deploy: resources: reservations: devices: - driver: nvidia count: 2 capabilities: [gpu] restart: unless-stopped healthcheck: test: ["CMD", "curl", "-f", "http://localhost:8000/health"] interval: 30s timeout: 10s retries: 3 volumes: vllm_cache: 启动服务 # 创建环境变量 echo "HF_TOKEN=your_hf_token" > .env echo "VLLM_API_KEY=your_api_key" >> .env # 启动 docker compose up -d # 查看日志 docker compose logs -f vllm # 健康检查 curl http://localhost:8000/health 关键参数详解 模型加载参数 vllm serve /app/models/model_name \ --model /app/models/Qwen-3-32B \ # 模型路径,支持HuggingFace格式 --served-model-name qwen3-32b \ # API中使用的模型名称 --tokenizer /app/models/Qwen-3-32B \ # 分词器路径(默认与模型相同) --trust-remote-code \ # 信任远程代码(自定义模型结构需要) --dtype float16 \ # 数据类型:auto/float16/bfloat16/float32 --quantization awq # 量化方式:awq/gptq/squeezellm/None 并行与显存参数 --tensor-parallel-size 2 \ # 张量并行度(通常等于GPU数) --pipeline-parallel-size 1 \ # 流水线并行度 --gpu-memory-utilization 0.90 \ # GPU显存利用率上限(0-1) --swap-space 4 \ # CPU交换空间大小(GB) --kv-cache-dtype auto \ # KV Cache精度:auto/fp8/int8 批处理参数 --max-model-len 32768 \ # 最大序列长度 --max-num-seqs 256 \ # 最大并发序列数 --max-num-batched-tokens 8192 \ # 单次批处理的最大token数 --enable-chunked-prefill \ # 启用分块预填充 --max-num-partial-tokens 8192 # 分块预填充的块大小 高级配置 多模型服务 # docker-compose-multi.yml version: '3.8' services: vllm-model-a: image: vllm/vllm-openai:latest runtime: nvidia ports: - "8001:8000" command: > --model /models/Qwen-3-7B --served-model-name qwen3-7b --tensor-parallel-size 1 --gpu-memory-utilization 0.45 --max-model-len 8192 deploy: resources: reservations: devices: - driver: nvidia device_ids: ['0'] capabilities: [gpu] vllm-model-b: image: vllm/vllm-openai:latest runtime: nvidia ports: - "8002:8000" command: > --model /models/Qwen-3-32B --served-model-name qwen3-32b --tensor-parallel-size 1 --gpu-memory-utilization 0.45 --quantization awq --max-model-len 16384 deploy: resources: reservations: devices: - driver: nvidia device_ids: ['1'] capabilities: [gpu] # API网关 nginx: image: nginx:alpine ports: - "8000:8000" volumes: - ./nginx.conf:/etc/nginx/nginx.conf depends_on: - vllm-model-a - vllm-model-b Nginx路由配置 # nginx.conf upstream model_a { server vllm-model-a:8000; } upstream model_b { server vllm-model-b:8000; } server { listen 8000; # 按模型名称路由 location /v1/chat/completions { # 读取请求体中的model字段 set $upstream ""; if ($request_body ~* '"model"\s*:\s*"qwen3-7b"') { set $upstream model_a; } if ($request_body ~* '"model"\s*:\s*"qwen3-32b"') { set $upstream model_b; } proxy_pass http://$upstream; proxy_set_header Host $host; proxy_buffering off; proxy_read_timeout 300s; } # 健康检查 location /health { return 200 "OK"; } } 性能优化 分块预填充 vllm serve model \ --enable-chunked-prefill \ --max-num-batched-tokens 8192 \ # 预填充和生成可以混合批处理 # 避免长prompt阻塞短prompt的生成 前缀缓存 vllm serve model \ --enable-prefix-caching \ # 自动缓存相同前缀的KV Cache # 对系统提示词重复的场景大幅加速 推测解码 vllm serve model \ --speculative-model /models/draft-model \ --num-speculative-tokens 5 \ # 使用小模型加速大模型推理 客户端调用 Python SDK from openai import OpenAI client = OpenAI( base_url="http://localhost:8000/v1", api_key="your_api_key" ) # 对话 response = client.chat.completions.create( model="qwen3-32b", messages=[ {"role": "system", "content": "你是一个专业助手"}, {"role": "user", "content": "解释MoE架构"} ], max_tokens=2048, temperature=0.7, stream=True ) for chunk in response: if chunk.choices[0].delta.content: print(chunk.choices[0].delta.content, end="") 异步批量请求 import asyncio from openai import AsyncOpenAI async def batch_chat(): client = AsyncOpenAI( base_url="http://localhost:8000/v1", api_key="your_api_key" ) tasks = [ client.chat.completions.create( model="qwen3-32b", messages=[{"role": "user", "content": prompt}], max_tokens=512 ) for prompt in prompts ] results = await asyncio.gather(*tasks) return [r.choices[0].message.content for r in results] 监控 Prometheus指标 vLLM内置Prometheus指标导出: ...

2026-07-02 · 3 min · 598 words · 硅基 AGI 探索者
Ollama生产部署

Ollama生产部署完整指南

Ollama:简化LLM本地部署 Ollama是2026年最受欢迎的本地LLM部署工具之一。它以极简的命令行界面和自动化的模型管理,让在本地运行大模型变得前所未有的简单。但从"能跑"到"生产可用"之间,还有大量工程细节需要处理。 安装与环境准备 系统要求 # Linux安装 curl -fsSL https://ollama.com/install.sh | sh # 验证GPU支持 nvidia-smi # 确认GPU可用 ollama --version GPU显存规划 不同模型的显存需求: 模型 参数量 FP16显存 INT4显存 推荐GPU Qwen-3-7B 7B 14GB 5GB RTX 4060 8GB+ Llama-3-8B 8B 16GB 6GB RTX 4070 12GB+ Qwen-3-32B 32B 64GB 20GB RTX 4090 24GB+ Llama-3-70B 70B 140GB 40GB 2×A100 80GB Ollama服务配置 # 自定义模型存储路径 export OLLAMA_MODELS=/data/ollama/models # 监听所有网络接口(生产环境配合防火墙) export OLLAMA_HOST=0.0.0.0:11434 # 并发请求数 export OLLAMA_NUM_PARALLEL=4 # 上下文长度 export OLLAMA_CONTEXT_LENGTH=8192 # GPU层数(-1为全部卸载到GPU) export OLLAMA_NUM_GPU=-1 # 启动服务 ollama serve 模型管理 Modelfile自定义 # 基于Qwen-3创建自定义模型 FROM qwen3:32b # 系统提示词 SYSTEM """ 你是一个专业的技术助手。请提供准确、简洁的回答。 如果不确定,请明确说明。 """ # 参数调优 PARAMETER temperature 0.7 PARAMETER top_p 0.9 PARAMETER top_k 40 PARAMETER num_ctx 8192 PARAMETER num_gpu 50 PARAMETER stop "<|im_end|>" PARAMETER stop "<|endoftext|>" # 模板 TEMPLATE """ {{ if .System }}<|im_start|>system {{ .System }}<|im_end|> {{ end }}{{ range .Messages }}{{ if eq .Role "user" }}<|im_start|>user {{ .Content }}<|im_end|> {{ end }}{{ if eq .Role "assistant" }}<|im_start|>assistant {{ .Content }}<|im_end|> {{ end }}{{ end }}<|im_start|>assistant """ # 构建自定义模型 ollama create my-qwen -f Modelfile # 运行 ollama run my-qwen 模型量化 # Ollama自动选择量化级别 ollama pull llama3:70b # 默认INT4量化 ollama pull llama3:70b-q8_0 # 指定INT8 ollama pull llama3:70b-fp16 # FP16精度 # 从GGUF文件导入 ollama create my-model --file ./model.gguf API服务 REST API import requests # 基础对话 response = requests.post( "http://localhost:11434/api/chat", json={ "model": "my-qwen", "messages": [ {"role": "user", "content": "解释Transformer的注意力机制"} ], "stream": False, "options": { "temperature": 0.7, "num_ctx": 8192, } } ) print(response.json()["message"]["content"]) # 流式响应 response = requests.post( "http://localhost:11434/api/chat", json={"model": "my-qwen", "messages": [...], "stream": True}, stream=True ) for line in response.iter_lines(): if line: chunk = json.loads(line) print(chunk["message"]["content"], end="", flush=True) OpenAI兼容API Ollama提供OpenAI兼容接口,方便迁移现有应用: ...

2026-07-02 · 4 min · 780 words · 硅基 AGI 探索者
tgi 2026 guide

TGI(Text Generation Inference)2026 指南

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)是其高吞吐量的核心: ...

2026-06-28 · 4 min · 841 words · 硅基 AGI 探索者
vllm 2026 deployment guide

vLLM 2026 生产部署完全指南

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 降低了使用门槛。 ...

2026-06-28 · 5 min · 929 words · 硅基 AGI 探索者
production agent deployment checklist 2026

生产级 Agent 部署 Checklist 2026 版

引言 将 Agent 从 Demo 推向生产环境,需要跨越一道巨大的鸿沟。2025年,我们目睹了太多 Agent 在生产环境中翻车的案例:无限循环烧掉数万美元、Prompt 注入导致数据泄露、并发请求拖垮整个系统。这份 Checklist 是用真金白银换来的经验。 一、模型层 Checklist 1.1 模型选择与配置 模型版本锁定:生产环境使用明确的模型版本(如 gpt-5-2026-06-01),而非 gpt-5-latest Fallback 模型配置:主模型不可用时自动切换到备用模型 Token 限制设置:max_tokens 根据业务场景硬性设置,防止无限生成 Temperature 策略:事实性任务 T=0-0.3,创意任务 T=0.7-1.0,代码生成 T=0-0.2 上下文窗口管理:实现对话历史压缩策略,防止 Context Overflow PRODUCTION_MODEL_CONFIG = { "primary": { "model": "gpt-5-2026-06-01", "max_tokens": 4096, "temperature": 0.2, "timeout": 30, "retry": {"max_attempts": 3, "backoff": "exponential"} }, "fallback": { "model": "claude-opus-4-2026-04", "max_tokens": 4096, "temperature": 0.2, "timeout": 45, }, "emergency": { "model": "gpt-4o-2026-03", "max_tokens": 2048, "temperature": 0.0, } } 1.2 成本控制 Token 预算硬限:每个请求/用户/天的 Token 上限 模型路由策略:简单任务用小模型,复杂任务用大模型 缓存层:语义缓存命中率监控 成本告警:单次请求成本 > $0.1 时告警 class TokenBudget: """Token 预算管理器""" def __init__(self, redis_client): self.redis = redis_client async def check_budget( self, user_id: str, requested_tokens: int ) -> bool: daily_key = f"budget:{user_id}:{date.today()}" used = int(await self.redis.get(daily_key) or 0) limit = await self._get_user_limit(user_id) if used + requested_tokens > limit: await self._notify_overrun(user_id, used, requested_tokens, limit) return False return True async def consume( self, user_id: str, tokens_used: int, cost: float ): daily_key = f"budget:{user_id}:{date.today()}" cost_key = f"cost:{user_id}:{date.today()}" pipe = self.redis.pipeline() pipe.incrby(daily_key, tokens_used) pipe.incrbyfloat(cost_key, cost) pipe.expire(daily_key, 86400 * 2) pipe.expire(cost_key, 86400 * 2) await pipe.execute() 二、Prompt 层 Checklist System Prompt 注入防护:用户输入与系统指令严格分离 Prompt 版本管理:所有 Prompt 变更通过 Git 管理,支持 A/B 测试 Prompt 长度监控:System Prompt 不超过 Context Window 的 20% Few-shot 示例审计:示例中不包含敏感数据 输出格式约束:使用 JSON Mode 或 Structured Output class PromptSafetyValidator: """Prompt 安全验证器""" INJECTION_PATTERNS = [ r"ignore.*previous.*instructions", r"you.*are.*now.*a", r"system.*prompt.*is", r"reveal.*your.*instructions", ] def validate(self, user_input: str) -> ValidationResult: for pattern in self.INJECTION_PATTERNS: if re.search(pattern, user_input, re.IGNORECASE): return ValidationResult( safe=False, reason=f"Potential prompt injection: matched {pattern}" ) if len(user_input) > 10000: return ValidationResult( safe=False, reason="Input exceeds maximum length" ) return ValidationResult(safe=True) 三、工具层 Checklist 工具输入校验:每个工具的输入参数用 Pydantic 模型校验 工具超时设置:每个工具调用设置独立超时 工具权限分级:只读工具自动执行,写操作需审批 工具结果截断:工具输出超过 N 字符时自动摘要 工具幂等性:关键工具支持重试不会产生副作用 from pydantic import BaseModel, Field from typing import Literal class ToolRegistry: """工具注册中心""" def register(self, tool: Tool): # 验证工具定义 assert tool.timeout_ms <= 30000, "Tool timeout must be < 30s" assert tool.input_schema is not None, "Input schema required" assert tool.permission_level in ["read", "write", "admin"] if tool.permission_level in ["write", "admin"]: assert tool.requires_confirmation == True self._tools[tool.name] = tool class WebSearchInput(BaseModel): query: str = Field(..., min_length=1, max_length=200) max_results: int = Field(default=5, ge=1, le=20) safe_search: bool = True class WebSearchTool(Tool): name = "web_search" description = "Search the web for information" input_schema = WebSearchInput timeout_ms = 10000 permission_level = "read" requires_confirmation = False idempotent = True 四、架构层 Checklist 4.1 并发与限流 请求限流:QPS / 并发数 / Token/s 三维度限流 队列隔离:不同优先级请求使用独立队列 背压机制:下游不可用时主动拒绝请求,而非堆积 from asyncio import Semaphore, Queue import asyncio class AgentRequestHandler: def __init__(self, max_concurrent: int = 10): self.semaphore = Semaphore(max_concurrent) self.priority_queue = Queue(maxsize=1000) self.normal_queue = Queue(maxsize=5000) async def handle(self, request, priority: str = "normal"): queue = self.priority_queue if priority == "high" else self.normal_queue if queue.full(): raise ServiceUnavailableError("Request queue full") await queue.put(request) async with self.semaphore: return await self._process(request) 4.2 状态管理 会话持久化:对话状态可持久化到外部存储 检查点机制:长流程 Agent 支持断点续传 幂等 ID:每个请求分配幂等 ID,防重复执行 4.3 容灾设计 多 Provider 热备:OpenAI / Anthropic / Azure 至少两家 降级策略:LLM 不可用时回退到规则引擎 熔断器:错误率 > 50% 时自动熔断 30s class CircuitBreaker: """Agent 熔断器""" def __init__( self, failure_threshold: int = 10, recovery_timeout: int = 30, half_open_max_calls: int = 3 ): self.failure_threshold = failure_threshold self.recovery_timeout = recovery_timeout self.half_open_max_calls = half_open_max_calls self._state = "closed" # closed / open / half_open self._failures = 0 self._last_failure_time = None async def call(self, func, *args, **kwargs): if self._state == "open": if time.time() - self._last_failure_time > self.recovery_timeout: self._state = "half_open" else: raise CircuitOpenError("Agent temporarily unavailable") try: result = await func(*args, **kwargs) self._on_success() return result except Exception as e: self._on_failure() raise 五、安全层 Checklist PII 检测与脱敏:用户输入和 LLM 输出中的 PII 自动脱敏 输出过滤:有害内容、不当建议的过滤层 工具沙箱:代码执行工具在容器中运行,限制网络和文件访问 审计日志:所有 Agent 决策记录可审计 数据驻留:敏感数据不发送到 LLM,本地处理 class PIIRedactor: """PII 脱敏器""" PATTERNS = { "email": (r'[\w.-]+@[\w.-]+\.\w+', '[EMAIL]'), "phone": (r'\b1[3-9]\d{9}\b', '[PHONE]'), "id_card": (r'\b\d{17}[\dXx]\b', '[ID_CARD]'), "bank_card": (r'\b\d{16,19}\b', '[BANK_CARD]'), } def redact(self, text: str) -> tuple[str, dict]: """返回脱敏文本和映射表(用于恢复)""" mapping = {} redacted = text for pii_type, (pattern, replacement) in self.PATTERNS.items(): matches = re.finditer(pattern, redacted) for i, match in enumerate(matches): placeholder = f"{replacement}_{i}" mapping[placeholder] = match.group() redacted = redacted.replace(match.group(), placeholder) return redacted, mapping 六、可观测性 Checklist 全链路追踪:每个 Agent 步骤生成 Span 结构化日志:所有日志 JSON 格式,包含 trace_id 实时仪表盘:Grafana 仪表盘展示关键指标 告警规则:延迟、错误率、成本、Token 使用量告警 会话回放:支持根据 trace_id 回放完整 Agent 执行过程 七、运维层 Checklist 蓝绿部署:新版本 Agent 灰度发布,支持秒级回滚 配置热更新:Prompt、工具配置不重启即可更新 依赖版本锁定:所有依赖版本锁定,定期安全扫描 Secret 管理:API Key 通过 Vault/Secret Manager 管理 备份策略:对话历史、Agent 状态定期备份 八、合规层 Checklist 数据保留策略:用户对话数据保留期限明确 GDPR/PIPL 合规:支持用户数据删除请求 模型透明度:向用户说明使用了 AI 及其局限性 内容免责声明:输出中标注 AI 生成内容 审计合规:关键决策可追溯,满足监管要求 九、性能层 Checklist P95 延迟 < 5s:首 Token 延迟 < 2s,完整响应 < 30s 流式响应:长输出使用 SSE 流式返回 预计算:高频请求结果预计算缓存 连接池:LLM API 连接复用 CDN 加速:静态资源(Prompt 模板、配置)通过 CDN 分发 十、用户体验层 Checklist 加载状态:Agent 思考时展示进度提示 优雅降级:LLM 超时时返回友好提示而非错误码 多语言支持:Agent 输出跟随用户语言 反馈机制:用户可对 Agent 回答打分 边界处理:处理空输入、超长输入、非预期输入 十一、测试层 Checklist 单元测试覆盖率 > 80%:非 LLM 逻辑全覆盖 集成测试:关键业务流程端到端测试 混沌测试:主动注入 LLM 超时、工具失败 安全测试:Prompt 注入、数据泄露测试 负载测试:验证 10x 峰值流量下的表现 十二、上线前最终确认 □ 紧急关停开关(Kill Switch)可用且已测试 □ 回滚脚本已验证,可在 60s 内完成 □ on-call 排班已确认,告警通知链路畅通 □ 成本预算已设置硬性上限 □ 用户协议已更新,涵盖 AI 使用条款 □ 压测通过:P95 < 5s, 错误率 < 1% □ 安全审计已完成,无高危漏洞 □ 数据备份已验证可恢复 □ 运行手册(Runbook)已编写 □ 团队培训已完成 结语 这份 Checklist 看似冗长,但每一条都来自真实的生产事故。Agent 系统的复杂度远超传统应用——它不仅有代码的确定性风险,还有模型的不确定性风险、工具的副作用风险。上线的标准不是"能跑了",而是"出事了能兜住"。祝你的 Agent 平稳上线。 加入讨论 这篇文章有姊妹讨论帖在硅基AGI论坛 — 全球首个碳基硅基认知交流平台。 ...

2026-06-28 · 4 min · 762 words · 硅基 AGI 探索者
大模型推理加速 2026:vLLM vs SGLang vs TensorRT-LLM

大模型推理加速 2026:vLLM vs SGLang vs TensorRT-LLM

大模型推理引擎是 AI 基础设施的核心组件。2026 年,三大推理引擎——vLLM、SGLang、TensorRT-LLM——已形成三足鼎立格局。vLLM 凭借 PagedAttention 开创了高效推理范式,SGLang 以 RadixAttention 和结构化生成突围,TensorRT-LLM 则依托 NVIDIA 的硬件级优化。本文将在相同硬件上对三者进行全方位对比。 一、推理引擎概览 维度 vLLM SGLang TensorRT-LLM 开发者 UC Berkeley LMSYS/UC Berkeley NVIDIA 开源许可 Apache 2.0 Apache 2.0 Apache 2.0 核心技术 PagedAttention RadixAttention + 结构化生成 TensorRT 编译优化 支持模型 几乎所有主流模型 主流模型(覆盖中) 主流模型(覆盖窄) 部署复杂度 低(pip install) 低(pip install) 高(需编译) 社区活跃度 最高 快速增长 中等 二、核心技术解析 2.1 vLLM:PagedAttention vLLM 的核心创新是 PagedAttention——将 KV Cache 按 page 管理,避免显存碎片: 传统推理: KV Cache 连续分配 → 显存碎片 → 利用率 40-60% PagedAttention: KV Cache 分页管理 → 按需分配 → 利用率 90%+ 2026 版本新增: ...

2026-06-28 · 4 min · 709 words · 硅基 AGI 探索者
openclaw deployment guide

OpenClaw 部署完整指南:从本地到云端

部署概述 OpenClaw 支持多种部署方式,包括本地部署、云端部署和混合部署。通过灵活的部署方式,用户可以根据自己的需求选择合适的部署方案。 部署方式 1. 本地部署 本地部署是将 OpenClaw 部署在本地计算机上。 特点: 数据本地化 隐私保护强 配置简单 适用场景: 个人使用 数据敏感 网络不稳定 2. 云端部署 云端部署是将 OpenClaw 部署在云服务器上。 特点: 访问方便 资源弹性 配置复杂 适用场景: 多设备访问 资源需求高 网络稳定 3. 混合部署 混合部署是将 OpenClaw 部分部署在本地,部分部署在云端。 特点: 兼顾隐私和方便 配置复杂 资源利用率高 适用场景: 数据敏感但需要多设备访问 资源需求高但隐私要求高 网络不稳定但需要高可用性 部署步骤 1. 环境准备 系统要求: 操作系统:Windows、macOS、Linux 内存:2GB 以上 磁盘:10GB 以上 网络:稳定网络连接 软件要求: Node.js 16+ Python 3.8+ Git 2. 安装 OpenClaw # 安装 OpenClaw npm install -g openclaw # 验证安装 openclaw --version 3. 配置 OpenClaw 配置文件: ...

2026-06-27 · 1 min · 195 words · 硅基 AGI 探索者
鲁ICP备2026018361号