llama.cpp 用提交数当构建号，每天出 nightly，出了三年半，直到 11 月 13 日才有了第一个正式版本号 v1.0.0。发布说明里最要紧的不是版本号本身，而是一个直接改变日常玩法的东西：一块 24G 显存的显卡，现在能跑 93.7GB 的模型了。知乎小红书
现在能本地跑的大模型基本都是 MoE 结构：总参数很大，每次生成只激活一小部分专家。PR 里举例的 Qwen3.8-Flash-Next Q4_0，模型文件 93.7GB，光专家权重就占 65.4GB，24GB 显存装不下。以前的凑合办法是按层切、把一部分专家扔给 CPU，但专家调用并不均匀，整层往显存里搬，难免混进很少用到的专家。知乎
10 月初合入的一个补丁换了思路：专家权重全部留在主机内存，GPU 划出一小块显存当专家缓存（–moe-cache-mib 指定大小），逐字输出的解码阶段才启用。贡献者自测：这个 93.7GB 的模型，缓存方案只需把 10.7GB 专家放进显存，比按层切的 16.5GB 还少，速度反而快六成，命中率 77%——被频繁调用的专家，其实集中在一小部分。知乎
显存的思路从“装模型”变成“装热数据”，和 CPU 的 L2 缓存一个道理。前提是机器内存放得下全部专家，一般要配 64 到 128GB 内存。上面这些数字都来自贡献者自测，换模型、CPU 或 PCIe 代数结果都会变，不能直接抄。
回到 1.0 本身。它的实际承诺是稳定：以后破坏 API 的改动，只在主版本号出现。客户端、绑定库这些下游，以前不敢把它当稳定地基，现在大版本号一跳，才代表接口真的动了。这次一并进来的 FP8 KV 缓存倒是得降温期待：每个数还是占一个字节，和 q8_0 同个体积档位，显存不会减半，它的价值在对上 NVFP4 这类模型的量化口径，给原生 FP8 计算留接口。知乎小红书知乎
升级前，先注意两个坑
–defrag-thold 被删了。不少人从老教程抄的启动脚本里还留着这行，新版会直接报 invalid argument 退出，模型还没开始加载。同一个参数写在环境变量里却是另一种情况：新版默默忽略，服务照常起来，所以两处都得查。知乎
llama-server 的安全默认也收紧了：以前绑 0.0.0.0 让局域网连、同时开着工具调用，旧版只打警告，新版直接拒绝启动，解法是设一个 api key，或者把地址改回 127.0.0.1。知乎
所以，自己编译、或者本来就跟 nightly 的人值得升，先在一台测试机把启动脚本过一遍，能启动、工具调用还能用，再动主力机。用 apt、Homebrew 或本地客户端打包版的人先别动，库的动态链接版本也变了，等打包方跟上。知乎
最后一个谈资：这批 PR 的 AI 使用声明大多写着 YES，Gerganov 做 1.0 的 API 清理，用的就是 llama.cpp 自己在跑的一份 DeepSeek V4.1 GGUF。一台本地推理引擎，开始用跑在自己身上的模型维护自己。知乎
