オープンウェイトのLLMは、いま業務で使えるのか

結論

オープンウェイトのLLMは、ネットワークから切り離された環境や、セキュリティの要件でOpenAIやClaudeのAPIを使えない状況なら、業務で実用の範囲に入っていると思いました。社内ナレッジBOTや、Codexのようなコーディングエージェントからの利用など、普段APIでやっていることはひととおりできました。

バイブコーディングのように対話しながら進める使い方も、AGENTS.mdで指示を絞れば待てる速さでした。既定のままだと待ち時間が長いので、そこだけ手を入れる必要があります。

性能は、公開ベンチマークのArtificial Analysisでも使った感覚でも、1年半ほど前のGPT-4.1やClaude 3.7 Sonnetと同じくらいです。AIを使ったコーディングが活発になり始めたのがちょうどその頃なので、当時のAPIでできていたことを、データを外に出さずにできるようになった、と捉えています。

はじめに

社内のナレッジについて質問すると、DBやGoogle Driveのファイル、Slackのやり取りをもとに答えてくれるチャットボットを作りたいと考えました。機密データを扱うお客様向けにも使えるよう、LLMを自前でホストできないか調べることになりました。

普段はAPI経由でLLMを使っていますが、自分で動かす場合に何が必要なのかは分かっていませんでした。

調べ始めて困ったのは、モデルも、それを動かす機材も選択肢が多いことです。手元のPCで足りるのか、ワークステーションやMacを買うのか、クラウドのGPUを借りるのかで、かかる費用も試せる規模も変わります。個人や小規模な企業でも無理なく払えるインフラ代で、どの組み合わせなら実用になるのかを知りたかったのですが、価格と性能の相場が分からず、何から試せばよいか迷いました。

そこで、まずは業務で使っていたKimiを自分で動かせないか調べました。必要なメモリを確認すると、手元のPCで試せる規模ではありませんでした。別のモデルを探し、最終的にはRunPodでGPUを借りて、5モデルを量子化や設定を変えながら検証しました。

この記事で分かること：

• 手元のPCで動かせないモデルを、機材とモデルの両方からどう絞ったか
• 残った3モデルで社内ナレッジ用のチャットボットを作って比べた結果
• コーディングエージェント（Codex CLI）から使ったときの速度と感触

APIで使うか、自分で動かすか

最初に整理したのが、LLMの利用形態です。入力したデータの行き先で、大きく4つに分けて考えました。

使い方	例	データの行き先	機密データを扱うお客様向けにも使えるか
クローズドモデルのAPIを使う	OpenAI API、Anthropic API	提供元のサーバー	使いにくい
オープンウェイトモデルの配信サービスを使う	Cloudflare Workers AI、Amazon Bedrock	配信事業者のサーバー	使いにくい
クラウドGPUでセルフホストする	RunPod、AWSのGPUインスタンス	自分のアカウント内のクラウド	条件付きで使える
自社の機材でセルフホストする	RTX 5090を積んだPC、Mac Studio	社内	使える

クローズドモデルのAPI

OpenAIやAnthropicのように重みを公開していないモデルは、クローズドモデルやプロプライエタリモデルと呼ばれます。これを提供元のAPIで呼ぶ形です。データは提供元のサーバーに送られます。

学習に使わない、入力を保存しない、と規約で明記されていて、契約にその条件を入れること自体は難しくありません。ただ、守られているかを自分たちで確かめる手段はなく、データの扱いは提供元に委ねることになります。お客様の機密データをそこまで委ねられるかは案件によって違い、委ねられない案件もあります。この記事では、そうした案件を想定して考えます。

オープンウェイトモデルの配信サービス

Workers AIやBedrockのように、事業者が動かしているモデルをAPIで呼ぶ形です。モデルは自分で選べますが、データの行き先は他社のサーバーで、機密データの観点ではクローズドモデルのAPIと変わりません。

クラウドGPUでのセルフホスト

