Silver

貌似微博升级了自己的服务器，之前像图片之类的静态资源可以直接通过请求拿到。现在可能要绕一下，逆向一下前端的请求逻辑。 图片的url依然是有效的。最近比较忙，有空了可以搞一个脚本。

I am afraid int32 is not the reason for this error. I have submitted a commit to use int64 for all ints in the dataset: https://huggingface.co/datasets/liwu/MNBVC/commit/857ac00d9eab96a6708ad6a82bd9001686042a9e and I have updated...

i am using uint64 for simhash uint64 ranges up to about 3.69E19. 18329103420363166823 is less than this value. moreover, our simhash algorithm use 64 bits. it should fit in uint64.

Thank you for checking this issue in detail. However, it seems that using `np.uint64(simhash)` does not work. The same issue still exists. https://huggingface.co/datasets/liwu/MNBVC/commit/1e44f1e400b7e61052647d44c99cdae3bae9c830 Anyway, we decide to use string type...

> 请问这个裁剪是只涉及 00001 和 00008 两个文件吗？我在日志里看只有这两个，模型文件太大，不想全都重新下载。 是的，权重文件中只涉及这两个文件的修改。 huggingface的model zoo里面可以查看文件的哈希值，比如： https://huggingface.co/silver/chatglm-6b-slim/blob/main/pytorch_model-00002-of-00008.bin 和 https://huggingface.co/THUDM/chatglm-6b/blob/main/pytorch_model-00002-of-00008.bin 你可以比较一下其他几个权重文件。 但是*.json配置文件和*.py代码文件里面有更新，记得下载。

> 大约可以减少多少的显存占用呢 因为没有足够多的GPU设备，所以我还没有具体测试。 但是理论上减少不了很多，毕竟被砍掉的词表只占原来词表的13.33%。 涉及到不同框架管理显存的策略不一样，所以实际节省的显存数量还需要测试。 不过考虑到ChatGLM-6B-Slim不会对模型性能造成**任何**影响，使用Slim版本总是好的，这些显存的节省几乎是免费的午餐。

> 能否参考 https://huggingface.co/THUDM/chatglm-6b-int4 做一下量化后的模型？这样加载更快 在这里： https://huggingface.co/silver/chatglm-6b-int4-slim 模型参数文件大小从4.06GB减少到3.78GB。（但是不知道为啥新的ckpt在huggingface的repo里面显示的依然是4.06GB，实际下载的时候大小其实是3.78GB）

> 请问对token生成有提速效果吗？ 会有一点点性能提升，毕竟节省了一些冗余计算，但是估计影响不大。

I have a self defined model that use a integrated query_key_value layer: ```python self.query_key_value = skip_init( torch.nn.Linear, hidden_size, 3 * self.inner_hidden_size, bias=bias, dtype=params_dtype, ) ``` I want to use LoRA...

Moreover, `bloom`, `gpt_neox`, `gpt_neo` all use `nn.Linear` rather than `nn.Conv1D` to implement their `query_key_value` layer. In this case, we should not set `fan_in_fan_out=True`