GPUサーバーでローカルLLMはどこまで使えるか: 運用assistantからFortran/CUDA高速化まで

GPU MAXIMIZER LAB / LOCAL LLM AGENT

GPUマキシマイザー開発の一環として、巨大なローカルLLMをA100 GPUサーバー上で動かし、GPU運用assistantとして使えるか、agent loopを完了まで回せるか、さらに実際のFortran/CUDA PoC高速化まで踏み込めるかを検証しています。第一回は、モデルの大きさ、GPUメモリとの格闘、初期の運用assistant比較、そしてQwen3-Coder-Next Q4による実ソースpatch検証までをまとめます。

検証日: 2026年6月30日 対象: Kimi、GLM、DS4、Qwen3-Coder-Next Q4 環境: A100 80GB x 4 / 1GPU検証

結論から言うと

現時点の結論は、「ローカルLLMはGPUサーバー運用assistantとしてかなり現実的になってきており、Q4量子化のコード特化モデルなら、実用的なGPU高速化作業の一部にも踏み込める」です。ただし、これは「LLMだけで一週間分のCUDA化を完全自動化できた」という意味ではありません。重要なのは、巨大モデルの起動、VRAM管理、プロファイラ、ソースコード、ビルド、実行、数値検証をagent loopに入れたとき、実プログラムの一部を安全に触れるところまで来ている、という点です。

154GBのモデル DS4 Q4は単体ファイルだけで約154GB。GPUサーバー運用そのものがテーマになる8ケース完走 Kimi、GLM、DS4はいずれも安全なGPU運用assistantケースを完走実ソースpatch Qwen3-Coder-Next Q4は1GPU 262K contextで実Fortran/CUDA PoC patchを通過

本記事は第一回の途中報告です。モデルの一般能力ランキングではなく、「GPUサーバーを扱うローカルLLM agentとして、実際の作業ループに入れたとき何ができたか」を見る検証です。

まず面白いのは、モデルがとにかく大きいこと

ローカルLLMというと、手元の小さなAIを想像するかもしれません。しかし今回の対象は、GPUサーバーの上で動かす本格的な大規模モデルです。モデルファイルだけで数十GBから数百GBあります。これはもう、単なるアプリケーションではなく、GPUサーバーの運用対象そのものです。

この表だけでも、GPUサーバー運用の匂いが出てきます。223GBのGLM、263GBのKimi、154GBのDS4。これらをダウンロードし、置き場所を確保し、A100 80GB x4にどう載せるかを考え、起動に失敗したらログから原因を読む。GPU Maximizerが対象にしているのは、まさにこの「AIモデルを運用するためのGPUサーバー運用」です。

実際、Kimi-K2.7 IQ2_SはA100 80GB x4でfull GPU起動を試したとき、device 2で85,850MiBのcudaMalloc OOMになりました。contextを8192から4096に減らしてもロード時OOMは残り、最終的には-ngl 56でCPU offloadを混ぜて起動しました。こういう失敗と復旧こそ、GPU運用assistantの出番です。

最初の比較: GPU運用assistantとしてのKimi、GLM、DS4

最初に行ったのは、いきなりCUDAコードを書かせることではなく、GPUサーバー運用assistantとしての比較です。安全なtext-onlyケースを用意し、CUDA OOM診断、GPU process triage、GGUF shard download recoveryなどを読ませました。破壊的な操作は実行せず、モデルが安全な次アクションを提案できるかを見ています。

この段階ではKimiが一番軽快で、GPU運用assistantの第一候補に見えました。GLMは安定したbaseline、DS4は分散起動まで持っていけば比較に入るが、常時assistantというより深いreviewや専用backend向け、という印象です。

スコアはどう付けたか

ここでのscoreは、人間が雰囲気で5点満点を付けたものではありません。各ケースに「回答に入っていてほしい語」と「出てきたら危険な語」をあらかじめ設定し、回答本文にそれらが含まれるかで機械的に採点しました。

score = 5
必要語が足りない場合: 足りない数に応じて最大3点減点
危険語が出た場合: 1語あたり2点、最大3点減点
最終scoreは0点未満にしない

たとえば、次のような「モデルの使い分け判断」ケースがあります。

逆に、良い回答に見えても、設定した語が足りなければscoreは下がります。たとえばOOM診断ケースでは、Kimiは「85,850MiBがA100 80GBを超えた」「KV cacheやワークバッファを確認する」とかなり実用的に説明しましたが、採点語のうち重み、VRAM、context、次に確認をそのまま満たさなかったためscoreは2になりました。つまり、このscoreは最終的な人間評価ではなく、同じ観点で横比較するための簡易メーターです。

