作者 |路飞

来源 | 至顶AI实验室

最近追开源模型，我养成了一个习惯：新模型发布当天先不急着下载，先去看看 llama.cpp 有没有跟上。参数量决定模型有多大，推理引擎决定它能不能在手边这台电脑上正常工作。

7 月 13 日凌晨，llama.cpp 的发布页排到了 b9982。往前翻到 b9973，10 次更新挤在不到 12 个小时里。先说明这组数字的性质：llama.cpp 不发版本号，每合并一个提交就自动打包一次，构建号加一。也就是说，这 10 次更新不是一次冲刺，而是这个项目每一天的常规节奏。这 12 个小时里，并没有任何新模型发布。

一天 10 次更新，忙的是三件事

第一件是追模型。DeepSeek V4 用了新的压缩注意力结构，思路是先由一个轻量索引器挑出值得关注的重点 token，再在压缩过的 token 序列上做注意力。模型结构里出现新算法，旧引擎不认识，权重下载到本地也无法按原设计执行。V4 发布后，社区先在好几个 fork 里各自抢跑移植，上游支持随后合入；这轮更新里的 b9973 又调整了它的缓存管理——清理时只清指定序列，不再整个清空。支持一个新架构从来不是合入那一下的事，之后还要接着磨。Qwen 那边同样如此：Qwen3.6-27B 发布后 24 小时内，社区就放出了能把权重体积再砍一半的新量化版本。

第二件是磨硬件。b9974 处理了一个多卡用户会撞上的崩溃：某张 CUDA 卡的显存已经被其他程序占满时，启动阶段查询显存这个动作本身就会触发显存不足，程序直接退出。修复后，这张卡会被记为零可用内存，装载算法自动跳过它，程序照常启动。b9976 修正了多卡张量切分方式不受支持时的提示信息。这类改动不会出现在任何跑分里，却决定一台配置不那么标准的电脑能不能把模型跑起来。

第三件是补 Agent 接口。b9977 修复了一个多模态漏洞：工具返回截图时，图片会在 Anthropic 和 OpenAI 两种消息格式的转换中被静默丢弃，模型后面的判断就缺了依据。b9979 解决了消息里混入空字符、提示词被悄悄截断的问题。b9982 让推理预算——即限制模型在正式回答前最多“思考”多少 token 的设置——真正按每次请求生效，此前服务端会忽略请求里带的值，只认服务器默认值。聊天场景里这些都是小事；代码助手和 Agent 连续调用模型几十次，每个小问题都会一路传导到后续步骤。

这三件事，对应普通用户的三堵墙：装不上、跑不快、接不稳。

一个 GGUF 文件背后，还有三笔内存账

游戏里的扫描器，变成 AI 摄像头

很多人是在模型站下载 GGUF，再用 LM Studio 打开；用 Ollama 拉取模型的人，长期以来跑的也是 llama.cpp 一系的引擎。LM Studio 官方文档写明，它加载 GGUF 时使用基于 llama.cpp 的引擎。界面里的一次点击，背后是量化格式解析、内存分配和 CPU、GPU 调度。

GGUF 把模型参数、分词器和运行信息放在同一套文件格式里。量化再把参数从较高精度压到 8-bit、6-bit、5-bit、4-bit，甚至更低。位数降低后，文件和内存占用通常缩小，模型质量也可能跟着下降；同一种量化放到不同硬件上，速度差异还会很大。

算配置时至少要留出三块空间：

权重这笔账可以粗算：参数量乘以位宽再除以八。30B 模型用 4-bit 量化，权重就在 15GB 上下；社区实测里，27B 级模型的 Q4_K_M 文件约 17GB。KV Cache 是弹性的一笔，聊天记录和文档越长，占用越高。所以 15GB 的模型文件，并不等于 16GB 显卡一定装得下。

显存不够，llama.cpp 可以把部分模型层放在系统内存，由 CPU 和 GPU 分担。模型有机会跑起来，速度取决于内存带宽、显卡带宽和两边的数据传输。容量解决的是能不能装下，带宽决定等待多久。

12GB 的 4070，从 30B 跑到 35B

这三笔账落到真机上是什么样？今年年初，量化作者 steampunque 在 llama.cpp 官方讨论区分享过一套很具体的配置：RTX 4070 12GB，加一颗 i9-9900K，运行 Qwen3-VL-30B-A3B-Instruct 的混合精度 GGUF。上下文开到 32K，KV Cache 使用 Q8_0，生成速度约 27 tokens/s。

30B 模型塞不进 12GB 显存。他把一部分 MoE 专家层交给 CPU，另一部分留在 GPU；自制的混合量化又把权重占用压到大约只有 Q8_0 的一半。A3B 里的“3B”也很重要：模型总参数是 30B，每次生成只激活约 3B，CPU 分担专家层才不至于慢到不能用。

这条思路没有停在年初。3 月底的另一条讨论里，有人用同一档的 4070 12GB 跑起了更新的 Qwen3.6-35B-A3B：动态 4-bit 量化，34 层专家放在 CPU，KV 同样用 Q8_0，上下文撑到 23 万 token 以上时，生成速度仍有每秒 35 到 40 个 token。硬件没换，模型换了一代，切分方式跟着引擎参数一起调，原本装不下的模型就一直有运行空间。