RunPodやAWSでGPUを借り、自分のアカウントの中でモデルを動かす形です。データはクラウドに出ますが、間に他社のサービスは入りません。すでにAWSで業務システムを動かしているお客様なら、同じAWSにサーバーを1台足すのと、リスクの種類は変わらないと思っています。クラウド事業者の法的な管轄やリージョンの問題は残りますが、それは既存のシステムと同じ判断です。許容できるかはお客様の状況次第で、ぎりぎりのところだと感じています。

自社の機材でのセルフホスト

自社のサーバーやPCで動かす形で、データは外に出ません。一番安心ですが、機材を先に買う必要があります。

目安として、GPUのメモリが32GBのRTX 5090を積んだPCで120万円ほど、ユニファイドメモリが128GBのMac Studioで77万円ほどです（2026年9月時点）。容量あたりではMacが安く見えますが、速度は別の話で、そこは後の「GPUをどう選ぶか」で触れます。どの規模のモデルが要るか分からない段階では、どの機材を買えばよいかも決められません。

今回は費用を抑えるためクラウドGPU上でのセルフホストで検証を進めました。

どうやって動かすのか

まず調べたのは、モデルをどこから取得して、何を使って動かすのかでした。

Hugging Faceなどで公開されているモデルの重みを取得し、推論エンジンで読み込むのが基本です。アプリケーションから使う場合は、推論エンジンをAPIサーバーとして起動して呼び出します。

推論エンジンについて

推論エンジンは、モデルの重みを読み込んで回答を生成するソフトウェアです。vLLMのようなサーバー向けのエンジンは、KVキャッシュの管理や複数リクエストの同時処理も受け持つので、同じモデルでもエンジンと設定で速度やメモリ使用量が変わります。

ClaudeやGPTをAPI経由で使うときは意識しなくて済んでいた、この実行部分も用意するのがセルフホストです。vLLM、llama.cpp、SGLangなどから、使いたいモデルと量子化形式、GPUに対応しているものを選びます。

今回はvLLMを使いました。社内の複数人から同時に使う想定だったので、GPUで多数のリクエストを同時にさばく前提で作られているものを選んでいます。

同じモデルにも複数の形式がある

モデルを探すと、同じ名前の後ろにBF16、FP8、AWQ、INT4、GGUFといった表記が付いたものが並んでいます。最初はどれを選べばよいのか分かりませんでした。

モデルの重みは数の集まりで、その1つの数を何ビットで表すかが、この表記の正体です。公開されるモデルの標準は16ビットの小数で、FP16やBF16と書かれます。ここから半分、4分の1とビット数を削って小さくするのが量子化で、削るほどメモリは減り、代わりに回答の正確さが少し落ちます。どれくらい落ちるかは、モデルや量子化の方法、解かせる問題によって違います。重みの大きさは、ビット数から見当が付きます。

名前に付く表記	何か	1パラメータ	30Bなら重みだけで
BF16、FP16	公開時の標準。16ビットの小数	2バイト	60GB
FP8、INT8	8ビットに削ったもの	1バイト	30GB
INT4、AWQ、GPTQ、W4A16	4ビットに削ったもの。AWQとGPTQは削り方の名前。W4A16は「重みは4ビット、計算は16ビット」という意味	0.5バイト	15GB
QAT	4ビットに削る前提で学習し直したもの。品質の落ちが小さい	0.5バイト	15GB
GGUF、Q4_K_M など	llama.cpp用の保存形式。Q4なら4ビット	形式による	形式による

実際のファイルは補助情報が付くのでこの値より少し大きくなります。名前を見て「何バイトか」と「使うエンジンが読める形式か」の2つが分かれば、載るかどうかの見当は付きます。品質は表記からは分からないので、測るしかありません。

GPUをどう選ぶか

動かし方が分かったところで、次に気になったのは、どのGPUなら何が載るのかです。調べていくと、見るところは3つに絞れました。

メモリの容量 → どのモデルを載せられるか
速度        → 計算力（読む速さ）とメモリ帯域（書く速さ）
GPUの世代   → 使いたい量子化形式が速く動くか

メモリ容量で載るモデルが決まる