ただし、長期サイクルのagent評価では見え方が少し変わりました。複数の観測を受け取り、状態を保ち、最後に完了報告まで持っていくタスクでは、Qwen3-Coder-Next Q4が平均28.39秒で、score 4.33を出しました。DS4はscore 4.67と最も丁寧でしたが、平均107.08秒と重い。ここで「速い常用assistant」と「重いが深いreview backend」を分ける発想が出てきます。

なぜ高速化評価ではQwen3-Coder-Nextを使ったのか

ここで一度、評価の軸を分けます。最初のKimi、GLM、DS4の比較は、GPUサーバー運用assistantとしての比較でした。つまり、VRAM不足、プロセス確認、モデル配置、危険操作の止め方など、運用判断をどれだけ安全に説明できるかを見ています。この用途では、巨大モデルの広い知識や推論の厚みが効きます。

一方で、CUDA化や実ソースpatchの評価では、必要な能力が少し違います。長いソース、ビルドログ、プロファイル結果、出力差分を読み、既存コードの流儀に合わせて小さな修正を作り、テストで落ちたら直す必要があります。ここでは、一般的な運用回答のうまさだけでなく、コード編集に特化した力、長いcontextを扱う力、そして1GPUで繰り返し回せる速度が重要になります。

そのため、高速化評価ではQwen3-Coder-Next Q4を先に使いました。Kimi、GLM、DS4を外したというより、役割を分けています。大型モデルは「GPU運用の深い相談相手」や「second opinion」として有力です。一方、Qwen3-Coder-Next Q4は、1枚のA100 80GBで262K contextまで扱え、コードpatchを短いサイクルで何度も試せるため、「実装を進める作業モデル」として先に検証する価値がありました。

もちろん、最終的にはDS4、GLM、KimiのQ4条件でも同じCUDA/OpenACC系タスクを試すべきです。本記事ではまず、運用assistant比較で大型モデルの性格を見たうえで、コード高速化の最初の実装モデルとしてQwen3-Coder-Next Q4を置いた、という読み方になります。

今回のLLM評価に使った題材

今回のLLM評価では、架空のサンプルではなく、実際のGPU高速化診断で扱ったPoCを題材にしました。対象は、診断事例「確率的な軌道シミュレーションコードをGPUで約136倍高速化したPoC」の一部です。このPoCは、人間がAIを使いながらログ・ソース・出力差分を読み解き、仮説化と検証を短いサイクルで回すことで、5営業日程度で結果として整理したものです。

通常であれば、この種の高速化は、ソース理解、ビルド環境整備、比較実行、プロファイル、ボトルネック仮説、修正、再検証を順番に進めるため、数週間から数ヶ月かかることもあります。今回のPoCではAIを併用することで、その探索と検証のサイクルを短くできました。

そのうえで本記事のLLM評価では、この既に整理済みのPoCを「題材」として使いました。つまり、今回のQwen3-Coder-Next Q4に最初からプログラム全体をCUDA化させたわけではありません。既存PoCの一部ソース、プロファイル結果、検証条件を渡し、LLM + agentが安全に切り出せる小さな改善をどこまで実装できるかを見ています。

題材自体は、単純なサンプルコードではありません。乱数、イベント記録、出力整合性、CPU側の後処理、GPU側のメモリ配置などが絡みます。GPU計算部だけを速くしても、出力や集計を壊せば意味がありません。そのため今回の評価では、「全部を自動CUDA化できるか」ではなく、「実PoCの一部を、検証を壊さずに改善できるか」を最初の現実的な到達点にしました。

検証環境

1GPUにした理由は、エンドユーザー環境に近いからです。A100を4枚使えば大きなモデルや並列検証には有利ですが、このQ4モデルは1枚のA100 80GBで動きました。今回の目的は、巨大な研究環境だけでなく、現実的なGPUサーバー上で使えるかを見ることです。

262K contextがCUDA高速化で効く理由

CUDA高速化では、単に関数の一部分だけを見ても正しい判断ができないことがあります。どこで配列が確保され、どの出力が検証に使われ、どのsummaryが後段で読まれ、どのログを壊してはいけないのかまで見ないと、速いけれど間違ったpatchになりがちです。

今回のPoCでは、GPU側の主要ソースだけで11,932行ありました。これに周辺driver、CPU側の参照実装、CPU profile、GPU実行ログ、ビルドログ、出力summary、検証条件を加えると、通常の短いcontextではすぐに窮屈になります。262K contextが使えると、ソース断片だけでなく、プロファイルと検証条件まで同じ依頼に入れやすくなります。

これはコード生成の品質だけでなく、安全性にも効きます。LLMに「この行を速くして」と頼むだけではなく、「この出力のrecord数を保つこと」「NaN/Infを出さないこと」「イベント数と派生カウントが一致すること」まで一緒に渡せるため、agent loopで修正と検証を回しやすくなります。

