vLLM、SGLang、TGI、llama.cpp怎么选：推理服务社区选型帖

[admin]

开源大模型推理服务选型，最容易陷入两个误区。第一个误区是只问“哪个最快”，却没有说清楚模型大小、显卡数量、上下文长度、并发形态、流式体验、结构化输出、量化方式和运维环境。第二个误区是只看单机压测分数，忽略了上线后的排队、冷启动、显存碎片、长短请求混跑、监控告警、模型兼容和团队维护能力。vLLM、SGLang、TGI、llama.cpp都能跑大模型，但它们适合的主战场不完全一样。

如果只要一句话结论：GPU服务器上的通用高并发推理，优先看vLLM；复杂代理、多轮流程、结构化输出和前缀复用很重，重点看SGLang；已经在Hugging Face生态里、需要稳定容器和成熟接口，TGI仍有参考价值，但要注意它的维护状态；本地电脑、CPU、边缘设备、GGUF量化模型、轻量私有部署，llama.cpp最实用。真正做选型时，不要把这句话当成硬规则，而要按自己的负载画像做验证。

推理服务的“快”不是一个指标。用户打开聊天框后，第一感知是首个token多久出来，也就是首token延迟；连续生成时，用户感知每秒能看到多少字，对应输出token速度；平台经营者关心单位时间能处理多少请求、多少token，对应吞吐；运维关心显存利用率、排队长度、错误率、重启恢复时间；产品关心流式是否平滑、长问题是否不容易超时、工具调用和JSON是否稳定。四个项目的差异，往往体现在这些指标的取舍上。

一、先画清楚自己的负载画像

选型前先回答六个问题。第一，模型多大，是七十亿、三百亿、七百亿，还是混合专家模型。第二，硬件是什么，是单张消费级显卡、单机多卡、集群多卡、CPU、Mac、边缘设备，还是云端托管。第三，请求形态是什么，是短问短答、长文总结、代码生成、客服对话、RAG问答、代理调用、批量离线生成，还是多模态理解。第四，并发规模是什么，是个人使用、十几人团队、几百并发、上千并发，还是平台级调度。第五，输出约束是什么，是普通聊天、强JSON、工具调用、函数调用、正则约束、分类打分，还是多轮程序化控制。第六，运维要求是什么，是能跑就行、可观测、可灰度、可回滚、多租户、安全审计，还是要接入现有网关。

没有负载画像时，任何“最佳推理框架”都只是口号。比如同一台服务器，短请求高并发需要连续批处理和调度效率；长上下文RAG需要KV缓存管理和显存稳定性；代理系统需要前缀缓存和结构化输出；本地隐私助手需要简单部署和量化模型；研究实验需要快速换模型和改采样参数。场景不同，最优选择会变化。

还要区分“服务框架”和“模型格式”。vLLM、SGLang、TGI通常服务Hugging Face Transformers生态里的权重和配置，面向GPU推理；llama.cpp长期围绕GGUF量化格式和C/C++运行时发展，CPU和多种后端都能覆盖。模型从一个生态迁到另一个生态，可能需要转换权重、重新验证tokenizer、对齐chat template、检查停止词、测试函数调用和JSON输出。不要以为只要模型名一样，服务行为就完全一致。

二、评估指标要从用户体验和机器效率两边看

首token延迟决定“有没有反应”。聊天产品里，用户点发送后如果几秒没有任何输出，就会觉得系统卡住。首token延迟由排队、预填充、调度、显存状态和网络共同决定。长提示词、RAG上下文、系统提示、多轮历史都会增加预填充成本。支持前缀缓存、连续批处理和高效KV管理的框架，在长上下文场景里会更有优势。

生成吞吐决定“能不能撑住”。同一模型同一显卡，服务框架的批处理策略、注意力实现、KV缓存分配、张量并行、量化支持都会影响吞吐。吞吐不只看单请求每秒token，还要看多用户混合请求下的总体输出。生产环境里，几十个短请求和几个长请求同时进来，比单条固定长度压测更接近真实情况。

尾延迟决定“最差用户会不会崩”。平均延迟漂亮不代表系统稳定。一个请求如果因为队列饱和、长上下文抢占、显存不足、批次调度不均而拖到几十秒，用户体验仍然很差。选型压测时要看P50、P90、P95、P99，而不是只看平均值。还要分别压测短请求、长请求、混合请求、流式请求和失败重试。

