ARTICLE / 00208 章立て

モデルを増やす前に、使い方を軽くする。

Ollama、量子化、VRAM、Context を試しながら、ローカル AI を「ダウンロードしたモデル」から作業の土台へ見直した記録。

Local AI
量子化
環境

毎回 Ollama からモデルを取るわけではない。Hugging Face からモデルや GGUF を直接選び、どの runtime で動かすかを後から決めることも多い。Ollama は取得、管理、ローカル API の入口を簡単にしてくれる。

量子化形式、Context、GPU メモリ、実行方法まで気になり始めると、llama.cpp と GGUF を調べるようになった。モデルの入手元、ファイル形式、runtime、Agent は別々に考えた方が、何が起きているか見えやすい。

主な環境は Windows のデスクトップ、RTX 3080 Ti、64GB RAM と SSD。Qwen3.8-27B のようなモデルでは重み、KV cache、Context、ほかのアプリの余白を一緒に見る。SSD は読み書きを助けるが、VRAM を増やすものではない。

導入の手間が減ると、次の疑問が見えてくる。概念図

01
準備
モデルを用意
02
実行
読み書きとツール
03
確認
仕事が続くか

最初はモデルのファイルサイズばかり見ていた。圧縮して VRAM に近づけば使えそうだと思ったが、実行中には KV cache、作業領域、バッファもある。Windows とほかのアプリにも余裕が必要だ。

Agent にはファイル、差分、ツール説明、端末出力が積み重なる。Context や session が増えてメモリが上がり、画面が重くなった。driver reset や Windows freeze も経験した。自分の環境での出来事で、すべての構成に当てはめない。

今は余裕を残し、最大 Context をいきなり使わない。一件が安定して終わることを確かめてから長さや並行数を増やす方が、自分には現実的だ。

重み、KV cache、作業用メモリを分ける。概念図

手順	重み	Context	余裕
モデルの本体	含む	含まない	含まない
KV cache の予算	含まない	含む	含まない
実行環境とほかのアプリ	含まない	含まない	含む

GGUF を調べると Q4_K_M、Q8、IQ 系列によく出会う。最初は bit 数だけで順番を付けていたが、形式、runtime の対応、残るメモリも見るようになった。

小さい IQ3 系は、大きなモデルが手元の機材に近づくので魅力的だった。ただ、重みを減らしても Agent の長い Context は残る。小さなダウンロードを、そのまま長時間の安定性とは考えない。

llama.cpp / GGUF を研究の基準にして、組み合わせを比較したい。量子化の順位が完成したわけではない。次は同じ作業を固定して、話し方より修正と確認が終わるかを見たい。

容量: 重みと残る余裕
対応: runtime で使えるか
完了: 同じ仕事を終えるか

AWQ、GPTQ、QAT を調べると、量子化は 4-bit という表示だけでは読めないとわかった。方法ごとに誤差の扱いが違い、最後は目的の runtime がその形式を扱えるかを見る。

Hugging Face の元の重みと GGUF を直接比べることもある。Unsloth の Qwen3.8-27B-GGUF は、量子化済みの Qwen3.8-27B を試す具体的な入口だった。ファイルの大きさ、残るメモリ、動かし方を同じ条件で考えられる。

Unsloth を自分の Harness や学習結果として扱っているわけではない。量子化モデルを入手して比較する一つの経路であり、取得した後は llama.cpp、vLLM などの推論環境に渡して、仕事に合うかを確かめる。

方法: AWQ / GPTQ / QAT
数値形式: FP8 / NVFP4
実行: runtime と GPU を確認

Prefill は提示と Context を読む段階、Decode は生成、TTFT は最初の token までの待ち時間。出力が始まってから速くても、その前が長ければ作業のリズムは途切れる。

Agent はファイルやツールの結果を次の段階へ持ち込む。次の比較ではモデルの読み込み、入力の処理、最初の出力、生成を分けて記録したい。Context が長くなったときの待ち時間も、一つの tokens/s にまとめない。

読み込み、Prefill、TTFT、Decode を分ける。概念図

01
読み込み
モデルを準備
02
Prefill
提示と Context を読む
03
Decode
TTFT と生成を記録

NInfer では特定のモデル、機材、runtime を合わせる方向に注目した。Strata では GPU に収まらないとき、PC 全体でどう分担するかを考えた。興味がモデル選びから実行環境へ広がった。

二つは研究対象で、プロジェクトの展示速度を自分の Windows PC の成果にはしない。デプロイの道具も機材に合わせる必要がある。Ollama、llama.cpp / GGUF、LM Studio、vLLM で起動、API、Context、ツール呼び出し、安定性を比べている段階で、完成済みの一つの配置ではない。

研究の対象と、実測の結果を分ける。概念図

NInfer

特定構成の実行を調べる

Strata

PC 全体の分担を調べる

同じ repository、task、test を固定し、モデル、量子化、runtime、harness を変えてみたい。主要な条件を一つずつ変える方が、違いを追いやすい。これは次のテスト計画だ。

時間とメモリ以外に、ツール呼び出し、変更内容、テストの実行、人の助けが必要だったかも見る。最後に使える結果かどうかの方が、文字量より日々の仕事に近い。

会話の速さから、仕事の結果へ。概念図

01
固定
repo・task・test
02
観察
時間・資源・ツール
03
確認
使える結果か

今はローカル AI を、モデルファイル、モデルを動かす runtime、必要なときに公開する API / サービス、そして仕事を進める Harness の四つに分けている。Harness はプロジェクトを読み、ツールを使い、Context と権限を扱い、結果を受け入れ確認へ戻す。これは同じ製品ランキングではなく、仕事の中の役割だ。

モデルの入手先は一つではない。Hugging Face から元の重みや GGUF を直接探すこともある。Ollama は取得・管理・ローカル API の入口を簡単にし、llama.cpp は GGUF、量子化、GPU 実行を深く調べる入口になる。vLLM はサービスとスループットを意識した推論エンジンだ。llama.cpp 自体も server API を出せるので、サービスは別製品が必須という意味ではない。

日常の主力は OpenCode と Codex だ。Pi、DeepSeek Harness、MiniMax Code などは設計の違いを知るために試している。モデル、Context、ツールのつなぎ方を見ているが、試用を日常の開発経験としては書かない。

MODEL: 重みそのもの
RUNTIME: llama.cpp / GGUF / 推論
SERVICE: Ollama / vLLM / API
HARNESS: Context・ツール・受け入れ

モデルを増やす前に、使い方を軽くする。

Ollama を入口にし、Hugging Face へ広がった。

ファイルが収まっても、余裕は必要だった。

Q4、Q8、IQ を同じ仕事で見たい。

AWQ、GPTQ、QAT は名前を増やす話ではない。

話し始めるまでの待ち時間も見る。

NInfer と Strata で、問いが広がった。

次は、同じ仕事を最後まで比べたい。

モデル、Runtime、サービス、Harness を分ける。