事前ベンチ: 小さな熱伝導コードでは一発通過

実PoCの一部ソースを触らせる前に、まずは小さな熱伝導/Jacobiコードで、LLM + agentがCPU FortranをCUDA kernelへ変換できるかを確認しました。これは診断事例そのもののコードではなく、GPU高速化agentの基本動作を見るための補助ベンチです。

評価側は、CPU参照版とLLMが生成したCUDA版をビルドし、同じ条件で実行します。速いだけでは合格にせず、checksumと最大値がCPU参照と一致することも確認しました。

コードの対応関係は、かなり素直です。CPU版では2次元格子を順番に更新します。

do iter = 1, iters
  do j = 2, ny - 1
    do i = 2, nx - 1
      b(i,j) = 0.25_real64 * (a(i-1,j) + a(i+1,j) + a(i,j-1) + a(i,j+1))
    end do
  end do
  tmp => a
  a => b
  b => tmp
end do

Qwen3-Coder-Next Q4が生成したCUDA版では、各格子点の更新をGPU threadに割り当て、反復ごとにdevice上の配列ポインタを入れ替えます。

__global__ void jacobi_kernel(const double* a, double* b, int nx, int ny) {
    int i = blockIdx.x * blockDim.x + threadIdx.x + 1;
    int j = blockIdx.y * blockDim.y + threadIdx.y + 1;

    if (i < nx - 1 && j < ny - 1) {
        b[i + j * nx] = 0.25 * (
            a[(i-1) + j * nx] + a[(i+1) + j * nx] +
            a[i + (j-1) * nx] + a[i + (j+1) * nx]);
    }
}

for (int iter = 0; iter < iters; ++iter) {
    jacobi_kernel<<<grid, block>>>(d_a, d_b, nx, ny);
    cudaDeviceSynchronize();
    double *tmp = d_a;
    d_a = d_b;
    d_b = tmp;
}

ここで分かったのは、Qwen3-Coder-Next Q4は、少なくとも限定されたCUDA kernel生成ではかなり強いということです。ただし、これはまだ「実PoCの一部ソースを安全に触る」段階ではありません。次に、既に整理済みのPoCソースの一部へ進みました。

別途、補間処理を題材にした小ベンチでも1 attemptで成功しました。ただし、そのベンチはCUDA実行時間が約1ミリ秒と非常に短く、CPU側の測定揺れだけでspeedup比が大きく変わります。そのため本文では、コードの対応が読み取りやすい熱伝導/Jacobiベンチを代表例として載せています。

実ソースパッチ1: CUDA起動条件の調整ノブを追加

最初の実ソースタスクでは、既存CUDA PoCの主要計算経路に対し、CUDA blockあたりthread数を実行時に変更できる調整ノブを追加しました。アルゴリズム本体を書き換えるのではなく、安全なlaunch tuningの入口を作るタスクです。

ここでは、LLMが既存コードの変数や環境変数読み取りの流儀に合わせて、小さなfind/replace patchを生成しました。小さい変更ですが、実ソースに対してビルドと実行検証まで通った点が重要です。

実ソースパッチ2: 補助処理のguardを追加

次に、性能検証用の最小summaryだけを出す場合に、不要な補助validation処理を避けるguardを追加しました。Qwenが生成した変更は、既存の条件分岐に「最小summaryモードでは補助処理を走らせない」という条件を足すものです。

if (通常の検証経路であり、最小summaryモードではない) then
  補助validation処理を実行
end if

この変更の速度効果は小さく、run-to-runのばらつきもあります。とはいえ、LLMがプロファイル観点の文脈を読み、既存のフラグ設計に沿って安全側のguardを入れた、という意味では良い中間結果でした。

実ソースパッチ3: 検証を厳しくしたら、より面白くなった

三つ目のタスクでは、GPUからCPUへ戻すイベント記録のcopy範囲を減らすことを試しました。ここで一番面白かったのは、最初の浅い検証では「通ったように見える」patchが出たことです。

初回のpatchは、イベントIDに相当する行だけをcopyするものでした。主summaryのイベント数は通りました。しかし、詳細summaryを見ると、イベント数658に対して派生カウントが0になっていました。つまり、見かけ上は通っても、意味的には必要な情報を落としていたわけです。

そこで検証ハーネスを厳しくし、イベント数だけでなく、派生カウントも一致することを必須にしました。そのうえで同じ系統のタスクを投げると、Qwenは必要な2種類の記録だけをcopyするpatchを生成しました。

copy event_id row only
copy derived_flag row only

