vllm deployment deep

vLLM 部署深度指南:高吞吐 LLM 推理引擎

vLLM 架构总览 vLLM 由 UC Berkeley 团队开发,核心创新是 PagedAttention——一种受操作系统虚拟内存启发的注意力机制。其架构层次: ┌─────────────────────────────────────────────┐ │ OpenAI Compatible API │ │ (Streaming / Function Calling) │ ├─────────────────────────────────────────────┤ │ Request Scheduler │ │ (Continuous Batching + Priority Queue) │ ├──────────────┬──────────────────────────────┤ │ PagedAttention│ ParallelWorker │ │ KV Cache Mgr │ (Tensor Pipeline Parallel)│ ├──────────────┴──────────────────────────────┤ │ GPU Workers (CUDA) │ │ FlashAttention / FlashInfer Backend │ └─────────────────────────────────────────────┘ PagedAttention 原理 核心问题 传统 LLM 推理中,KV Cache 按最大序列长度预分配连续显存。这导致: 内部碎片:实际序列 < 最大序列,浪费 60-80% 显存 外部碎片:频繁分配/释放产生碎片 无法共享:相同前缀的请求各自维护 KV Cache PagedAttention 方案 借鉴 OS 的分页机制,将 KV Cache 分割为固定大小的 block(通常每 block 存 16 个 token 的 KV): ...

2026-06-25 · 5 min · 903 words · 硅基 AGI 探索者
langfuse observability

Langfuse 可观测性:开源的 LLM 监控方案

LLM 应用的可观测性困境 当你的 LLM 应用从 Demo 走向生产,一系列问题随之而来:某个请求为什么返回了错误结果?Prompt 改动后效果到底是变好还是变差?不同模型的延迟和成本如何对比?传统 APM 工具(如 Datadog)对 LLM 场景缺乏原生支持。Langfuse 作为开源的 LLM 可观测性平台,正填补了这一空白。 Langfuse 核心功能 功能矩阵 功能模块 说明 Tracing 请求级全链路追踪,含 LLM 调用、工具调用、检索流程 Prompt Management Prompt 版本管理、AB 测试、在线编辑 Analytics 延迟、Token 用量、成本统计 Evaluation 人工标注 + 自动评估(基于规则或模型裁判) User Feedback 用户点赞/点踩采集与关联 Model Usage 多模型/多项目用量看板 Tracing:全链路追踪 集成方式 Python SDK(推荐) from langfuse import Langfuse from langfuse.decorators import observe langfuse = Langfuse() @observe() # 自动创建 trace def chat_bot(user_message: str): # 嵌套的 @observe 会自动建立父子关系 retrieved_docs = retrieve(user_message) # 被 trace answer = generate_response(user_message, retrieved_docs) # 被 trace return answer @observe(as_type="generation") def generate_response(question, docs): response = openai.chat.completions.create( model="gpt-4o", messages=[{"role": "user", "content": f"基于以下内容回答:{docs}\n问题:{question}"}], ) return response.choices[0].message.content @observe(as_type="span") def retrieve(query): # 检索逻辑 return vector_db.search(query) OpenAI SDK 集成(Drop-in) from langfuse.openai import openai # 只需替换 import,所有 OpenAI 调用自动被 trace response = openai.chat.completions.create( model="gpt-4o", messages=[{"role": "user", "content": "Hello"}], metadata={"user_id": "user_123"}, # 附加用户信息 ) LangChain 集成 from langfuse.callback import CallbackHandler handler = CallbackHandler() chain.invoke( {"input": "什么是量子计算?"}, config={"callbacks": [handler]} ) Trace 结构 Trace (chat_bot 调用) ├── Span (retrieve - 向量检索) │ └── Generation (embedding 调用) ├── Generation (generate_response - LLM 调用) │ ├── input: "基于以下内容..." │ ├── output: "量子计算是..." │ ├── model: gpt-4o │ ├── tokens: {input: 350, output: 280} │ └── cost: $0.0091 └── Span (后处理) 自定义 Span from langfuse import Langfuse langfuse = Langfuse() trace = langfuse.trace(name="rag-pipeline", user_id="user_123") span = trace.span(name="document-retrieval", input={"query": "量子计算"}) # ... 执行检索 ... span.end(output={"docs": [...]}) gen = trace.generation( name="answer-generation", model="gpt-4o", input={"messages": [...]}, output={"content": "..."}, usage={"prompt_tokens": 350, "completion_tokens": 280}, ) Prompt 管理 版本化 Prompt from langfuse import Langfuse langfuse = Langfuse() # 获取生产环境的 Prompt(自动缓存) prompt = langfuse.get_prompt( name="summarizer", version=2, # 指定版本,或省略获取最新 ) # 编译 Prompt(变量替换) compiled = prompt.compile( text="一段需要总结的长文本...", max_length="200" ) # 直接用于 LLM 调用 response = openai.chat.completions.create( model=prompt.config["model"], messages=[{"role": "user", "content": compiled}], ) Prompt AB 测试 import random # 50% 用户用 v1,50% 用 v2 version = random.choice(["v1", "v2"]) prompt = langfuse.get_prompt(name="customer-support", version=version) # Langfuse 自动记录每个请求使用了哪个版本 trace = langfuse.trace(name="support-chat") trace.update(metadata={"prompt_version": version}) 在线编辑 Langfuse Web UI 提供 Prompt 在线编辑器: ...

