2026 年 11 月 13 日，UTC 上午 10 点 20 分 19 秒，llama.cpp 打了 v1.0.0 这个 tag。
47 秒之后，b12359 上线。
13 小时 47 分之后，编号走到 b12374。这中间一共 12 个 b 系列构建。
【本人未实测】下面所有版本号、时间戳、改动条目，来自 GitHub 上 ggml-org/llama.cpp 的 release 页面和 API 返回。v1.0.0 的完整 release notes 我读了，标题为「llama.cpp v1.0.0: A stronger foundation for the local AI ecosystem」的那篇官方博客，页面是 JS 渲染的，我只拿到标题，正文没读到。IT之家 11 月 14 日的报道我读过。
1.0.0 里到底有什么
release notes 写得像一张工单。我按它的分节往下抄。
接口层面：删掉了 llama_set_warmup，删掉 35 个标记为废弃的函数，删掉 defrag_thold 参数和对应的命令行选项。
NextN 相关的推测解码接口，从 llama-ext.h 提到了 llama.h。还有个叫 llama_set_embd_state_src 的函数，改名成 llama_set_ctx_state_src。
缓存和内存：加了 FP8 的 KV cache，命令行是 -ctk 和 -ctv 接 f8_e4m3，可以选择给每个张量配固定的缩放系数。
MoE 的专家缓存能放在主机内存里，CPU 占用比例可调。淘汰策略用了 LRFU 和 ClassLRU。命中缓存时不再等 CPU。
外部 PLE shard 可以从独立的 GGUF 文件加载，对应 --shard 和 --ple。
新模型：三个文本架构，Kimi-K3.1-Pro、Ripple-65B-Preview、xing4_0。一个语音，drama-3 TTS。两个视觉，MageVL-Cowork 和 Kimi-K3.1。
服务端：加固了 llama-server，涉及 SSRF、CORS、DNS 重绑定和 MCP 工具取消这四类问题。新增了兼容 OpenAI 格式的 /v1/audio/speech 接口。Web 界面重做了一版，加了群组对话和 markdown 编辑器。
其他：Windows 上的模型加载改成无缓冲模式，对齐 Linux 的 DirectIO 路径。ggml 一并升到 1.0.0。
就这么些。没有一条是革命性的。
真正变了的是版本号
IT之家 的报道里贴了官方给的版本规则，三档。
主版本号升级，条件是 ./include 里的公共 C 接口出现破坏性变更。次版本号升级，是加了向后兼容的功能、后端更新、模型支持或新接口。修订号升级，是不改变接口的 bug 修复。
【个人看法】这三行比前面那一堆改动都重要。
以前你知道的版本号长这样：b12374。这个号告诉你它是第几个构建，仅此而已。兼容不兼容、能不能直接换，全得自己试。
现在你能从 1.0.0 这个号上读出边界：主版本不变，接口不动。
代价也写在 release notes 里。35 个废弃函数被删了。如果你的代码调过其中任何一个，升上去就编译不过。
这不是 bug，是设计。1.0.0 明确说了主版本号就是用来标破坏性变更的。但如果你只是顺手把版本号往上改一改，可能会撞一堵墙。
为什么用了三年八个月
仓库建在 2023 年 3 月 10 日。到 v1.0.0 是 1343 天，三年八个月。
现在的数字是：13.4 万 star，2.5 万 fork，2598 个没关的 issue。
这不是小项目。
【个人看法】这三个数字放在一起，反而比单独看任何一个更有意思。13.4 万 star 说明用的人多，2598 个未关 issue 说明它不是「做完了」。它一直是个工地，而且人很多。
IT之家 那篇的标题用了「史诗级更新」。
我看完 release notes 之后的感受不太一样。它更像一份工程清单。有几条是删旧的，有几条是补新的，还有服务端加固和界面重做。
每一条都不大。加起来是一次长跑的阶段性收口。
【个人看法】「史诗级」这个说法，我保留意见。
47 秒那个细节说明了什么
如果 1.0.0 是一次大版本更新，你大概会期待它之后安静一段时间。
事实是 47 秒后又出一个。
而且这不是特例。b 系列的编号现在排到 12374。按 1343 天算，平均一天接近 9 个构建（这个数是拿编号除以天数推的，中间可能有跳号，我没有逐个点开数）。
【个人看法】所以 1.0.0 的真实含义，我的理解是：给这套滚动节奏加了一把标尺，不是给节奏踩了刹车。
它让外面的人第一次能从版本号判断兼容性。仅此一点，对靠这个库做产品的人来说，价值就不小。
但它也意味着，如果有人以为「1.0.0 等于稳定版，之后不会变了」，这个期待会落空。
那些我没核实的
先说模型架构数量。IT之家 写的是「超过 150 种模型架构变体及主流推测解码方法」。我在 release notes 里没有找到这个数字，GGUF 那边的统计口径我也没查。【暂无相关资料】
这个 150 指的是架构种类还是模型数量，我分不清。
CI 那块也一样。公告提到三件事：用 Hugging Face 的 HF Buckets 和 HF Jobs 扩测试基础；在 NVIDIA、AMD、Qualcomm、Arm、IBM、Intel 六家提供硬件的前提下，增加自托管测试运行器；在开发流程里审慎使用 LLM。
【个人看法】第三件事我觉得挺有意思。
一个专门用来跑大模型的项目，说自己在开发流程中「审慎使用 LLM」，同时把代码质量和对实现细节的理解放在首位。
具体怎么个审慎法，公告只有这一句，没有细节。【暂无相关资料】
六家芯片厂商给测试硬件这件事，覆盖哪些卡、多少台，公告也没写。
本地跑大模型这件事，变了什么
llama.cpp 的定位一直很朴素：让大语言模型能在个人电脑、服务器这些设备上跑起来。它主要用 C 和 C++ 写，既可以本地部署，也可以做云端服务。
这次有个改动值得单独说。后端可以编译成动态库，运行时按需加载。
意思是，换一种硬件后端，不用重新编整个程序。
【个人看法】这个改动听起来不性感，但它决定了这个项目能不能继续长大。后端越加越多，全靠编译期解决，最后没人编得动。
至于普通用户，其实感受不到这些。你用的多半是某个 GUI 客户端，它把 llama.cpp 包在里面。1.0.0 之后要等那些客户端跟上，你才会在日常界面里看到变化。
要不要升级
分两种人。
你用现成的 GUI，那就等。等它把 1.0.0 吃进去，你什么都不用做。
那 35 个被删的函数，跟你没关系。
你自己编译，或者手里有基于 libllama 写的程序，那就先做一件事：搜一遍代码里有没有 llama_set_warmup、defrag_thold 这些被删掉的名字。有，就先别动。
我没有任何实测数据说 1.0.0 比之前的 b 版本快多少。release notes 里也没给性能数字。【暂无相关资料】
它这次卖的不是速度。
你平时跑本地模型用什么？自己编译，还是装现成的客户端？评论区说一声，我看看大家卡在哪一步。