例えば配信サービス（Cloudflare Workers AI）経由で業務に使っていたKimi K2.6は、モデルカードによると総パラメータ数が1Tで、重みをすべて4ビットにしても単純計算で500GBです。

「32B activated」ともありますが、これはMoEという構造で1トークンの処理に使う部分の大きさで、メモリには全体を載せる必要があります。48GBのGPUを1枚借りる構成では、まったく届きません。

ただ、モデルのファイルサイズだけではGPUを選べないことも分かりました。推論時には、おおむね次の合計が必要です。

必要なメモリ ≒ モデルの重み + KVキャッシュ + 実行時の作業領域

KVキャッシュは、それまでのトークンについて計算した情報を再利用するための領域です。必要量はモデルの構造やキャッシュの精度に加え、入力・出力の長さ、同時に処理する件数で変わります。

そのため、重みが40GBのモデルでも、48GBのGPUで十分とは言えません。パラメータ数と量子化形式で重みの大きさを見積もって候補を絞り、使う予定の入力長と同時実行数で動かして確かめる、という手順になりました。

速度は読む速さと書く速さに分かれる

LLMの処理は2段階に分かれていて、決め手になるGPUの性能が違います。

prefill（読む） 渡した文章をまとめて読み込む → 計算力で決まる
decode（書く）  回答を1トークンずつ生成する  → メモリ帯域で決まる

読み込みは大量の行列計算なので、GPUの計算力で決まります。カタログでは、先ほどの16ビットの小数（FP16）の計算を1秒に何回できるか（TFLOPS）で示されます。

書く速さは、1トークン書くたびにモデルの重みを丸ごと読み出すので、メモリ帯域、つまり1秒間にどれだけの重みを読み出せるかで決まります。

用途によって効く側が違います。長い資料を渡して短く答えさせるなら読み込みの時間がほぼすべてで、短い質問に長く書かせるなら書く速さが効きます。体感に近いのは、送ってから回答が出始めるまでの時間（TTFT）で、これは読み込みの時間に左右されます。

同じGPUでも、モデルによって読む速さも書く速さも数倍違います。同じモデルでも、GPUを替えれば変わります。読む速さは計算力に、書く速さはメモリ帯域にほぼ比例するので、カタログ値から見込みが立ちます。今回のA40は安さで選んだので、速さが要るなら上のGPUに載せ替えることになります。

GPU	メモリ	計算力（FP16、TFLOPS）	メモリ帯域	購入価格の目安（2026年9月）
A40（今回）	48GB	約150 TFLOPS	696GB/s	約95万円〜120万円
RTX 5090	32GB	約210 TFLOPS（約1.4倍）	1,792GB/s（約2.6倍）	約70万〜100万円
A100 80GB	80GB	312 TFLOPS（約2.1倍）	2,039GB/s（約2.9倍）	約360万円~400万円
H100 SXM	80GB	989 TFLOPS（約6.6倍）	3,352GB/s（約4.8倍）	約520万〜570万円

RTX 5090は書く速さは大きく伸びますが、読む速さはA40とそれほど変わりません。長い入力を毎回送る用途では、計算力のほうが効きます。

GPUの世代で量子化が効くかが変わる

GPUの世代で決まるのは、どの数値形式を計算回路が直接扱えるかです。Ampere（A40、A100）は16ビットまでで、Ada（RTX 4090、L40S）とHopper（H100）からFP8が、Blackwell（RTX 5090）からFP4が加わります。回路が扱えない形式のモデルを載せると、計算のたびに16ビットへ戻すので、その形式の速さは出ません。今回のAWQ int4は、重みだけを4ビットで持ち、計算は16ビットで行う方式なので、Ampereでも速さが出ます。効果が出るのは書く速さで、重みが半分になれば約2倍、4分の1なら約4倍が上限の目安です。

Macの場合

