2025/12/13
元々この記事は、LLM を動作させる backend と、それを使う AI tool について書いていたのですが、長くなってしまうので LLM backend のみについてにします。
AI tool 以降は別記事として投稿します。

LLM を使った AI Agent を作っていると、やっぱり便利だなぁと思うわけで。
で、我が身を振り返ると、completion として GitHub Copilot を使っているだけで、全然 AI 化されていないことに気付いた。
LLM に（ほんの少しだけ）関わってる身として、それはどうなの？と思ったので、早急に改善する。

どの backend を使うか

2025年12月時点でも、本当に色々なサービスがある。お金を払いさえすれば、AI はかなりのことをやってくれる。
しかし私はひねくれ者なので、あえてこれらを使わず、全部無料のもので揃えてしまおうと思う。
（ただのケチであるという説もある）

色々試したのだが、現時点（2025年12月）では　LLM に推論させる backend として、ollama が良いと思う。

使ってみると、本当に便利
GGUF 形式しか対応しないが、既にたくさんのモデルが自動的にダウンロード出来て、使えるようになっている
自分で Fine Tuning したモデルを使うことだって可能

ちなみに ollama の他には以下のもの等がある。（まだまだいっぱいあるけど）

ollama のインストールと設定

OS は Ubuntu です。（断言）

公式のインストール方法が一番信頼度は高いが、User や Group を追加しなければならなったり、バイナリが /usr/local/bin の下に入ったりと、ちょっと気持ち良くはない。
なので、asdf 経由でインストールする。
（asdf は本当にオススメ）

asdf plugin add ollama
asdf install ollama latest
asdf global ollama latest

インストールは上記で終了。（2025年12月現在で、Version 0.13.2）
後は、ollama serve を自動的に起動する設定を追加するだけ。

~/.ollama というディレクトリが自動的に作られているはずなので、~/.ollama/ollama_serve_asdf.sh というファイルを以下の内容で作る。

#!/usr/bin/bash
export PATH="${ASDF_DATA_DIR:-$HOME/.asdf}/shims:${HOME}/.local/bin:$PATH"
export ASDF_CONFIG_FILE=${HOME}/.asdf/asdfrc
export OLLAMA_KEEP_ALIVE=0
export OLLAMA_CONTEXT_LENGTH=131072
export OLLAMA_FLASH_ATTENTION=1
export OLLAMA_KV_CACHE_TYPE="q8_0"
ollama serve

chmod +x ~/.ollama/ollama_serve_asdf.sh も忘れずに。

設定している ollama 関係の環境変数について

上記の設定ファイルの中で、ollama 関係の環境変数を４つ設定している

OLLAMA_KEEP_ALIVE
OLLAMA_CONTEXT_LENGTH
OLLAMA_FLASH_ATTENTION
OLLAMA_KV_CACHE_TYPE

`OLLAMA_KEEP_ALIVE` について

私は ollama で様々なモデルを試したいと思っているのだが、私の手元の PC は VRAM が約 16GiB しかなく、なるべくメモリを節約したい。
OLLAMA_KEEP_ALIVE を 0 にすると、推論した直後に（ollama stop のように）モデルを停止してくれる。（公式FAQ）
デフォルトだと 5 分間モデルをキープするので、VRAM がすぐに枯渇してしまう。
なので VRAM がジャブジャブある人は、これを設定する必要はない。
個人的には、ollama でモデルをロードする時間は気にならない（GPU がそれほど良くないので、推論にけっこう時間がかかる）ので、これで十分使えると思っている。

`OLLAMA_CONTEXT_LENGTH` について

使っていると「あれ？私の ollama 精度低くない？」と思うことが度々あった。
この場合、この OLLAMA_CONTEXT_LENGTH のせいであることが多いと思う。

無限の長さの文章を学習したり推論したりすると無限にメモリが必要なので、どちらの場合もある程度の長さで文章をブチ切らないといけない。それが「コンテクスト長（Context Length）」。

このコンテクスト長には２種類あって、

ollama server の OLLAMA_CONTEXT_LENGTH
- ollama のサーバーが処理する最大コンテクスト長
- デフォルトで 4096
ollama で動作するモデルの context length
- モデルが学習・推論する時に受け取る最大コンテクスト長
- モデルによって異なる

モデルの context length は、ollama show [モデル名] というコマンドで確認できる。

ollama server は「VRAM が少ない環境で動くように」と親切で 4096 という比較的小さい値に設定してくれている。しかし、複雑なタスクを行う際には、これが仇になる。

例えば gpt-oss:20b 自体は context length が 128K(131072) あるのに、ollama server の OLLAMA_CONTEXT_LENGTH で 4096 に限定してしまうと、モデル自体には複雑な処理を出来る能力があるのに、それをオミットしてしまうことになる。

