本地推理运行时选型

收到 HTTP 200 响应，只说明请求返回了，不说明答案对。本地跑一个模型要经过四个相对独立的层级，任何一层变了，输出质量、内存占用、延迟或工具调用行为都可能跟着变：

所以比较运行时之前，要先把每一层用的是什么固定下来，下面的兼容性检查清单就是做这件事的。

运行时全景图

运行时/产品	核心优势	主要运维风险
llama.cpp	GGUF 格式支持、CPU/GPU 混合卸载、底层控制力强	需手动管理参数、模板、转换来源及后端调优
Ollama	管理本地模型包并提供 API	产物/模板可能漂移；云模型不在本机推理（见下文安全一节）
LM Studio	桌面端模型发现、交互式对比、兼容 API；三个系统都用 llama.cpp 跑 GGUF，Apple Silicon 上还能跑 MLX 模型	GUI 默认配置与下载变体需手动记录以确保可复现
MLX / mlx-lm	Apple Silicon 上 CPU 与 GPU 共用同一块内存，权重不用拷贝；Ollama 和 LM Studio 都能用它做后端	只在 Apple Silicon 上运行；MLX 文件和 GGUF 是两套量化，不能互换
vLLM	CUDA/Python 服务、连续批处理（Continuous Batching）、高吞吐	环境依赖较重，需关注产物兼容性及调度器/显存调优

SGLang、Transformers、TensorRT-LLM 或特定厂商运行时可能在特定场景下更优。上表并非完整排名，仅列出常见选项。

影响检查清单的近期变化

核对于 2026-10-29，依据各项目的发布说明。只列会改变安装或调用方式的三条：

• Ollama 0.40.0（9 月 25 日）起，在 Apple Silicon 上，MLX 支持的模型架构会自动用 MLX 运行。发布说明举的例子有 qwen3.8、gemma4 和 qwen3.6。10 月 28 日的最新版是 0.40.13。同一个模型名在 Mac 和 NVIDIA 机器上可能走不同后端，所以每次运行都要记下实际用的是哪个。
• vLLM 0.32.0（10 月 18 日）不再支持 Python 3.10，max_tokens 也不再从上下文窗口里预留。0.31.0（10 月 5 日）把在线量化的 quantization="fp8" 换成了 fp8_per_tensor，旧启动脚本要改。
• SGLang 0.5.22（10 月 19 日）要求 Python 3.11 或更新版本。

兼容性检查清单

开始评测前，先把影响行为和资源占用的条件固定下来：明确模型仓库、Revision、具体文件名与量化方式；锁定分词器、对话模板、推理输出解析器与停止词，以及工具调用和结构化输出的表现；同时记下原生和扩展上下文长度、实际设置的上下文长度、KV Cache 类型、批处理并发度和 GPU 卸载策略，并核对运行时与显卡驱动版本是否满足 Ollama、LM Studio 或 vLLM 的官方硬件要求。

“实际设置的上下文长度”最容易漏。Ollama 默认只开 4096 个 token 的上下文窗口，编码 Agent 的系统提示加上几个文件就会超过，超出的部分进不了模型。用 OLLAMA_CONTEXT_LENGTH 环境变量或请求里的 num_ctx 调大，再按单卡预算确认缓存放得下。llama.cpp 的 -c 默认是 0，表示沿用模型自带的长度（server 文档）。

OpenAI 兼容 API 仅标准化了请求结构的一部分，推理字段、Token 计数、工具 ID、流式分块、Logprobs、取消机制和错误码都可能各不相同。

选型实战案例

场景一：一张 16 GB 消费级 GPU 或一台 Apple Silicon Mac，单用户交互

1. 从支持的量化产物和原生上下文长度开始；
2. 若需精确控制 GGUF 卸载，选 llama.cpp；若追求最快上手进行手动对比，选 Ollama 或 LM Studio。在 Mac 上，先试模型的 MLX 版本，再拿同档的 GGUF 对比；
3. 在并发为 1 的情况下，测量首 Token 时间（TTFT）和解码速度；
4. 在评估模型智能之前，先验证 Chat 格式和工具调用格式是否正确；
5. 仅当明确的批量/服务需求且产物受支持时，才迁移至 vLLM。

场景二：24 GB 显存，常驻多客户端服务

这是小团队的需求：吞吐、排队、取消和隔离比桌面便利更重要。选 vLLM 或 SGLang 这类带连续批处理的服务端，固定并发测首 Token 时间和 token 间隔的 p95。确认客户端断开后生成真的停止，配好鉴权和请求大小限制，再开放端口。

启用推测解码前，先检查草稿与目标的兼容性，再在相同负载和质量条件下比较延迟、吞吐与内存。

交给统一评测协议

本页负责运行时兼容性、服务方式和运维风险。本地模型评测统一管理 run card、单变量实验、延迟与吞吐、内存测量、可接受结果率和重复任务结果。

安全与运维

对数据位置有要求时，要区分本地服务器和模型实际运行的位置。Ollama 的云模型在命令行和桌面应用里用 gemma4:cloud 这类名字调用，不用下载，推理在 Ollama 的云端完成。文档说 Ollama 会处理云端的提示和回答，但不用它们训练模型。要求纯本地推理时，只用已下载的本地模型，并关闭云功能。做法是设置 OLLAMA_NO_CLOUD=1，或在 ~/.ollama/server.json 里写 "disable_ollama_cloud": true。重启 Ollama 后，日志里应出现 Ollama cloud disabled: true。这个开关关闭的是 Ollama 云模型和网页搜索，不会限制其他 Harness 的外部工具，也不是网络沙箱。

网络绑定同样要收紧：Ollama 默认绑定 127.0.0.1:11434，用 OLLAMA_HOST 改地址对外暴露前必须先加上认证；模型服务应使用单独签发的密钥，既不与其他服务共用，也不放进 Harness 能读到的仓库或日志里。还要查清运行时和客户端会向外发送哪些遥测数据并按需关闭，给单次请求、上下文和输出长度设好上限，并在客户端断开后确认服务端确实终止生成、释放 GPU。同时把模型文件和对话模板当作供应链输入逐一审计，切勿让兼容端点变成未经审查的内网代理。

我的阅读