正式標(biāo)題:修復(fù)chatglm int4 gpu環(huán)境下加載cpu量化內(nèi)核錯(cuò)誤

大概說說原因和流程，水水字?jǐn)?shù)，記錄踩坑流程

chatglm模型太大，完整版和int8量化對(duì)8G顯存設(shè)備不友好，8G適合使用int4量化減少顯存不足情況。

chatglm webui自動(dòng)下載的是全量模型大概13個(gè)G，使用GPU計(jì)算，全量模型先加載進(jìn)內(nèi)存，再cpu自動(dòng)量化到int4，這期間浪費(fèi)內(nèi)存浪費(fèi)cpu，而且也不緩存量化后的模型，如果內(nèi)存不夠或許加載都是問題。

對(duì)了，這十幾個(gè)G都在C盤空間，還是個(gè)緩存文件夾，非常無語。

但可惜quantization.py寫了一堆cpu內(nèi)核處理代碼，這會(huì)導(dǎo)致報(bào)錯(cuò)，而且搜不到正確的解決方案，也沒有整合包。

聞達(dá)似乎有整合，但百度云太慢了，huggingface下載速度飛快，幾十秒下完。

內(nèi)核報(bào)錯(cuò)解決方案:

內(nèi)核報(bào)錯(cuò)即運(yùn)行到quantization.py時(shí)反復(fù)編譯cup kernel，然后反復(fù)加載失敗的問題。

啟動(dòng)文件我是照著啟動(dòng)的bat改寫了一個(gè)啟動(dòng)方式，本質(zhì)上只是做了指定模型路徑的微小工作。

然后修改quantization.py文件，位置如圖。手動(dòng)指定so位置。

然后就能正常加載內(nèi)核和正常啟動(dòng)了。

加載速度和系統(tǒng)占用比起完整模型得到了極大改善!

那么這個(gè)so文件怎么來的?

我不知道這個(gè)編譯文件是不是通用的，如果通用的話明明可以直接提供，不用用戶編譯。如果是這樣那就太蠢了。

裝mingw，這是c++的編譯器，網(wǎng)上搜即可，然后設(shè)置下環(huán)境變量。

啟動(dòng)webui 在找不到量化內(nèi)核(quantization kernels)時(shí)，會(huì)自行執(zhí)行編譯，然后會(huì)在這里緩存。把它隨便放個(gè)短路徑的位置或者丟進(jìn)模型文件夾，然后前面提到的修改的quantization.py的路徑寫對(duì)就行。

這可以看到明明已經(jīng)正確編譯了，可是原始程序偏偏因?yàn)闊o法讀取而報(bào)錯(cuò)，這太蠢了。

所以就有了上面的方案，手動(dòng)指定內(nèi)核路徑。

因?yàn)樽畛跏菍懡鉀Q問題的，但想了想還是寫下如何本地搭建，所以就成倒敘了。

搭建:

1.安裝 git

2.找個(gè)空文件夾

3.輸入 git clone https://github.com/Akegarasu/ChatGLM-webui

4.然后下載模型:

如果顯存大如16G，就下載全量的chatglm-6b，12G用int8。

8G顯存玩int8量化不穩(wěn)，適合int4,即使int4也容易在十幾輪后爆顯存

5.啟動(dòng)方式后面加 --model-path 用于指定模型文件夾路徑

如圖,我的文件夾是glm-int4，完整寫法就是python webui.py --model-path "glm-int4"

6.使用webui-start.cmd啟動(dòng)，將自動(dòng)安裝環(huán)境。

使用和上面一樣的方法修改模型所在路徑。

如果不修改，默認(rèn)將會(huì)下載13G的模型，那就違背優(yōu)化加載初衷了。

正式使用

不過這個(gè)ai的智商就…很感人…很不穩(wěn)定。而且輸出公式會(huì)導(dǎo)致非?？?。

能跑就行，能跑就行

參數(shù)解釋

top-p

模型不斷生成回復(fù)時(shí)，它有許多可選字詞。top-p低了候選就多，高了候選就少。

Temperature

溫度用于調(diào)整隨機(jī)程度的數(shù)字，小了模型輸出結(jié)果盡可能一致，高了則更隨機(jī)。

不過調(diào)這倆參數(shù)在這個(gè)模型和webui上我感覺沒啥區(qū)別，重復(fù)問它只是不斷復(fù)讀。