個人的な日本語ローカルLLM関連のメモ用Wikiです。一般の方は編集できません。

追加された行はこの色です。
削除された行はこの色です。

このWikiは主に日本語対応ローカルLLM(大規模言語モデル)関連のメモ的なWikiです。
ページの内容が古かったり誤った情報が載っているかもなので気をつけて下さい。

----
#contents
*そもそもLLM(大規模言語モデル)ってなに?
LLM(大規模言語モデル)は大量のテキストデータをディープラーニングを使用して学習された自然言語処理モデル、らしい。(正直わからん、俺は雰囲気でLLMを触っている...)


*LLMのざっくりした仕組み
''ユーザーの入力したテキスト(プロンプトと呼ばれる)から続きのテキストデータ(正確にはトークンと呼ばれる文字を区切ったもの)を確率などを用いて予測して出力する。''
例えば”日本の首都は”というユーザーからの入力に対して、事前に学習したデータから確率的に”東京”が一番高い場合、”東京”と出力される。
ものすごく簡単に言えばPCやスマホのIMEの入力補完機能をより複雑にしたもの、かな?
(今日→の→天気→は→...といった具合)

そのため、幻覚(ハルシネーション)と呼ばれる”嘘”をつく。
”架空の人間の名前”とその人の経歴を教えて、と入力すると事前に学習されたデータからそれらしいテキストを出力してまるでその人が実在するかのようにユーザーを錯覚させる。

