Open yuanjie-ai opened 1 year ago
能提供一个Patch吗,直接换了ChatGLM,attention mask那个地方报错了。不知道怎么搞. ChatGLM直接出来的attention_mask attention_mask.shape:torch.Size([12, 1, 714, 714]) [batch*2, 1, seq_length,seq_length]
Traceback (most recent call last):
File "/home/jovyan/ws/nbce/test.py", line 114, in <module>
generate(1000)
File "/opt/conda/envs/alpaca/lib/python3.10/site-packages/torch/autograd/grad_mode.py", line 27, in decorate_context
return func(*args, **kwargs)
File "/home/jovyan/ws/nbce/test.py", line 110, in generate
attention_mask = torch.cat([attention_mask, torch.ones(n, 1, dtype=torch.long, device=device)], dim=-1)
RuntimeError: Tensors must have same number of dimensions: got 4 and 2
['菲律宾国家电网公司,中国占股40%。', '领英计划裁员716人。', '吉利德收购Pharmasset的价格是20亿美元。', '丙肝神药Sovaldi在2013年上市。', '中亚峰会将于2023年6月在<0xE7><0x83><0x8F><0xE8><0x98><0xAD>举行,由国家主席习近平主持。', '演员李某某由于侮辱人民军队而被立案调查。', '默沙东的CEO的首要任务是确保基本盘。']
个人感觉比预期中好了哈哈,感谢提供。
演员李某某~没答出来,感觉opensuudy结果更好一些
发自我的iPhone
------------------ 原始邮件 ------------------ 发件人: 苏剑林(Jianlin Su) @.> 发送时间: 2023年6月6日 10:56 收件人: bojone/NBCE @.> 抄送: Betterme @.>, Author @.> 主题: Re: [bojone/NBCE] chatglm的结果 (Issue #2)
演员李某某~没答出来,感觉opensuudy结果更好一些
我记得原文也提到“李某某”,所以模型回答“李某某”也无可厚非,倒是Pharmasset的收购价格答错了。
比较耗内存
发自我的iPhone
------------------ 原始邮件 ------------------ 发件人: yw2278 @.> 发送时间: 2023年6月8日 15:39 收件人: bojone/NBCE @.> 抄送: Betterme @.>, Author @.> 主题: Re: [bojone/NBCE] chatglm的结果 (Issue #2)
我参考苏神的代码,结果显存OOM了,我3090ti塞chatglm6B没问题的,大佬有出现过同样的错误么
我不知道大家是不是有什么误解。。。NBCE是提供了一种long context的方案,但实际上能有多long,肯定是取决于你的显存的啊。
NBCE对显存的需求,关于context长度来说是线性的,这在理论效率上已经是最优的了。也就是说,假如你原本2048的长度,用掉了24G显存,那么要想处理4096,那么就需要48G,如果想处理8192长度,那么就需要96G显存,这应该都是很自然的结果吧(假如忽略模型自身参数的显存占用)。。。
我认为这不能算叫做“比较耗显存”,只是“正常耗显存”,如果长度乘以2,显存消耗要乘以4,那才是“比较耗显存”。
当然,也可以不增加显存,只要修改脚本,改为串行(而不是batch)地计算每个sample的结果,然后再按NBCE的公式融合,这样显存是不增加了,但是每个token的生成时间增加了,看你实际怎么取舍了。
这就好比阅读一本书,跟阅读一页书,总不能是相同的成本吧,要不你花更多的时间去读,要不你请更多的人一起读,无他。。。
我参考苏神的代码,结果显存OOM了,我3090ti塞chatglm6B没问题的,大佬有出现过同样的错误么
我不知道大家是不是有什么误解。。。NBCE是提供了一种long context的方案,但实际上能有多long,肯定是取决于你的显存的啊。
NBCE对显存的需求,关于context长度来说是线性的,这在理论效率上已经是最优的了。也就是说,假如你原本2048的长度,用掉了24G显存,那么要想处理4096,那么就需要48G,如果想处理8192长度,那么就需要96G显存,这应该都是很自然的结果吧(假如忽略模型自身参数的显存占用)。。。
我认为这不能算叫做“比较耗显存”,只是“正常耗显存”,如果长度乘以2,显存消耗要乘以4,那才是“比较耗显存”。
当然,也可以不增加显存,只要修改脚本,改为串行(而不是batch)地计算每个sample的结果,然后再按NBCE的公式融合,这样显存是不增加了,但是每个token的生成时间增加了,看你实际怎么取舍了。
这就好比阅读一本书,跟阅读一页书,总不能是相同的成本吧,要不你花更多的时间去读,要不你请更多的人一起读,无他。。。
如果是这样的话,这种方式与Langchain做map reduce相比有啥优势呢?
如果是这样的话,这种方式与Langchain做map reduce相比有啥优势呢?
更加简单直接