显存效率决定“同样硬件能服务多少人”。大模型推理时，权重占一部分显存，KV缓存占另一部分，而且KV缓存会随着上下文和生成长度增长。PagedAttention、RadixAttention、连续批处理、前缀缓存、量化KV缓存等技术，都是围绕显存和调度效率展开。显存利用率高不等于安全，真正要看高并发下是否会频繁OOM、是否能稳定拒绝超限请求、是否有明确的最大上下文和最大并发边界。

接口兼容决定“能不能低成本接入”。很多应用已经按OpenAI风格的chat completions、embeddings、responses、tool calling或streaming来写。服务框架提供兼容接口，可以减少迁移成本。但兼容不等于完全一致。字段支持、错误格式、流式事件、工具调用格式、JSON schema约束、logprobs、停止原因、usage统计都要实际测试。网关层最好做适配，不要让业务代码直接依赖某个框架的细节。

运维能力决定“能不能长期跑”。健康检查、指标暴露、Prometheus、OpenTelemetry、请求日志、模型加载日志、限流、优雅关闭、滚动升级、容器镜像、Kubernetes部署、权限隔离、私有模型鉴权，这些都不是压测榜单里的亮点，却是生产上线的底座。社区选型不能只看性能图，还要看团队能不能修问题、查问题和升级问题。

三、vLLM：通用GPU高并发服务的默认强选项

vLLM的核心吸引力是把大模型服务里的KV缓存管理和调度做得很强。PagedAttention论文把操作系统分页思想引入注意力KV缓存管理，减少碎片和重复复制，让服务能在相近延迟下承载更高吞吐。对普通工程团队来说，这意味着vLLM不是只适合跑demo，而是天然面向高并发在线服务。

vLLM适合的场景很明确：有NVIDIA或其他支持后端的GPU资源，主要运行开源聊天模型、代码模型、RAG生成模型、Embedding或Reward等服务，希望通过OpenAI兼容接口对上层应用提供统一访问；请求量不是个人玩具级，而是希望稳定支撑团队或产品流量；未来可能要做张量并行、LoRA适配、量化、前缀缓存、投机解码、监控指标和Kubernetes部署。

vLLM的优势之一是生态入口清楚。它提供在线服务、OpenAI兼容服务、离线推理、支持模型列表、量化、LoRA、结构化输出、生产指标等文档。对团队协作来说，文档完整度很重要，因为部署、调参、扩容、排障都需要统一语言。一个框架如果只有零散命令和社区帖子，短期能跑，长期会把维护成本转嫁给团队。

vLLM尤其适合“平台层”角色。比如公司内部要搭一个模型网关，后面挂多个开源模型，对前端、RAG、代理、批处理任务提供统一接口。vLLM的OpenAI兼容服务可以让许多现有SDK直接接入，生产指标可以进入监控系统，部署文档也能对接容器和集群。对于LocalAIHub这类社区或团队基础设施，vLLM常常是GPU推理池的第一候选。

但vLLM不是所有场景的答案。第一，它更偏GPU服务，不是低资源本地端的最省心选择。第二，它支持很多模型，但具体模型、量化格式、多模态能力、工具调用行为仍要按版本验证。第三，高性能参数很多，团队要理解max model len、gpu memory utilization、tensor parallel size、batch相关配置、prefix caching等设置，否则容易出现“能启动但不稳定”。第四，某些复杂代理流程如果大量复用共享前缀、强结构化输出或需要语言模型程序控制，SGLang可能更顺手。

选择vLLM时，建议先做三组压测。第一组是短问答高并发，用来观察吞吐、排队和首token。第二组是长上下文RAG，用真实检索上下文压测预填充、显存和尾延迟。第三组是混合负载，把短请求、长请求、流式请求、失败重试放在一起，看系统是否稳定。只跑单条固定prompt，很难发现生产问题。

四、SGLang：复杂流程、结构化输出和前缀复用强项明显

SGLang最初强调的不只是“把模型跑起来”，而是高效执行结构化语言模型程序。论文里把前端语言和运行时结合起来，用RadixAttention复用KV缓存，用压缩有限状态机加速结构化输出解码。这些方向非常贴近今天的代理系统：多轮调用、工具使用、JSON输出、并行分支、少样本提示、RAG流水线、复杂控制流，都不只是普通聊天补全。

如果你的应用有大量固定系统提示、固定工具说明、固定角色模板、固定知识前缀，前缀缓存就很重要。很多平台的真实请求并不是完全不同的prompt，而是共享一大段系统规则和工具schema，然后用户输入不同。RadixAttention这类面向前缀复用的优化，在这种负载下会体现价值。尤其是代理平台、代码助手、评测平台和复杂工作流服务，SGLang值得认真测。

