Llama.cpp 突破：30B 模型仅需 6GB 内存运行

加载时出错。请重新加载此页面。

通知：你必须登录才能更改通知设置。

jart 于 2023 年 3 月 29 日评论：

这是一项破坏性变更，将为我们带来三项好处：

1. 你的推理命令加载速度应该能提高 100 倍
2. 你或许可以安全加载体积大一倍的模型
3. 你可以同时运行多个推理进程

我们通过修改文件格式实现了这一点：现在可以直接用 mmap() 将权重映射进内存，无需再通过 read() 读取或复制。这样，内核便能让推理进程直接访问文件缓存页面；其次，文件缓存页面被逐出的可能性也大幅降低——否则加载过程就不得不访问磁盘——因为它们不再需要与那些由数 GB 标准 I/O 无谓创建的内存页面争夺空间。

新文件格式既支持 LLaMA 7b 这样的单文件模型，也支持 LLaMA 13B 这样的多文件模型。现在，我们的 Python 工具会将 foo.1、foo.2 等文件重新合并成单个文件，这样负责映射文件的 C++ 代码就不必每次都重新调整数据形状。这让 llama.cpp 简化了许多，大量加载相关代码现在已经被删除。

此外，这项变更还能确保 tensor 正确对齐到 32 字节边界。这为进一步探索性能优化打开了大门：在某些微处理器上，我们或许可以通过使用要求内存对齐的 ops 获得额外性能提升。

最后需要说明的是，POSIX 和 Windows 平台均受支持。

这个 PR 解决的问题是 #91。

这个 PR 由我与 @slaren 协作完成。同时，这个 PR 已经 rebase 到 PR #586 上，所以请不要 squash merge！请使用 merge 或 rebase。

luminalle 于 2023 年 3 月 30 日评论：

其他 converter 是否也应该重写，以支持这种新格式？

jart 于 2023 年 3 月 30 日评论：

确实应该。我刚刚修复了 quantize 程序。现在正在逐一排查所有测试。

jart 于 2023 年 3 月 30 日评论：

除了一个 CMake 测试之外，其他测试似乎都通过了。例如：https://github.com/ggerganov/llama.cpp/actions/runs/4559537462/jobs/8043597142?pr=613

这个错误把我难住了。我不知道 models/ggml-vocab.bin 文件是从哪里来的。有人知道吗？会不会是旧缓存？

FNsi 于 2023 年 3 月 30 日评论 · 已编辑

正在加载。糟糕！加载时出错。请重新加载此页面。

加载时出错。请重新加载此页面。

除了一个 CMake 测试之外，其他测试似乎都通过了。例如：https://github.com/ggerganov/llama.cpp/actions/runs/4559537462/jobs/8043597142?pr=613

这个错误把我难住了。我不知道 models/ggml-vocab.bin 文件是从哪里来的。有人知道吗？会不会是旧缓存？

#355 中提到：“添加了 ./models/ggml-vocab.bin，其中只包含 LLaMA 词表数据（用于测试）。”

bakkot 于 2023 年 3 月 30 日评论 · 已编辑

正在加载。糟糕！加载时出错。请重新加载此页面。

加载时出错。请重新加载此页面。

隐藏此评论时出现问题。

请选择隐藏此评论的原因。

该原因将显示给其他人，用于说明为什么隐藏这条评论。了解更多。

一个小意见：为什么要修改 magic，而不是 version？我原以为原计划是让 magic 永远保持不变。如果改为提升 version，旧版可执行程序就能识别出新的模型文件，并给出更有用的错误信息。而且，能够区分下面两种情况也很好：“这肯定是本项目的模型文件，只是 version 不对”和“这只是某种我们一无所知的随机垃圾数据”。

（这个 PR 的工程实现非常巧妙，请不要让我的这点小意见掩盖这一点。）

Green-Sky 于 2023 年 3 月 30 日评论：

隐藏此评论时出现问题。

请选择隐藏此评论的原因。

该原因将显示给其他人，用于说明为什么隐藏这条评论。了解更多。

这不只是小意见，而是一个真正的变更请求 :)

Green-Sky 于 2023 年 3 月 30 日评论：

隐藏此评论时出现问题。

请选择隐藏此评论的原因。

该原因将显示给其他人，用于说明为什么隐藏这条评论。了解更多。

ggerganov 于 2023 年 3 月 30 日评论 · 已编辑

正在加载。糟糕！加载时出错。请重新加载此页面。

加载时出错。请重新加载此页面。

@jart，models/ggml-vocab.bin 是由 convert-pth-to-ggml.py 在提供一个额外参数时生成的。

