你下载了一个 GGUF 模型，想放到树莓派外接的加速卡上运行，却发现它像一份格式不兼容的文件：每换一个模型，都要先交给厂商编译器重新加工。现在，一名开发者拆开了这道封闭环节，让 llama.cpp 能在加载时把 GGUF 权重写进预编译引擎，再交给 NPU 运行。
这项工作值得看，不只是因为速度变快。它尝试把常见的本地模型文件与封闭的边缘芯片接起来，让上层工具不必围着厂商格式重写。不过，目前全部信息都来自作者 woolcoxm 的一篇 Reddit 自述，没有代码、论文、厂商资料或第三方测试交叉验证，以下效果数字都应视为作者报告。
先弄懂那两个“半字节”
GGUF 是本地大模型常用的文件格式，llama.cpp 则是运行这类模型的开源推理工具。作者使用的设备，是由 Raspberry Pi 5 托管的 M5Stack LLM-8850 外接卡；按其自述，卡上搭载 Axera AX8850 NPU、8GB LPDDR4x 内存，标称算力为 24 TOPS。NPU 就是专门执行神经网络计算的芯片。
问题在于，厂商要求每个模型都经过自家编译器，生成封闭的 .axmodel 引擎。作者希望把这张卡做成 llama.cpp 的后端——也就是连接上层软件与具体硬件的适配层。目标可以概括成一句话：输入 GGUF，输出模型生成的 token，不再为每个模型单独编译。
为此，他对 .axmodel 做了逆向工程：从编译结果反推内部格式。作者称，模型的 int8 权重位于名为 npu_params 的数据块中，并以两个 nibble plane 保存。nibble 是半个字节，也就是 4 bit。这里可以把一个完整字节想成一张被上下拆开的纸：高 4 bit 和低 4 bit 没放在一起，而是分布在两层排列中；其中保存低位的字节还位于另一字节之前 18 个位置。
作者没有靠猜。他制作了大约 10 个“标记版”检查点，让每个权重都编码自己的行、列坐标，再逐个通过厂商工具链编译，对比输出差异。借此，他称自己还原了每层 7 个矩阵的完整布局以及缩放参数表。
不是毫无转换，而是省掉逐模型编译
格式被看懂后，作者在加载阶段把 GGUF 权重直接写进预编译引擎。具体流程仍包括三步：先将 GGUF 权重反量化，再按照引擎自带的 scale 重新量化，最后只改写真正发生变化的字节。
因此，标题里的“无需模型转换”需要收窄理解。它省掉的是厂商工具链中的逐模型转换和编译，并非完全取消格式处理或量化处理。真正的价值，是把这些步骤藏进加载过程，让 llama.cpp 的使用方式尽量保持不变。
作者报告，这条路径与同一 GGUF 的 CPU 参考实现相比，输出 token 的一致率为 96%。这意味着结果很接近，但不是完全相同。文中另一处“byte-identical”只针对修复后的批量 prefill 路径，不能据此推断整个端到端生成过程逐字节一致。
快的不只是“吐字”
模型推理大致有两个阶段。prefill 是先读完用户输入、建立中间状态；decode 才是随后一个 token 接一个 token 地生成答案。两者的 t/s 含义不同，不能直接横比。
作者称，厂商其实已经提供可用于 prefill 的 shape-groups，只是自家的 host runtime 没有调用。此前大家认为这条批处理路径不可用，实际故障来自输出缓冲区的绑定方式；修复后，prompt processing 达到 716 t/s，并得到逐字节一致的输出。
在单路、贪心生成条件下，作者报告 int4 引擎在 2k context 时解码为 24.5 t/s；使用 1k-context build 时为 29.9 t/s；裁剪 vocabulary head 后为 26.8 t/s。相比之下，作者给出的厂商封闭 runtime 速度是 13.5—14.5 t/s。不同数字来自不同上下文长度或构建条件，因此不能简单排成同一张成绩表。
标题宣称“快 1.5 倍”，但正文没有说明这个倍数采用哪组条件。仅按所列数字计算，24.5 对 13.5—14.5 约为 1.69—1.81 倍，29.9 则约为 2.06—2.21 倍。可能存在未披露的测试口径，现有材料无法确认。
为什么这是一次底层突破
我们此前报道过社区量化 Qwen 在本地硬件上的能力上限。这次进展更靠下游：它不讨论模型会什么，而是解决模型文件怎样真正进入边缘 NPU。
作者称，运行时 Raspberry Pi 的 CPU 处于空闲状态，计算由外接卡完成。他还报告，batch-1 decode 的主要瓶颈不是芯片缺少乘加算力，而是内存搬运：有效流式带宽约 25 GB/s，相当于所称 LPDDR4x 峰值的 73%，MAC——执行乘加运算的计算单元——利用率约为 1%。说白了，厨房里有很多厨师，菜却送得不够快。若这一判断成立，继续堆标称 TOPS 未必能直接提高单路生成速度，数据如何喂给芯片同样关键。
局限与未知
- 作者没有提供代码、补丁、模型文件、完整测试参数或功耗数据，其他开发者目前无法据此复现。
- 24 TOPS、内存规格、带宽、利用率及全部速度均缺少厂商规格表或独立测量验证；原始自述末句也被截断。
- 96% token 一致率为何未达到完全一致、差异会怎样影响实际输出，现有材料没有解释。
这项工作的分量，最终取决于代码能否公开、测试能否复现，以及适配能否扩展到更多模型。即便先不接受标题里的速度倍数，逆向封闭权重布局、把 GGUF 接入 llama.cpp 的 NPU 后端，本身已经指向一个重要变化：边缘推理的竞争，不只发生在芯片算力上，也发生在谁能把封闭部署链路重新接回通用开源工具。