ここまでの見積もりは、A40やGeForceのように専用メモリを持つGPUの話です。Apple SiliconのMacはCPUとGPUがメモリを共有するので、大容量の構成なら、専用メモリの小さいGPUには収まらないモデルも候補になります。ただし、OSやほかのアプリが使う分は差し引いて考えます。帯域はM4 Maxで546GB/s、M3 Ultraで819GB/sと、A40と同じくらいです。実行基盤も、CUDAを使うvLLMやSGLangではなく、Metalを使うllama.cppやMLX LMになります。

モデルをどう選ぶか

Kimiが載らないと分かったあとは、公開情報で候補を絞り、残ったものを借りたGPUで動かして測ることにしました。

日本語と画像を扱えるモデルから候補を探す

モデルを探し始めると、候補の多さに迷いました。Qwen、Llama、DeepSeek、Gemma、Phi、gpt-ossなど、よく名前を見かけるものだけでも、それぞれにサイズや派生モデルがあります。

まずはこうしたモデルを中心に、Artificial Analysisなどの性能比較や公開ベンチマークを参考にしました。そのうえで、次の3点を見ていきました。

• 日本語である程度やり取りできそうか
• 画像を入力できるか
• 必要なメモリが大きすぎないか

社内のナレッジについて質問する際には、文章だけでなく画像も添付できるようにしたいと考えました。例えば、資料の図表についての質問や、エラー画面を見ながらの原因・対処方法の確認などです。そのため、日本語で質問を受け、画像も読めるモデルの中から、できるだけ回答性能のよさそうなものを試すことにしました。

量子化した重みのサイズとGPUの料金も見ながら候補を絞り、今回はGemmaとQwenを試すことにしました。ライセンスの条件もモデルごとに確認しています。公開スコアは候補を決めるための目安で、実際の使い心地は動かして確かめることにしました。

実際に動かす5モデルを決める

検証計画では、48GBのGPUに載る範囲で、役割の違う5モデルを選んでいます。

• Gemma 4 31B：48GBに載るなかで一番大きい。回答品質の上限を見るため
• Gemma 4 26B A4B：同じGemma 4のMoE版。31Bに近い品質で速く動くなら本命になる
• Qwen3.8-27B：別の系列で、サイズが同じくらいのもの。Gemma以外の選択肢を残すため
• Qwen3-VL-8B：小型で安い。どこまで小さくして大丈夫かの下限を見るため
• Gemma 4 12B：唯一、量子化なし（BF16）でも48GBに載る。量子化で品質がどれだけ落ちるかを測る物差し

最初の4モデルはAWQ int4を使いました。量子化形式をなるべく揃えて比べるためですが、モデルごとの量子化設定まで完全に同じではありません。12Bは、今回の候補の中でBF16の重みも48GBに収められたため、量子化の比較に使いました。BF16でも動かしてint4と比べ、自由記述の品質に差がなかったので、以降はint4で進めました。

検証のために機材を借りる

機材を買うことも考えましたが、購入した後にメモリが足りないと分かっても、簡単には変更できません。

そこで、検証に必要な時間だけGPUを借りることにしました。48GBで足りなければ、さらにメモリの多いGPUを検討できます。まずモデルを試し、その結果を見て本番の機材を考えるほうが進めやすそうでした。

RunPodでA40 48GBを借りた

クラウドは、まず料金の安いところを探しました。最後まで迷ったのはVast.aiとRunPodです。RunPodを選んだのは、安定して使えそうに感じたことと、CLIやMCPとの連携で操作できそうだったことです。

GPUを選ぶときにまず見たのは、メモリ容量に対する料金です。当時見た候補の中では、A40が容量の割にいちばん安いと判断しました。48GBあれば候補のLLMを動かせそうだったので、検証に使うことにしました。

GPU料金は1時間あたり$0.49で、1ドル150円で換算すると約74円です。モデルを取得してvLLMを起動し、API経由で入力を渡します。各検証はGPU1枚で動かし、一部は複数のインスタンスを借りて並行して進めました。

この単価で1日8時間・月20日動かすと11,760円、24時間起動し続けると52,920円で、これはGPU代だけの試算です。

GPUを買って検証するよりは気軽に試せました。