SGLang也适合重结构化输出场景。普通聊天可以容忍句子自由发挥，但生产系统经常需要稳定JSON、固定字段、工具参数、分类标签、评分结果、可解析动作。结构化输出如果不稳定，上游业务就要写大量修补逻辑。SGLang围绕结构化语言模型程序的设计，使它在这类需求上有明确定位。

多模态和大规模服务也是SGLang的重要方向。官方文档强调它是面向大语言模型和多模态模型的高性能服务框架，支持低延迟、高吞吐、前缀缓存、多GPU并行，以及OpenAI兼容接口。对于想把文本模型、视觉语言模型、复杂推理流程统一到一个服务层的团队，它不是小众玩具，而是可作为生产候选的推理框架。

SGLang的潜在成本在于学习曲线。vLLM更像“强推理服务引擎”，SGLang还带有“语言模型程序运行时”的思路。团队如果只需要普通OpenAI兼容聊天接口，可能一开始觉得SGLang的优势没有完全用上；但如果系统正在走向代理编排、工具调用、结构化输出和复杂多步推理，提前理解SGLang会减少后续改造成本。

选择SGLang时，要重点验证三件事。第一，自己的模型和硬件是否在当前版本下稳定支持。第二，结构化输出和工具调用是否符合业务解析要求。第三，前缀缓存、并行请求和长上下文在真实prompt模板下是否有收益。不要只拿随机prompt压测，因为SGLang的优势常常来自真实业务prompt的共享结构。

五、TGI：Hugging Face生态里的成熟老牌，但要看维护状态

Text Generation Inference曾经是开源模型服务的重要选择，尤其适合Hugging Face模型生态。它提供容器化服务、token streaming、连续批处理、张量并行、量化、Prometheus指标、OpenTelemetry等生产能力。很多团队第一次把开源模型作为HTTP服务上线，就是从TGI开始。

TGI的优点是路径熟悉。模型在Hugging Face Hub上，部署方式、镜像、CLI参数、私有模型鉴权、流式输出、指标文档都比较完整。对于已经有Hugging Face平台经验的团队，TGI的接入心智成本低。它也能作为理解推理服务架构的好样本：launcher、router、model server、batching、streaming、metrics这些概念都很典型。

但现在选择TGI必须注意官方文档里的维护状态。文档已明确说明TGI进入维护模式，后续主要接受小修复、文档改进和轻量维护任务，同时提到下游推理引擎如vLLM、SGLang以及llama.cpp等方向。这个信息对新项目很关键：如果你是从零建设长期演进的推理平台，应该谨慎把TGI作为唯一核心底座。

这并不代表TGI没有价值。已有TGI服务如果运行稳定、模型覆盖够用、团队熟悉、业务没有复杂新需求，可以继续维护并逐步规划迁移。某些标准Hugging Face模型、固定容器环境、简单生成接口，TGI仍能完成任务。它更像一个成熟但增长速度放缓的选项，而不是当前最值得押注的新平台核心。

新项目是否选TGI，关键看约束。如果公司已有大量TGI部署脚本、监控模板、镜像仓库和运维经验，短期用TGI上线一个稳定服务并非错误。相反，如果需求包含快速跟进新模型架构、复杂结构化输出、多模态扩展、大规模高并发优化、社区活跃演进，那么vLLM或SGLang通常更值得优先验证。

TGI迁出时要做兼容测试。虽然上层可能都是HTTP生成接口，但不同框架的采样参数、停止词、流式chunk、错误码、usage统计、模板处理、工具调用、量化模型输出都会有差异。迁移时不要只测服务能不能返回文本，要用真实业务问题对比答案、延迟、成本和失败率。

六、llama.cpp：本地、边缘、CPU和GGUF生态的实用冠军

llama.cpp的定位和前三者不同。它是轻量C/C++推理生态，围绕本地运行、量化模型、CPU/GPU混合、GGUF格式、跨平台和低门槛部署发展。它不一定是数据中心GPU高并发的第一选择，但在个人电脑、Mac、边缘设备、离线环境、小团队私有助手里非常有生命力。

llama.cpp的HTTP server已经不仅是简单demo。官方README列出OpenAI兼容的聊天、响应和嵌入路由，支持量化模型的CPU和GPU推理，支持连续批处理、多用户并行、监控端点、schema约束JSON、函数调用、投机解码、Web UI等能力。这些特性让它能承担轻量服务，而不只是命令行工具。

