llama.cpp 终于发 1.0：本地推理的底座，把 35 个废弃 API 删了

要点

• 2026-11-13，llama.cpp 发布 v1.0.0（tag 时间戳 2026-11-13T10:20:19Z，prerelease: false），ggml 同步升到 v1.0.0。
• 这是一次「清理 + 转正」的破坏性版本：删掉 llama_set_warmup、35 个废弃函数、defrag_thold 与 --defrag-thold；把 NextN / 推测解码 API 从 llama-ext.h 提升进 llama.h；llama_set_embd_state_src 改名为 llama_set_ctx_state_src。
• 两个直接影响跑得动不动的核心改动：OCP FP8 KV 缓存（-ctk/-ctv f8_e4m3，可选静态 per-tensor scale）；MoE 专家缓存（moe_cache_size + moe_cache_cpu_share，LRFU/ClassLRU 替换，命中缓存的专家不让 CPU 等待）。
• 新增三个文本架构 + 一个 TTS：Kimi-K3.1-Pro（把 K3 的全注意力 MLA 层换成 DSA）、Ripple-65B-Preview（ricursive 的新 dense 65B，无新算子）、xing4_0（mHC / MLA / MoE / MTP）、drama-3 TTS（fishaudio）；视觉侧加 MageVL-Cowork 与 Kimi-K3.1。
• llama-server 补了一批安全项：SSRF、CORS、DNS rebinding、MCP 工具取消；新增 OpenAI 兼容的 /v1/audio/speech 端点与 /tts 的 temperature。
• Web UI 重做：新增会话分组与 markdown 编辑器。
• 仓库现状（2026-11-14 实取）：134,878 stars、最近 push 2026-11-13、许可证 MIT。
• 取证说明：官方 Release 里指向的 Hugging Face 博客（huggingface.co/blog/ggml-org/llama-cpp-v1）在本站网络下请求失败（HTTP 000），本次未能读取。以上全部来自 GitHub Releases 官方原文，不含博客里的设计动机叙述。

背景与分析

llama.cpp 用 b#### 这种构建号发版发了好几年，跳到 v1.0.0 本身就是个信号：它不再把自己当「实验性推理实验」，而是当「本地推理的基础设施」。

1.0 干的三件事，正好对应「从实验走向基础设施」的三个必需动作。

第一，把欠账清掉。 删掉 35 个废弃函数、llama_set_warmup、defrag_thold，这不是「顺手清理」，而是给下游一个明确的契约重置点：1.0 之前的弃用警告可以永远挂着，1.0 之后必须删——否则「稳定 API」这句话就没有意义。代价是所有绑了这些符号的项目（各种语言绑定、GUI 封装、推理服务）都要改一次代码。升级前先 grep 一遍你的依赖树。

第二，把最好的东西转正。 NextN / 推测解码 API 从 llama-ext.h 提到 llama.h，意味着它从「扩展实验」变成了「一等公民」。推测解码是本地推理最划算的加速手段之一（用一个小模型起草、大模型验证），把它放进主头文件，等于告诉生态：这东西该被默认支持了。

第三，攻硬件现实。 这两条是本次对普通用户最有感的：

第二条尤其实在。2026 年的开源大模型主流是 MoE——总参数动辄几百 B，激活只有二三十 B。理论上你只需要激活部分的算力，但权重得放下。moe_cache_cpu_share 给的是一个显式的旋钮：允许多大比例的专家权重躺在 CPU 内存里，miss 的时候走 CPU。再加上「命中缓存的专家不让 CPU 等待」这条优化，说明他们认真处理了「显存/内存两级缓存被打穿」时的停顿问题。

更值得注意的是 llama-server 补的那四项安全项：SSRF、CORS、DNS rebinding、MCP 工具取消。

这四个词放在一起，指向一个很具体的事实：llama-server 已经在被当生产服务跑，而且它带着 MCP 工具调用能力。一旦服务器能调工具，SSRF 就从「理论风险」变成「模型可以被诱导去访问内网地址」；DNS rebinding 则让「只允许访问白名单域名」这类防护形同虚设。这些不是 Web 框架的通用问题，是「让模型决定访问哪个 URL」这件事特有的问题。

对开发者的影响