ただし、APIのトークン課金とは違い、リクエストを送っていない時間にもGPUの料金は発生します。モデルのダウンロードや環境構築、作業を止めていた時間も含めて費用を見る必要があります。停止したPodのストレージ料金が残ることもあったので、結果を回収した後は、不要なPodやストレージを削除するところまで作業に含めています。

本番は、お客様が既に使っているクラウドに置く前提で考えています。

A40で5モデルを動かして3つに絞った

5モデルが動いたところで、どれを本命にするかです。最初は、ベンチマークのスコアが高いものを選ぶつもりでした。品質は2種類で測りました。一問一答はllm-jp-evalの7データセットの正答率の平均、自由記述はELYZA-tasks-100の100問をLLMで採点した5点満点の平均です。同じA40・AWQ int4の条件で測った結果を並べます。

モデル	一問一答	自由記述	25,000トークンの読み込み	書く速さ
Gemma 4 31B	60.45%	4.54	13.73秒	27.1トークン/秒
Gemma 4 26B A4B	54.58%	4.47	2.72秒	105.3トークン/秒
Qwen3.8-27B	39.96%	4.32	12.79秒	30.9トークン/秒
Gemma 4 12B	50.16%	4.32	5.44秒	52.8トークン/秒
Qwen3-VL-8B	45.34%	3.38	4.90秒	91.6トークン/秒

一問一答と自由記述は採点方法も尺度も違うので、横に並べて差を比べられる数字ではありません。それでも、順位の付き方が違うことは読み取れます。Gemma 4の31Bと26B A4Bは、一問一答では6ポイント近く開いているのに、自由記述ではほとんど違いません。一方で速度は、読み込みも書く速さも数倍の差があります。

小型のQwen3-VL-8Bは自由記述が3.38点で、同じ段落を繰り返して出力上限に達する回答が100問中9問ありました。12Bは量子化の比較用に動かしたもので、実在しない固有名詞を挙げる例がありました。画像入力は、応答が返ることだけ確かめました。

Qwen3.8-27Bの一問一答は最下位ですが、回答の形式が合わずに途切れた問題が多く、この数字は実力より低く出ていると考えています。

総合点だけで31Bに決めず、速度を見て26B A4Bを本命にしました。次のチャットボットでは、この26B A4Bに、品質の基準として31B、別系列としてQwen3.8-27Bを加えた3モデルで比べることにしました。

実際にチャットボットを作って測った

社内の情報を探して、その内容をもとに答えるチャットボットを作ってみました。本番の社内データは使えないので、小型家電のオンライン専業ECという仮想の会社を作り、商品も顧客も注文もすべて生成しています。

情報は3か所に散らばっている想定です。確かめたかったのは、1か所を見ただけでは答えが出ない問いにどう答えるかなので、ある商品の返品が増えた、という筋書きを3か所に分けて仕込みました。

どこに	何が	仕込んだ事実
データベース	商品・注文・顧客・返品・在庫	返品率が7月の1.9%から8月に4.1%へ上がった
ファイル置き場	製品仕様書、部品表、議事録、稟議	5月の稟議でヒーター部品を別のサプライヤに変更していた
チャット	問い合わせ対応、品質、調達のやり取り	7月下旬から「持ち手が熱い」という問い合わせが増えていた

データベースの返品データだけを見ても「増えた」としか分からず、原因はファイル置き場とチャットにしかありません。

LLMに任せた仕事

LLMには3つのツールを渡しました。

• データベースにSELECT文を実行する
• 文書置き場をキーワードで検索する
• 社内チャットをキーワードで検索する

どのツールをどの順に、どんなSQLや検索語で呼ぶかはLLMが決めます。SQLの選択肢を用意したり、検索語を足したりする処理はコード側に置いていません。こちらが渡したのは次の3つだけです。

• テーブルと列の一覧
• 文書の種類とチャンネル名
• 「無いものは無いと言う」「権限エラーは推測しない」といった答え方の規則