它最适合的场景，是“资源有限但要掌控”。比如开发者想在本机跑一个私有代码助手，社区节点想在小服务器上提供低成本模型，企业某个内网工具不能把数据发到外部GPU集群，边缘设备需要离线问答，或者教育场景需要每台机器本地运行。GGUF量化模型让显存和内存压力大幅降低，部署也比完整GPU服务栈简单。

llama.cpp的优势还包括可移植性。很多机器没有数据中心GPU，却有CPU、Apple Silicon、消费级显卡或其他后端。llama.cpp生态长期围绕这些环境优化，能让“先跑起来”变得容易。对于社区项目，低门槛很重要，因为不是每个人都有A100、H100或多卡服务器。

它的限制也要说清。第一，高并发平台服务不是它最典型的优势区。第二，极致吞吐和多机调度通常不如vLLM、SGLang这类数据中心服务框架。第三，GGUF模型转换、量化等级选择、上下文长度、GPU offload层数、CPU线程、内存带宽都会显著影响效果。第四，量化会带来质量变化，不能只看模型能跑，还要用业务样本测回答质量。

选择llama.cpp时，建议把目标说清楚：是本地个人助手、局域网小服务、离线演示、低成本社区节点，还是生产平台后端。如果是前几类，llama.cpp往往又快又省事；如果是最后一类，除非负载很轻或硬件特殊，否则应把vLLM和SGLang也纳入评测。

七、四个项目放在一起怎么判断

如果你的核心需求是“单机或多卡GPU上服务多个开源模型，接OpenAI兼容接口，追求高吞吐和成熟部署”，先测vLLM。它在工程社区里的默认心智很强，资料多，部署路径清楚，生产指标和扩展能力比较完整。很多团队从普通聊天、RAG生成、代码补全、embedding服务开始，用vLLM做统一推理层，是务实选择。

如果你的核心需求是“代理流程、结构化输出、长系统提示复用、多轮程序化控制、复杂RAG流水线”，优先测SGLang。它不只是补全服务器，而是把语言模型调用当成可优化的程序执行。当前代理应用越来越多，工具schema和系统提示越来越长，前缀复用、结构化解码和并行控制的重要性会持续上升。

如果你已经重度使用TGI，而且服务稳定，短期没有必要为了追新而盲目迁移。但如果你在做新平台，TGI的维护模式意味着它更适合作为存量服务或过渡方案。新需求增长很快的团队，应把主要验证精力放在vLLM和SGLang上，同时保留TGI经验作为接口和运维参考。

如果你的核心需求是“本地可用、低成本、私有、离线、CPU也能跑、GGUF模型丰富”，llama.cpp就是优先级很高的选择。很多社区应用不需要一开始就追求多卡集群，先让用户在自己的机器或小服务器上稳定跑起来，反而更有价值。

还有一种常见组合：云端GPU用vLLM或SGLang，本地节点用llama.cpp，历史Hugging Face服务保留TGI，上层通过统一模型网关屏蔽差异。这样每个框架做自己擅长的事，不强迫一个工具覆盖所有场景。对于社区基础设施，这种多后端架构比单一框架崇拜更稳。

八、模型兼容比框架口碑更重要

选型时不要只问框架支持哪些“家族”，要验证具体模型。模型架构、tokenizer、chat template、rope scaling、context length、多模态processor、quantization config、特殊token、工具调用模板，都可能影响运行结果。同样叫Qwen、Llama、DeepSeek、Mistral的模型，不同版本和微调分支也可能有不同要求。

上线前要做模型兼容矩阵。每个候选框架至少记录：能否加载、最大上下文、显存占用、首token延迟、输出速度、流式是否稳定、stop tokens是否正确、中文质量是否异常、JSON是否可解析、工具调用是否符合上层协议、长上下文是否退化、并发下是否报错。矩阵比口头经验可靠。

量化模型要单独评测。AWQ、GPTQ、bitsandbytes、FP8、GGUF等路线对速度、显存和质量影响不同。量化不是免费午餐。某些任务几乎不受影响，某些任务会在数学、代码、工具参数、细节抽取上明显变差。社区服务如果要开放给很多用户，最好提供“高质量模型”和“低成本模型”两个档位，而不是把量化模型伪装成完全等价。

多模态模型更要保守。图像、视频、音频输入涉及预处理、processor、输入格式、显存峰值和接口兼容。某个框架支持文本模型，不代表同等成熟地支持你的多模态模型。要用真实图片、长图、截图、表格图、低清图、中文图文混排做测试。多模态失败常常不是服务崩溃，而是输出看似正常但理解错误。

九、硬件决定上限，也决定麻烦