我原本以为支持 mmap 会对代码造成更大范围的侵入式改动，但事实证明，实现非常紧凑。现在 llama.cpp 简单多了。做得很好。

关于 version 的评论——没错，原计划是提升 version，而不是修改 magic。不过，我也可以接受修改 magic，用它来纪念这次更新的重要意义。事实上，也许我们可以把它变成项目传统：今后任何为项目做出重大贡献的人，都可以把自己的姓名首字母追加到 version 中。你觉得怎么样？😄

合并之前，让我今晚先试一试。我们必须特别注意，为外面流传的其他 ggml 模型文件——Alpaca、GPT4All、Chinese LLaMA 等——提供一种方便转换到新格式的方法，并更新 README 中的说明。

此外，可能还需要与 #545 做一些同步。

This is a breaking change that's going to give you three benefits:

1. Your inference commands should load 100x faster
2. You may be able to safely load models 2x larger
3. You can run many concurrent inference processes

This was accomplished by changing the file format so we can mmap()
weights directly into memory without having to read() or copy them
thereby ensuring the kernel can make its file cache pages directly
accessible to our inference processes; and secondly, that the file
cache pages are much less likely to get evicted (which would force
loads to hit disk) because they're no longer competing with memory
pages that were needlessly created by gigabytes of standard i/o.

The new file format supports single-file models like LLaMA 7b, and
it also supports multi-file models like LLaMA 13B. Our Python tool
now merges the foo.1, foo.2, etc. files back into a single file so
that the C++ code which maps it doesn't need to reshape data every
time. That's made llama.cpp so much simpler. Much of its load code
has now been deleted.

Furthermore, this change ensures that tensors are aligned properly
on a 32-byte boundary. That opens the door to seeing if we can get
additional performance gains on some microprocessors, by using ops
that require memory alignment.

Lastly note that both POSIX and the Windows platform are supported

Fixes ggml-org#91

jart 于 2023 年 3 月 30 日评论：

文件已更新。现在通过的测试多了很多。不知道 sanitizer 到底出了什么问题。

我之前也是这么想的！实际效果如此顺利，也让我感到惊喜。很高兴我们花了几周时间认真思考这件事。

你这么说让我深感荣幸。如果你愿意，我可以把 magic 扩充到 64 字节，这样将来就有空间向贡献者致意，同时不破坏向后兼容性。由于我的姓名首字母也相当于一种认可印章，我接下来还会提交一项后续变更，加强加载代码的安全性。这样，大家就能以最高程度的安全性和信心，在 HuggingFace 上交换这种格式的模型文件。

#545 是一次雄心勃勃的统一工作。我已经尽可能为自己的改动添加注释，让作者合并时少一些痛苦。我也尝试更新其他脚本，但不知道该如何运行它们。对于这个项目，你还可以考虑的一件事是增加一个 contrib/ 目录。大家可以按自己的意愿把个人内容合并进去，前提是谁需要它，谁就负责维护它。

隐藏此评论时出现问题。

请选择隐藏此评论的原因。

该原因将显示给其他人，用于说明为什么隐藏这条评论。了解更多。

对于 4GB 以上的文件，使用 mmap64 是否更安全？

mmap、mmap64 和 MapViewOfFile 看起来都支持从指定 offset 开始映射。能否从 header_len 开始映射，也就是将其作为 offset？如果可以，就没必要对齐模型文件了，对吗？

隐藏此评论时出现问题。

请选择隐藏此评论的原因。

该原因将显示给其他人，用于说明为什么隐藏这条评论。了解更多。

在 32 位平台上，正确的做法是让构建系统定义 -D_FILE_OFFSET_BITS=64。这样，系统头文件会自动执行 #define mmap mmap64。

传给 mmap() 的文件 offset 必须按页面大小对齐，所以我认为不行。

pgoodman 于 2023 年 3 月 31 日评论 · 已编辑

正在加载。糟糕！加载时出错。请重新加载此页面。

加载时出错。请重新加载此页面。

隐藏此评论时出现问题。

请选择隐藏此评论的原因。

该原因将显示给其他人，用于说明为什么隐藏这条评论。了解更多。

@jart，是否可以确保文件大小是 hugepage 大小的整数倍——例如使用 ftruncate——从而在访问模型数据时减少 TLB 查询次数并获益？可能还需要使用相应的 mmap hints 或其他系统专用 API，例如 macOS 所需的 API。

隐藏此评论时出现问题。

请选择隐藏此评论的原因。

该原因将显示给其他人，用于说明为什么隐藏这条评论。了解更多。

