我同意轮子的观点。建造它们需要很长时间。

我记得加速支持类似于pre_layer的功能，我会再次阅读源代码，并可能重新设计自动GPTQ与加速器的集成方式。

关于轮子：我之前开始研究这个问题，但后来转向了其他优先事项。感谢提供GPTQ轮子的链接，这对我很有帮助。这周我会尝试让AutoGPTQ编译器运行一个演示。

关于pre_layer:我同意在这方面肯定需要做一些工作。-pre_layer看起来有点像一个hack。但它有效，现在AutoGPTQ中的卸载和多GPU功能并不那么好用，而且相当令人困惑。

还有一个问题需要解决，那就是strict=False。大多数模型都需要strict=False -包括我最近的所有模型。我不得不回到使用oobabooga的旧CUDA分支的GPTQ-for-LLaMa来发布模型。否则，使用该分支的用户(下载我的模型的人中大约有95%)无法使用CPU卸载。

我想使用ooba的旧GPTQ-for-LLaMa分支将获得最大的兼容性，因为AutoGPTQ可以使用strct=False加载这些模型。但目前的问题是：a)AutoGPTQ中没有默认的strict=False;b)它影响了max_memory代码路径。

一旦我们达到AutoGPTQ可以大规模使用的阶段，我愿意重新量化并重新发布我的所有模型。但我认为这并不能解决问题，因为总会有一些用户还没有下载AutoGPTQ,仍然在使用旧版本的GPTQ-for-LLaMa。

因此，我认为在AutoGPTQ中需要有一个解决方案：
a)允许使用旧GPTQ-for-LLaMa量化的模型加载，理想情况下自动/带有默认参数
b)允许所有模型有效地进行CPU卸载和多GPU分布
c)至少保持与现有GPTQ-for-LLaMa实现相同的性能水平，理想情况下比现有实现更好

关于多GPU性能的相关内容：我最近了解到一种Accelerate的新方法，可以显著提高多GPU性能。请参见这里： huggingface/accelerate#1394
这种方法已经整合到一个GPTQ-for-LLama分支中： qwopqwop200/GPTQ-for-LLaMa@triton...Dhaladom:TALIS:triton
我认为这段代码值得在AutoGPTQ中集成

大家好！现在你们可以尝试这个pr #100,它实现了一个“真正的”CPU卸载，并修复了量化模型在使用CPU卸载加载预训练模型时无法保存的错误。

非常感谢@PanQiWei
第一印象似乎不错。我很高兴Strict已经消失，而且使用旧的GPTQ-for-LLaMa代码制作的模型仍然可以正常加载，现在默认就是这样。
简要测试后，CPU卸载似乎像您描述的那样工作。例如，我可以将GPU 0限制为仅4GB + Context。
稍后我会尝试双GPU设置，例如在2 x 4090上运行65B。

大家好，感谢@jllllll ,现在预构建轮子可以在CUDA 11.7和11.8上成功构建Python 3.8~3.10版本的workflow。从现在开始，在每次发布时，我都会将wheels添加到发布资源中！🥂

非常棒 @PanQiWei ,非常感谢！我已经将新轮子纳入我的项目了。

$x_1^e_0f_1^x$

稍后我会测试双GPU设置，例如在2个4090上运行65B。
你得到了什么？对我来说，它非常慢，大约为5t/s,而与GPTQ-for-llama相比约为15t/s。