单张消费级显卡适合小团队试用、中小模型服务和低并发应用。此时vLLM、SGLang都可能可用，llama.cpp也能通过量化模型提供更省资源的路线。关键瓶颈通常是显存容量和散热稳定性。不要把消费级显卡压到没有余量，长上下文请求很容易把服务打爆。

单机多卡适合更大的模型和更高吞吐。这里要看框架的张量并行、流水并行、专家并行、通信后端和部署经验。vLLM和SGLang都在多GPU方向持续投入，但具体模型要实测。多卡服务不是把参数设成卡数就结束，跨卡通信、负载均衡、显存碎片、故障恢复都会变复杂。

多机集群适合平台级服务，但工程成本显著上升。此时推理框架只是底层之一，还要有模型网关、队列、调度、监控、灰度发布、容量规划、权限控制、成本归因和自动扩缩容。不要指望单个推理框架替代平台工程。vLLM和SGLang可以是核心引擎，但平台能力需要单独建设。

CPU和边缘设备更适合llama.cpp。CPU推理速度不一定快，但胜在便宜、可控、部署简单、隐私好。很多内部问答、离线摘要、小模型分类、嵌入、低频助手不需要GPU集群。只要把用户预期管理好，CPU本地模型能解决大量“够用就好”的问题。

Mac和个人开发环境也值得单独考虑。开发者常常希望在本机调prompt、测RAG、跑小模型、做离线验证。llama.cpp在这类环境里很顺手。vLLM和SGLang更适合正式服务环境，本地开发也能用，但依赖和硬件要求通常更重。

十、接口层最好统一，不要把业务绑死在单一框架上

无论底层选谁，上层都建议经过模型网关。模型网关负责统一认证、限流、计费、日志、重试、路由、模型别名、灰度、熔断、字段适配和安全策略。业务应用只认“聊天模型”“代码模型”“嵌入模型”“重排模型”，不直接关心后端是vLLM、SGLang、TGI还是llama.cpp。

统一接口有两个好处。第一，迁移成本低。底层框架升级或切换时，上层业务不需要大量改代码。第二，能做多后端调度。高并发请求走vLLM，结构化代理走SGLang，本地私有任务走llama.cpp，历史服务保留TGI，都可以在同一个入口下共存。

但模型网关不能掩盖所有差异。工具调用、JSON schema、logprobs、函数参数、图像输入、embedding维度、rerank接口等能力，不同后端支持程度不同。网关应提供能力声明，让业务知道某个模型支持什么，而不是等请求失败。更好的做法是把模型能力写进注册表：上下文长度、输入类型、输出约束、价格、延迟、适用任务、风险说明。

十一、结构化输出和工具调用要认真测

很多AI应用从聊天演示走向生产后，最先遇到的问题不是模型不会说话，而是模型输出不稳定。JSON少一个逗号、字段名变了、数组多一层、工具参数类型错了，都会让业务流程断掉。推理框架如果支持约束解码、schema约束、工具调用格式或结构化输出优化，会明显降低上层修补成本。

vLLM和SGLang都在结构化输出上有相关能力，SGLang的系统设计尤其强调结构化语言模型程序。TGI也有Guidance相关能力，llama.cpp server也列出schema-constrained JSON和函数调用。实际选型时，不能只看“支持”两个字，要拿业务schema测试。比如订单创建、日程安排、代码审查、财务分类、RAG引用数组、工具调用参数，都要验证能否稳定解析。

结构化输出还要看速度。约束越复杂，解码开销可能越大。一个小JSON对象和一个深层嵌套schema不是一回事。压测时要分别测自由文本、简单JSON、复杂JSON、工具调用、多工具选择和错误输入。不要等上线后才发现结构化输出让吞吐下降明显。

十二、长上下文和RAG场景要单独压测

RAG应用常常把检索证据、系统规则、对话历史、用户问题一起送进模型。输入长，输出可能短。普通聊天压测无法代表这种负载。长上下文场景里，预填充成本、KV缓存显存、前缀复用、上下文截断策略和流式首token都很关键。

vLLM的PagedAttention和KV缓存管理对这类场景有吸引力。SGLang的RadixAttention和前缀复用在共享模板、共享工具说明、共享RAG框架提示里也可能很有价值。TGI支持连续批处理和PagedAttention等优化，但新项目仍要考虑维护状态。llama.cpp能跑长上下文模型，但本地资源和量化质量会成为主要限制。

RAG压测不要用随机长文本。要用真实检索片段，包含中文、表格、代码、标题、引用编号、长制度条款和多轮历史。观察模型是否能稳定引用、是否会因为上下文太长忽略中间证据、是否首token过慢、是否生成到一半断流。推理框架只负责高效运行模型，但框架选择会影响RAG产品的实际体验。