对于 mmap() 来说，即使文件长度没有按页面大小对齐也无所谓，小页面也是如此。如果你手动修改 llama.cpp 中的 mmap() 代码，而且真的能让 huge page 正常工作，同时不把机器搞崩，那应该就没问题了 :-)

pgoodman 于 2023 年 3 月 31 日评论：

隐藏此评论时出现问题。

请选择隐藏此评论的原因。

该原因将显示给其他人，用于说明为什么隐藏这条评论。了解更多。

加载时出错。请重新加载此页面。

加载时出错。请重新加载此页面。

加载时出错。请重新加载此页面。

jart 于 2023 年 3 月 30 日评论：

@ggerganov，这项变更现在包含了一个名为 migrate-ggml-2023-03-30-pr613.py 的迁移工具。它可以确保那些已经删除原始 .pth 文件的旧版 GGML 文件格式用户，仍然能够把自己的 ggml+ggmf 文件转换为新的 ggml+ggjt 格式。请看一下。

x02Sylvie 于 2023 年 3 月 30 日评论：

迁移 Alpaca 模型 ggml-alpaca-13b-q4.bin 时遇到了问题。Python 脚本似乎认为该模型有两个 n_parts，而不是一个。能否给转换脚本增加一个 --n_parts 参数，以便手动指定 --n_parts 1，就像在 llama.cpp 上运行 Alpaca 模型时那样？这样或许可以解决问题。

jart 于 2023 年 3 月 30 日评论：

@x02Sylvie，我无法获取 Alpaca 模型。这个合并之后，你能否提交一个修复该问题的 pull request？

x02Sylvie 于 2023 年 3 月 30 日评论 · 已编辑

正在加载。糟糕！加载时出错。请重新加载此页面。

加载时出错。请重新加载此页面。

我其实不懂 Python，所以更愿意把这个 pull request 留给比我更聪明的人来做。

不过，我确实通过在 .py 转换脚本中手动把 n_parts 设置为 1，成功转换了 Alpaca 13b 模型。只是我不确定这里是不是设置 n_parts 的正确位置。

def get_n_parts(dim):
    mappings = {4096: 1, 5120: 2, 6656: 4, 8192: 8}

    n_parts = mappings.get(dim)

    if n_parts is None:
        print(f"Invalid dim: {dim}")
        sys.exit(1)
    print(f"n_parts = {n_parts}\n")
    return n_parts

def get_n_parts(dim):
    mappings = {4096: 1, 5120: 2, 6656: 4, 8192: 8}

    n_parts = 1

    if n_parts is None:
        print(f"Invalid dim: {dim}")
        sys.exit(1)
    print(f"n_parts = {n_parts}\n")
    return n_parts

不过，转换后的模型确实可以正常工作。

If you deleted your old Meta LLaMA .pth files, then the
migrate-ggml-2023-03-30-pr613.py script will allow you to convert your
old ggml files into the new mmap()'able format.

See ggml-org#613

asklar 于 2023 年 4 月 1 日评论：

做得太棒了，@jart 和 @slaren！<3

As noted in https://github.com/ggerganov/llama.cpp/blob/master/migrate-ggml-2023-03-30-pr613.py,

Authors from `llama.cpp` caused a breaking change to the file format on 2023-03-30 in:
ggml-org/llama.cpp#613

Therefore, we need further use `migrate-ggml-2023-03-30-pr613.py` to convert the llama model.

As noted in
https://github.com/ggerganov/llama.cpp/blob/master/migrate-ggml-2023-03-30-pr613.py,

Authors from `llama.cpp` caused a breaking change to the file format on
2023-03-30 in: ggml-org/llama.cpp#613

Therefore, we need further use `migrate-ggml-2023-03-30-pr613.py` to
convert the llama model.

If you deleted your old Meta LLaMA .pth files, then the
migrate-ggml-2023-03-30-pr613.py script will allow you to convert your
old ggml files into the new mmap()'able format.

See ggml-org#613

If you deleted your old Meta LLaMA .pth files, then the
migrate-ggml-2023-03-30-pr613.py script will allow you to convert your
old ggml files into the new mmap()'able format.

See ggml-org#613

If you deleted your old Meta LLaMA .pth files, then the
migrate-ggml-2023-03-30-pr613.py script will allow you to convert your
old ggml files into the new mmap()'able format.

See ggml-org#613

If you deleted your old Meta LLaMA .pth files, then the
migrate-ggml-2023-03-30-pr613.py script will allow you to convert your
old ggml files into the new mmap()'able format.

See ggml-org#613