问题描述:
朋友们,希望有人能在这里帮助我或者给我指明方向。我觉得这可能是与transformers
的集成问题?我不明白为什么在transformers中会输出乱码,但vLLM却可以正常工作。我认为这可能与解码策略/采样有关,但考虑到我的以下非常奇怪的观察结果,这种说法似乎也不对:
- 这个8位Llama 3量化模型在使用vLLM进行推理时表现得非常好。参数和提示完全相同,但使用huggingface
transformers
的model.generate()
和文本生成管道时会出现乱码。 - 我再次使用不同的包版本重新量化它。同样的问题:如果使用
transformers
,会出现乱码,但在使用vLLM推理时表现良好。 - 我也使用相同的数据集、环境、脚本和设置制作了一个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
6条答案
按热度按时间k3bvogb11#
请使用最新版本的4.40.1或最新的发布版本。他们刚刚修复了我遇到的一个llama生成问题回归。这个bug是特定于transformers和llama的。
r7s23pms2#
@Qubitium 我尝试了4.40.1,它也有同样的问题。我也已经在从
transformers
的github仓库直接安装。(4.41.0.dev0)此外,如果我使用
bfloat16
,我会得到乱码,但如果我使用float16
,我会得到nan
的logits。所以像这样的错误信息:
probability tensor contains either
inf,
nanor 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
的代码库中,而且我是从最新的源代码构建的,这是否意味着在transformers
和AutoGPTQ
之间有其他问题?此外,当我在为Phi 3扩展支持做PR时,我有
transformers-4.41.0.dev0
(但我在4.41.0.dev0上也遇到了麻烦,这就是我现在使用的版本),之前它运行得很好,因为没有乱码推理和nan
的logits。现在如果我运行相同的推理脚本,它会产生nan
的logits或乱码,具体取决于dtype。swvgeqrz3#
所以我觉得可能与huggingface/transformers#30380无关?因为它已经合并了吗?还是有其他的东西被添加破坏了?
到目前为止,我们知道transformers 4.38.2、4.40.1和4.41.0.dev0(当前版本的dev0)是有问题。只是为了参考编译一些东西
顺便说一下,Phi-3使用LLAMA 2架构,所以这可能是一个llama家族相关的问题......
whhtz7ly4#
可能相关的 huggingface/transformers#27179
probability tensor contains either inf, nan or element < 0
是一个常见的问题,我甚至在未量化的模型中也看到了它。尽管如此,我没有找到根本原因。也许是因为一些 fp16/bf16/autocast 行为。如果我有时间的话,我会尝试看一下。
vmjh9lq95#
是的,我研究了
nan
的logits。问题是大多数人可以通过加载bfloat16
来绕过这个问题,这种行为看起来正常且正确,确实主要是基本模型。在我们的情况下,基本模型没问题,但量化模型有问题。值得注意的是,在这个场景下,两种dtype似乎都有问题。加载
float16
得到的是nan
的logits,加载bfloat16
得到的是乱码。vLLM
和其他文本生成引擎(基于其他人的报告)表现得很好......所以,肯定是关于transformers的问题,而且最近一直存在且持续不断。我有种感觉这可能与我们能找到的关于nan
logits的较旧帖子无关。无论如何,我也会对此进行调查。我对AutoGPTQ的知识不如其他人那么好,所以速度会慢一些,但我可以肯定地说,所有与llama家族模型相关的8位量化都受到了影响。41zrol4v6#
遇到了相同的问题。8位量化模型输出了乱码,而4位则正常工作。此外,CPU上的AutoGPTQ也使用8位,但在CUDA版本上出现了问题。