なので OLLAMA_CONTEXT_LENGTH は大きければ大きい方が良いが、大きすぎるとそれだけ VRAM を食うし、モデルの context length を超えても意味はない。
（モデル側がブッ千切ってしまうだろう）
ざっと ollama が対応しているモデルを見ると、有名なモデルの中には 256K のものもあるけど、16GB の VRAM で動くモデルの context length は大きくても 128K っぽいので、131072 にしておけば問題ないだろう。
（もちろんこの設定にしてあなたの環境でも動けば、だが）

OLLAMA_CONTEXT_LENGTH を 131072 にした場合、どれだけ VRAM を余分に食うのかを試してみた。
ただメモリの消費量を見たいだけなので、適当に超長い文章作って gpt-oss:20b に食わせた。
（夏目漱石「こころ」を青空文庫から引っ張ってきて、100文字以内で要約させた）

OLLAMA_CONTEXT_LENGTH=4096（デフォルト）の場合
- VRAM 使用量: 最大 12504 MiB
- 結果: 何をしたら良いのか分からないようで、最後の方の文章を英訳したりした
OLLAMA_CONTEXT_LENGTH=131072 の場合
- VRAM 使用量: 最大 14734 MiB
- 結果：「鎌倉で出会った先生と親戚を通じて、恋愛や家族の悩み、死への葛藤を語る自叙伝。」

約 2.2 GiB ほど増加している。
そして結果から見ると、OLLAMA_CONTEXT_LENGTH でのぶった切り方は、テキストの最初を切り取るんじゃなくて、テキストの終わりから切り取るっぽい。これは OLLAMA_CONTEXT_LENGTH が短いと何をしたら良いか分からなくなるわけだ。

余談

ollama は自分で作った（Fine Tuning した）モデルなども動かすこともできる。
例えば、HuggingFace Hub から適当なモデル（このモデルは HuggingFace 形式と呼ばれる）をダウンロードし、llama.cpp で GGUF 形式に変換して、これに対応する Modelfile を作って ollama create することで、そのモデルが ollama に組み込まれて使うことが出来る。

これによって、Fine Tuning 自体は transformers でやって、それを ollama で動かす、なんてことが可能になる。

HuggingFace 形式のモデルを GGUF 形式に変換した場合の context length はどうなっているのだろうか。
日本語で事後学習されたモデルを３つダウンロードし、ollama で動かしてみた。
まずは Modelfile で（GGUF 形式のファイルがどこにあるかだけを指定した他は）何も指定せずに ollama で動かした場合。

elyza/ELYZA-japanese-Llama-2-7b-instruct
- パラメータ数: 6.7B
- アーキテクチャ: llama（Llama 2）
- context length: 4096
tokyotech-llm/Gemma-2-Llama-Swallow-2b-it-v0.1
- パラメータ数: 2.6B
- アーキテクチャ: gemma2
- context length: 8192
lightblue/karasu-1.1B
- パラメータ数: 1.1B
- アーキテクチャ: llama（TinyLlama）
- context length: 2048

これらの context length の値がどこから来たものかと言うと、 transformers.AutoModelForCaucalLM.config.max_position_embeddings の値がこれらと完全一致した。あまりに完全一致なので、疑う余地は無いだろう。

とすると、（学習時の）context lengeh が短い（HuggingFace 形式の）これらのモデルは、長い Prompt が必要となる実際のタスクでは使い物にならないのだろうか。

ダウンロードした HuggingFace 形式の中には config.json があり、ここに max_position_embeddings の設定があるので、この値を強引に 131072 に書き換えてから GGUF 形式に変換して動かしてみた。

すると、動かなかった。GGUF 形式への変換は成功し、ollama でもモデルを認識することは出来て、しっかり context length の値も 131072 と認識されているのだが、動かすと使用 VRAM の量が 15GB を超えてダウンしてしまった。Q4_K_M や MXFP4_MoE の量子化を施してもダメだった。
（量子化の手法については、こちらに素晴らしくまとめられている）
（MXFP4_MoE は gpt-oss で採用されている量子化手法。MXFP4（4bit浮動小数点）に量子化する。MoE(Master of Experts) については、モデルがそういう構成（mixtral:8x7bとか）だったら有効かもしれないけど。llama.cpp にあったからやってみた…）

なので、context length の値はモデルの構造と密接に関連しているので、うかつに変えることは出来ないのだろう。Fine Tuning の際に max_position_embeddings の値を変えてやれば良いかもしれないけど…ダメな気がする。

色々実験をしたので、その結果だけは残しておく。

ollama serve 側の OLLAMA_CONTEXT_LENGTH は 131072
モデルは tokyotech-llm/Gemma-2-Llama-Swallow-2b-it-v0.1（context length: 8192）
gpt-oss:20b の場合と同様に、夏目漱石「こころ」を要約させてみた

条件	バイナリサイズ	最大使用VRAM	実行時間（参考値）
量子化をしない（FP16）場合	5.2 GB	6718 MiB	12.121秒
`Q4_K_M` による量子化をした場合	1.7 GB	3184 MiB	7.631秒
`MXFP4_MoE` による量子化をした場合	2.8 GB	4208 MiB	10.445秒

