ggml-org/llama.cpp

解决什么问题

想在自己的硬件上跑大模型，常规做法是装一套 Python 环境、一个大框架、一套 CUDA 工具链，再加上只被单一技术栈认识的模型格式。这套东西在一台配置齐全的 Linux 机器上能用，换到旧笔记本、Mac、手机、带消费级显卡的 Windows 机器，或者只有半张卡的云主机上就散了。llama.cpp 要解决的就是把推理变成一个真正能跑起来的小体积可移植程序。

有什么不同

它是基于 ggml 的 C/C++ 推理实现，各后端是手写 kernel，而不是通用张量运行时外面套一层兼容层。真正拉开差距的有三点。第一，量化到很低位宽（README 写明支持 1.5 到 8 bit 的整数格式）是设计目标本身，不是补丁，这是大模型能塞进小显存的原因。第二，单一代码库覆盖的后端异常地广：CUDA、HIP、Metal、Vulkan、SYCL、WebGPU，还有若干 NPU 目标，并且支持 CPU+GPU 混合推理来跑超出显存的模型。第三，自带 CLI 和 OpenAI 兼容的 server，现有客户端改个地址就能用。

和 vLLM 比，取舍很清楚：vLLM 面向服务器 GPU 上的吞吐，对笔记本和骁龙手机兴趣不大。和 Python 的 transformers 加 bitsandbytes 比，llama.cpp 牺牲了灵活性和试新模型的便利，换来速度和可移植性。和直接调托管 API 比，你放弃模型质量和零运维，换回隐私、没有按 token 计费、不依赖网络。

适合谁

适合那些必须让推理跑在自己已有或能低价租到的硬件上的人：在桌面或移动应用里嵌入本地模型的开发者、数据不能外发的团队、边缘和嵌入式部署，以及用 Mac 做原型的人。小型自托管服务器、只有几个并发用户，也是合理选择。

如果你要做高吞吐的多租户服务、需要大规模连续批处理，或者需要长期稳定的 ABI，就别用。README 自己链了一个关于 lib llama API 的 open issue，说明库接口还在变。如果你的模型是上周刚发布的小众架构，也要等移植。

上手成本

MIT 协议，法律层面基本没障碍。安装确实轻：README 给了 curl 脚本（curl -LsSf https://llama.app/install.sh | sh）、PowerShell 一行命令、Docker、预编译 release 包和从源码构建几种方式。真正的成本在运维：GGUF 模型文件要自己挑、自己管，量化等级要自己选，GPU offload 层数要手动调到刚好塞进显存。带 GPU 后端的构建需要对应的厂商工具链，而且后端表里还有几个目标标着进行中。项目迭代快，有 nightly 也有正式 tag，建议锁版本而不是跟 master。

点评

这不是一个靠热度冲起来的新项目：2023 年 3 月创建，至今 1,300 多天积累到 132k stars、约 24.7k forks，最近上榜期间每天只涨 106 到 111 颗星，属于成熟项目正常的维护期关注度，而不是炒作。更有分量的信号是 ggml.ai 加入 Hugging Face 的公告（HN 839 分）——对一个最大的风险始终是维护者倦怠的项目来说，这是机构层面的背书。做本地推理，它基本是默认选项；不用它的主要理由只有一个：你要的是数据中心级服务吞吐，而不是可移植性。