• 升级前必做一次符号扫描：llama_set_warmup、35 个废弃函数、defrag_thold、llama_set_embd_state_src。尤其是自己写 C/C++ 绑定或用 Go / Rust / Python 封装的团队——上游删符号，绑定层编译就断。
• 长上下文场景优先试 FP8 KV。做法很直接：-ctk f8_e4m3 -ctv f8_e4m3。收益是 KV 缓存显存减半，代价是精度；建议用你的真实任务对比一遍输出质量，别只看能不能跑起来。静态 per-tensor scale 如果能拿到校准值，精度损失会更小。
• 消费级硬件跑 MoE 的调参顺序变了：先设 moe_cache_size 定缓存总量，再用 moe_cache_cpu_share 定「多少比例允许落 CPU」。这条路径比过去的 --n-cpu-moe 粒度更细，值得重测一遍你最常用的模型。
• /v1/audio/speech 是个被低估的改动。这意味着本地跑 TTS 也有了 OpenAI 兼容端点——任何按 OpenAI 音频接口写的客户端，改个 base URL 就能指向本地。配合 drama-3 TTS，本地语音链路（转写 + 合成）现在可以完全不依赖外部 API。
• 暴露 llama-server 到网络之前，先做三件事：① 确认版本 ≥ v1.0.0（SSRF / DNS rebinding 修复在此）；② 前面加一层带鉴权的反代——它本身不是网关；③ 如果开了 MCP 工具，逐个审工具的目标 URL 白名单，别指望模型不被告诱导。
• 想找官方「为什么发 1.0」的叙述，本次拿不到：那篇设计博客在 Hugging Face 上，本站网络请求失败。需要完整动机说明的读者请自行访问（见来源第 2 条）。

AI 之家 观点

llama.cpp 发 1.0 这件事，放在 2026 年 11 月这个时间点看很有意思：同一个月里，Anthropic 在把 Agent 控制面搬进企业机房，Google 在用网关跨云管 agent，各家大厂都在往「企业可控」上加码。而另一条线上，本地推理的底座悄悄毕业了。

这两条线最终会撞在一起。因为「企业可控」最好的答案，往往不是「自托管控制面 + 云端模型」，而是模型也本地跑——只不过过去这条路被「跑不动」挡住了。FP8 KV 缓存、MoE 专家 CPU 份额、推测解码转正，这三个改动合起来，把「跑得动」的门槛又往下压了一档。

AI 之家 推荐结论：如果你在评估「私有化部署」方案，现在应该把 llama.cpp v1.0.0 当基准重新算一遍账。判断顺序建议是：① 你的模型是不是 MoE——是的话先试专家缓存，收益最大；② 上下文是不是超过 32K——是的话先试 FP8 KV；③ 你是不是要靠它对外提供服务——是的话必须补网关层，别把 llama-server 直接暴露。

一句提醒给所有做本地部署的人：1.0 的破坏性比版本号看起来大。它不是「终于稳定了所以随便升」，而是「我们清了一次场，从现在开始才是契约」。升级前跑一遍完整回归，尤其是自己写绑定层的那部分。

相关阅读

• 本地部署工具卡：Ollama · LM Studio · vLLM · Jan
• 概念：MoE · 长上下文 · BYOK · 量化与 LoRA · Prompt 缓存
• 模型：Ripple 65B Preview · Kimi K3.1 Pro
• 同期：Ling 3.2 Flash 免费上架 OpenRouter

来源

• { title: "llama.cpp v1.0.0 Release（官方原文，含 API 变更、新架构、FP8 KV、MoE 专家缓存、server 加固逐条；tag 时间戳 2026-11-13T10:20:19Z，prerelease: false）", url: "https://github.com/ggml-org/llama.cpp/releases/tag/v1.0.0" }
• { title: "ggml-org 官方博客《llama.cpp v1.0》（Release 正文指向，本次请求 HTTP 000 未能读取）", url: "https://huggingface.co/blog/ggml-org/llama-cpp-v1" }
• { title: "GitHub Repos API：ggml-org/llama.cpp（stars 134,878 / pushed 2026-11-13 / MIT，2026-11-14 实取）", url: "https://github.com/ggml-org/llama.cpp" }