超级管理员
楼主
自托管推理现在基本是三条路：vLLM 做服务化、llama.cpp 做轻量化、Ollama 做开发体验。选错路线会在后期付出很大的重构成本。
vLLM：多并发服务 核心能力是连续批处理、PagedAttention、分块预填充和多 GPU 张量并行。当你的场景是多个客户端同时通过网络请求模型时，这些能力直接决定吞吐上限。
适用：生产环境、多租户、需要高吞吐。 不适用：单机本地工具、资源受限环境。
llama.cpp：零依赖、跨平台 C/C++ 写的推理引擎，GGUF 格式，mmap 加载，基线内存占用很低。从 Apple Silicon 到纯 CPU 服务器到边缘设备都能跑。
适用：端侧部署、异构硬件、需要精细控制参数的场景。 不适用：需要高并发服务的场景。它也可以开 server，但吞吐比不上 vLLM。
Ollama：开发体验层 它本质上是 llama.cpp 外面包了一层，提供模型分发、硬件自动检测、REST API 和 schema 管理。一条命令跑起来。
适用：本地开发、快速验证、结构化 Agent 工具链。 不适用：规模化生产。
迁移时机 从 Ollama 迁到 vLLM 的触发点很明确：从单人本地开发变成多租户生产服务。不要等到线上扛不住了再迁，那时候模型、提示词、调用方式都已经固化。
反过来，如果只是在做原型验证，直接用 vLLM 是过度设计。
几条实操经验
- 量化格式要一开始就定。GGUF 和 vLLM 的格式不一样，中途换要重新处理权重。
- 先想清楚并发模型。单请求低延迟和多请求高吞吐是两种不同的优化方向，选型阶段就要明确。
- 硬件决定上限。Apple Silicon 上 llama.cpp 的性价比很高；有 A100/H100 集群就上 vLLM。别在错误的硬件上优化软件。
- 留一个抽象层。哪怕现在只用 Ollama，也把调用封装一下，未来换引擎时改动范围可控。
本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。