結果の文章は、あまり変わらなかった。実行時間は出力の長さにも依るので、ご参考まで。

なので、Small な Language Model は context length も短いので、比較的簡単なタスクしかこなせませんよ、ということだろう。まぁ 8192 や 4096 だって普通のテキストならば十分大きいのだが。

`OLLAMA_FLASH_ATTENTION` と `OLLAMA_KV_CACHE_TYPE` について

OLLAMA_FLASH_ATTENTION

VRAM の消費量と処理の高速化の手法のひとつ
Transformer で結局つらいのは Attention の計算
タイリングとカーネル融合で計算量を O(N^2) から O(N) に落とす
論文はこちら
ちなみにまだ prerelease だけど ollama v0.13.4 から自動的に付けられるらしい

OLLAMA_KV_CACHE_TYPE

これも VRAM の消費量と処理の高速化の手法
やっぱり Attention をなんとかしたい
モデルの量子化ではなく、（ollama の）キャッシュを量子化する
指定できるタイプは f16, q8_0, q4_0 の３つ
- f16: デフォルト（量子化しない）
- q8_0: メモリ使用量がちょっと少なくなるし、性能がほとんど落ちない（推奨）
- q4_0: メモリ使用量はかなり少なくなるけど、性能がちょっと落ちる
より詳細はこちら
有効にするには、OLLAMA_FLASH_ATTENTION=1 が必須

ということで検証してみた。

使ったモデル
条件
- なし: OLLAMA_FLASH_ATTEMTION=0, KV_CACHE_TYPE="f16"
- FLASH_ATTENTION: OLLAMA_FLASH_ATTENTION=1, KV_CACHE_TYPE="f16"
- KV_CACHE_TYPE: OLLAMA_FLASH_ATTENTION=1, KV_CACHE_TYPE="q8_0"

使用VRAM量：

モデル	なし	FLASH_ATTENTION	KV_CACHE_TYPE
oss-gpt:20b	14734 MiB	14742 MiB	14662 MiB
llama2:7b	6224 MiB	5886 MiB	4988 MiB
qwen3:4b	15336 MiB	15338 MiB	13406 MiB
gemma3:4b	6588 MiB	6588 MiB	5782 MiB

所要時間：
※注意※ 所要時間は回答の長さによって全く異なるし、Thinking Mode があるモデル（oss-gpt:20b, qwen3:4b）だと、その長さによっても変わるので、あくまで参考値

モデル	なし	FLASH_ATTENTION	KV_CACHE_TYPE
oss-gpt:20b	1:48.47	2:14.25	1:43.43
llama2:7b	0:12.88	0:11.09	0:8.55
qwen3:4b	11:19.54	14:11.34	3:52.79
gemma3:4b	0:48.35	0:49.87	0:44.21

ちなみに:

動かしてみての感想：
- oss-gpt:20b
  - 無料なのにすごい精度が高い。Thinking Mode もかなり正確に思考している
- llama2:7b
  - かなり高速だが、精度は低い
- qwen3:4b
  - 非常に遅く、VRAM使用量多いが、精度は高めか。ただ、Thinking Mode が冗長になりがち
  - これら２つの高速化の恩恵を一番受けると思う。やるのとやらないのとではかなり体感が違う
- gemma3:4b
  - Thinking Mode がないので回答が指示に沿わない場合があるが、高速で精度も高いと思う
Llama3.1, Llama3.2 は共に動かなかった。Llama3 シリーズの評判が良くなく、meta が急いで Llama4 を作っているという噂が身に染みて分かった
Thinking Mode についてはこちらにまとめられている
HugginFace から GGUF に変換して動かす場合も、FLASH_ATTENTION, KV_CACHE_TYPE 両方ちゃんと働く

結論：今回は小さいモデルでしかやってないので、それほど改善されていないけど、付けても全く問題ないし、確実に少しでも改善するので、やるしかないよね。

設定の続き

次に以下の内容で ~/.config/systemd/user/ollama.service というファイルを作る。

[Unit]
Description=Ollama Service
After=network-online.target

[Service]
ExecStart=%h/.ollama/ollama_serve_asdf.sh
Restart=always
RestartSec=3

[Install]
WantedBy=default.target

後は以下のコマンドを叩いてサービスに登録するだけ。

systemctl --user daemon-reload
systemctl --user enable ollama.service
systemctl --user start ollama.service

ollama をアンインストールしたい場合は、以下のコマンドで完全削除出来るだろう。

systemctl --user stop ollama.service
systemctl --user disable ollama.service
asdf uninstall ollama
asdf plugin remove ollama
rm -rf ~/.ollama
rm -f ~/.config/systemd/user/ollama.service

ollama を使ってみる

gpt-oss:20b をダウンロードする。

ollama pull gpt-oss:20b

使おう。