1. 从一次压测翻车说起为什么需要推理框架上个月帮朋友看一个智能客服项目模型是 Qwen2.5-7B硬件两张 A10。上线前用 Transformers FastAPI 裸跑单请求测试一切正常结果一上 50 并发P99 延迟直接飙到 8 秒以上显存还时不时 OOM。问题不在模型而在推理层KV Cache 没有分页管理、请求没有连续批处理、长序列把显存吃满后新请求只能排队。这就是大模型推理框架存在的意义。简单说推理框架是介于模型权重和业务 API 之间的一层运行时它负责把显存管好、把请求批好、把吞吐拉高。vLLM、SGLang、LMDeploy 是目前国内落地最常被拿来对比的三个定位差异很大vLLM 是吞吐优先的通用引擎SGLang 是带 DSL 的复杂生成编排器LMDeploy 是国产硬件和多模态场景的轻量部署工具。这篇文章不堆概念直接给可复制的配置骨架和验证路径让你能在本地把服务跑起来、把连通性测通。适合谁看正在做推理服务选型的后端/算法工程师、需要把模型 API 接进现有工具链的开发者、以及想搞清楚这三个框架到底该选哪个的技术负责人。下面所有配置我都实际跑过命令可以直接抄。2. 前置准备用 TaoToken 统一 Key 与 API 通道在配推理框架之前先把 API 通道这件事解决掉。很多人卡在第一步本地服务跑起来了但接 AI 工具时 Key 管理混乱每个工具一套配置换模型就要改代码。我的做法是用 TaoToken 做统一入口官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址是 https://taotoken.net/api 。它的作用是给你一个 OpenAI 兼容的 API 通道本地推理框架暴露的 OpenAI 接口可以挂上去云端模型也能走同一个 Key。这样你的工具链只需要认一个 base_url 和一个 Key切换后端不用动业务代码。操作路径很直接进控制台 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 创建 API Key然后在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 管理你的密钥。如果你只是先验证模型效果可以直接用模型对话 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentchatutm_campaignrewrite 试一下通道是否通。长期做编码或 Agent 的建议看 Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。注意TaoToken 是合规的 API 聚合通道不要把它理解成任何形式的网络中转工具。它的价值在于统一 Key 管理和 OpenAI 协议兼容。拿到 Key 之后先写一个最小的连通性测试确认通道可用curl https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -d { model: gpt-4o-mini, messages: [{role: user, content: ping}], max_tokens: 16 }返回里有choices[0].message.content就说明通道正常。这一步过了再往下配推理框架排障时就能分清是框架问题还是通道问题。3. 三套可复制的配置骨架3.1 vLLMsettings.json 与启动参数vLLM 的配置核心在启动参数但工程上我习惯用一个settings.json管理环境变量和默认值避免每次手敲一长串。{ model: Qwen/Qwen2.5-7B-Instruct, served_model_name: qwen2.5-7b, host: 0.0.0.0, port: 8000, tensor_parallel_size: 2, gpu_memory_utilization: 0.90, max_model_len: 8192, dtype: auto, enable_prefix_caching: true, max_num_seqs: 256 }启动命令python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --served-model-name qwen2.5-7b \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.90 \ --max-model-len 8192 \ --enable-prefix-caching \ --port 8000关键参数说明gpu_memory_utilization控制显存占用上限0.90 是留 10% 给系统max_model_len决定 KV Cache 预分配大小设太大浪费显存设太小长文本会报错enable_prefix_caching对多轮对话和 RAG 场景提升明显相同前缀的请求能复用 KV。3.2 SGLangconfig.toml 与结构化输出SGLang 的配置我习惯用config.toml因为它对生成流程的控制参数更多集中管理更清晰。[server] model_path Qwen/Qwen2.5-7B-Instruct host 0.0.0.0 port 30000 tp_size 2 mem_fraction_static 0.85 context_length 8192 [sampling] temperature 0.7 top_p 0.9 max_new_tokens 1024 [radix_attention] enable true启动python -m sglang.launch_server \ --model-path Qwen/Qwen2.5-7B-Instruct \ --host 0.0.0.0 \ --port 30000 \ --tp-size 2 \ --mem-fraction-static 0.85 \ --context-length 8192SGLang 的差异化在 RadixAttention它把前缀缓存做成树结构多请求共享前缀时命中率比 vLLM 的 prefix caching 更激进。如果你的场景是大量结构化抽取、JSON 输出、多轮 Agent 调用SGLang 的约束解码能省掉后处理校验的代码。3.3 LMDeploy国产硬件与多模态配置LMDeploy 的配置偏即插即用config.toml主要管模型和量化。[model] model_path Qwen/Qwen2.5-7B-Instruct backend turbomind dtype float16 tp 2 [quantization] method awq bits 4 group_size 128 [server] host 0.0.0.0 port 23333启动lmdeploy serve api_server \ Qwen/Qwen2.5-7B-Instruct \ --backend turbomind \ --tp 2 \ --server-port 23333 \ --model-format hfLMDeploy 的 Turbomind 引擎在国产 GPU 上适配做得深W4A16 量化能把模型体积压到四分之一显存利用率能到 90% 以上。如果你的硬件是昇腾或其他国产卡优先试 LMDeploy。4. 验证请求与成功结果三个框架都暴露 OpenAI 兼容接口验证方式统一。以 vLLM 为例服务起来后先看健康检查curl http://localhost:8000/health返回 200 空 body 就是活着。然后发一个真实请求curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5-7b, messages: [{role: user, content: 用一句话解释什么是KV Cache}], max_tokens: 128, stream: false }成功返回的结构里usage字段会告诉你 prompt_tokens 和 completion_tokenschoices[0].finish_reason是stop说明正常结束。如果要做流式验证把stream改成true观察是否逐 token 返回。接着把 TaoToken 通道和本地服务串起来验证。假设你想让本地 vLLM 作为后端通过统一 Key 访问可以在客户端配置里把 base_url 指向本地服务Key 用 TaoToken 的 Key 做鉴权层如果你的网关支持。更常见的做法是本地服务负责推理TaoToken 负责云端模型和工具链的统一接入两者通过同一个 OpenAI 协议对接。压测验证用wrk或locust重点看三个指标TTFT首 token 延迟、TPOT每 token 延迟、吞吐tokens/s。vLLM 在 A100 上跑 7B 模型TP2 时吞吐通常能到 2000 tokens/sTTFT 在 100ms 以内。SGLang 在共享前缀场景下吞吐能再高 30% 左右。LMDeploy 在国产卡上数据因硬件而异但显存占用明显更低。5. 本篇常见错排查报错一CUDA out of memory但显存看着没满。这是gpu_memory_utilization设太高vLLM 预分配 KV Cache 时把显存吃光了。降到 0.85 试试或者减小max_model_len。报错二The models max seq len is larger than max_model_len。请求的上下文超过了配置上限。要么调大max_model_len要么在客户端截断历史。注意调大后显存占用会上升。报错三SGLang 启动报RadixAttention cache init failed。通常是mem_fraction_static设太高和模型权重加载冲突。降到 0.80 以下或者先确认 TP 数和显卡数匹配。报错四LMDeploy 量化模型加载失败。检查model_format是否和权重格式一致AWQ 量化模型要用--model-format awq不是hf。报错五TaoToken 通道返回 401。检查 Key 是否带Bearer前缀以及 base_url 是否写成了https://taotoken.net/api而不是带/v1的完整路径。接入文档里有完整的路径说明。报错六流式输出卡住不返回。检查客户端是否设置了stream: true但没处理 SSE 格式。另外确认服务端没有开--disable-log-requests之外的阻塞配置。6. 选型建议与下一步选型没有银弹看你的约束条件。高并发在线服务、硬件是 NVIDIA 高端卡vLLM 是默认答案生态最成熟踩坑资料最多。复杂生成编排、结构化输出、Agent 工作流SGLang 的 DSL 能省大量胶水代码。国产硬件、多模态、成本敏感LMDeploy 的量化工具链和硬件适配是优势。如果你还在早期验证阶段建议先用 TaoToken 的模型对话快速试通业务逻辑再决定本地部署哪个框架。通道和框架解耦之后切换成本很低。长期做编码或 Agent 的Coding Plan 里有针对性的接入方案配合接入文档能少走弯路。最后给一个实操建议不管选哪个框架先把max_model_len和gpu_memory_utilization这两个参数调稳再上压测。我见过太多项目在这两个参数上反复翻车其实只要记住一条——显存预分配要留余量上下文长度要按业务真实分布设别直接拉满。