llama.cpp 在 2026 年下半年的进展，可以分成几条同时推进的线：项目本身发布了首个正式版本，主线持续合入新模型，硬件后端从苹果芯片、Windows NPU 一直铺到旧款数据中心卡和非标准设备，而显存与上下文的优化手段也从前端配置下沉到 KV 缓存和内核层。与此同时，围绕项目归属的传闻和第三方竞品的实测对比，让它的技术路线多了一层不确定性。
最基础的信号是版本与模型接入。llama.cpp 发布了 v0.1.0，这是这个本地运行大语言模型工具的首个正式版本，关注本地部署的用户可以据此跟踪后续功能更新 [9]。主线方面，Ling-3.0（BailingMoE3）通过 PR #26608 正式合入主分支，从 build b10472 开始可以不用云端直接本地运行，8B 的 tiny 和 127B 的 flash 两个尺寸都有社区放出的 GGUF imatrix 量化文件 [12]。新模型的跟进并非总是同步，Qwen3.8-27B 模型卡上线时，llama.cpp 用户还在确认当前版本能否完整支持，GGUF 格式可能要再等等 [16]。
硬件覆盖面的扩张是这一阶段最明显的变化。苹果芯片上运行 llama.cpp，LLM 推理速度可以提升 11 到 16 倍，用虚拟机跑推理的开发者不用额外调整硬件配置就能直接用上 [1]。Windows 侧新增了 Windows ML 支持，开发者可以更快在 GPU、NPU 和 CPU 上试验并部署新型开源模型 [3]。CPU 路线也没有被落下，1.7B 参数的 Qwen3 TTS 四 bit 量化版本配合 llama.cpp，纯 CPU 就能快速生成零样本语音克隆 [5]。
在非英伟达显卡和旧硬件上，llama.cpp 的支持程度直接决定了这部分用户能不能跑本地模型。目前它支持 AMD 的 ROCm 接口和 Vulkan，非英伟达显卡跑本地模型主要靠这两条路 [2]。针对约 80 美元的 Tesla P100 的内核优化项目，把 decode 速度从空上下文时的 7 到 15 tps 提升到 50 到 60 tps，260k 上下文时从 2 到 4 tps 提升到 30 到 35 tps，prefill 从 220 tps 提升到 350 tps [13]。12GB 显存的 Intel Arc B580 上，Ling-3.0-tiny 的 Q8_0 量化版在 16384 上下文下 prompt 处理 120.76 token/秒、生成约 114 token/秒，配合把 KV 缓存压到 8 位，完整 128K 上下文跑得动 [12]。更边缘的场景也有落地案例，llama.cpp 已经能跑在越狱的 PS5 上，原生运行任意 GGUF 模型 [15]。
跨厂商混合 GPU 是另一个被 llama.cpp 的构建方式打开的方向。Infermeld 不是新的推理后端，它的做法是让用户按文档编译指定版本的 llama.cpp，AMD 显卡走 Vulkan、NVIDIA 显卡走 CUDA，由启动参数指定哪张卡承担哪部分，测试硬件是一对 AMD RX 6900 XT 16GB 加 NVIDIA RTX 3080 10GB [11]。更激进的配置出现在单个 llama.cpp 进程里：AMD Ryzen AI MAX+ 395 的统一内存侧走 Vulkan、通过 eGPU 连接的 RTX 3090 Ti 走 CUDA，一个 27B 模型跨两者切分，代码类生成在 32K 上下文下达到 153.32 tok/s，200K 上下文下 87.74 tok/s [8]。
软件优化方面，最直接的收益来自 KV 缓存量化和投机解码的组合。在 16GB 显存的 RTX 5060 Ti 上跑 Qwen 3.8 27B，主上下文的 KV cache 用 q4_1 量化、MTP 草稿上下文用 q5_1，同时打开原生 MTP 投机解码，73k 上下文能塞进 16GB [7]。RTX 3090 的社区分支则采用编译时开启 all-quants、KV 缓存改用 q8_0 和 q5_1 的方案，在 262144 上下文下速度能到 85 TPS [17]。这些配置的共同逻辑是把缓存数据存成更低精度省出显存，再让草稿模型先生成候选 token、主模型批量验证来提升吞吐 [7]。
有些优化的效果超出了对 GPU 本身的调优。在一组记录了 159 次实验的测试里，把层放置、KV 格式和 llama.cpp 本身当作实验变量逐一调整后，真正起作用的因素中排在前面的是聊天模板：换用更简洁的 Qwen-Sharp 模板后，实际耗时减少 44%，输出 token 减少 51%，精度没有变化，效果比几周的 GPU 调优还大 [8]。这说明在引擎已经相对成熟的阶段，提示与模板层的开销开始成为可观的速度来源。
KV 缓存的控制粒度也在被第三方分支推进。focus-llama 给原版 llama-server 加了新接口，能在 prefill 中途或之后丢弃请求的 KV token 范围，默认模式下客户端先把文档分块，服务器解析模型吐出的第一个 focus 标签后把其他块丢掉，这个动作一次性、单向 [10]。但底层限制仍然明确：llama.cpp 目前没有 vLLM 版本里那种分页块表，单纯掩码并不会减少实际读取的 KV 数据量，从源码看 CUDA 上的单 token 解码现在也不会跳过被掩码的块，所以实际能加速多少要看后续内核层优化 [10]。
生态层面的变量同样影响技术路线。有消息称英伟达可能收编 llama.cpp 及其团队，担心集中在放慢更新节奏、把员工调去别的项目，甚至通过修改许可证收紧控制；对用 AMD 显卡或集成显卡的用户来说，最直接的担忧是 ROCm 和 Vulkan 这两条支持路径被去掉 [2]。项目还有一层保护，llama.cpp 采用 MIT 许可证且没有贡献者许可协议 [2]。竞品对比也在给出参照：Uzu 针对 Apple Silicon 优化，在 M5 上测试速度达 92 token/秒，比 llama.cpp 快 4 倍 [6]；NInfer 依靠 MTP3 投机解码把速度拉到 llama.cpp 的 1.4 到 4.9 倍且质量持平，同时指出 llama.cpp 的并行数被锁在 parallel=1、上下文窗口为 196K [19]。社区分支的归属也尚未解决，针对特定显卡优化的仓库仍是独立形态，没有并入上游 [17]。多引擎运行时则把 llama.cpp 作为兼容后端之一，例如 Lemonade 同时支持 llama.cpp、Ryzen AI SW、FastFlowLM 等引擎 [20]。