VLLM

跑一个大模型到底有几种跑法？从 llama.cpp、Ollama 到 vLLM 的三条路 本文回答一个看似简单的问题：「我想在本地跑个大模型」——然后呢？这三个 GitHub 上最火的推理项目，其实回答的是三个完全不同的问题。 周末折腾本地大模型的人，大概率经历过这个场景：搜「本地跑 LLM」，GitHub 推荐给你 llama.cpp、Ollama、vLLM 三个项目，Star 数加起来四十多万。打开 README 都是「高性能推理」，看起来互为竞品。 但我研究完这三个项目的架构后，结论是：**它们根本不是竞品，是三条不同的路，解决三个不同的问题。**选错工具不是性能差一点的问题，是方向错了。 三个项目，三个问题 先把结论摆出来： 项目 回答的问题 服务对象 优化目标 llama.cpp 「我的笔记本/手机能跑吗？」 单个极客 单请求延迟、硬件可及性 Ollama 「我只想跑，不想折腾」 所有人 上手门槛（降到一条命令） vLLM 「一块 GPU 怎么服务上千用户？」 生产 API 服务 多请求吞吐 注意看第三列——llama.cpp 和 vLLM 的优化目标甚至是对立的。一个恨不得为单个请求榨干每一毫秒延迟，一个恨不得把一千个请求塞进一个 batch 里摊薄成本。这两个目标天然冲突，所以它们不可能是同一个工具的两种实现。 llama.cpp：把 LLM 从数据中心拽到你的笔记本 llama.cpp 的故事从一个意外开始：2023 年初 LLaMA 权重泄露，作者 Georgi Gergashev 四天内拿出了原型。这个「时机比技术重要」的案例后来被反复引用，但真正让这个项目活下来的是架构决策。 它做了一个关键分层：底层是 ggml 张量库（算子、内存管理、多后端抽象），上层是 llama 推理引擎（模型定义、KV Cache、采样、API）。最大的亮点是多后端抽象——同一套 ggml API，底下可以是 CPU（AVX2/AVX512/NEON）、CUDA、Metal、Vulkan、SYCL、HIP，还支持 CPU+GPU 混合推理（-ngl 指定丢给 GPU 的层数）。你 MacBook 上跑 Metal、Linux 服务器上跑 CUDA、安卓手机上跑 NEON，代码是同一套。 ...