Ollama、llama.cpp、vLLM、SGLang 怎么选？本地推理引擎验收法

选本地模型，是决定让哪套权重回答；选推理引擎，是决定怎样加载权重、接收应用请求、调度并观察服务。一款模型在笔记本里能回答，不代表所选服务器能加载手头的文件、返回应用要求的字段，或在真实流量下保持可用。

这不是四家速度排行榜。先用本地部署与云 API 决策确定运行位置，再用显存预算缩小模型文件范围。本文把四个候选变成一套小型验收试验；最终服务能承受的负载，另用推理服务并发试验测量。

先固定模型文件和调用方

写下模型的确切修订版、权重格式、量化方案、分词器、聊天模板、所需上下文长度和许可。“同一模型”若使用不同量化文件或模板，就不是完全相同的对照。再写应用实际调用哪些能力：聊天、补全、向量、流式输出、工具调用、结构化输出，还是引擎专属接口。

文档写着 OpenAI 兼容，不等于每个请求参数、响应字段、错误码、流式事件和模型能力都一致。只对应用真正使用的接口逐项测试。四个候选可以这样进入短名单：

引擎	值得先试的情形	最先查的落差
Ollama	个人或小团队希望较快完成模型获取、本地对话与 API 原型；原生接口和模型封装减少首次配置。	指定模型包、上下文设置以及应用实际请求；如果依赖兼容接口，要测所用字段。
llama.cpp server	已有合适的 GGUF 文件，或需要控制 CPU/GPU 放置、在受限硬件运行；服务端提供兼容聊天和向量接口及较细的运行选项。	GGUF、分层卸载、聊天模板与上下文是否匹配；能加载不等于 CPU 回退后的等待时间可接受。
vLLM	团队准备在加速器上提供共享服务，需要服务配置和生产指标，并选用了它支持的模型。	具体模型架构、权重格式、硬件后端、模板，以及固定版本下的接口行为。
SGLang	要评估共享模型服务，希望测试其兼容接口和运行特性。	当前版本对模型及部署环境的支持，还有应用契约与运行证据。

这些是试验起点，不是能力边界。项目更新很快，支持情况也随版本和硬件后端变化。旧对比表没写某项能力，不能证明现行版本没有；文档列出一项能力，也不能证明它在你的模型上可用。每条关键判断都附版本与核对来源。

三道关卡筛选推理引擎

第一关：能否加载并稳定驻留。 对每个候选记录引擎版本、硬件和驱动、模型文件或仓库修订版、上下文长度及内存表现。先发一条普通请求，再发允许的最长输入，确认它按计划在 GPU/CPU 上运行且没有显存溢出。若某条路径不得不换权重文件，记录变化并重跑质量案例。4-bit 量化对照说明为何不能只用文件大小作决定。

第二关：是否满足应用契约。 让真实客户端对每个服务重放同一组已验收案例。检查角色及模板处理、流式顺序、停止原因、Token 用量、超时、错误状态，以及必需的结构化字段或工具字段。某项能力缺失，要明确标为阻断问题、需要适配器并复测，或本任务并未使用；一次 curl 成功不能证明应用兼容。请求与响应样例使用合成或脱敏数据。

第三关：团队能否运行目标服务。 对通过前两关的方案使用相同输入长度分布、生成上限、到达模式和质量标准。记录首 Token 延迟、完整响应、合格完成量、排队增长、拒绝请求及峰值内存。指定模型更新、访问控制、日志、健康检查和恢复负责人。单人离线工具可以重点检查冷启动与反复使用；共享服务则要做完整负载试验，而不是只看一次调用的速度。

只有通过硬门槛的候选才值得评分。吞吐好看，不能补救不兼容的模型文件或缺失的应用字段。若所有候选都没通过，应明确修改模型、接口、硬件或部署要求，再重新试验。

案例一：离线研究笔记本

一位分析员出差时要离线分类公开研究笔记。笔记本加速器内存有限，获准模型已有一个确定的 GGUF 文件。客户端只需要普通的流式聊天，不调用服务端工具。团队先试 llama.cpp server，因为 GGUF 加载和可调 GPU 卸载符合文件及硬件条件；同时试一份基于同一基础模型的 Ollama 模型包，比较部署与维护工作，并记下量化和模板是否不同。

假设两条路径都能启动，但最长笔记使其中一条大量回退到 CPU，等待明显变长。决定取决于预先写好的等待上限及同一组笔记的分类正确性，不取决于启动命令哪条更短。若两个模型包不同，质量差异也不能直接归因于引擎。记录应把引擎影响与模型包影响分开，只有结果实际通过时才选择配置更省事的路径。

案例二：团队共用 GPU 复核队列

一家客服团队基于获准知识库起草答复。应用发流式聊天请求，要求固定的 JSON 结果形状，并要在规定时间内把草稿交给复核人员。团队有专用 GPU 服务，换班前会出现请求突发。vLLM 与 SGLang 都进入短名单，因为它们提供适合这种部署形态的接口服务。团队固定版本、可用模型文件和客户端请求契约，再跑十条任务案例，包含输入不完整及缺乏证据的主张。

如果一套服务在无限速压测中完成请求更多，却在换班突发中突破首 Token 或排队上限，它就没通过。如果必需 JSON 字段或错误行为不一致，要么加入经测试的适配器，要么淘汰候选。最终决定附上合格答复、客户端契约结果、可重放的流量轨迹和服务恢复负责人，不能把它推广到另一款模型或 GPU。

填写推理引擎选择试验

下面的工作台针对一项任务和一组硬件条件。每个候选复制一行，并给日志和测试样例附受控证据位置。未做的实验应写未测试，不要用功能宣传填空。

记录	所需证据
固定任务	输入输出类型、至少两条代表案例、阻断错误、响应目标、隐私和许可门槛
候选身份	引擎与版本、模型修订版、权重文件与量化、分词器/模板、硬件、驱动、上下文和放置方式
应用契约	实际使用的端点和字段、流式与错误预期、案例结果、必要的适配工作
运行试验	冷/热加载、峰值内存、质量结果、首 Token 与完整响应时间、突发排队、拒绝请求、监控与恢复负责人
结论	通过、适配并重测或拒绝；证据位置、复核人和触发重测的变化

常见问题

**有 OpenAI 兼容端点就能直接换引擎吗？**不能。用固定版本测试应用实际发送的请求，检查必需字段和失败场景。兼容性只对已验证的调用子集成立。

**笔记本用户也要安装四套引擎吗？**只有候选支持手头模型和硬件、且任务确实需要那种服务能力时才值得试。短名单的作用是缩小试验范围。

**能按公开的每秒 Token 排名选择吗？**可以据此找候选，不能直接验收。模型文件、精度、硬件、上下文、前缀重用、请求组合和合格标准都会改变结论。

不适用边界

这套试验只为指定模型、任务、客户端、硬件条件和引擎版本选运行方式；它不能证明模型普遍更好、软件安全、许可已获批准或生产容量已达标。暴露的端点、模型下载、遥测和保存的 Prompt 都属于部署数据边界。更换权重、量化、模板、服务版本、硬件、接口能力或流量形状后，应重跑受影响的关卡。