2026-06-24 · 3 min · 629 words · 硅基 AGI 探索者
openai evals guide

OpenAI Evals 框架指南:标准化 LLM 评估

为什么需要标准化评估框架 大语言模型能力飞速迭代,但"模型到底好不好"这个问题却越来越难回答。手工测试覆盖面有限, ad-hoc 脚本难以复现,不同模型之间的对比缺乏统一基准。OpenAI Evals 框架正是为解决这一痛点而生——它提供了一套标准化的评估流程,让模型评估变得可复现、可对比、可扩展。 Evals 框架核心架构 三层设计 ┌─────────────────────────────────┐ │ Eval Runner │ ← 评估运行器 ├─────────────────────────────────┤ │ Template / Custom Eval │ ← 评估模板/自定义逻辑 ├─────────────────────────────────┤ │ Dataset (JSONL / JSON) │ ← 评估数据集 └─────────────────────────────────┘ 组件 职责 说明 Eval Runner 执行评估 驱动模型推理、收集输出、触发评估器 Template 评估逻辑 定义 Prompt 模板和评估方法 Dataset 评估数据 JSONL/JSON 格式的测试样本 Evaluator 判定结果 判断模型输出是否正确 评估模板类型 OpenAI Evals 内置了多种评估模板: basic:单轮问答,对比模型输出与参考答案 matching:精确匹配评估 includes:包含匹配(输出包含期望字符串) factuality:基于另一个 LLM 判断事实准确性 model-graded-closedbook:模型作为裁判,无参考资料 model-graded-closedbook-cf:模型裁判 + 反转选项防止位置偏见 快速开始 安装 pip install openai-evals # 或从源码安装 git clone https://github.com/openai/evals.git cd evals && pip install -e . 使用内置评估模板 # 使用 basic 模板评估 oaieval gpt-4o basic --max_samples 100 # 使用 model-graded 模板 oaieval gpt-4o model-graded-closedbook \ --max_samples 50 \ --eval.evaluator gpt-4o 数据集格式 评估数据集采用 JSONL 格式,每行一个样本: ...

2026-06-24 · 3 min · 487 words · 硅基 AGI 探索者
vllm advanced guide

vLLM 高级配置指南:压榨每一滴性能

vLLM 性能基石 vLLM 的核心性能优势来自三大技术: 技术 解决的问题 性能提升 PagedAttention KV Cache 内存碎片 2-4x 吞吐 连续批处理 静态批处理浪费 3-8x 吞吐 高效注意力 标准 Attention 慢 2x 推理速度 PagedAttention 原理 传统 KV Cache 为每个请求预分配连续内存,导致大量碎片: 传统方式: [请求A: ████░░░░] [请求B: ██░░░░░░] [请求C: ██████░░] 预分配8块, 用4块 预分配8块, 用2块 预分配8块, 用6块 浪费4块 浪费6块 浪费2块 总利用率: 12/24 = 50% PagedAttention: [块0:A1] [块1:A2] [块2:B1] [块3:C1] [块4:C2] [块5:A3] [块6:C3] [块7:空闲] 按需分配, 几乎无浪费 总利用率: 7/8 = 87.5% KV Cache 被分成固定大小的 block(通常 16 token/block),通过页表映射,类似操作系统的虚拟内存。 ...

2026-06-24 · 4 min · 795 words · 硅基 AGI 探索者
fastchat deployment

FastChat 多模型对话平台部署实战

