AutoGPTQ Llama-3 8B指令量化为8位,在transformers模型的generate()中输出乱码,但在vLLM中正常工作?

3bygqnnd  于 6个月前  发布在  其他
关注(0)|答案(6)|浏览(75)

问题描述:
朋友们,希望有人能在这里帮助我或者给我指明方向。我觉得这可能是与transformers的集成问题?我不明白为什么在transformers中会输出乱码,但vLLM却可以正常工作。我认为这可能与解码策略/采样有关,但考虑到我的以下非常奇怪的观察结果,这种说法似乎也不对:

  1. 这个8位Llama 3量化模型在使用vLLM进行推理时表现得非常好。参数和提示完全相同,但使用huggingface transformersmodel.generate()和文本生成管道时会出现乱码。
  2. 我再次使用不同的包版本重新量化它。同样的问题:如果使用transformers,会出现乱码,但在使用vLLM推理时表现良好。
  3. 我也使用相同的数据集、环境、脚本和设置制作了一个4位量化模型,但这个4位模型在使用vLLM和transformers时表现良好。使用transformers时不会出现乱码。基本上没有任何问题。我已经将4位模型列在下面。这是我最困惑的部分......
8位量化配置(乱码8位模型)
quantize_config = BaseQuantizeConfig(
        bits=8,
        group_size=32,
        desc_act=True,
        damp_percent=0.1,
        true_sequential=True,
        sym=True,
)
与4位模型量化配置(在没有乱码的情况下表现良好的模型)相比
quantize_config = BaseQuantizeConfig(
        bits=4,
        group_size=128,
        desc_act=True,
        damp_percent=0.1,
        true_sequential=True,
        sym=True,
)
量化数据集
  • 500行或随机的wikitext片段
  • 我觉得数据集不是问题,因为使用model.generate()表现良好的4位模型使用的是完全相同的数据集。
推理脚本:
import torch
import transformers
print(transformers.__version__)

from transformers import AutoModelForCausalLM, AutoTokenizer, LocalAgent, GPTQConfig, Tool, pipeline
model = AutoModelForCausalLM.from_pretrained("astronomer/Llama-3-8B-Instruct-GPTQ-8-Bit", torch_dtype=torch.bfloat16, device_map="cuda:0")
tokenizer = AutoTokenizer.from_pretrained("astronomer/Llama-3-8B-Instruct-GPTQ-8-Bit", torch_dtype=torch.bfloat16)

messages = [
    {"role": "system", "content": "You are a helpful assistant"},
    {"role": "user", "content": "Who made you?"},
]
tokenized_chat = tokenizer.apply_chat_template(messages, tokenize=True, add_generation_prompt=True, return_tensors="pt").to('cuda:0')
print(tokenizer.decode(tokenized_chat[0]))
output = model.generate(inputs=tokenized_chat, temperature=0.7, max_new_tokens=100)
print(tokenizer.decode(output[0]))

输出:

<|begin_of_text|><|start_header_id|>system<|end_header_id|>

You are a helpful assistant<|eot_id|><|start_header_id|>user<|end_header_id|>

Who made you?<|eot_id|><|start_header_id|>assistant<|end_header_id|>

_<? Shoreuros_<?_<? fø_<?�470_<?_<? тру_<?utzer�_<?_<?_<?utzeremmeimersonse_<?_<?_<?_<?ribaimersutzer_<?emouth_<?_<?_<?_<?utzer姫utzer_<?utzerregon snaimers469_<?_<?_<?_<?_<?_<?utzerregonutzerutzerutzerutzerutzer_<?utzer-reduxutzeronseutzerutzer_<?utzer_<?emmeimers_<?_<?_<?utzeronse_<?utzer_<?_<? snaimers cubutzer snaimers_<?_<?_<?_<?utzerutzerecessonse_<?_<?_<?_<?_<?_<?_<? Shore

还尝试使用AutoGPTQ加载模型,结果也是乱码

