本地推理运行时
本地部署至少有四层：
模型产物/量化 → 推理引擎/硬件 backend → server/API/scheduler → client/模板/工具 parser/harness
任一层变化都可能改变质量、内存、延迟或工具行为；HTTP 200 只证明有响应。
运行时地图
| 运行时/产品 | 强项起点 | 操作者承担的风险 |
|---|---|---|
| llama.cpp | GGUF、CPU/GPU 可移植、混合 offload、底层控制 | 参数、模板、转换来源和 backend 调优 |
| Ollama | 快速托管本地模型包和 API | 隐藏的产物/模板选择及包漂移 |
| LM Studio | 桌面发现、交互比较、兼容 API | GUI 默认和下载变体仍需记录 |
| vLLM | CUDA/Python 服务、continuous batching、吞吐 | 环境更重、产物支持、scheduler/显存调优 |
SGLang、Transformers、MLX、TensorRT-LLM 和特定硬件运行时可能更好；本表不是完整排名。
兼容性门
冻结模型仓库/revision/文件/量化、tokenizer/模板/推理 parser/停止 token、工具格式、上下文/KV/batch/offload、运行时与驱动。OpenAI-compatible 只统一部分请求形状，不保 证 reasoning 字段、token 计数、工具 ID、stream、logprob、取消和错误一致。
选择例子
单张 16 GB 消费卡、单交互用户：从支持量化和原生上下文开始；需要精确 GGUF/offload 控制时用 llama.cpp，最快手工比较可用 Ollama/LM Studio；并发 1 测首 token 和 decode；先验证模板/工具再判断智能；只有批量/服务需求明确且产物受支持时再转 vLLM。
24 GB 常驻多客户端则更关注吞吐、排队、取消、指标和隔离。这是负载差异，不证明某引擎总能生成更好的 token。
性能与安全
一次只改产物、上下文、KV、batch 或并发之一。预热后报告中位/尾延迟、prompt/decode 吞吐、峰值 VRAM/RAM、offload、接受率与 OOM。不同提示和量化的 tokens/s 不是受控比较。
默认绑定 loopback，网络暴露前加认证；隔离凭据；审查遥测；限制请求/上下文/输出；测试取消；把模型文件和模板视作供应链输入。
偏差
本文偏向 Linux 开发工作流和流行开放生态。Apple、AMD、Windows、移动 NPU、能耗、无障碍与大规模 fleet 需另测。官方文档能证明支持特性，性能必须在实际硬件和负载上测。