検索はキーワード検索（BM25）にしました。ベクトル検索を入れると、埋め込みモデルの選定という別の検証が始まるからです。ただ、「返品が増えた理由」という問いと「ヒーター部品の変更」という稟議には共通の単語が1つもなく、そのまま検索しても稟議は出てきません。LLMが自分で言い換えて引き直せるかが、この検証の見どころになりました。

30問を3モデルに解かせた

答えが分かっている質問を並べて、機械で採点しました。観点は6つです。

観点	見ること	問数
転記	資料にある値をそのまま返せるか	8
集計	件数が合っているか	4
捏造	存在しない型番を聞かれて「ない」と言えるか	4
権限	見えない列について数値を作らないか	2
横断	3か所すべてに触れて答えられるか	6
矛盾	資料同士が食い違うとき、新しいほう、データベースのほうを採れるか	6

Gemma 4 26B A4B、Gemma 4 31B、Qwen3.8-27Bに、同じ30問を3回ずつ解かせました。30問×3回で、90点満点です。同じ設定でも生成は毎回同じにならないので、3回のぶれも見ています。思考モードのオン・オフでも変わるので、両方測っています。

モデル	思考オフ	1問あたり	思考オン	1問あたり
Gemma 4 26B A4B	78/90	3.9秒	82/90	12.9秒
Gemma 4 31B	84/90	11.5秒	84/90	37.1秒
Qwen3.8-27B	90/90	23.9秒	90/90	53.6秒

転記、集計、権限は3モデルとも落としませんでした。SQLはLLMが書いたもので、返品と注文を結合して返品日で絞り、理由コードで数えるところまで合っています。列の一覧に「sku は型番（例 PX-100）」のような一言を添えて渡したので、型番を商品名の列で引くような取り違えも、3モデルとも約50本のSQLで起きていません。

権限エラーもそのまま「参照できない」と答えました。

差が出たのは横断と矛盾です。Gemmaの2モデルは「PX-100 発熱」の1語で検索し、拾えた資料だけで答えを組みます。

7月の問い合わせは「持ち手が熱い」という言い回しで、原因は5月の稟議の「ヒーター部品変更」で、どちらも「発熱」では検索に引っかかりません。返品が増えた原因は3回とも「持ち手の熱対策の構造的な問題」で止まり、部品変更にはたどり着きませんでした。31Bは26Bより2問多く正解しましたが、この型の2問は同じ経路で落としています。

Qwen3.8-27Bは違いました。同じ問いで、返品の内訳をSQLで見てから「ヒーターユニット 変更」で文書を検索し直し、稟議にたどり着いています。1問に平均4回、多いときは16回ツールを呼び、その分だけ遅くなります。26B A4Bの6倍の時間です。答えを短くする指示で縮む余地はありますが、ここでは測っていません。

思考モードは効いたか

Gemma 4 26B A4Bだけ4点上がり、31BとQwenは動きませんでした。上がったのは、存在しない前提を疑う、別型番の罠を避ける、という型で、検索語を言い換えて必要な資料にたどり着く型は変わりません。代わりに時間は3倍から4倍になります。思考で出力の上限を使い切って回答が出ない、ということも1回起きました。

コーディングエージェントから使ってみた

社内ナレッジのほかに、コーディングも試しました。Codex CLIの接続先をRunPodのvLLMに向け、3モデルに同じ課題を同じ順で出しました。

1. ReactのTodoアプリの新規作成（6機能）
2. ドラッグでの並べ替え
3. 期限の設定と、期限切れの強調
4. 見た目の仕上げ

指示は1つずつ出し、前の指示の出来（ビルドと操作の検査、画面）を確かめてから次を出し、承認待ちは無しにしました。思考モードは3モデルともオフです。表の最後の行は、後述のAGENTS.mdを置いた場合です。

モデル	所要時間	結果	手直し	見た目	コマンド数	出力トークン
Gemma 4 26B A4B	4分37秒	4つとも完了	1回	行の崩れが残る	19	15,649
Gemma 4 31B	12分22秒	4つとも完了	0回	整っている	14	14,581
Qwen3.8-27B	45分41秒	4つとも完了	0回	整っている	36	65,190
Qwen3.8-27B（AGENTS.mdあり）	8分48秒	4つとも完了	0回	整っている	9	13,024