from auto_gptq import AutoGPTQForCausalLM, BaseQuantizeConfig
gptq_model = AutoGPTQForCausalLM.from_quantized("astronomer/Llama-3-8B-Instruct-GPTQ-8-Bit", device="cuda:0")
tokenized_chat = tokenizer.apply_chat_template(messages, tokenize=True, add_generation_prompt=True, return_tensors="pt").to('cuda:0')
print(tokenizer.decode(tokenized_chat[0]))
output = gptq_model.generate(inputs=tokenized_chat, temperature=0.7, max_new_tokens=100)
print(tokenizer.decode(output[0]))
软件版本:

transformers: 尝试了4.38.2和4.40.0dev
auto_gptq: 0.7.1
optimum: 1.19.1

k3bvogb1

k3bvogb11#

请使用最新版本的4.40.1或最新的发布版本。他们刚刚修复了我遇到的一个llama生成问题回归。这个bug是特定于transformers和llama的。

r7s23pms

r7s23pms2#

@Qubitium 我尝试了4.40.1,它也有同样的问题。我也已经在从transformers的github仓库直接安装。(4.41.0.dev0)

此外,如果我使用bfloat16,我会得到乱码,但如果我使用float16,我会得到nan的logits。

所以像这样的错误信息:probability tensor contains either inf , nan or element < 0。这也被其他人在这里注意到了:https://huggingface.co/astronomer/Llama-3-8B-Instruct-GPTQ-8-Bit/discussions/5

非常有趣的是,我正在为AutoGPTQ扩展到Phi 3做这个PR(#651),并被要求发布困惑度结果。为了简单起见,我使用了AutoGPTQ的基准脚本(内部使用float16),该脚本在GPTQ 8位 模型上产生了nan的困惑度(但原始模型没问题)。在插入一些调试代码后,我发现所有的logits都是由这个GPTQ量化产生的nan

但是考虑到huggingface/transformers#30380已经合并到了transfromers的代码库中,而且我是从最新的源代码构建的,这是否意味着在transformersAutoGPTQ之间有其他问题?

此外,当我在为Phi 3扩展支持做PR时,我有transformers-4.41.0.dev0(但我在4.41.0.dev0上也遇到了麻烦,这就是我现在使用的版本),之前它运行得很好,因为没有乱码推理和nan的logits。现在如果我运行相同的推理脚本,它会产生nan的logits或乱码,具体取决于dtype。

swvgeqrz

swvgeqrz3#

所以我觉得可能与huggingface/transformers#30380无关?因为它已经合并了吗?还是有其他的东西被添加破坏了?
到目前为止,我们知道transformers 4.38.2、4.40.1和4.41.0.dev0(当前版本的dev0)是有问题。只是为了参考编译一些东西

顺便说一下,Phi-3使用LLAMA 2架构,所以这可能是一个llama家族相关的问题......

whhtz7ly

whhtz7ly4#

可能相关的 huggingface/transformers#27179
probability tensor contains either inf, nan or element < 0 是一个常见的问题,我甚至在未量化的模型中也看到了它。尽管如此,我没有找到根本原因。也许是因为一些 fp16/bf16/autocast 行为。
如果我有时间的话,我会尝试看一下。

vmjh9lq9

vmjh9lq95#

是的,我研究了nan的logits。问题是大多数人可以通过加载bfloat16来绕过这个问题,这种行为看起来正常且正确,确实主要是基本模型。在我们的情况下,基本模型没问题,但量化模型有问题。
值得注意的是,在这个场景下,两种dtype似乎都有问题。加载float16得到的是nan的logits,加载bfloat16得到的是乱码。vLLM和其他文本生成引擎(基于其他人的报告)表现得很好......所以,肯定是关于transformers的问题,而且最近一直存在且持续不断。我有种感觉这可能与我们能找到的关于nan logits的较旧帖子无关。无论如何,我也会对此进行调查。我对AutoGPTQ的知识不如其他人那么好,所以速度会慢一些,但我可以肯定地说,所有与llama家族模型相关的8位量化都受到了影响。

41zrol4v

41zrol4v6#

遇到了相同的问题。8位量化模型输出了乱码,而4位则正常工作。此外,CPU上的AutoGPTQ也使用8位,但在CUDA版本上出现了问题。

相关问题