同一个模型，为什么有人跑得快，有人跑得慢

不过，这两组数字来自两台机器、两套参数，直接横向比较没有意义。看懂本地模型的速度，先要把它拆成两段。它先把问题、文档和历史对话读进去，这叫 prompt processing；读完以后，答案才开始一个 token 一个 token 地生成。前一段影响首字等待时间，后一段影响回答出现得快不快。

前面两条 4070 案例报的主要是生成速度，3 月那条只顺带提了一句读入速度比较稳定，没有给长文档的具体成绩。以后再看到“每秒多少 token”，至少要先问一句：说的是读入，还是生成？

量化版本、上下文长度、装进 GPU 的层数、Flash Attention、KV Cache 放在显卡还是内存，都会改掉最后的速度。4K 上下文和 64K 上下文的负担不在一个量级，CUDA 和纯 CPU 也不是一种跑法。

硬件再往下分，还有后端的差别：NVIDIA 走 CUDA，苹果用 Metal，AMD、Intel 和高通各有各的接口。后端没有跟上，轻则跑得慢，重则模型根本起不来。

聊天能用，只是最低门槛

llama.cpp 自带 llama-server，能把电脑里的模型开放成 OpenAI 兼容接口。原来调用云端模型的软件，换成本地地址就能继续工作。

它支持同时处理多个请求，能运行向量模型和重排模型，可以限制模型按 JSON 格式输出，也支持推测解码。做本地文档问答时，可以先用向量模型从资料库里找内容，再用重排模型挑出最相关的几段，最后交给大模型写答案。整个过程不用把文件发到云端。

代码助手和 Agent 对接口要挑剔得多。它们不只要文字，还会把网页截图、图表和工具结果塞回模型，并要求推理预算、输出格式按每次请求精确执行。这轮 10 次更新里，服务端和接口相关的改动占了 6 条，压力来自哪里，一目了然。

llama.cpp 也不是每台机器的唯一答案

llama.cpp 的长处是覆盖面广：从纯 CPU 到各家 GPU 后端都有现成的构建，前面那套 CPU、GPU 混合分担的打法也是它的招牌。对 GGUF、本地单机和消费级硬件来说，它通常是最容易遇到的一条路线。

苹果芯片用户还会遇到 MLX-LM。它由 Apple 的 MLX 生态提供，专门用于 Apple silicon 上的大模型生成和微调，也支持量化。手里是 Mac，模型已经有成熟的 MLX 版本，没必要只盯着 GGUF。

如果目标是让很多人同时调用一台 GPU 服务器，vLLM 更偏向高吞吐推理和在线服务。今年 4 月有团队在两张 16GB 消费卡上，用同一个 27B 模型对跑过这两个引擎：高并发下 vLLM 的吞吐量高出三到四倍；换成 4 万多 token 的长文档，llama.cpp 能完整服务，vLLM 在同样硬件上的上下文上限则停在 16K。全部使用 NVIDIA GPU、要把单一硬件榨到极限，还有 TensorRT-LLM。它们解决的任务不同，不能只用单人聊天时每秒多少 token 排高低。

“卷”在哪里：都想挤进这份构建列表

回头看 llama.cpp 每次发布附带的下载列表，能读出另一层信息：macOS、iOS、Windows、Ubuntu、Android 之外，同一份代码还同时打包出 CUDA 12 和 13、Vulkan、ROCm、OpenVINO、SYCL、HIP 的版本，甚至有面向高通 Adreno 的 OpenCL 版本和 IBM 大型机的 s390x 版本。Intel、AMD、高通的名字，都以后端的形式出现在这份官方列表里。

原因不复杂。这个由 Georgi Gerganov 发起、如今由 ggml-org 社区维护的项目，在 GitHub 上积累了约 12 万 star，是 GGUF 格式事实上的标准运行时。模型这头，DeepSeek V4 那样的移植接力隔三差五就来一轮；硬件这头，芯片厂商把自家后端的适配和优化提交进来；应用这头，LM Studio、Ollama 们在它之上争夺用户入口。三方都在往同一个项目里使劲，因为不在这份构建列表里，就不在本地 AI 的牌桌上。标题里那个“卷”字，卷的是这个位置。

装新模型前，我会按这个顺序看

先在 llama.cpp 的发布记录和 issue 里搜模型名，确认架构、特殊算子和聊天模板是否已经适配。能下载权重，不代表当前引擎已经完整支持。

再选量化文件。4-bit 常被用作容量和质量之间的起点；2-bit 更省空间，质量损失和硬件支持要单独确认。随后把模型权重、KV Cache 和缓冲区一起算进内存，长文档场景还要额外留余量。

最后看用途。只在 LM Studio 里聊天，文字生成稳定就够了；做本地资料库，要继续检查向量模型和重排模型；接入 Agent，还要看多模态、工具调用、结构化输出和接口兼容。

llama.cpp 的更新记录里很少有醒目的大功能，却能看到本地 AI 每天卡在哪里，也能看到有多少人在乎这件事。新模型发布只是起点，是这些日复一日的小修小补，把模型站里的一个文件磨成一套能长期使用的工具。本地 AI 真正的竞争，就发生在这个过程里。