FastChat 概述 FastChat(原 Vicuna 项目)是 LMSYS Org 开发的开源大模型对话平台,核心功能: 多模型对话:同时与多个模型对话,横向对比输出质量 Web UI:基于 Gradio 的聊天界面,支持流式输出 OpenAI 兼容 API:提供标准 API 接口 分布式架构:Controller-Worker 分离,支持多 GPU 节点 模型竞技场:Chatbot Arena 盲测打分系统的开源实现 FastChat 的定位更偏向模型评测和对比,而非纯生产服务。如果你想搭建一个多模型对比平台,FastChat 是最合适的开源方案。 架构解析 ┌─────────────┐ │ Controller │ (中心调度) └──────┬──────┘ ┌────────────┼────────────┐ │ │ │ ┌─────┴─────┐ ┌───┴─────┐ ┌───┴─────┐ │ Worker 0 │ │Worker 1 │ │Worker 2 │ (模型推理) │ Vicuna-13B│ │LLaMA-70B│ │Qwen-14B │ └───────────┘ └─────────┘ └─────────┘ │ │ │ ┌─────┴─────────────┴─────────────┘ │ Gradio Web Server / API │ └─────────────────────────────────┘ Controller:注册中心,管理所有 Worker 的模型信息,做负载均衡 Worker:加载模型,处理推理请求,可分布在多台 GPU 机器 Web Server:Gradio 界面 + REST API 安装 pip install fschat[model_worker,webui] 或从源码安装最新版: ...

2026-06-24 · 3 min · 617 words · 硅基 AGI 探索者
litellm proxy guide

LiteLLM 多模型代理部署:统一管理所有 LLM API

LiteLLM 是什么 LiteLLM 是一个统一的 LLM 代理层,用一套 OpenAI 兼容 API 调用 100+ 个模型提供商。它解决的核心问题是:每个 LLM 提供商的 API 格式都不一样。 提供商 API 格式 认证 流式格式 OpenAI /v1/chat/completions Bearer token SSE Anthropic /v1/messages x-api-key SSE (不同结构) Google Gemini /v1/models:generateContent API key JSON streaming Bedrock /model/{id}/invoke AWS Sig v4 Event stream DeepSeek /v1/chat/completions Bearer token SSE LiteLLM 把这些全部统一成 OpenAI 格式。你的应用代码只对接 LiteLLM,换模型只改配置不改代码。 快速部署 Docker 部署 docker run -d \ --name litellm-proxy \ -p 4000:4000 \ -v $(pwd)/config.yaml:/app/config.yaml \ -e LITELLM_MASTER_KEY=sk-1234 \ ghcr.io/berriai/litellm:main-latest \ --config /app/config.yaml 配置文件 # config.yaml model_list: # OpenAI 模型 - model_name: gpt-4o litellm_params: model: openai/gpt-4o api_key: os.environ/OPENAI_API_KEY # DeepSeek(OpenAI 兼容格式) - model_name: deepseek-chat litellm_params: model: deepseek/deepseek-chat api_key: os.environ/DEEPSEEK_API_KEY api_base: https://api.deepseek.com/v1 # Claude - model_name: claude-sonnet litellm_params: model: anthropic/claude-3-5-sonnet-20241022 api_key: os.environ/ANTHROPIC_API_KEY # Ollama 本地模型 - model_name: qwen-local litellm_params: model: ollama/qwen2.5:14b api_base: http://host.docker.internal:11434 # 负载均衡:同一模型名指向多个后端 - model_name: fast-model litellm_params: model: openai/gpt-4o-mini api_key: os.environ/OPENAI_API_KEY - model_name: fast-model litellm_params: model: deepseek/deepseek-chat api_key: os.environ/DEEPSEEK_API_KEY litellm_settings: # 缓存 cache: true cache_params: type: redis host: redis port: 6379 # 限流 max_budget: 100 # 每日 $100 上限 budget_duration: 1d router_settings: routing_strategy: least-busy # 负载均衡策略 num_retries: 3 timeout: 30 fallbacks: - model: gpt-4o fallback_to: [deepseek-chat, qwen-local] 启动验证 # 测试 OpenAI 兼容 API curl http://localhost:4000/v1/chat/completions \ -H "Authorization: Bearer sk-1234" \ -H "Content-Type: application/json" \ -d '{ "model": "deepseek-chat", "messages": [{"role": "user", "content": "Hello"}], "stream": false }' 核心功能 负载均衡 同一 model_name 配置多个后端,LiteLLM 自动分流: ...

2026-06-24 · 3 min · 600 words · 硅基 AGI 探索者
open webui guide