以下のやり取りは[[TheBloke/Swallow-13B-Instruct-AWQ>>https://huggingface.co/TheBloke/Swallow-13B-Instruct-AWQ]]モデルを使ってテストした例
&color(#ff0000){ユーザー}:佐藤田中さんの経歴を教えて~~
&color(#0075c8){アシスタント}:佐藤田中は、日本の実業家であり投資家です。 彼は、日本で最も成功した起業家の 1 人と見なされており、多くの企業を設立しています。 彼の経歴には、大学卒業後に就職した会社での仕事、自分の会社の設立、投資ファンドの設立などが含まれます。

このため、出力された情報の信憑性には気を付ける必要がある。
一方で出力される情報が正確である必要のない用途(小説を書かせる、キャラクターになりきってチャットを行うなど...)には問題ない...かも

また、学習後に起きた事(時事)なども苦手な分野とされているが、RAGといわれる手法で検索エンジンなどと連携する事でカバーする動きもある。
*なんでローカルで動かすの?
ChatGPTなどに比べて性能に劣るローカル環境で動かす意味と言えば''ロマン''しかないでしょ。%%マロン美味しいよね%%
一般的な用途ならChatGPTとかの方が良いよ
*必要なマシンスペックや使うソフトウェアなど
**PCスペック
基本的にはNVIDIA製のGPUが必要(※Linux環境下ではAMD,Intel製GPUも行けるみたい?)

必要なマシンスペックは動かすモデル(のサイズや量子化タイプなど)と求める応答速度(トークン生成速度)による。

LLMには7B,13B,70B...など◯B、という表記がある。これはモデルのパラメータ数の事で7Bなら70億パラメータという意味になる。
基本的にはこのパラメータ数が多い方が賢いと言えるがパラメータ数が多いほど要求されるVRAM(GPUメモリ)も必要になってくる。(基本的にはLLMはGPU/VRAM上で動作させるので)
ざっくり言えば◯Bの◯を二倍にした値が必要なVRAM容量らしい。(7BならVRAM/14GB)

ただ、量子化という精度(賢さ)を犠牲にして高速化する手法があり、ローカル環境ではこの(事前)量子化されたモデルを動かすことが多い。
//※RTX3060/12GBの場合、モデルのロード時のオプションで"load-in-4bit"を有効にすれば(事前)量子化されてなくても13B程度ならロードできる(精度は落ちるけど)
(生の16ビットモデルを)8ビットに量子化したモデルなら◯B=◯GB VRAM(7Bなら7GBのVRAM)、4ビットに量子化したモデルなら◯B=(◯の1/2)GB VRAM(7Bなら3.5GBのVRAM)が必要

※ちなみに、画像生成AIと違ってローカルLLMは複数のGPUを組み合わせて動作させれるのでマイニング用ライザーカードと複数のRTX3060/12GBで動かす方%%変態%%も居られるとか %%こっわ%%

量子化されていないモデルをロードする時に8ビットor4ビットで読み込む方法と事前にモデルを量子化(変換)する方法がある。(後者は事前量子化と言われる)

[[事前量子化の種類>https://local-llm.memo.wiki/d/%a4%cf%a4%b8%a4%e1%a4%cb#content_5_6]]によって要求されるスペックが異なる。

-GGUF(旧GGML)
CPUやメインメモリで動く量子化タイプ
GPUなしでも動作するし、一部をGPUへオフロードする事もできる。(あとmacでも動くらしい)
%%できるだけ多コアCPUで積めるだけのメインメモリがある方が良い。%%
%%動かかすモデルのサイズ(◯B)にもよるが、最低6コア/12スレッド以上のCPU、32GB以上のメインメモリは欲しい。(できれば8コア/16スレッド、64GB以上)%%
現在市販されているCPUなら4コア/8スレッド程度でも実用上は変わらないようだ。
メインメモリの帯域(転送速度)がボトルネックになるので下手に高性能なCPUやメインメモリにコストを掛けるよりそのお金でGPUを良いものにした方が速度は出ると思う。
Ryzen 5700X(8コア/16スレッド)メインメモリ88GB/DDR4-2666(うち60GBを割り当て)+ RTX3060/12GBへオフロードして70B(q4_K_M)モデルが動いた(チャットとしては返答速度が遅いが我慢すれば使えるレベル)

GGUF形式の70Bモデルを動かすならGPUへのオフロードなしの場合メインメモリは64GBほどは欲しい。(RTX3060/12GBへオフロードできるんなら32GBでも行けるかも)

-GPTQ
GPU専用
RTX3060/12GBで13B@4bit量子化モデルが動いた。(チャットとして実用的なレベル)

-AWQ
GPU専用 GPTQより新しい量子化の手法
RTX3060/12GBで13B@4bit量子化モデルが動いた。(チャットとして実用的なレベル)

現在市販されているミドルクラス以上のPCスペックならGGUFで70Bモデルは動くと思う。(低速かも)
GPTQまたはAWQの場合はGPUがRTX3060/12GBでは13B@4bitモデルが限度かと
//※GPTQなどで量子化したモデルの場合は◯B=VRAM◯GBぐらい必要らしい。(7Bで必要VRAM/7GB)

言語モデルのファイルサイズ×1.2倍が必要なVRAMのおおよそのサイズ(?)
**ソフトウェア
ローカルでLLMを動かす際にCLIから言語モデルを利用するのはあまり現実的ではないのでなんらかのフロントエンド(UI)が必要になる。
//ローカルでLLMを動かす際の(スタンドアロン)フロントエンドとして[[Text generation web UI>>https://github.com/oobabooga/text-generation-webui]](通称、ooba,大葉)をこのWikiでは扱う。
このWikiでは(スタンドアロン)フロントエンドとして[[Text generation web UI>>https://github.com/oobabooga/text-generation-webui]](通称、ooba,大葉)を主に解説する。
他にも同様のフロントエンドとして[[koboldcpp>>https://github.com/LostRuins/koboldcpp]]などがあるが、Text generation web UIと比べると日本語圏での利用者が少ない感じ?
※koboldcppについては[[localmlhub @ ウィキ>>https://w.atwiki.jp/localmlhub/]]が詳しくておすすめ
//メモ:[[open-webui>>https://github.com/open-webui/open-webui]]が個人的に気になっている...

その他、Text generation web UIやkoboldcppなどを必要とするロールプレイ/チャットなどに特化したプロキシフロントエンドと呼ばれるソフトウェアもある。
代表的なのが[[SillyTavern>>https://github.com/SillyTavern/SillyTavern]]で、そのほか[[RisuAI>>https://github.com/kwaroran/RisuAI]]など、これらのソフトウェアはText generation web UI(やkoboldcpp)と同時に実行する(接続する)必要がある。
//その他、Text generation web UIやkoboldcppなどをバックエンドとして使い、ロールプレイ/チャットに特化したフロントエンドのソフトウェアとして[[SillyTavern>>https://github.com/SillyTavern/SillyTavern]]などもある。
*言語モデルの種類(バリエーション)など

**ベースとしている言語モデル
現在、日本語モデルで実用的なものは1から作られたものよりオープンなLLMをベースにしたものが多い
ローカルで動く日本語対応言語モデルだとMate社が開発したLLaMA系列が強い(賢い)感じ(個人的な感想です)
→[[Swallow>>https://tokyotech-llm.github.io/swallow-llama]]や[[ELYZA-japanese-Llama-2>>https://huggingface.co/elyza/ELYZA-japanese-Llama-2-13b-instruct]]など

他にも中国のAlibabaが開発した''Qwen''をベースとしてファインチューニングした[[Qarasu>>https://prtimes.jp/main/html/rd/p/000000053.000038247.html]]や、仏Mistral AI社が開発した''Mistral''をベースにした''[[Shisa>https://huggingface.co/augmxnt/shisa-7b-v1]]''、''Shisa''に対して継続事前学習とファインチューニングを行った''[[Karasu>>https://huggingface.co/collections/lightblue/karasu-658e78e9188f3934c6fb701e]]''、StabilityAI社の''Japanese Stable LM Gamma 7B''などがある。

ベースとしている言語モデルが同じ場合、''[[mergekit>>https://github.com/cg123/mergekit]]''でモデルのマージが行える(?)
**パラメータ数(◯B)による違い
例えば[[Swallow>>https://tokyotech-llm.github.io/swallow-llama]]には7B、13B、70Bのバリエーションがある。
基本的にこの◯Bが大きいほど賢いと言えるがそのかわり要求されるスペックも相応のものが求められる。

**base/Instructの違い
言語モデルによっては''base''モデルと''Instruct''(or ''Chat'')モデルが公開されている事がある。
''base''は単に入力した文章の続きを書くタイプで''Instruct''(Chat)モデルはチャット(ユーザーとの応答、やり取り)に適するようbaseモデルを微調整(ファインチューニング)したモデル

%%どちらか迷ったら取り敢えずbaseでいいと思う(Instructモデルでも文章の続きを書くことはできるけど精度が落ちるのかな?)%%
%%Instructモデルはベースとしている%%言語モデルごとにテンプレート(書式)があるのでモデルに適したテンプレを使う必要がある。
[+]いくつかあるが、LLaMA2系列だと下記の二種類が有名かな?
<s>[INST]<<SYS>>~~
&color(#ff0000){<ここにシステムプロンプトを入力(あなたはアシスタントです。など)>}~~
<</SYS>>~~
~~
&color(#ff0000){<ここにプロンプト(〇〇を教えて、など)>} [/INST] ~~
最後の[/INST]の後に半角スペースを入れること。

そのほか、下記のような書式もある
&color(#ff0000){<ここにシステムプロンプトを入力(あなたはアシスタントです。など)>}~~
~~
~~
### 指示:~~
~~
&color(#ff0000){<ここにプロンプト(〇〇を教えて、など)>}~~
~~
~~
### 応答:~~
[END]

**事前量子化の種類
huggingfaceなどで有志の方が事前量子化したモデルを公開されている場合がある。

現時点(2024/01/26)では下記の%%3つの%%事前量子化タイプがある。
量子化のタイプで迷ったらとりあえずGGUFで良いと思う

-GGUF(旧GGML)
GPU/VRAMでなく、CPUやメインメモリで動くタイプ(※GPUへオフロードさせることもできる)
※ただしCPUだけで動かす場合、同じ◯Bモデルなら下記のGPTQなどと比べて遅い?(あとmacでも動くらしい)
非量子化、k-量子化、i-量子化などをサポート
[[llama.cpp:複雑化する量子化バリエーションの整理(2024.02現在)>>https://sc-bakushu.hatenablog.com/entry/2024/02/26/062547]]によれば、
おすすめの量子化サイズ~~
性能重視の場合(VRAM容量に余裕がある場合)は、6bit量子化の"Q6_K"あたりがよいと思います。7Bモデルの場合、キャッシュを除いて5GB強のサイズで、"F16"や"Q8_0"からの性能劣化は実質的に無いとされています。~~
性能とサイズのバランスを取りたい場合、従来のk-量子化だと"Q4K_M"程度までなら無難とされています。iMatrix版を使えるのなら"IQ4_XS", "Q4K_S"でも十分だと思います。これらは、7Bモデルの場合、3.5GB〜4GBくらいのサイズ感です。~~
サイズ重視で小さめのモデルを選びたい場合は、iMatrix版が必須です。3bitの"IQ3_XXS"程度なら意外と劣化を感じにくいと思います。i-量子化で初期に導入されたクラスで、7Bモデルの場合は3GB弱のサイズ感です。2bit以下の量子化になると、劣化が着実に見え始めてくる印象があります。~~
とのこと。


-GPTQ
GPU専用


-AWQ
GPU専用 GPTQより新しい量子化の手法


-EXL2
GPU専用 AWQより新しい量子化の手法

管理人/副管理人のみ編集できます