十三、监控和排障能力决定能否放心开放给用户

生产服务必须有健康检查、请求指标、延迟分位数、token统计、队列长度、显存使用、错误类型、模型加载状态和版本信息。vLLM文档里有生产指标、监控看板、Prometheus和Grafana相关内容；TGI文档强调Prometheus指标和OpenTelemetry；llama.cpp server也提供监控端点；SGLang作为生产服务框架同样需要接入监控体系。框架提供基础能力，团队要把它们接入统一观测平台。

日志要能支持问题定位。用户说“刚才回答很慢”，你要知道请求进入哪个后端、排队多久、预填充多久、生成多久、输出多少token、是否命中缓存、是否重试、是否被限流。用户说“回答格式错了”，你要能找到模型、参数、模板、schema和原始输出。没有日志，推理服务就是黑盒。

告警要按影响设置。服务进程挂掉当然要告警，但更常见的问题是尾延迟升高、OOM次数增加、首token变慢、某个模型错误率上升、流式中断、显存接近上限、队列积压。高质量告警不追求多，而追求能让值班者知道该扩容、降级、重启、切流还是回滚。

十四、安全和权限不是上层应用单独负责

推理服务经常处理内部文档、用户输入、代码、合同、图片和日志。即使模型本身不联网，服务层也可能泄露数据。基础安全包括认证、授权、TLS、请求体大小限制、日志脱敏、模型访问控制、租户隔离和密钥管理。不要把推理端口裸露在公网，也不要让任何人都能调用高成本模型。

多模型平台还要防止越权使用。某些模型可能只能内部团队访问，某些量化模型只能用于低风险场景，某些带工具调用的模型不能给未授权用户。模型网关应按用户、应用、租户和场景做权限控制。底层框架提供服务能力，权限边界应由平台层明确执行。

提示注入和越狱也会影响推理服务，尤其是RAG和代理场景。虽然防护不完全属于vLLM、SGLang、TGI、llama.cpp本身，但服务层要支持日志、审计、限流和策略控制。对高风险请求，可以路由到更保守的模型、关闭工具调用、降低最大输出或要求人工确认。

十五、迁移策略：先兼容，再灰度，再替换

从TGI迁到vLLM或SGLang，从vLLM迁到SGLang，或者把部分请求迁到llama.cpp，都不要一次性切干净。先建立统一接口适配层，把请求和响应字段对齐。再选一批低风险流量做影子请求，比较输出、延迟、错误率和成本。确认没有明显退化后，再做灰度切流。

迁移时要保留回滚路径。模型服务失败通常会直接影响用户对话、自动化流程或后台任务。上线前准备旧服务地址、路由开关、模型别名回滚、缓存清理和指标对比。不要把迁移和模型升级、提示词改版、业务逻辑重构放在同一天，否则出了问题无法判断原因。

迁移验收要看真实任务。普通“你好”没有意义。要覆盖中文问答、长上下文、JSON输出、工具调用、RAG引用、代码生成、拒答、超长输入、并发流式、错误参数和限流场景。只有这些都过了，才能说迁移可用。

十六、社区部署里的几种推荐组合

个人开发者组合：llama.cpp跑本地GGUF模型，配一个轻量Web UI或OpenAI兼容客户端；需要GPU云服务时，再接一个vLLM后端。这样本地隐私和云端能力都能兼顾。

小团队组合：单台GPU服务器上用vLLM服务主力聊天模型和embedding模型，另起llama.cpp做低成本本地备用或小模型任务。上层通过统一网关管理模型名、权限和日志。

代理应用组合：SGLang作为复杂代理和结构化输出后端，vLLM承担通用聊天和RAG生成，llama.cpp用于开发者本地调试。这样既能利用SGLang的程序化执行能力，也能保留vLLM的通用服务优势。

存量Hugging Face组合：已有TGI继续稳定跑，新增模型优先在vLLM和SGLang验证。网关层把TGI标为存量后端，逐步迁移高价值模型，不做无意义的大爆炸替换。

社区节点组合：中心节点用vLLM或SGLang提供高性能GPU服务，普通成员机器用llama.cpp贡献低成本边缘能力。模型网关按任务、成本和隐私要求路由。这样能让社区基础设施更开放，也更符合不同硬件水平。

十七、常见错误判断

