[ggerganov/llama.cpp]转换：更新 Falcon 脚本以适应新的 HF 配置

这是https://github.com/ggerganov/llama.cpp/pull/3049的延续吗？:)

这是#3049 的延续吗？:)

我所说的最近的变化是指三天前。

是的，但您的更改只是 180B 实际更改的一部分

$ diff convert-falcon-hf-to-gguf.py convert-falcon180-hf-to-gguf.py --color=always -w

2c2
< # HF falcon--> gguf conversion
---
> # HF falcon180B--> gguf conversion
16a17
> from safetensors import safe_open
48c49
<         if filename.startswith("pytorch_model-"):
---
>         if filename.startswith("model-00"):
90c91
< if hparams["architectures"][0] != "RWForCausalLM":
---
> if hparams["architectures"][0] != "FalconForCausalLM":
103c104
< block_count = hparams["n_layer"]
---
> block_count = hparams["num_hidden_layers"]
111,113c112,114
< gguf_writer.add_head_count(hparams["n_head"])
< if "n_head_kv" in hparams:
<     gguf_writer.add_head_count_kv(hparams["n_head_kv"])
---
> gguf_writer.add_head_count(hparams["num_attention_heads"])
> if "num_kv_heads" in hparams:
>     gguf_writer.add_head_count_kv(hparams["num_kv_heads"])
181,182c182,183
< n_head    = hparams["n_head"]
< n_head_kv = hparams["n_head_kv"] if "n_head_kv" in hparams else 1
---
> n_head    = hparams["num_attention_heads"]
> n_head_kv = hparams["num_kv_heads"] if "num_kv_heads" in hparams else 1
193c194
<         f"pytorch_model-{n:05}-of-{num_parts:05}.bin" for n in range(1, num_parts + 1)
---
>         f"model-{n:05}-of-{num_parts:05}.safetensors" for n in range(1, num_parts + 1)
200c201
<     model_part = torch.load(dir_model / part_name, map_location="cpu")
---
>     with safe_open(dir_model / part_name, framework="pt", device="cpu") as model_part:
203c204
<         data = model_part[name]
---
>             data = model_part.get_tensor(name)

（我与旧版本的 convert-falcon 进行了比较，因为自那时起 master 上发生了一些小的变化。）

是的，但您的更改只是 180B 实际更改的一部分

好的，那么你建议我做什么才能让 Falcon <180B 再次在主服务器上运行？

我们还需要#3049 吗？

这个 PR 中的脚本不知道如何读取 safetensors 文件，所以我认为我们仍然需要该 PR。

绝对不行，为什么不先合并#3049，然后放弃它，最后合并这个。

没有人会丢失贡献记录，并且猎鹰推理继续发挥作用。

有人可以用 Falcon-180B 测试这个脚本吗？

atm 测试 - 需要一些时间。此更改是否会修复https://github.com/ggerganov/llama.cpp/issues/3484中报告的问题

此更改是否会修复 #3484 中报告的问题？

不幸的是没有。这似乎是由 #3252 引起的另一个回归

有人可以用 Falcon-180B 测试这个脚本吗？

它与这个 repo 一起工作：https://huggingface.co/tiiuae/falcon-180B/tree/main

这很奇怪，因为这看起来像安全张量数据，我们不希望能够用这个脚本读取它。

这很奇怪，因为这看起来像安全张量数据，我们不希望能够用这个脚本读取它。

我最近为这个 PR 添加了 safetensors 支持，以便它可以支持 180B，这就是我询问的原因。

此更改破坏了旧架构（RWForCausalLM）。有点烦人，因为还有另一项更改需要重新转换原始的 HuggingFace 模型： https://github.com/ggerganov/llama.cpp/issues/3484

这一变化破坏了旧的架构（RWForCausalLM）。

HF 上的官方 falcon-7b、falcon-40b 和 falcon-180B 型号与此脚本的新版本兼容。您的用例是什么？

我从 Hugging Face 下载了这个模型： https://huggingface.co/ehartford/WizardLM-Uncensored-Falcon-40b/tree/main

这是 Falcon 的官方版本吗？ https://huggingface.co/tiiuae/falcon-7b/tree/main 模型文件上最新的提交消息是“Upload RWForCausalLM”。转换脚本在此上运行正常吗？

模型文件上最新的提交消息是“Upload RWForCausalLM”。转换脚本在此上运行正常吗？

最新的提交是 898df13“移动到库内检查点（这次是真的）”。这就是你想要的。

我想我可以重新添加对旧格式的支持直到微调更新完成。

哦，我明白了；他们更新了 config.json 文件，但实际的多 GB 模型文件没有改变。我认为这对某些人来说可能不清楚，他们最终可能会重新下载整个模型，这不是一个好的用户体验。此外，一些微调可能永远不会更新。在我看来，最好同时支持这两种格式，但我会让你决定如何优先考虑这一点。感谢您调查这个问题。