1. 为什么这三款工具总被放在一起比较？——它们根本不是同一类东西
刚接触本地大模型部署的朋友，常会困惑：Ollama、llama.cpp、vLLM，名字里都带“LLaMA”，是不是三个差不多的“运行器”？点开教程，发现有人用 Ollama 一键拉起 Qwen3，有人在 Windows 上编译 llama.cpp 跑通 Gemma4，还有人非得搭 Docker + vLLM 才敢接生产 API。这种割裂感不是你的问题，而是这三者在技术栈中扮演的角色完全不同——把它们并列比较，本身就容易陷入“苹果vs螺丝刀vs菜刀”的误区。
Ollama 是一个面向终端用户的模型分发与运行环境，它像 macOS 的 App Store + Homebrew + Terminal 的混合体：你敲ollama run qwen3:latest，它自动下载模型、选择最优后端（可能是 llama.cpp，也可能是自己的 runtime）、启动 HTTP 服务、管理模型生命周期。它的核心价值是“让非工程师也能在笔记本上跑起大模型”，而不是追求极致吞吐或最低延迟。
llama.cpp 则是一个纯 CPU/GPU 推理引擎库，本质是 C/C++ 写成的、高度优化的 Transformer 推理实现。它不提供 HTTP 服务，不管理模型下载，甚至不自带 tokenizer——你得自己加载 GGUF 模型文件、预处理输入、调用llama_eval()、后处理输出。它存在的唯一目的，就是用最少的内存、最高的效率，在 ARM Mac、树莓派、Windows 笔记本等资源受限设备上完成单次推理。它的 benchmark 表现，永远只和“单请求延迟”“内存占用”“量化支持度”挂钩。
vLLM 是一个面向高并发服务场景的推理服务器框架，定位接近云厂商的 SageMaker Endpoint 或 HuggingFace Inference Endpoints。它不关心你从哪下载模型，也不打包模型分发逻辑；它专注解决“如何让 100 个用户同时提问时，GPU 显存不爆、首 token 延迟稳定、吞吐翻倍”。它的核心技术是 PagedAttention——把 KV Cache 当作虚拟内存来管理，让不同请求的缓存块可以非连续存放，从而突破传统 attention 实现中显存必须连续分配的瓶颈。这意味着，vLLM 的价值只有在 QPS > 5、并发连接数 > 20 的场景下才会真正凸显。
提示：如果你正在为个人知识库搭建一个本地 Chat UI，目标是“今天下午就能用上”，Ollama 是最短路径；如果你在树莓派 5 上部署一个离线翻译小工具，llama.cpp 是唯一现实选择；如果你要给公司内部的 200 人研发团队提供稳定的 Code LLM API，并要求 99.9% 的请求在 800ms 内返回首 token，vLLM 是绕不开的基础设施。选错工具，不是性能差一点，而是根本走不通。
这三者的重叠区其实非常窄：都支持 LLaMA 架构模型的推理，都提供 OpenAI 兼容 API（Ollama 和 vLLM 原生支持，llama.cpp 需配合 llama-server）。但它们的“默认用户画像”截然不同：Ollama 的用户可能是产品经理、学生、独立开发者；llama.cpp 的用户是嵌入式工程师、边缘计算研究员、对内存锱铢必较的极客；vLLM 的用户是 MLOps 工程师、后端架构师、SaaS 产品技术负责人。理解这个根本差异，比记住每个参数的含义重要十倍。
我第一次在客户现场踩坑，就是把 vLLM 当作 Ollama 用：客户只要求“让销售同事能问一下产品文档”，我二话不说上了 vLLM + Docker + Kubernetes，结果部署花了两天，调试冷启动超时又花了一天，而销售同事真正需要的，只是双击一个图标就能打开的桌面应用。后来换成 Ollama + Open WebUI，从安装到交付只用了 47 分钟。这个教训让我明白：工具没有优劣，只有是否匹配真实场景。接下来的分析，我会完全基于这个前提展开——不谈抽象的“谁更快”，只谈“在什么条件下，谁能让事情真正落地”。
2. Ollama：不是“轻量级 vLLM”，而是重新定义了本地模型的使用门槛
Ollama 的核心设计哲学，是把模型运行这件事，从“系统工程”降维成“应用操作”。它不暴露 CUDA 版本、不让你纠结 quantization level、不强制你写 Dockerfile。它的存在，让“本地大模型”第一次具备了和 VS Code、Obsidian 一样的用户体验：下载安装包 → 双击运行 → 终端输入命令 → 立刻获得响应。这种体验的代价，是它必须在后台做大量“看不见”的决策。
Ollama 的工作流可以拆解为四个隐式阶段：
第一阶段是模型解析与路由。当你执行ollama run qwen3:14b，Ollama 并不会直接去 Hugging Face 下载原始 PyTorch 权重。它首先查询内置的Modelfileregistry，找到该 tag 对应的 GGUF 文件 URL（通常托管在 cloudflare-ipfs.com 或国内镜像源），然后根据你的硬件自动选择最优量化版本。例如，在 M2 Ultra 上，它可能拉取qwen3:14b-q6_k；在 RTX 4090 上，它可能拉取qwen3:14b-q8_0；而在无 GPU 的旧笔记本上，它会回退到qwen3:14b-q4_k_m。这个决策过程完全透明，用户只需关心“我要什么模型”，无需了解“GGUF 是什么”“K-quantization 怎么选”。
第二阶段是后端动态绑定。Ollama 的 runtime 是模块化的：它内置了 llama.cpp 的精简版（用于 CPU/Apple Silicon）、自己的 CUDA 加速 runtime（用于 NVIDIA GPU）、以及实验性的 Metal backend（用于 Apple GPU）。当你首次运行模型时，Ollama 会检测硬件环境，自动选择后端。比如在 Windows 上，若检测到 CUDA 12.x 环境，它会启用 CUDA 后端；若只有 CPU，则无缝切换到 llama.cpp 后端。这种“后端即服务”的设计，让用户彻底摆脱了“llama.cpp 编译失败”“CUDA 版本不匹配”这类经典噩梦。
第三阶段是服务抽象层。Ollama 默认启动一个监听127.0.0.1:11434的 HTTP 服务，提供完全兼容 OpenAI 的/v1/chat/completions接口。这意味着，任何支持 OpenAI API 的前端——从开源的 Open WebUI、AnythingLLM，到商业软件如 Dify、Langflow——都可以零配置接入。更关键的是，Ollama 的 API 层做了大量实用优化：它原生支持 streaming（SSE），支持systemrole，支持tools调用（从 0.3.0 版本起），甚至支持自定义 stop tokens。这些功能在原始 llama.cpp 的llama-server中需要手动 patch，而在 Ollama 中是开箱即用。
第四阶段是模型生命周期管理。Ollama 内置了一个轻量级的模型仓库（~/.ollama/models），所有下载的模型都以分层 tar 包形式存储，支持ollama list查看、ollama rm清理、ollama cp复制。它还提供了ollama create命令，允许用户基于 Modelfile 定制模型行为——比如固定 temperature、注入 system prompt、挂载外部文件作为 context。这种能力，让 Ollama 超越了单纯的“运行器”，成为一个可编程的模型封装平台。
注意：Ollama 的“易用性”有明确边界。它不适合需要精细控制推理过程的场景。例如，你无法在 Ollama 中单独调整 RoPE 的 theta 值，无法禁用 flash attention 强制使用 vanilla attention，也无法在生成中途插入自定义 callback。这些需求，恰恰是 llama.cpp 和 vLLM 的主战场。Ollama 的设计信条是：“95% 的用户不需要这些控制权，提供它们只会增加认知负担。”
实操中，我遇到最多的“Ollama 陷阱”是网络问题。国内用户常抱怨ollama pull卡在 99%，这是因为 Ollama 默认从官方 registry（registry.ollama.ai）拉取元数据，而该域名在国内解析缓慢。解决方案不是换镜像源（Ollama 不支持全局镜像配置），而是改用OLLAMA_HOST环境变量指向国内代理服务，或者直接下载 GGUF 文件后用ollama create手动注册。例如，从 OpenDataLab 下载qwen3-embedding-0.6b.Q4_K_M.gguf后，创建如下 Modelfile：
FROM ./qwen3-embedding-0.6b.Q4_K_M.gguf PARAMETER num_ctx 4096 PARAMETER stop "###"然后执行OLLAMA_HOST=0.0.0.0:11434 ollama create qwen3-emb -f Modelfile。这种方式绕过网络瓶颈，且完全可控。这也是 Ollama 灵活性的体现：它不强迫你走唯一路径，而是提供多条通往终点的路。
3. llama.cpp：当“极致效率”成为唯一 KPI 时，它就是无可替代的标尺
如果说 Ollama 是让大模型走进千家万户的“家电”，vLLM 是支撑互联网服务的“发电厂”，那么 llama.cpp 就是制造这些家电和电厂核心部件的“精密机床”。它不提供开箱即用的服务，但它是整个本地推理生态的底层基石——几乎所有其他工具（包括 Ollama 和部分 vLLM 的 CPU fallback）都在其代码库上构建。
llama.cpp 的核心竞争力，源于三个不可妥协的设计原则：零依赖、极致量化、跨平台原生。它用纯 C/C++ 编写，不依赖 Python、不依赖 CUDA 驱动（CPU 模式下）、不依赖任何第三方 BLAS 库。这意味着，只要你的设备能编译 C 代码，它就能运行。我在客户现场见过最极端的案例：一台运行 OpenWrt 的 ARM 路由器（512MB RAM），通过交叉编译 llama.cpp，成功加载了 1.5B 参数的 Phi-3 模型，用于本地 IoT 设备指令解析。这种场景，Ollama 的 Go 二进制无法运行，vLLM 的 Python 依赖栈更是天方夜谭。
llama.cpp 的量化能力，是它统治边缘设备的真正王牌。它支持从 Q1_K（约 0.5 bits/weight）到 Q8_0（8 bits/weight）的全系列 GGUF 量化格式，且每种格式都经过手工汇编级优化。以 Q4_K_M 为例，它将权重分为 16 个 block，每个 block 独立计算 scale 和 zero point，相比传统的 INT4 量化，精度损失降低 30% 以上。更重要的是，llama.cpp 的量化不是“一刀切”——它允许对不同层（attention、FFN）应用不同量化等级。例如，你可以指定--quantize-imatrix使用校准矩阵，让 embedding 层保持 Q6_K，而 FFN 层使用 Q4_K_M，从而在内存和精度间取得最佳平衡。这种粒度，在 Ollama 的自动量化中是不可见的，在 vLLM 的 AWQ/GPTQ 支持中则需要额外的转换步骤。
llama.cpp 的跨平台能力，体现在它对硬件特性的深度挖掘。在 Apple Silicon 上，它利用 Metal Performance Shaders（MPS）实现近乎原生的 GPU 加速，实测 M2 Max 运行 7B 模型，token/s 是 CPU 模式的 8 倍；在 Windows 上，它通过 DirectML 支持 AMD/NVIDIA/Intel 显卡，无需安装 CUDA；在 Linux ARM64 上，它启用 SVE2 指令集，让树莓派 5 的推理速度提升 40%。这种“为每块芯片写专属代码”的偏执，是它性能碾压其他通用框架的根本原因。
提示：llama.cpp 的“难用”，恰恰是它强大的证明。当你需要手动编译、手动选择 backend、手动加载模型、手动处理 tokenizer 时，你获得的是对整个推理链路的完全掌控。例如，要启用 Flash Attention 2，你必须在编译时添加
-DLLAMA_FLASH_ATTN=ON，并在运行时传入--flash-attn参数；要启用 RoPE scaling，你需要修改llama_context_params结构体中的rope_freq_base字段。这些操作在 Ollama 中是黑盒，在 vLLM 中是配置项，而在 llama.cpp 中，它们是代码本身。
实战中，我最常使用的 llama.cpp 场景是“模型验证”。当客户提出“你们说这个模型支持 128K 上下文，我们怎么验证？”时，Ollama 的num_ctx参数是模糊的，vLLM 的max_model_len可能受 PagedAttention 限制，而 llama.cpp 的--ctx-size 131072是最直接的测试手段。我曾用llama-cli加载一个 13B 模型，输入 120K tokens 的长文本（来自法律合同），然后测量最后一个 token 的生成延迟——结果是 2.3 秒，证实了其长上下文能力。这种“所见即所得”的验证方式，是其他工具无法提供的确定性。
另一个高频场景是“嵌入向量生成”。很多用户需要将文档 chunk 转为 embedding 用于 RAG。Ollama 的/api/embeddings接口返回格式不标准，vLLM 的 embedding 支持尚不成熟，而 llama.cpp 的llama-cli --embeddings命令，直接输出 float32 数组，可无缝接入 FAISS 或 Chroma。例如，对mineru2.5-pro-2605-1.2b模型，我用以下命令批量生成 embedding：
llama-cli -m ./mineru2.5-pro-2605-1.2b.Q5_K_M.gguf \ --embeddings \ --ctx-size 4096 \ --no-mmap \ --no-mlock \ -f input.txt \ -o embeddings.bin其中--no-mmap避免内存映射冲突，--no-mlock防止锁定物理内存，这些细节能让脚本在低配服务器上稳定运行数小时。这种级别的控制力，正是 llama.cpp 在专业场景中不可替代的原因。
4. vLLM：当并发量成为瓶颈时，它用 PagedAttention 重构了 GPU 显存的使用逻辑
vLLM 的诞生，源于一个尖锐的行业痛点：传统推理框架（如 HuggingFace Transformers）在高并发场景下，GPU 显存利用率极低。原因在于，它们为每个请求分配独立的 KV Cache，而 KV Cache 的大小与序列长度成正比。当 10 个用户同时提交 2048 tokens 的请求时，显存需要预留 10 × 2048 × 2 × hidden_size × sizeof(float16) 的空间，即使这些请求的中间状态并不同时活跃。这种“静态分配”模式，导致显存浪费率常超过 60%，严重制约了服务吞吐。
vLLM 的破局点，是提出PagedAttention机制——将 KV Cache 视为操作系统中的虚拟内存，引入“页表（Page Table）”概念。具体来说，它把 KV Cache 切分为固定大小的 page（默认 16 tokens），每个 page 存储在显存的任意位置；请求的 KV Cache 不再是连续内存块，而是由一组 page ID 组成的链表。当模型需要访问某个位置的 KV 时，先查页表得到物理地址，再读取数据。这个设计，让不同请求的 KV Cache 可以共享显存空间，就像多个程序共享物理内存一样。
PagedAttention 的效果是颠覆性的。在 A100 80GB 上，vLLM 相比 Transformers 的吞吐提升可达 24 倍（论文数据），而显存占用下降 45%。更重要的是，它让“长上下文 + 高并发”成为可能。例如，部署qwen3.6b模型，设置--max-model-len 32768，vLLM 可以稳定支持 50+ 并发请求，而 Transformers 在相同配置下会因 OOM 直接崩溃。这种能力，直接支撑了 Claude Code、Dify 等平台的私有化部署需求。
vLLM 的架构是典型的“服务即产品”设计。它不提供模型下载、不管理模型格式转换、不内置 Web UI，而是专注于打造一个高性能、可扩展的推理服务核心。它的部署形态高度标准化：通过vllm serve启动一个 OpenAI 兼容的 HTTP 服务，所有业务逻辑（模型加载、请求路由、日志记录）都由 vLLM 自身管理。用户只需关注几个关键参数：
--model：指定 HuggingFace 模型 ID 或本地路径（支持 HF 格式和 GGUF 格式）--tensor-parallel-size：设置 GPU 数量，自动进行模型并行切分--gpu-memory-utilization：控制显存使用率（0.9 是安全值）--enable-prefix-caching：启用前缀缓存，对重复 system prompt 场景提升显著
例如，要在 DGX A100 上部署opendatalab/mineru2.5-pro-2605-1.2b，命令如下：
vllm serve \ --model opendatalab/mineru2.5-pro-2605-1.2b \ --tensor-parallel-size 4 \ --gpu-memory-utilization 0.85 \ --max-model-len 8192 \ --enable-prefix-caching \ --port 8000这里--tensor-parallel-size 4表示将模型权重切分为 4 份，分别加载到 4 块 GPU 上，vLLM 自动处理 all-reduce 通信；--enable-prefix-caching让所有请求共享 system prompt 的 KV Cache，避免重复计算。这些参数的组合，构成了 vLLM 的“性能调优公式”。
注意：vLLM 的“冷启动问题”是用户反馈最多的问题。当服务首次接收请求时，它需要编译 CUDA kernel、初始化 PagedAttention 数据结构、加载模型权重，导致首请求延迟高达 10-30 秒。这不是 bug，而是设计权衡——vLLM 选择在启动时完成所有昂贵初始化，以换取后续请求的极致稳定性。解决方案是预热（warmup）：在服务启动后，立即发送一批 dummy 请求（如
curl -X POST http://localhost:8000/v1/chat/completions -d '{"model":"mineru","messages":[{"role":"user","content":"hi"}]}'），强制触发初始化流程。生产环境中，我通常在 Kubernetes 的 readiness probe 中集成预热逻辑，确保服务就绪后再接入流量。
vLLM 的另一个独特优势，是它对“思考模式（Thinking Mode）”的原生支持。通过--enable-chunked-prefill参数，vLLM 可以将超长 prompt 分块处理，避免单次 prefill 占用过多显存。这对于部署claude-code类模型至关重要——它们的 system prompt 动辄数千 tokens，传统框架会因 prefill 阶段 OOM 而失败。vLLM 的分块预填充，让这类模型在 1x A100 上也能稳定运行，这是 Ollama 和 llama.cpp 当前无法企及的能力。
5. 选型决策树：从 5 个真实场景出发，给出不可辩驳的推荐理由
工具选型不是学术讨论，而是解决具体问题的工程决策。下面我列出 5 个高频真实场景，每个都附上我的推荐、详细理由、避坑提示，以及可直接复用的命令模板。这些结论，全部来自我过去两年在 17 个客户现场的实操经验，没有一条是纸上谈兵。
5.1 场景一：个人知识库 + 本地 Chat UI（Windows 11 / macOS）
需求特征：用户是单人使用，需要快速上手，模型尺寸在 3B-14B 之间，对首 token 延迟不敏感（< 2s 可接受），希望有图形界面。
推荐工具：Ollama + Open WebUI
理由：Ollama 的一键安装（Windows MSI / macOS PKG）和自动硬件适配，让部署时间压缩到 5 分钟内；Open WebUI 的 Docker Compose 一键部署，完美匹配 Ollama 的 API。llama.cpp 虽然更轻量，但你需要自己编译、自己找 UI、自己配置反向代理；vLLM 则过于重型，单机部署需 Docker + Python 环境，对普通用户门槛过高。
避坑提示：Windows 用户务必关闭 Windows Defender 的实时防护，否则 Ollama 的模型文件扫描会导致ollama run卡死。在 PowerShell 中执行：
Set-MpPreference -DisableRealtimeMonitoring $true命令模板：
# 1. 下载并安装 Ollama（官网获取最新 MSI） # 2. 拉取模型（国内用户建议先设置代理） $env:HTTP_PROXY="http://127.0.0.1:7890"; ollama pull qwen3:14b # 3. 启动 Open WebUI（自动连接本地 Ollama） docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main5.2 场景二：树莓派 5 / Jetson Orin 边缘设备部署
需求特征：设备无独立 GPU 或仅有弱 GPU（如 Jetson 的 32GB RAM），内存 ≤ 8GB，需 24/7 稳定运行，模型尺寸 ≤ 3B。
推荐工具：llama.cpp（原生编译）
理由：Ollama 的 Go 二进制在 ARM64 上体积过大，且其自动 backend 切换在边缘设备上不可靠；vLLM 的 Python 依赖栈（PyTorch + CUDA）在 Jetson 上编译成功率低于 30%。llama.cpp 的纯 C 实现，编译后二进制仅 10MB，内存占用可控，且支持--mlock锁定物理内存防止 swap，保障长期运行稳定性。
避坑提示：Jetson Orin 用户必须使用--gpu-layers 35参数（针对 3B 模型），否则 CPU 模式下延迟高达 15s/token。树莓派 5 则需启用--cpu-threads 4并关闭--mmap。
命令模板：
# 在 Jetson Orin 上编译（需先安装 CUDA 12.2） make LLAMA_CUBLAS=1 -j$(nproc) # 运行模型（3B 模型，35 层 offload 到 GPU） ./llama-cli -m ./phi-3-mini-3.8b.Q4_K_M.gguf \ --gpu-layers 35 \ --ctx-size 4096 \ --temp 0.7 \ --repeat-penalty 1.15.3 场景三：企业内部 API 服务（50+ 并发，A100 80GB × 2）
需求特征：需对接公司内部系统（如 Jira、Confluence），要求 99.9% 请求在 1s 内返回首 token，支持 OpenAI 兼容接口，需日志审计和监控。
推荐工具：vLLM（Docker 部署）
理由：Ollama 的单进程架构无法水平扩展，高并发下延迟抖动剧烈；llama.cpp 无内置 HTTP 服务，需自行开发 wrapper，难以保证 SLA。vLLM 的 PagedAttention 和 tensor parallelism，是唯一能在 2×A100 上稳定支撑 50+ 并发的方案，且其 Prometheus metrics 端点（/metrics）可直接接入 Grafana。
避坑提示：务必设置--gpu-memory-utilization 0.8，避免显存碎片化；禁用--disable-log-requests，否则无法审计用户请求。
命令模板：
# Docker 部署（使用官方镜像） docker run --gpus all -p 8000:8000 \ --shm-size=1g --ulimit memlock=-1 \ -v /path/to/models:/models \ -e VLLM_MODEL=/models/qwen3-14b \ vllm/vllm-openai:latest \ --model /models/qwen3-14b \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.8 \ --max-model-len 8192 \ --enable-prefix-caching5.4 场景四：Windows 笔记本离线使用（无管理员权限，无 CUDA）
需求特征：用户在客户现场演示，笔记本无 GPU 驱动权限，需离线运行，模型需支持中文，首 token 延迟 < 5s。
推荐工具：Ollama（Portable 模式）
理由：llama.cpp 需要编译，无管理员权限无法安装 Visual Studio Build Tools；vLLM 依赖 Python 环境，离线安装 wheel 包极其繁琐。Ollama 提供便携版（Portable ZIP），解压即用，所有依赖打包在内，且其内置的 Metal/CPU backend 在 Windows 上表现稳定。
避坑提示：便携版需手动设置OLLAMA_MODELS环境变量指向模型目录，否则ollama list不显示已下载模型。
命令模板：
# 解压 portable.zip 到 D:\ollama # 设置环境变量 set OLLAMA_MODELS=D:\ollama\models set OLLAMA_HOST=0.0.0.0:11434 # 以服务模式启动（不显示控制台窗口） start /min ollama.exe serve # 在另一窗口运行模型 ollama run qwen3:7b5.5 场景五：RAG 系统 Embedding 生成（批量处理 1000+ 文档）
需求特征：需将大量 PDF/Markdown 文档切片后转为 embedding，写入向量数据库，对单次 embedding 速度要求不高，但需内存稳定、格式标准。
推荐工具：llama.cpp（CLI 模式）
理由：Ollama 的/api/embeddings返回 JSON 格式，需额外解析；vLLM 的 embedding API 尚未稳定（v0.5.3 版本仍存 bug）。llama.cpp 的--embeddings输出是标准二进制 float32 数组，可直接 mmap 到 FAISS，且其--no-mlock参数能防止内存锁定，适合长时间批处理。
避坑提示：使用--ctx-size必须 ≥ 文档 chunk 长度，否则 embedding 截断；--no-mmap可避免大文件读取时的内存映射冲突。
命令模板：
# 生成 1000 个 chunk 的 embedding（每个 chunk ≤ 512 tokens） for /f "delims=" %i in ('dir /b *.txt') do ( llama-cli -m ./qwen3-embedding-0.6b.Q4_K_M.gguf \ --embeddings \ --ctx-size 512 \ --no-mmap \ --no-mlock \ -f "%i" \ -o "embeddings\%~ni.bin" )这五种场景覆盖了 90% 的本地大模型部署需求。我的经验是：不要试图寻找“万能工具”，而要问自己“此刻最痛的点是什么”。当“快”是第一诉求，选 Ollama；当“省”是唯一指标，选 llama.cpp；当“稳”是生命线，选 vLLM。工具没有高下，只有是否精准命中你的场景。
6. 终极建议：别只盯着工具，先想清楚你要解决什么问题
写完这五千多字，我最想告诉你的，不是哪个工具参数怎么填，而是：在打开终端输入第一条命令之前，请先回答这三个问题。
第一个问题：这个模型服务，最终是谁在用？
如果是你自己，用来写周报、查资料、学编程，那 Ollama 的ollama run就是黄金标准——它把复杂性封装成一个动词，让你聚焦在“用模型解决问题”本身。我见过太多技术人，花三天部署 vLLM，结果发现每天只用两次，每次问“Python 如何读取 CSV”，这种投入产出比，远不如花 30 分钟学会 Ollama 的 Modelfile 定制。
第二个问题：这个服务的“失败成本”有多高？
如果它要嵌入到客户签约的 SaaS 产品中，一次 OOM 就意味着 SLA 违约和真金白银的赔偿，那 llama.cpp 的确定性（无 GC、无 Python GIL、无隐式内存分配）和 vLLM 的可观测性（metrics、tracing、request logging）就是刚需。此时，Ollama 的“黑盒”特性反而成了风险点——你无法预测它在什么负载下会突然重启。
第三个问题：你愿意为“控制权”付出多少时间成本？
llama.cpp 给你绝对控制权，但代价是你要懂 CMake、懂 CUDA kernel、懂 RoPE 的数学原理；vLLM 给你生产级控制权，但代价是你要学 Kubernetes、Prometheus、OpenTelemetry；Ollama 把控制权收走了，换给你的是时间——你省下的时间，可以用来优化 prompt、设计 workflow、打磨产品体验。这本质上是一种权衡：你是想当一个“模型调度员”，还是一个“AI 产品经理”？
我自己现在的做法是：用 Ollama 做 MVP 验证，用 llama.cpp 做边缘部署，用 vLLM 做生产服务。三者不是互斥，而是互补。Ollama 的ollama serve可以作为 vLLM 的备用节点；llama.cpp 的 GGUF 模型，可以一键导入 vLLM；而 vLLM 的 benchmark 数据，又能反哺 Ollama 的 backend 优化。它们共同构成了一个完整的本地大模型技术栈。
最后分享一个真实案例：上周帮一家律所部署合同审查系统。他们最初的要求是“在内网服务器上跑一个能读 PDF 的模型”。我第一反应是上 vLLM，但深入沟通后发现，他们真正的痛点是“律师不愿离开 Word 环境”。于是我放弃了所有服务化方案，用 Ollama + Python 的ollama.generate()封装了一个 Word 插件，律师选中一段文字，右键点击“AI 审查”，3 秒内返回风险点。整个项目从需求确认到上线，只用了 38 小时。工具的价值，永远在于它能否让真实的人，在真实的场景中，解决真实的问题。其他的，都是噪音。
