2.1 GGML 时代的遗产与局限

2.1 GGML 时代的遗产与局限

本节摘要：GGML 是 llama.cpp 最初的模型格式，也是底层张量库的名字。它撑起了 2023 年上半年的本地推理热潮，但「超参数写死在文件头」的设计让它撑不住模型架构的爆发式增长。本节复盘它的结构与三大局限——这些缺陷正是下一节 GGUF 每个设计决定的直接动因。

一段已经退役的格式，为什么还值得讲

翻 2023 年上半年的老教程，你会看到满屏的 .bin 后缀文件——那就是 GGML 格式的模型。如今新版 llama.cpp 已经移除了对它的加载支持，按说它该安静退场了。但把它请回这一节有两个理由：其一，你迟早会在网盘、老博客、论坛附件里撞见这些遗留文件，得知道它们是什么、还能不能救；其二，GGUF 的每个设计决定都是对着 GGML 的痛点打的，不懂病灶就看不懂药方。这是承接 1.1 节历史线的第二站：项目起源之后，第一次重大重构。

一、GGML 文件长什么样

GGML 格式的结构直白到近乎原始：文件开头是一段固定布局的超参数区，接着是词表，最后是按顺序排布的张量数据。用伪结构描述：

GGML 文件布局（示意）
[ 魔数 0x67676d6c ]        # 四字节标识，"ggml" 的十六进制
[ 版本号 ]                  # 整数，如 1
[ n_vocab ]                # 词表大小，如 32000
[ n_embd  ]                # 嵌入维度，如 4096
[ n_mult  ]                # FFN 中间层推算用的乘数
[ n_head  ]                # 注意力头数
[ n_layer ]                # 层数，如 32
[ f16     ]                # 半精度标记
[ 词表 token 列表 ]         # 逐条写入
[ 张量名 + 数据 ... ]       # 依次排布
​

问题就出在这个「固定布局」上。超参数按位置对号入座：加载器读到第几个字节是什么，是写死在代码里的。LLaMA 原版有七个超参数？好，代码里就读七个。后来某个新架构多了旋转编码的缩放参数？对不起，加字段意味着文件布局变了，新旧加载器互不认识。

二、三大结构性局限

局限一：超参数集写死，架构扩展举步维艰。 这是致命伤。2023 年下半年起，几乎每个月都有新架构冒出来：有的加滑动窗口，有的改归一化位置，有的带视觉编码器。GGML 格式下，每支持一个新架构都要同时改文件写入端与加载端，任何一处不同步就是损坏的文件或错误的加载。格式本来应该是「容器」，却变成了「模具」——装不进新形状的模型。

局限二：元数据残缺，配置与权重分家。 GGML 文件里没有词表类型、没有对话模板、没有架构名称。下载一个模型，你得另外找配套的说明：是什么架构、用什么分词器、聊天时该套什么模板。当年社区最常见的求助帖是「模型加载出来全是乱码」——十有八九是权重与配置文件版本错配。模型分发从单文件退化为「一堆必须配套的文件」，与 llama.cpp「单文件交付」的哲学直接冲突。

局限三：字节布局绑死，小修小补都算破坏性变更。 超参数区用定长整数、词表紧贴着按顺序排，想加一个字段就得整体挪动后面所有内容的偏移。于是每次格式微调都产生互不兼容的「新 GGML」，工具链生态跟着碎片化：某个量化脚本只认某年某月的格式，另一个校验工具只认另一个版本。

三、遗产盘点：哪些东西活了下来

复盘旧格式不是全盘否定，GGML 留下了三笔仍在增值的遗产。第一是名字本身：底层张量库至今叫 ggml，分块量化的数据布局（32 权重一块、块内共享缩放因子）原样延续到了 GGUF 时代，第 3 章的量化实验会直接受惠于这套布局。第二是 mmap 加载约定：模型文件直接映射进进程地址空间、按需换页的机制从 GGML 时代定型，这让「内存不够」的处理第一次变得优雅可预测。第三是「格式跟着推理引擎走」的社区习惯：格式规范、转换脚本、加载器都在同一个仓库里演进，出问题不用跨项目追责——这个协作模式被 GGUF 完整继承。

对老文件的处理建议只有一条：别修补，重新转换。如果你手里有珍贵的 GGML 老权重，正确的路径是找到它对应的原始精度来源或用旧版工具先转回通用格式，再用当前版本的转换管线转成 GGUF。直接拿旧文件在新版引擎上碰运气，只会浪费一个下午。

迁移现场：一次真实的格式考古

把复盘落到一次真实操作。主线上手时硬盘里翻出一份 2023 年 4 月的 7B 旧格式文件，验证它的处置流程：第一步看魔数与头几个字段，确认是旧格式（新格式的四字节标识完全不同）；第二步检索当年发布页，找到对应的原始模型来源；第三步下载新格式的社区量化版，用第 2.3 节的三关校验通过后，旧文件归档退役。全程没有尝试任何「修补旧文件」的捷径——旧格式的张量数据本身是完好的，缺的是新加载器认得的元数据结构，而补全这套结构的工作量远超重新下载。这个案例的通用结论：格式退役后，数据可救、文件不必救，找回来源比修复容器更便宜也更可靠。

自查三问

一问：旧格式最致命的缺陷用一句话说是什么？答：超参数按固定偏移写死，格式成了装不下新架构的模具。二问：为什么乱码问题在旧格式时代高发？答：词表与对话模板不在文件里，靠外部配套，版本错配即乱码。三问：手里只有旧格式文件时正确做法是什么？答：找回原始权重来源重新转换，而不是找旧版加载器修补容器。

常见问题

旧格式文件还能转成 GGUF 吗？

分两种情况。手里有对应的原始权重来源时，直接走新转换管线，问题消失。只有旧文件本身时，需要先用旧版本工具链把权重导出成通用格式，再转 GGUF——可行但折腾，除非这权重独一无二，否则不建议。

为什么底层库还叫 ggml，不改名区分新旧？

名字承载的是张量运算库本身，它一直在演进并没有退役；退役的只是旧的文件格式约定。库与格式同名是历史遗留，社区选择保留这个名字作为对起源的纪念，文档里靠上下文区分。

这段历史对新学习者还有什么现实意义？

两条。看懂旧资料：2023 年的老教程、老脚本、老参数大量存在，知道格式分界线，就能判断一份资料是否过期。理解设计：GGUF 的每个优点都对应旧格式的一个痛点，知道「为什么」的设计才记得住、用得活。

一条辨析：格式与张量库的两条演进线

复盘历史时容易把两条线混为一谈，值得辨析清楚：文件格式的演进（GGML 到 GGUF）解决「怎么存」，张量库的演进（内核优化、新后端）解决「怎么算」。格式在 2023 年 8 月发生过大迁徙，张量库却从未推倒重来——它以增量方式一路长成今天的多后端体系。理解这两条线的独立节奏，你读社区公告时就能快速分类：哪些变更影响你的旧文件（格式线），哪些变更影响你的速度（内核线），哪些与你无关（内部重构）。历史读得准，新闻才读得快。

本节要点回顾

• GGML 的病灶是「模具化」：超参数按固定偏移写死，新架构装不进旧模具；
• 元数据残缺是分发灾难的根源：词表、模板靠外部配套，版本错配即乱码；
• 任意微调都是破坏性变更：字节布局绑死导致工具链碎片化；
• 遗产仍在增值：ggml 张量库、分块量化布局、mmap 约定都活了下来；
• 遗留文件的正确处理是重新转换，不是寻找旧版加载器；
• 下一节进入 GGUF 的内部结构，逐个看它如何拆解这些病灶。