Open WebUI 本地部署指南:打造你的私人 ChatGPT

为什么选 Open WebUI Open WebUI(原 Ollama WebUI)是最成熟的开源 LLM 前端,Star 数超过 80k。核心优势: ChatGPT 级交互体验:流式输出、Markdown 渲染、代码高亮、文件上传 多模型支持:通过 Ollama 或 OpenAI 兼容 API 接入任意模型 内置 RAG:上传文档自动切片、嵌入、检索,无需额外搭建 多用户管理:RBAC 权限、API Key 管理、使用统计 插件生态:函数调用、工具集成、自定义 Pipeline Docker 部署 单机部署(推荐) docker run -d \ --name open-webui \ --restart always \ -p 3000:8080 \ -e OLLAMA_BASE_URL=http://host.docker.internal:11434 \ -v open-webui-data:/app/backend/data \ ghcr.io/open-webui/open-webui:main 访问 http://localhost:3000,第一个注册的用户自动成为管理员。 Docker Compose 完整方案 version: '3.8' services: ollama: image: ollama/ollama:latest container_name: ollama restart: always ports: - "11434:11434" volumes: - ollama-data:/root/.ollama deploy: resources: reservations: devices: - driver: nvidia count: all capabilities: [gpu] open-webui: image: ghcr.io/open-webui/open-webui:main container_name: open-webui restart: always ports: - "3000:8080" environment: - OLLAMA_BASE_URL=http://ollama:11434 - ENABLE_RAG=true - RAG_EMBEDDING_ENGINE=ollama - RAG_EMBEDDING_MODEL=nomic-embed-text - CHUNK_SIZE=512 - CHUNK_OVERLAP=64 - ENABLE_SIGNUP=true volumes: - open-webui-data:/app/backend/data depends_on: - ollama volumes: ollama-data: open-webui-data: 启动:docker compose up -d ...

2026-06-24 · 3 min · 513 words · 硅基 AGI 探索者
sglang inference engine

SGLang 掐理引擎指南:超越 vLLM 的新选择

SGLang 是什么 SGLang(Structured Generation Language)是由 LMSYS Org 开发的高性能 LLM 推理引擎,核心创新是 RadixAttention——用基数树缓存 KV Cache,在多轮对话和复杂推理场景下显著优于 vLLM。 核心创新:RadixAttention 传统推理引擎的 KV Cache 是按请求隔离的——每个请求独立计算 Attention 的 K 和 V,无法复用。在多轮对话中,前几轮的 KV Cache 每次都要重算。 SGLang 用基数树(Radix Tree)管理 KV Cache: RadixTree: [system prompt] → [user msg 1 + assistant msg 1] → [user msg 2 + ...] ↑ 命中缓存 ↑ 命中缓存 ↑ 新计算 当新请求的前缀与已缓存的前缀匹配时,直接复用 KV Cache,跳过重复计算。 效果: 多轮对话:第 N 轮只计算第 N 轮的 KV,前 N-1 轮全部命中缓存 Few-shot 场景:多个示例的前缀共享缓存 Agent 场景:system prompt 长且固定,缓存命中率接近 100% 与 vLLM 的 PagedAttention 对比 特性 vLLM PagedAttention SGLang RadixAttention 缓存粒度 物理页(块级) 逻辑前缀(语义级) 跨请求复用 需手动启用 prefix caching 自动复用 多轮对话 每轮重新计算 prefix 前缀自动命中 树结构管理 页表 基数树 缓存命中率 中 高 内存效率 高 高 安装 # 安装 SGLang pip install sglang # 或从源码安装 pip install --upgrade pip pip install "sglang[all]" GPU 要求:CUDA 12.0+,推荐 A100/H100/L40S。消费级显卡(3090/4090)也可用。 ...

2026-06-24 · 4 min · 683 words · 硅基 AGI 探索者
opensource ecosystem

开源 AI 生态 2026:从 LLM 到 Agent 的完整工具链

2026 年开源 AI 生态有多成熟?从模型到框架到工具,一张地图看懂开源 Agent 全栈技术选型。

2026-06-09 · 3 min · 523 words · 硅基 AGI 探索者
local deploy guide

本地部署大模型实战:从 0 到 1 搭建私有 AI

数据隐私 + 成本控制 + 无限调用——本地部署大模型的三大理由。本文手把手教你部署生产级 LLM 服务。

2026-06-07 · 3 min · 438 words · 硅基 AGI 探索者
鲁ICP备2026018361号