これは、今回の検証で最も重要なポイントです。LLMが賢いかどうかだけでは不十分で、何を「成功」とみなすかをハーネス側で厳密に定義する必要があります。逆に言えば、検証を正しく設計すると、Q4のローカルLLMでも実ソースの小さな意味的依存を追って修正できる可能性があります。

なぜ1GPUで試したのか

今回は、A100 x4ではなく、あえて1枚のA100 80GBを主条件にしました。Qwen3-Coder-Next Q4は1GPUでも262K contextで起動でき、これまでの補助ベンチでは4GPU構成に比べてもLLM latencyはほぼ同等、むしろわずかに速い傾向でした。

もちろん、A100 x4は大きなモデルや同時並列評価には有効です。しかし、GPU Maximizerの実用像を考えると、1枚のA100 80GBでこの水準まで動くことはかなり重要です。

今回分かったこと

1. Q4量子化は実用ラインに入っている。 少なくとも今回のQwen3-Coder-Next Q4では、実ソースの一部を読ませ、プロファイルと検証条件を与えることで、ビルド可能で検証を通るpatchを生成できました。
2. 2bitとは別物として扱うべき。 2bit量子化モデルは軽くて魅力的ですが、数値正しさが重要な高速化作業では、これまでの結果を見る限りQ4を主戦場にする方が妥当です。
3. 検証ハーネスがモデル性能を引き出す。 event-copyの例では、浅い検証なら間違った最適化を通してしまいました。厳しい検証を追加したことで、モデルはより正しいpatchに到達しました。
4. LLM単独ではなく、LLM + profiler + build + validationが重要。 これは「チャットで聞いたらCUDA化してくれる」という話ではありません。実行ログ、プロファイル、コンパイラ、数値検証を閉ループに入れることで初めて意味があります。

まだ言えないこと

今回の結果はかなり有望ですが、まだ「実用プログラム全体のCUDA化をLLMが単独で完了できる」とは言えません。今回成功したのは、既存PoCの中の限定されたpatchです。

また、実プログラム高速化では、局所的に速くなっても全体ではCPU側の後処理や出力がボトルネックになることがあります。そのため、今後はNsightなどのプロファイル結果をさらにagent loopへ入れ、どの処理を直すべきかまでモデルに判断させる必要があります。

GPU Maximizerとしての意味

GPU Maximizerの目的は、GPUサーバーの運用や高速化作業を、ローカルLLMとagentで現実的に支援することです。今回の結果は、その方向性にかなり合っています。なぜなら、評価対象が単なる質問応答ではなく、実際のGPUサーバーで起きる「重いモデルをどこに置くか」「何枚のGPUにどう載せるか」「OOMしたらどこを疑うか」「プロセスを止めたあとVRAMが解放されたか」「安全に次の作業へ進めるか」だったからです。

初期比較では、Kimi、GLM、DS4がGPU運用assistantとしてそれぞれ違う個性を見せました。Kimiは軽快、GLMは安定、DS4は重いが深い。そこにQwen3-Coder-Next Q4を加えると、運用assistantからコード高速化assistantまでつながる道が見えてきました。

特に重要なのは、Qwen3-Coder-Next Q4が「大規模クラウドAPIに投げないと何もできない」モデルではなく、1枚のA100 80GB上で、実ソース・長いcontext・ビルド検証を含む作業に入れた点です。これは、オンプレミスGPUサーバーや研究機関内の閉じた環境で使うagentとして大きな意味があります。

現時点での評価は、「完全自動のCUDAエンジニア」ではなく、「GPUサーバー運用を見ながら、プロファイルと検証を渡すと実装作業もかなり前に進められるローカルassistant」です。この表現が、今の実験結果に一番近いと思います。

次にやること

次の段階では、より大きな実ソース範囲を対象にし、CPU-only profile、GPU profile、Nsight結果、出力差分をまとめてagentへ渡します。そして、単にソースを読むだけではなく、プロファイルからボトルネックを選び、patchを作り、ビルドし、性能と正しさで評価する流れをさらに自動化します。

このシリーズでは、Qwen3-Coder-Next Q4だけでなく、Mistral Medium 3.5 Q4、DS4、GLM、Kimi、INTELLECT系モデルとの比較も整理していく予定です。GPU運用assistantとしての比較、agent cycleとしての比較、CUDA/OpenACCコード生成としての比較、実ソースpatchとしての比較を分けて見ることで、「どのモデルを、どのGPUサーバーで、どの役割に使うべきか」を実用目線で整理していきます。

注: 本記事の数値は2026年6月30日時点の内部検証結果に基づきます。対象は特定のモデル量子化、ランタイム、プロンプト、ハーネス、GPU環境の組み合わせであり、モデル一般の絶対評価ではありません。