错误一：看到某个benchmark第一，就认为它适合所有业务。benchmark通常有固定模型、固定硬件和固定请求长度。你的业务如果是长RAG、强JSON、多轮代理或低资源本地，结果可能完全不同。

错误二：只测吞吐，不测输出质量。不同框架、不同模板、不同量化和不同采样参数可能让答案行为变化。推理服务选型不是纯系统问题，也会影响最终模型表现。

错误三：把OpenAI兼容当成完全兼容。兼容接口能降低接入成本，但字段细节、流式格式、工具调用、错误处理和usage统计仍要测。业务代码最好通过网关适配，避免直接依赖底层差异。

错误四：忽略维护状态。开源项目活跃度、文档更新、issue响应、模型支持速度和社区方向都会影响长期成本。TGI进入维护模式这一点，对新项目选型就是重要信号。

错误五：在没有监控的情况下开放服务。推理服务不是静态网站，成本高、状态多、错误形态复杂。没有指标和日志，用户越多，风险越大。

错误六：用一个框架解决所有问题。vLLM、SGLang、TGI、llama.cpp各有主场。统一网关加多后端，往往比单一工具崇拜更适合社区和团队长期演进。

十八、最终建议

如果你现在要为生产级GPU推理服务选一个默认起点，先测vLLM。它的通用性、性能路线、OpenAI兼容、部署文档和生产指标都适合做主力后端。测试通过后，再根据模型和业务逐步调参。

如果你的应用已经明显走向代理、工具调用、复杂JSON、长前缀、多轮控制和结构化语言模型程序，SGLang应该和vLLM并列进入第一轮评测。不要等业务代码写出大量修补逻辑后才意识到结构化执行的重要性。

如果你维护的是Hugging Face旧服务，TGI可以继续服务稳定业务，但新平台不要忽略它的维护模式。把它当成成熟存量和参考架构，比把它当成未来唯一底座更合理。

如果你的目标是本地、离线、低成本、边缘、CPU或GGUF模型，llama.cpp优先级非常高。它让模型服务从“必须有GPU集群”变成“很多机器都能跑”，这对社区生态很重要。

真正成熟的选型不是争论谁赢，而是把不同后端放到统一服务体系里：主力GPU池、代理专用池、本地轻量池、存量兼容池，各自承担合适任务。这样既能跟上开源推理框架的快速变化，也能让最终用户拿到稳定、快速、可控的模型能力。

十九、压测方法：别让测试流量骗了你

推理服务压测最忌讳使用漂亮但无意义的样本。固定一个短prompt、固定输出几十个token、固定并发数，确实能得到整齐表格，却很难代表真实产品。真实请求往往有长短混合、中文英文混合、RAG上下文、工具schema、多轮历史、用户中途断开、失败重试和突发流量。压测样本越接近真实业务，选型结论越可信。

建议准备五类测试集。第一类是短问短答，用来测首token和基础吞吐。第二类是长输入短输出，模拟RAG、文档问答和政策解释。第三类是短输入长输出，模拟写作、代码生成和报告草稿。第四类是结构化输出，模拟JSON、工具调用和分类结果。第五类是混合流量，把前四类按真实比例混在一起，观察尾延迟、排队和错误率。

压测要记录完整指标。至少包含请求成功率、首token延迟、总延迟、输出token每秒、输入token吞吐、输出token吞吐、P50、P90、P95、P99、显存峰值、CPU占用、队列长度、OOM次数、超时次数、流式中断次数和服务重启次数。只看“每秒多少token”会忽略很多用户真正感受到的问题。

还要测冷启动和热启动。模型第一次加载需要多久，服务重启后多久可用，切换模型要不要清理显存，容器滚动升级时是否会中断请求，这些都属于生产体验。某些框架在稳定运行时很快，但模型加载慢、失败恢复慢，也会影响运维选择。

压测结果要按成本解释。同样吞吐下，使用几张卡、什么显卡、量化等级、上下文长度、功耗、云厂商价格，都会影响最终成本。社区或小团队尤其要算“每万输出token成本”和“高峰并发所需机器数”。性能高但硬件贵，不一定比性能略低但部署简单的方案更适合。

二十、配置参数常见坑

最大上下文长度不是越大越好。把模型服务配置成超长上下文，会增加KV缓存压力，降低并发容量，甚至让普通短请求也被资源规划拖累。应根据业务场景设置默认上下文，并为少数长文任务单独开模型或后端。RAG系统更应先压缩证据，而不是无限扩大上下文。

显存利用率参数也不能拉满。很多服务允许设置GPU memory utilization或类似参数。数值过高看似充分利用硬件，但会减少突发余量，遇到长请求、并发波动或碎片变化时容易OOM。生产环境通常要留安全余量，并通过限流和最大输入长度保护服务。