速さと仕上がりは両立しなかった

3モデルの性格ははっきり分かれました。

• Gemma 4 26B A4B: 速いが粗い。見た目を直すとレイアウトが崩れる退行が1回あり、行の崩れも残った
• Gemma 4 31B: その中間。最初から整った見た目で退行もなく、時間は26B A4Bの3倍近く
• Qwen3.8-27B: 仕上がりが一番良く、期限切れの印や行ごとの期限入力など気が利く。ただ1つの指示に8〜15分かかり、対話しながらは使えない

つまり、速さと品質が逆の順に並びます。速いモデルは手直しが増え、品質のいいモデルは待ち時間で使えない、という関係です。

AGENTS.mdで縮めた

Qwenが遅い理由は2つあります。

• 書く速さ: 1秒あたり約30トークンで、26B A4Bの3分の1
• 書く量: 計画や振り返りを長い文で書き、作った後に自前の動作テストまで書いて走らせるので、出力が4倍

あまりに遅かったので、作業ディレクトリに次の4行を書いたAGENTS.mdを置いて、同じ手順をやり直しました。

- 返答は3行以内。計画や振り返りを文章で書かない。すぐに手を動かす。
- 動作確認は npm run build が通ることだけ。開発サーバの起動、ブラウザでの確認、独自のテストの作成はしない。
- ファイルを直すときは、変更箇所だけを差分で当てる。ファイル全体を書き直さない。
- 1回の返答で、必要なコマンドだけを実行する。

結果、下記のようにだいぶ速くなりました。

• 4つの指示の合計: 45分41秒 → 8分48秒
• 出力トークン: 65,190 → 13,024
• 品質: 変わらず。リファクタリングまでの6つの指示も18分で完走

指示の与え方でここまで変わります。1つの指示で2分ほどなので、これなら実用の範囲内だと考えています。

分かったこと

社内ナレッジBOTは実用の範囲に入る

30問のうち、1か所を見れば答えが出る問い（転記・集計・権限）は3モデルとも落とさず、資料同士の食い違いを判断する問いも大半に正しく答えました。

落としたのは、資料の言葉が問いと違っていて言い換えて調べ直す必要がある問いで、26B A4Bで4問、31Bで2問、Qwenは0問でした。

日本語の短答では最下位だったQwenが、社内ナレッジでは唯一、検索語を言い換えて必要な資料までたどり着けました。問いが複雑になるほどQwenが優勢で、1か所で答えが出る問いなら速い26B A4Bで足ります。何が得意かは、何をさせるかで入れ替わるようです。

コーディングも、指示の与え方次第で実用に近づく

エージェントに自走させた4つの指示は、3モデルとも最後までやり切りました。差が出たのは速度と仕上がりで、26B A4Bは1つの指示が1〜2分で済むぶん粗く、Qwenは仕上がりが一番良いかわりに既定のCodexでは8〜15分かかります。ただしAGENTS.mdで書く量を絞ると、Qwenでも2分前後まで縮み、対話しながら進める使い方でも待てる範囲に入りました。さらに速さが要るなら、上のGPUに載せ替えることになります。

おわりに

1年半ほど前にAPI経由で使っていたモデルが、手の届く費用で動くようになっていると感じました。今回はA40を1枚借りて、3モデルをint4で動かし、生成した社内データをLLM自身に探させて答えるところまで確認できました。次の課題は、AGENTS.mdをさらに整えて、待ち時間をもう一段詰めることです。また、重みを自分で持っているからこそできることとして、ファインチューニングも試してみたいと思っています。

普段どおりクラウドのAPIで足りるなら、そのほうが手軽です。一方、セキュリティの要件でAPIに送れないデータを扱う場合には、セルフホストは十分に選択肢に入ってくると思います。ここまでの検証にかかったGPU代は、合わせて10ドルほどでした。