批处理参数要和延迟目标一起调。连续批处理能提高吞吐，但等待合批会影响首token。客服聊天、实时助手和代码补全更看重响应快；离线批量生成和评测任务更看重总体吞吐。不要用同一套参数服务所有任务，最好按产品类型拆分后端池。

采样参数会影响质量和可复现性。temperature、top_p、top_k、repetition penalty、max tokens、stop sequences不是纯前端选择，它们会影响服务负载和错误率。结构化输出场景通常需要更低随机性；创意写作可以更开放；代码和工具调用要保守。模型网关应给不同任务设置默认参数，避免每个业务随意传值。

chat template必须校验。很多开源模型依赖特定对话模板。模板错了，模型可能仍然输出文本，但质量明显下降，工具调用失效，停止符异常。迁移框架或换模型时，必须用同一批问题对比模板前后输出，不要只看服务能否启动。

二十一、容量规划：把高峰当成常态的一部分

容量规划不是等服务满了再加机器。先估算日活、峰值并发、平均输入token、平均输出token、长请求比例、流式保持时长和重试率。再用压测数据反推需要多少GPU、多少副本、多少队列余量。对社区服务来说，还要考虑某些用户批量脚本调用导致的突发压力。

限流策略必须提前设计。按用户、应用、模型、租户和IP设置不同额度，防止单个调用方占满昂贵GPU。高成本模型可以设置更低并发，低成本模型可以开放更多额度。限流文案要面向用户说明当前繁忙和重试建议，不要暴露内部队列、GPU编号或服务栈细节。

降级策略同样重要。高峰时可以把部分非关键请求路由到小模型、量化模型或本地llama.cpp节点；也可以降低最大输出、关闭长上下文、延迟离线任务、暂停批量评测。降级不等于随便变差，而是按任务优先级保护核心体验。

多后端架构下，容量规划还要看路由规则。不要让所有请求默认打到最强模型。简单分类、摘要草稿、轻量问答可以走便宜后端；关键推理、长代码、重要RAG答案再走强模型。这样推理平台才有可持续成本。

二十二、最终用户体验不能被技术细节污染

推理服务选型最终会落到产品体验。用户不关心后端叫vLLM、SGLang、TGI还是llama.cpp，用户关心回复快不快、会不会断、答案是否稳定、格式是否能用、隐私是否可信。界面里不应把内部错误、GPU显存、batch编号、trace id直接抛给普通用户。技术信息应进入日志和运维面板，用户界面只给清楚、可行动的提示。

流式输出要稳定。很多系统模型本身够快，但前端流式处理不平滑，用户看到一大段一大段跳出来，体验仍然差。后端需要稳定发送chunk，网关要避免缓冲，前端要正确处理断线和重试。框架支持streaming只是基础，端到端体验还要单独验证。

错误恢复要自然。模型服务繁忙时，用户应看到“当前请求较多，请稍后重试”这类最终用户能理解的话；如果输入太长，应提示如何缩短或拆分；如果模型暂不可用，应自动切换备选模型或保留草稿。不要把Python异常、HTTP堆栈、内部模型路径显示给用户。

对于社区平台，还要给用户透明选择。可以用“快速模型”“高质量模型”“本地模型”“长文模型”这样的名称，而不是要求用户理解每个推理框架。底层选型越复杂，前台呈现越要简单。把复杂性留在平台层，是推理服务工程的基本责任。

参考资料

• vLLM 官方文档: https://docs.vllm.ai/en/latest/
• vLLM OpenAI-Compatible Server 文档: https://docs.vllm.ai/en/latest/serving/openai_compatible_server.html
• vLLM Production Metrics 文档: https://docs.vllm.ai/en/latest/usage/metrics.html
• Kwon et al., Efficient Memory Management for Large Language Model Serving with PagedAttention: https://arxiv.org/abs/2309.06180
• SGLang 官方文档: https://docs.sglang.io/
• Zheng et al., SGLang: Efficient Execution of Structured Language Model Programs: https://arxiv.org/abs/2312.07104
• Hugging Face Text Generation Inference 文档: https://huggingface.co/docs/text-generation-inference/index
• Hugging Face TGI API Reference: https://huggingface.co/docs/text-generation-inference/reference/api_reference
• llama.cpp HTTP Server README: https://github.com/ggml-org/llama.cpp/blob/master/tools/server/README.md
• llama.cpp 项目仓库: https://github.com/ggml-org/llama.cpp