ローカル LLM の性能を確認するとき、最初に目に入るのは、モデルを端末のメモリーへ読み込めるか、そして 1 秒間に何トークンを生成できるかという数字である。前者はモデルをその計算機で実行できるかを決め、後者は文章が返ってくるまでの待ち時間に直接関係するため、どちらも必要な指標である。コーディングエージェントへ仕事を任せる場合、実用性の判断には、この 2 つと仕事全体の進行の両方を見る必要がある。実際の開発作業では、一度プロンプトを入力して回答を受け取るだけで終わらず、リポジトリーの構成を調べ、関連するコードを読み、変更箇所を特定し、ファイルを編集し、テストや静的検査を実行し、その結果を読んで次の操作を決める。この一連の処理では、モデルの推論が何度も呼び出され、その間に外部環境の状態も変化する。
既稿では、MacBook Pro でローカル LLM を使う条件として、モデルを起動できることと、実際の業務入力に対して必要な品質、応答時間、メモリー使用量を満たすことを分けて考えた[1]。モデルファイルがメモリーへ収まり、短い入力に対して十分な速度で文章を生成できても、長い入力で待ち時間が急増したり、実際の作業で必要な品質に達しなかったりすれば、そのモデルを業務へ組み込むことは難しい。この区別をコーディングエージェントへ広げると、さらに一段階先の条件が加わる。個々の推論が許容時間内に終わるだけでなく、それらを何十回、何百回と繰り返した結果として、一件の仕事全体が許容時間内に終了しなければならない。
M4 Max は最大 128GB のユニファイドメモリーを持つため、従来のノート型計算機では保持できなかった大型モデルをローカルへ載せられる範囲を広げる。容量の制約を越えた後も、仕事の完了時間は一回の推論時間と反復回数に左右される。モデルを保持できても、一回の推論に時間がかかれば、その遅延は反復回数に応じて累積する。作業中に読み込んだコード、検索結果、差分、テスト結果がコンテキストへ追加されると、後半の推論では入力そのものが長くなり、最初と同じ時間では処理できない場合がある。そこへ誤った修正やツール操作の失敗が重なると、失敗の調査、別の修正、再検証という追加経路が生じる。
このため、ローカル LLM の評価単位は、一回の推論ではなく、要求を受け取ってから必要な観測と操作を繰り返し、最終結果を検証できる状態へ到達するまでの全体に置く必要がある。本稿では、この一連の処理を一件の仕事として捉える。実用性の判断基準は、モデルが動くか、短い入力で何 tok/s 出るかという単独の性能値から、任せた仕事が検証可能な時間内に最後まで閉じるかへ移る。
1. ローカル LLM は「動く」だけでは実用にならない
短い質問に答える用途では、モデルを読み込めることと生成速度から利用時の待ち時間を比較しやすい。入力を一度与え、出力が返れば、その処理はそこで終了する。たとえば、数百トークンの質問に対して数百トークンの回答を返すだけなら、モデルの初期読み込み時間、入力処理時間、生成速度を測れば、利用者がどの程度待つかを概算できる。多少の誤答があっても、人間が回答を読んで採否を決めるなら、その誤答が自動的に次の処理を発生させるわけではない。
コーディングエージェントでは、出力が次の入力を作る。要求を読んだモデルが関連ファイルを検索すると、その検索結果が次の判断材料になる。ファイルを編集するとリポジトリーの状態が変わり、テストを実行すると成功、失敗、警告、実行ログが新たに得られる。テストが失敗すれば、その失敗内容を読んで原因を推定し、再びコードを調べ、別の修正を行う。この循環では、前の推論結果が外部環境を変え、変化した環境から得た情報が次の推論内容を変える。単発の質問応答と異なり、途中の一回だけを切り出しても、仕事全体がどこまで進んだかは分からない。
反復回数が増えると、一回ごとの小さな遅延も総作業時間へ蓄積する。仮に、あるモデルが別の構成より一回の判断に 20 秒余計に必要で、その判断を 100 回行うなら、追加される待ち時間は 2,000 秒、約 33 分 20 秒になる。この計算では、100 回すべての処理時間が同じであると仮定している。実際のエージェント作業では、後半ほどコード、ログ、差分、過去の判断がコンテキストへ蓄積しやすいため、一回当たりの処理時間が増える可能性がある。最初の 10 回を短い入力で処理できても、50 回目や 100 回目に同じ速度を維持できるとは限らない。
誤りが起きた場合には、遅延は別の形でも増える。たとえば、本来失敗しているテストを成功と判断すれば、モデルは修正を続けずに終了条件を満たしたと誤認する。逆に、正しい修正を失敗と判断すれば、不要な変更を追加し、新しい不具合を作る可能性がある。存在しないファイルを繰り返し探したり、利用できないコマンドを呼び出したりすれば、そのたびにエラーメッセージが生成され、それを読むための推論が追加される。一回の誤りは、その後の作業経路まで長くし得る。誤った操作が環境を変えると、その変更を調査して戻すための処理が生じ、作業経路そのものが長くなる。
| 評価対象 | 確認できること | 確認できないこと |
|---|---|---|
| モデルを読み込めるか | モデルの重みと推論に必要な実行時領域を、その端末のメモリー上へ確保できるかを確認できる。 | モデルを載せた後に、長い入力や反復推論を含む作業が許容時間内に終わるかは分からない。 |
| 生成速度 | 入力処理後に、新しい出力トークンをどの速度で生成できるかを確認できる。 | 長い入力を読む時間、ツール実行時間、再試行、失敗からの回復を含む総作業時間は分からない。 |
| ベンチマーク正答率 | 定められた入力と評価基準に対して、モデルがどの程度正しい回答やコードを生成できるかを比較できる。 | 実環境から必要な情報を取得し、状態を変更し、結果を確認しながら終了条件へ到達できるかは別に確認する必要がある。 |
| 一件の仕事の完了時間 | 入力処理、生成、ツール操作、再試行を含めて、要求から成果物まで何時間または何分を要するかを確認できる。 | 終了した成果物が正しいことまでは、完了時間だけでは保証できない。 |
| 最終結果の検証 | テスト、静的検査、差分確認などによって、エージェントが生成した成果物が終了条件を満たしているかを確認できる。 | 同じモデルが別のリポジトリーや異なる種類の要求でも同じ成功率を維持するとは限らない。 |
各指標は別々の性質を測っている。モデルを読み込めることは、推論を開始するための条件である。生成速度は、一回の出力に要する時間の一部を決める。ベンチマーク正答率は、定められた問題に対する能力を測る。一件の仕事の完了時間は、それらの能力を外部操作と組み合わせた結果として、実際の作業がどの程度の時間で終了したかを測る。終了した成果物はテストや差分確認で検証して初めて、速く終了したことと正しく終了したことを区別できる。
コーディングエージェントでは、これらの指標が独立したまま並ぶのではなく、前段の結果が後段の条件を変える。生成が遅ければ各操作の開始が遅れ、ツール操作を誤れば再試行回数が増え、再試行が増えればコンテキストも長くなり、長いコンテキストが次の推論時間とメモリー使用量へ影響する。検証を誤れば、本来続けるべき作業を終了したり、すでに正しい成果物へ不要な変更を加えたりする。モデル能力、推論時間、入力文脈、外部操作、検証結果は、一件の仕事の中で相互に接続している。
この構造を踏まえると、ローカル LLM の実用性を一件の仕事で測る理由が明確になる。個別の性能値は、仕事を構成する一部分の性質を示す。利用者が必要としているのは、要求した変更が実際に作られ、その結果を検証できる状態まで到達することである。コーディングエージェントでは、その到達までに必要な推論と操作が一つの閉ループを構成するため、実用性もその閉ループ全体で評価する必要がある。
2. 128GB のユニファイドメモリーは、載せられるモデルの階級を変える
M4 Max は最大 128GB のユニファイドメモリーと最大 546GB/s のメモリー帯域幅に対応する。Apple は、この構成によって約 2,000 億パラメーターを持つ大規模言語モデルを扱えるとしている[2]。ローカル LLM にとって、この 128GB の意味は、GPU 推論にも使える共有メモリーである点にある。Apple Silicon では CPU と GPU が同じ物理メモリーを共有するため、その大容量を GPU による推論にも利用できる。離散 GPU を搭載した一般的な PC のように、CPU 側には十分なメインメモリーがあっても、モデル全体を GPU の VRAM へ収められないという制約の現れ方が異なる。
MLX の公式文書では、Apple Silicon 上の CPU と GPU が同じユニファイドメモリーへ直接アクセスし、MLX の配列を CPU 用と GPU 用の別々の領域へコピーする必要がないと説明されている[3]。これはローカル LLM で特に意味を持つ。推論では、モデルの重みを繰り返し読みながら行列演算を行うため、モデル全体を GPU から直接参照できる領域へ置けるかどうかが、利用可能なモデルサイズを決める。CPU 側に 128GB のメモリーが存在していても、GPU が利用できる VRAM が 24GB や 32GB に限られる構成では、数十 GB の重みを持つモデルをそのまま GPU 上へ配置できない。Apple Silicon では、128GB の同じメモリープールを CPU と GPU が共有するため、この容量制約が大きく緩和される。
もっとも、128GB の搭載メモリーがあれば、128GB までのモデルファイルをそのまま実行できるわけではない。モデルファイルは推論時に必要となるメモリーの一部にすぎない。まず重みそのものを保持する領域が必要になり、さらに入力されたトークン列と生成中の状態、各層で一時的に生じる中間結果、過去のトークンに対する注意計算を再利用するための KV キャッシュなどが追加される。そこへ推論ランタイム、OS、同時に動作する他のプロセスも同じ 128GB を使用する。既稿でも、モデルファイルの大きさだけから実際の必要メモリーを判断することはできないと整理した[1]。
このうち KV キャッシュは、長いコンテキストを扱うほど増える。モデルの重みが一度読み込めばほぼ固定された容量を占めるのに対して、KV キャッシュは入力と生成履歴が長くなるにつれて拡大する。短い質問では十分な余裕が残っていても、数万トークンのコードや作業履歴を保持するエージェントでは、その余裕が減っていく。モデルを読み込んだ時点でメモリー使用量が限界に近ければ、長いコンテキストを扱う前に実行可能な範囲が狭まる。したがって、128GB という数字を見る際は、重みを配置したあとにどれだけ実行時領域を残せるかが重要になる。
| メモリーを使う対象 | 容量の決まり方 | 実用上の影響 |
|---|---|---|
| モデルの重み | パラメーター数と、各重みを何ビットで表現するかによって大きく変わる。 | モデルを端末上へ配置できるかという最初の容量制約になる。 |
| KV キャッシュ | モデル構造、コンテキスト長、生成したトークン数などに応じて増える。 | 短い入力では動くモデルでも、長時間のエージェント作業ではメモリー不足を生じる可能性がある。 |
| 中間結果と実行時領域 | モデル構造、推論方式、ランタイムの実装によって変わる。 | モデルファイルの容量だけから必要メモリーを算出できない理由になる。 |
| OS と他のプロセス | 実際の端末上で同時に動作するソフトウェアによって変わる。 | 搭載メモリーの全量を LLM 推論へ割り当てることはできない。 |
この容量制約を直接変える技術が量子化である。ニューラルネットワークの重みを 16 ビットで保持する場合、単純計算では 1 パラメーター当たり 2 バイトが必要になる。100B、すなわち 1,000 億パラメーターなら、重みだけで約 200GB になるため、128GB のメモリーには収まらない。同じ重みを 4 ビットで表現できれば、理論上の重み容量は 1 パラメーター当たり 0.5 バイトとなり、100B では約 50GB まで減る。実際のファイル形式や量子化方式にはスケール値などの追加情報があるため、この単純計算と完全には一致しないが、量子化ビット数がモデルを収容できるかどうかを大きく変えることは分かる。
既稿で整理したように、量子化では 16 ビットや 32 ビットで表現していた重みを 8 ビットや 4 ビットなどへ縮小し、モデル容量と重みを読み出すデータ量を減らす[4]。GPTQ では、175B 級の大規模言語モデルを 3 ビットまたは 4 ビットへ事後量子化し、精度低下を抑えながら単一 GPU で推論できることが示された[5]。量子化によって、同じ 128GB でも配置できるパラメーター数が増えるだけでなく、モデルの重みが占める領域を減らし、その分を KV キャッシュなどの実行時領域へ残せる。
この関係から、M4 Max 128GB と量子化は異なる制約に作用することが分かる。128GB のユニファイドメモリーは、GPU が利用できる物理的な容量の上限を引き上げる。量子化は、その容量の中で一つの重みが占める大きさを減らす。両者を組み合わせることで、数十 GB から 100GB 近い重みを持つモデルについても、推論に必要な余白を残しながらローカルへ配置できる範囲が広がる。
M4 Max 128GB の特徴は、CPU と GPU が共有する 128GB の領域へ量子化した大型モデルを置ける点にある。従来のノート型計算機では GPU メモリー容量の段階で候補から外れやすかった 100B 級を超えるモデルまで、ローカル推論の選択肢へ入ってくる。一方、容量の制約を越えても、そのモデルを一トークン処理するたびに全パラメーターを計算するなら、反復推論に必要な時間は大きくなる。次に問うべきなのは、どれだけ大きなモデルを保持できるかではなく、そのうち毎回どれだけのパラメーターを実際に計算するかである。
3. 大きなモデルと毎回の計算量を分離する
前章で見た 128GB のユニファイドメモリーと量子化は、大型モデルを端末上へ配置するための容量制約を緩和する。次の条件は、そのモデルを十分な速度で推論できることである。すべてのパラメーターを一トークンごとに計算へ使う構造では、モデルを大きくするほど保持すべき重みが増えるだけでなく、各トークンを生成するための計算量も増える。コーディングエージェントのように推論を何十回、何百回と繰り返す用途では、一回ごとの計算量の増加がそのまま総作業時間へ累積する。
Qwen3.8-Flash-Next は、モデル全体の規模と一トークン当たりの計算量を分離する構造を採る。Qwen の公式発表によれば、メインモデルは 125B、すなわち 1,250 億パラメーターで、さらに 51B パラメーターの N-gram Embedding を持つ。メインモデルで一トークン当たりに活性化されるパラメーターは 6B である[6]。モデル全体としては 100B 級を超えるパラメーターを保持しながら、各トークンではメインモデルの一部だけを計算する。
この仕組みの基礎にあるのが Mixture of Experts、MoE である。MoE では、モデル内部に複数の専門部分を用意し、入力されたトークンに応じて、その中から計算に使う部分を選択する。すべての専門部分を毎回動かすのではなく、一部だけを活性化するため、モデル全体へ保持できるパラメーター数と、一回の推論で実際に計算するパラメーター数を分けられる。
Switch Transformer は、この疎な活性化によってモデルを大規模化する方法を示した。入力ごとに利用する専門部分を選ぶことで、モデル全体のパラメーター数を増やしても、その増加分すべてを各トークンの計算へ投入する必要がない[7]。モデル容量を増やすと計算量も同じ比率で増えるという密なモデルの制約を緩め、より多くのパラメーターを保持しながら一回の計算量を限定できる。
Mixtral 8x7B も同じ関係を具体的に示す。各層には 8 個の専門部分が存在するが、一つのトークンに対して利用されるのはそのうち 2 個である。そのため、モデル全体では約 47B のパラメーターへアクセス可能な構造を持ちながら、一トークンの推論で活性化されるパラメーターは約 13B に抑えられている[8]。47B の重みを保持するためのメモリー容量は必要だが、一トークンごとに 47B すべてを同時に計算するわけではない。保持容量と演算量が同じ数字では決まらない例である。
Qwen3.8-Flash-Next の 125B と 6B も、この区別に沿って読む必要がある。「125B のモデルだが、6B モデルと同じ計算量で動く」という意味ではない。専門部分の選択以外にも、注意機構や共有部分などの計算が存在し、必要な重みをメモリーから読み出す処理も発生する。さらに、Qwen3.8-Flash-Next には 51B パラメーターの N-gram Embedding があり、公式説明では、この部分は入力から決定的に参照され、一トークンごとの行列積の計算予算には含まれないとされている[6]。6B という数字だけから、同規模の密な 6B モデルと推論時間やメモリー帯域の要求が等しいとは判断できない。
ここで分けて考える必要があるのは、モデルを保持するためのコストと、モデルを使って一トークンを計算するためのコストである。総パラメーター数が大きくなれば、量子化したとしても保持すべき重みの容量は増える。この制約に対して 128GB のユニファイドメモリーが作用する。一トークン当たりに活性化するパラメーターを限定すれば、モデル全体を毎回計算する場合より演算量を抑えられる。この制約に対して MoE が作用する。二つは、大型モデルをローカルで使う際に現れる別々の制約を担当している。
| 構成要素 | 直接決まるもの | 実行時に生じる制約 | M4 Max 128GB との関係 |
|---|---|---|---|
| 総パラメーター | モデル全体で保持する重みの規模を決める。 | パラメーター数が増えるほど、重みを保持するためのメモリー容量が増える。 | 128GB のユニファイドメモリーによって、100B 級を超える重みをローカルへ配置できる範囲が広がる。 |
| 活性パラメーター | 一トークンの処理で実際に利用するモデル部分の規模を決める。 | 活性化する部分を限定できれば、総パラメーター数と同じ規模の計算を毎回行う必要がなくなる。 | 大型モデルを保持したまま反復推論する際の、一回ごとの計算時間を抑える条件になる。 |
| 量子化ビット数 | 一つの重みを保持するために必要なデータ量を変える。 | ビット数を減らすほど、モデルの保存容量と重みの読み出し量を減らせる。 | 同じ 128GB の中で大型モデルを配置し、KV キャッシュなどに使う実行時領域を残しやすくなる。 |
| コンテキスト長 | 一回の推論で保持し、処理する入力履歴の長さを決める。 | 長くなるほどプレフィル、KV キャッシュ、注意計算などの時間とメモリー負荷が増える。 | モデル本体が 128GB に収まっていても、長時間のエージェント作業では別の時間・容量制約として現れる。 |
この関係から、100B 級を超えるモデルがノート型計算機で使えるようになった理由は、メモリー容量と一トークン当たりの活性計算量の両方にある。128GB のユニファイドメモリーがあれば大きなモデルを保持できるが、密な構造のままモデル全体を各トークンで計算すれば、推論時間が長くなり、エージェントによる反復処理ではその遅延が蓄積する。逆に MoE で活性計算量を減らしても、モデル全体の重みを保持できるメモリーがなければローカルへ配置できない。大容量メモリーと疎な活性化を組み合わせることで、二つの制約を同時に緩和している。
一トークン当たりの活性パラメーターを減らしても、コーディングエージェントの総作業時間はコンテキスト処理の影響を受ける。エージェントは作業を進めるにつれてコード、検索結果、差分、テスト結果をコンテキストへ蓄積する。モデルそのものの計算量を抑えても、長くなった入力を毎回読み直す処理が大きくなれば、次の操作を開始するまでの時間は増える。大型 MoE を「載せて計算できる」ところまで進んだあとに残るのが、長いコンテキストをどの速度で処理できるかという制約である。
4. 長いコンテキストでは生成速度だけを見ても足りない
コーディングエージェントでは、作業が進むほどモデルへ渡す情報が増える。最初は要求とリポジトリーの概要だけでも、調査を始めれば関連ファイルの内容、検索結果、修正差分、テスト結果、エラーメッセージ、直前までの判断が追加される。これらは次の操作を決めるために必要な情報であると同時に、次の推論で読み込む入力でもある。エージェントの処理時間は、出力の生成速度と、それまで蓄積したコンテキストの処理速度の両方で決まる。モデルが新しいトークンを生成し始める前に、それまで蓄積したコンテキストをどの速度で処理できるかが、作業時間の別の構成要素になる。
大規模言語モデルの推論は、入力を処理する段階と、新しいトークンを生成する段階に分けて考えると分かりやすい。入力されたトークン列をまとめて処理し、後続の生成に利用する内部状態を作る処理がプレフィルである。その後は、直前までの状態を使いながら新しいトークンを一つずつ生成していく。一般に表示される生成速度の tok/s は後者を指すことが多いが、長いコードや作業履歴を入力する場合には、プレフィルが終わるまで出力そのものが始まらない。生成が 1 秒間に数十トークン進んでも、その前に数十秒あるいは数分の入力処理が必要なら、エージェントが次の操作を開始できる時刻はその分だけ遅くなる。
コンテキストが長くなると処理が増える理由の一つは、自己注意機構が過去のトークンとの関係を計算するためである。標準的な自己注意では系列が長くなるほど比較すべきトークン間の関係が増え、計算量だけでなく中間データの読み書きも増える。FlashAttention は、この処理を数学的に近似するのではなく、GPU の高帯域メモリーと高速だが小容量のオンチップメモリーの間でデータを何回移動させるかに着目し、読み書きを減らすことで注意計算の実時間とメモリー使用量を改善した[9]。この結果は、長文脈の性能にメモリーアクセスも大きく影響することを示している。必要なデータが大きくなるほど、どのデータをどこへ保持し、何回読み出すかというメモリーアクセスも実時間を左右する。
コンテキスト長には、速度とは別に能力上の制約もある。あるモデルが 32K や 128K の入力を受け付けられるという仕様は、その長さまで同じ精度で情報を利用できることを意味しない。LongBench は、長文質問応答、文書要約、情報検索、コード補完など複数の課題を長い入力で評価し、入力長の増加に伴って高性能モデルでも成績が低下することを示した[10]。モデルが入力を拒否せず処理できることと、その入力の中から必要な情報を正しく取り出して推論へ利用できることは、別の性能である。
RULER はこの違いをより細かく調べている。単純に長い文章の中から一つの文字列を探す課題だけではなく、複数の情報を追跡したり、分散した情報を集約したりする処理を含めて 17 モデルを評価した。その結果、公称 32K 以上のコンテキスト長を持つモデルでも、入力が長くなるにつれて多くのモデルで性能が低下した[11]。つまり、コンテキスト長には少なくとも二つの意味がある。システムが入力として受け付けられる最大長と、その長さの入力から必要な情報を十分な精度で利用できる実効的な長さである。
| 指標 | 測っているもの | 長いエージェント作業で生じる制約 |
|---|---|---|
| 生成速度 | 新しい出力トークンを一つずつ生成する速度を示す。 | 入力処理が終わった後の速度であり、長いコンテキストを読み込む待ち時間は含まれない。 |
| プレフィル速度 | 既存の入力トークン列をモデル内部へ反映する速度を示す。 | コード、ログ、作業履歴が増えるほど、次の生成を開始するまでの時間へ影響する。 |
| 公称コンテキスト長 | モデルが入力として受け付けられる最大トークン数を示す。 | 最大長まで同じ精度で情報を検索、追跡、統合できることまでは保証しない。 |
| 実効的なコンテキスト長 | 必要な情報を十分な精度で利用できる入力長を示す。 | 公称上限より短い段階から推論能力が低下すれば、長時間の作業履歴をそのまま保持する運用が難しくなる。 |
| KV キャッシュ | 過去のトークンについて再利用する内部状態を保持する。 | コンテキストが長くなるほどメモリー使用量が増え、モデル本体とは別の容量制約になる。 |
Qwen3.8-Flash-Next が 262,144 トークンのネイティブコンテキストを持ちながら、Gated DeltaNet と Qwen Sparse Attention を組み合わせているのも、この制約と関係する[6]。長い入力を従来型の注意機構へそのまま渡すと、扱えるトークン数を増やすほど計算とメモリーアクセスの負担が増える。そこで、長い系列をより少ない計算量で処理する構造をモデル側へ組み込んでいる。262,144 という数字には、入力上限と、その長さへ近づいたときの計算負荷を抑えるというアーキテクチャー上の課題の両方が伴う。
コーディングエージェントでは、この長文脈の負荷が作業の進行そのものから発生する。たとえば、最初の要求が数百トークンでも、リポジトリーから複数のファイルを読み、テスト失敗のログを取得し、差分を作り、その結果を再確認すれば、モデルが参照する情報は数千、数万トークンへ増え得る。この情報には、文章量だけでなく、維持すべき作業状態も含まれる。過去にどのファイルを調べ、何を変更し、その結果どのテストが失敗したかを維持できなければ、同じ調査を繰り返したり、すでに否定された修正案へ戻ったりする。コンテキストを削れば処理は軽くなるが、削った情報によって作業状態を見失えば、別の形で反復回数が増える。
この結果、エージェントのコンテキスト管理には速度と情報保持の交換関係が生じる。履歴をすべて残せば、過去の判断を参照しやすい一方で、プレフィル時間、KV キャッシュ、注意計算の負荷が増える。履歴を要約したり不要な部分を削除したりすれば入力は短くできるが、修正理由、失敗した試行、特定のコード行とエラーの対応関係まで失えば、次の判断に必要な情報が不足する。長いコンテキストへの対応は、どこまで情報を保持したまま処理できるかという運用範囲を広げるが、交換関係自体は残る。
ローカル LLM の実用性を測るときは、短いプロンプトに対する最大生成速度とともに、実際の作業で使う長さの入力を読み終えるまでの時間、新しい出力を生成する速度、メモリー使用量、入力が長くなったときの能力低下を合わせて見る必要がある。コーディングエージェントの一件の仕事では、生成されたトークンだけでなく、それ以前に蓄積された作業状態を何度も読みながら次の操作を決める。モデルを載せられ、一トークン当たりの計算量を MoE で抑えられても、この読み直しが長くなれば総作業時間は増える。ローカル環境で仕事を閉じるには、生成速度だけでなく、長くなっていく作業状態を現実的な時間で処理し続けられることが必要になる。
5. コーディングエージェントは推論を閉ループの仕事へ変える
大規模言語モデルをチャットとして使う場合、モデルが生成した文章は通常、そのまま利用者へ返される。回答が適切かどうかを判断し、次に何をするかを決める主体は人間である。コーディングエージェントでは、この境界が変わる。モデルの出力がファイル検索、コード編集、コマンド実行といった操作へ変換され、その操作によって外部環境の状態が変化する。変化した状態を再びモデルが読み、次の操作を決めるため、モデルの出力は最終成果物であると同時に、次の推論条件を作る原因にもなる。
ReAct は、推論と外部環境への行動を交互に実行し、行動によって得られた観測結果を次の推論へ戻す構造を示した[12]。この構造をコード修正へ当てはめると、モデルは「どのファイルを読むべきか」と判断して検索を実行し、その結果から修正対象を決める。コードを書き換えた後にはテストを実行し、失敗すればエラーメッセージを新しい観測結果として受け取り、原因を再検討する。リポジトリー、シェル、テスト実行環境、バージョン管理システムは、単なる出力先ではなく、モデルが操作し、その結果から新しい情報を得る環境になる。
この違いによって、コーディングエージェントに求められる能力は、正しいコードを一度生成できることより広くなる。たとえば、不具合の原因となる関数を正しく推定できても、その関数が定義されているファイルを探索できなければ修正へ進めない。修正コードを生成できても、編集結果を対象ファイルへ正しく反映できなければリポジトリーの状態は変わらない。変更を適用できても、テストを実行せずに終了すれば、その変更が要求を満たしたかは確認できない。推論、観測、操作、検証のどこか一つが欠けるだけで、モデルが局所的には正しい答えを持っていても仕事全体は終了しない。
SWE-bench は、この違いを評価方法そのものへ取り込んでいる。元の SWE-bench は、実際の GitHub Issue と対応するコードベースを与え、Issue を解決する変更を生成できるかを評価する。12 個の Python リポジトリーから 2,294 件のソフトウェア開発課題が収集されており、対象となる課題では、既存コードの構造を読み、複数の関数やファイルの関係を把握し、必要な変更を加えたうえでテストを通す必要がある[13]。ここでは、問題文に対応するコード断片を生成できたかではなく、既存のソフトウェアへ変更を適用した結果として Issue が解決されたかが評価対象になる。
この評価単位の違いは、モデル能力の見方も変える。単発のコード生成では、生成したコードそのものを採点できる。既存リポジトリーの修正では、最初の推論が不完全でも、テスト失敗から原因を絞り込み、二回目の修正で正しい状態へ到達できれば仕事としては成功する。逆に、最初に正しい修正案を生成していても、別のファイルを誤って変更したり、テスト結果を読み違えたりして最終状態を壊せば失敗になる。個々の推論の正答率だけでなく、途中状態から誤りを検出し、終了条件へ収束できるかが結果を左右する。
SWE-agent は、モデルと外部環境の接続方法がこの収束性に影響することを示した。同じ言語モデルを利用していても、ファイルを開く、特定範囲を読む、検索する、編集する、テストを実行するといった操作をモデルへどのように提供するかによって、ソフトウェア開発課題の解決性能が変わる[14]。モデルが適切な次の操作を推論できても、その操作を表現しにくいインターフェースしかなければ実行へ移せない。反対に、現在位置や編集対象を誤認しにくく、操作結果を次の入力として取得しやすいインターフェースであれば、同じモデルでも必要な状態へ到達しやすくなる。
たとえば、あるテストが失敗したとする。モデルがそのエラーメッセージを取得できれば、失敗したテスト名、例外の種類、スタックトレースから調査対象を絞れる。ところが、テストコマンドの終了コードしか渡されず詳細な出力を取得できなければ、「失敗した」という事実から原因を推測するしかない。原因を特定するために追加の検索や再実行が必要になり、操作回数が増える。モデル自体の能力が変わらなくても、観測できる情報の粒度によって次の推論の条件が変わり、それが総作業時間と成功率へ影響する。
この構造は、既稿「AI に仕事を任せるには、モデルの外側を設計する」で整理した観測、判断、操作、検証の循環と一致する[15]。観測によって現在の状態を取得し、その情報から次の操作を判断する。操作によって外部環境が変化し、その変更結果を検証する。検証結果に問題があれば、再び観測と判断へ戻る。修正前の時点では修正後のテスト結果はまだ存在しないため、モデルが推論だけで最終結果を知ることはできない。コードを実際に変更し、テストを動かすことで初めて新しい情報が生成され、その情報を使って次の判断が可能になる。
| 段階 | モデル単体では不足する理由 | 外部環境で必要になる機能 | 失敗した場合の帰結 |
|---|---|---|---|
| 観測 | 現在のコード、変更差分、テスト結果はモデルの学習時点の内部知識には存在しない。 | ファイル読み取り、全文検索、差分取得、コマンド出力取得など、現在状態をモデルへ渡す手段が必要である。 | 古い状態や推測に基づいて判断し、存在しない問題を修正したり、実際の原因を見落としたりする。 |
| 判断 | 必要な状態が与えられていても、どの情報が原因と関係するかを選び、次の操作を決める必要がある。 | 必要な情報を保持できるコンテキストと、過去の失敗や変更履歴を適切に管理する仕組みが必要である。 | 不要なファイルを調査したり、すでに否定された修正を繰り返したりして作業経路が長くなる。 |
| 操作 | 正しい修正内容を推論しても、それだけではリポジトリーの状態は変化しない。 | ファイル編集、コマンド実行、依存関係操作、バージョン管理などを安全に実行する手段が必要である。 | 正しい判断を成果物へ反映できないか、誤った対象へ変更を適用して新しい不具合を作る。 |
| 検証 | 生成したコードを再読するだけでは、実行時エラー、既存機能の回帰、要求との不一致をすべて確認できない。 | テスト、静的検査、ビルド、差分確認、CI、レビューなど、変更後の状態を独立して確認する手段が必要である。 | 失敗している変更を成功と誤認して終了するか、正しい変更を失敗と誤認して不要な修正を続ける。 |
検証は、この循環を終了させる条件として特に意味を持つ。エージェントは、コードを変更した後に、テストや静的検査の結果から作業を止める時点を判断する。要求に対応するテストが通り、既存テストに回帰がなく、必要な静的検査も成功したという観測が得られて初めて、少なくとも機械的に定義された終了条件を満たしたと判断できる。反対に、テスト失敗を成功と読み違えれば、本来は循環を続けるべき状態で終了してしまう。終了判定を誤ると、未完成な成果物を完成品として扱うことになる。
この閉ループへローカル LLM を入れると、推論速度も単発チャットとは異なる意味を持つ。一回の返答が 5 秒遅い場合、対話用途では利用者が 5 秒余計に待つだけである。エージェントが観測、判断、操作、検証を 100 回反復する過程で毎回同じ 5 秒の差が生じれば、推論部分だけで約 8 分 20 秒の差になる。総作業時間が延び、その間にコンテキストが増えれば、前章で見たプレフィル時間や KV キャッシュの負荷も後半ほど大きくなる可能性がある。
一方、生成速度だけを高めても、エージェントが終了条件へ近づかなければ総作業時間は短くならない。たとえば、1 回の推論を半分の時間で終えられても、誤ったファイルを編集して修正とロールバックを 2 倍繰り返せば、一件の仕事としての時間短縮は失われる。ツール呼び出しの失敗、テスト結果の誤認、同じ調査の反復も同様である。局所的な推論速度と、一件の仕事が収束する速度は同じ指標ではない。
このため、コーディングエージェントとしてローカル LLM を評価する場合、生成速度とモデルの正答率に加え、要求を受け取ってから何回の観測と操作を行い、何回修正をやり直し、最終的にどの検証条件を通って終了したかを見る必要がある。推論速度は各反復に必要な時間を決め、モデル能力とツールインターフェースは終了までに必要な反復回数を変える。この二つが掛け合わされた結果として、一件の仕事の総時間が決まる。
ローカル LLM が実用になる境界も、この閉ループの中に現れる。モデルが正しいコードを生成できるだけでは足りず、そのコードを実環境へ適用し、変更後の状態を観測し、失敗から修正し、機械的に確認できる終了条件へ到達する必要がある。その全過程を許容できる時間と計算資源で反復できて初めて、「ローカルでモデルが動く」という状態が「ローカルで仕事を任せられる」という状態へ変わる。
6. M4 Max 128GB は限定されたエージェント作業を検証できる性能帯に入る
ここまで見てきた条件を M4 Max 128GB へ戻すと、2026 年 8 月時点では、100B 級を超えるモデルをノート型計算機へ載せて終わる段階から、そのモデルを反復推論へ使える段階まで進んでいることが分かる。oMLX に公開されたベンチマークでは、40 コア GPU と 128GB のユニファイドメモリーを持つ M4 Max 上で、4 ビット量子化した Qwen3.8-Flash-Next を実行している。8,192 トークンのコード入力に対して、プレフィル速度は 294.7 tok/s、生成速度は 23.1 tok/s、最初の出力までの時間は 27,796ms、oMLX が表示する Peak mem は 72.9GB と記録されている[16]。
この測定値は、それぞれ異なる処理を表している。PP tok/s は既存の入力を処理するプレフィル速度であり、TG tok/s は入力処理後に新しいトークンを生成する速度である。8,192 トークンを 294.7 tok/s で処理すると、単純計算では入力処理だけで約 27.8 秒かかる。実測された最初の出力までの 27,796ms とほぼ対応しており、この条件では最初の応答を待つ時間の大部分をプレフィルが占めている。一方、23.1 tok/s で 1,000 トークンを生成する場合、純粋な生成時間は約 43 秒になる。入力処理と 1,000 トークンの生成を単純に足せば約 71 秒であり、一回の応答時間にはプレフィルと生成の両方を含める必要がある。
コーディングエージェントでは、この約 71 秒に相当する処理を一度だけ実行するわけではない。最初にコードを読み、検索結果を受け取り、別のファイルを読み、修正案を作り、テスト結果を確認するたびに、入力処理と生成が再び発生する。実際の各ターンでは入力長も出力量も異なるため、71 秒をそのまま反復回数へ掛けることはできないが、プレフィルと生成の双方が総作業時間へ累積する構造は変わらない。第 4 章で見たように、作業履歴が増えれば入力も長くなりやすいため、短いターンの生成速度だけからエージェント全体の所要時間を推定することはできない。
| 実測項目 | 測定値 | エージェント作業での意味 |
|---|---|---|
| 入力長 | 8,192 トークン。 | 単純な短文対話ではなく、コードや作業状態を一定量含む入力で測定されている。 |
| プレフィル速度 | 294.7 tok/s。 | 8K 程度の入力では、モデルが最初の出力を始めるまでに数十秒を要することを示す。 |
| 生成速度 | 23.1 tok/s。 | 入力処理後は二桁 tok/s で出力を継続でき、反復推論へ利用できる速度帯にある。 |
| 最初の出力までの時間 | 27,796ms。 | 利用者やエージェントが次の出力を受け取るまでの実際の待ち時間を示す。 |
| Peak mem | 72.9GB。 | oMLX がこの測定で報告するメモリー指標であり、端末全体のピーク使用量とは区別して読む必要がある。 |
oMLX の Peak mem が 72.9GB である点も、生成速度とは別の意味を持つ。Qwen3.8-Flash-Next は、125B のメインモデルと 51B の N-gram Embedding を持ち、メインモデルでは一トークン当たり 6B のパラメーターを活性化する[6]。この規模のモデルを 4 ビット量子化して M4 Max 128GB 上へ配置し、8K のコード入力を処理した条件で、Peak mem は約 73GB と報告されている[16]。ただし、同じ Resource Usage では system used peak が 107.74GB と記録されており、72.9GB を端末全体のピークメモリー使用量と解釈することはできない[16]。
したがって、72.9GB を 128GB から単純に差し引いて利用可能なメモリー余地を評価することはできない。コンテキストを 8K から数万トークンへ伸ばせば KV キャッシュなどの使用量が変わり、同時に動作するアプリケーションや OS もユニファイドメモリーを使用する。量子化方式や推論器の設定が変われば測定値も変化する。72.9GB という数字は、この特定条件における oMLX の Peak mem として扱う必要があり、任意の長文脈や並列処理で同じ値になるという保証はない。
同じ理由から、このベンチマークだけを使って「GitHub Issue を何分で解決できる」と推定することもできない。測定されているのは、特定バージョンの推論器、特定の 4 ビット量子化モデル、8,192 トークンのコード入力に対する推論性能である。実際の Issue 解決時間には、対象リポジトリーの規模、必要なファイル数、修正の難易度、ツール呼び出し回数、テスト時間、失敗からの再試行回数が加わる。第 5 章で見たように、モデルが正しい修正方針を早く生成しても、観測や操作に失敗して反復回数が増えれば、一件の仕事としての所要時間は長くなる。
この測定は、エージェント実行の実用性を検証するための推論上の前提条件を具体的に確認している。第一に、100B 級を超える構成のモデルを 128GB のノート型計算機へ収容できている。第二に、8K のコード入力を数十秒で処理し、その後は 20 tok/s を超える速度で生成できている。この二つから、「モデルファイルを読み込める」という段階を越えて、コードや作業履歴を入力し、次の操作を決める推論を反復できる性能帯にあることまでは確認できる。ただし、検索、編集、テスト、再試行まで含む一件のエージェント作業が実用時間内に完了するかは、別途エンドツーエンドで測定する必要がある。
ここで実用性の範囲を決めるのは、モデルや Mac の性能に加え、仕事の終了条件である。仕様が確定した小規模なコード変更であれば、要求された差分を作り、既存テストと追加テストが成功し、静的検査にも問題がないという形で終了条件を定義できる。不具合修正でも、再現テストが失敗する初期状態から、修正後に同じテストが成功し、既存テストにも回帰がない状態まで到達すれば、機械的に確認できる範囲が大きい。こうした仕事では、エージェントが観測、判断、操作、検証を繰り返しながら、終了条件へ近づいているかを外部から確認できる。
一方、製品方針の決定、曖昧な要求の解釈、複数の設計案から許容リスクを選ぶ判断では、テストが成功しても仕事が完了したとは限らない。どの挙動を正しいとみなすか、互換性をどこまで維持するか、性能と保守性のどちらを優先するかといった評価基準そのものを決める必要があるからである。この種の仕事では、エージェントが高速に推論できることと、採用すべき判断を確定できることの間に別の工程が残る。
| 仕事の種類 | 終了条件 | ローカルエージェントとの相性 |
|---|---|---|
| 仕様確定後の小規模変更 | 要求された差分、テスト成功、静的検査成功などで終了を確認しやすい。 | 観測と検証を自動化しやすく、反復推論の対象にしやすい。 |
| 再現条件がある不具合修正 | 修正前の失敗が修正後に解消し、既存テストにも回帰がないことを確認できる。 | 操作結果をテストへ戻せるため、閉ループで収束させやすい。 |
| 定型的な変更 | 変更規則と検証方法を事前に明示できる。 | 判断の分岐が限定されるため、モデル能力と推論速度を作業時間へ結び付けやすい。 |
| 曖昧な仕様の設計 | 何を正しい成果とみなすか自体に判断が必要である。 | テスト成功だけでは終了を決められず、人間または別の判断工程が必要になる。 |
| 製品方針やリスク判断 | 技術的正しさ以外に事業、運用、互換性などの評価軸を選ぶ必要がある。 | 推論速度が十分でも、判断主体をローカルモデルだけへ移す根拠にはならない。 |
この区別を置くと、M4 Max 128GB で何を実用性の検証対象にできるかを限定できる。100B 級を超えるモデルをローカルで動かし、8K 程度のコード入力を処理し、二桁 tok/s で生成できるだけの推論性能は確認できる。しかし、それによってソフトウェア開発全体を自律実行できると結論することはできない。現在の性能から実用性を検証しやすいのは、終了条件を外部のテストや静的検査で定義でき、モデルがその条件へ向けて操作を反復できる仕事である。
その実行可能性は、複数の要素が別々の制約を緩和した結果として成立している。M4 Max の 128GB ユニファイドメモリーは大型モデルを保持する容量を提供する。4 ビット量子化は一つの重みが占めるデータ量を減らし、モデル本体以外の実行時領域を残しやすくする。MoE はモデル全体の規模に対して一トークン当たりの活性パラメーターを限定する。長文脈向けのモデル構造と推論器の最適化は、コードや作業履歴を入力したときの実時間を抑える。エージェント基盤は、その推論をファイル操作、コマンド実行、テストへ接続する。
一件の仕事を閉じるには、十分なメモリー、反復可能な推論速度、ツール操作、検証がすべて必要になる。M4 Max 128GB でローカル LLM の実用性を検証できる範囲が広がった理由は、単一の性能値が閾値を超えたからではなく、大型モデルを保持し、そのモデルで実際の作業状態を読む反復推論の条件が同じ端末上で揃い始めたことにある。
7. ローカル LLM は「一件の仕事が閉じるか」で評価する
ローカル LLM を選定するとき、モデルサイズ、量子化形式、コンテキスト長、プレフィル速度、生成速度、メモリー使用量は引き続き測る必要がある。これらはそれぞれ異なる制約を測る中間指標であり、実用性は組み合わせて評価する。モデルサイズと量子化形式は端末へ重みを収容できるかを左右し、コンテキスト長とプレフィル性能は作業状態をどこまで保持して次の推論へ渡せるかに影響する。生成速度は一回の出力時間を決め、メモリー使用量はその処理を継続できる余地を決める。コーディングエージェントとして使う場合、これらの値は最終的に、一件の要求を受け取ってから検証済みの成果物へ到達するまでの時間と成功率へ集約される。
既稿「Bonsai 8B でローカル LLM をミニマムから始める」では、小さなモデルを使う場合でも、モデルファイルの容量だけでなく、取得、読み込み、常駐といった運用上の負担が実際の使いやすさを左右することを確認した[17]。モデルを小さくすれば必要な計算資源は減るが、それだけで目的の仕事を十分な品質で処理できるとは限らない。反対に、大型モデルへ移れば能力を期待できても、読み込み時間やメモリー使用量が増え、端末上での運用が成立しなくなる場合がある。大型 MoE を使う現在の構成でも評価原理は変わらず、モデル内部の性能を、利用者が実際に完了させたい作業へ結び付けて考える必要がある。
コーディングエージェントで最初に測るべきなのは、実際の要求を与えてから成果物が検証可能な状態になるまでの総完了時間である。この時間には、モデルの読み込み、プレフィル、生成、ファイル検索、編集、コマンド実行、テスト、失敗後の再推論が含まれる。生成速度が 30 tok/s から 60 tok/s へ向上しても、誤った修正による再試行が増えれば、仕事全体の時間短縮は小さくなる。逆に、一回の生成速度が多少低くても、少ない反復で正しい修正へ到達できれば、総完了時間は短くなる。局所的な速度と仕事全体の速度を区別する必要がある理由はここにある。
総完了時間と並んで、同じ種類の仕事を複数回与えたときに、何件を終了条件まで到達させられたかという完了率も必要になる。10 件中 9 件を 30 分で終了できる構成と、10 件中 5 件だけを 20 分で終了できる構成では、後者の方が一回の成功例だけを見れば速くても、残り 5 件を人間が引き取る運用負担が大きい。自動化へ組み込む場合には、成功した一件の最短時間より、対象とする仕事群についてどの程度安定して終了できるかの方が重要になる。
再試行回数は、その完了率と総時間の内訳を知るための指標になる。テスト失敗後に一度修正して成功した場合と、同じファイルを何度も編集し直して最終的に成功した場合では、最終成果物だけを見ればどちらも成功である。後者は、わずかな入力条件の違いでさらに長い経路へ入りやすい。どの段階で何回やり直したかを記録すれば、時間がモデルの推論そのものに使われたのか、誤った判断からの回復に使われたのかを分けて確認できる。
| 評価項目 | 測る内容 | 単独で評価した場合に見落とすこと |
|---|---|---|
| モデルサイズと量子化形式 | どの規模のモデルを端末へ収容できるかを確認する。 | 収容後の推論速度や、目的の仕事を完了できる能力までは分からない。 |
| プレフィル速度 | コードや作業履歴を次の推論へ取り込むまでの時間を確認する。 | 生成後のツール操作や、失敗によって増える反復回数は含まれない。 |
| 生成速度 | 入力処理後に新しいトークンを生成する速度を確認する。 | 長い入力の待ち時間や、正しい終了状態まで何回推論する必要があるかは分からない。 |
| 最大メモリー使用量 | モデル、コンテキスト、実行時領域を含めて処理を継続できる余地を確認する。 | メモリーに収まった処理が実用時間内に終了するとは限らない。 |
| 再試行回数 | 誤った判断や検証失敗から、何回追加の推論と操作が必要になったかを確認する。 | 最終結果が要求を満たしたかは別に検証する必要がある。 |
| 総完了時間 | 要求を与えてから検証可能な成果物へ到達するまでの全工程を測る。 | 短時間で終了しても、終了判定そのものが誤っていれば成功とはいえない。 |
| 完了率 | 同種の仕事のうち、定義した終了条件まで到達できた割合を測る。 | どの工程が失敗原因だったかを知るには個別の実行記録が必要になる。 |
| 独立した検証結果 | テスト、静的検査、CI、レビューなどによって成果物が終了条件を満たすかを確認する。 | 別の種類の仕事でも同じ結果を再現できるとは限らない。 |
長時間の作業では、コンテキストの増え方も記録する必要がある。第 4 章で見たように、コード、検索結果、差分、テストログ、過去の判断が蓄積すると、次の生成へ進む前の入力処理が長くなる。初期状態では数秒で応答できても、作業後半で一回のプレフィルに数十秒から数分を要するようになれば、同じモデルでもエージェントとしての処理速度は変化する。コンテキストを圧縮して時間を短縮した結果、過去に失敗した理由まで失われ、同じ修正を再び試すなら、入力処理の短縮分が再試行によって相殺される。この挙動は、一件の仕事を最後まで実行して初めて観測できる。
検証可能性は、これらの性能指標とは別に、自動化できる範囲を決める。たとえば、テストで結果を確認できる不具合修正なら、モデル自身の説明ではなく、修正前に失敗したテストが成功し、既存テストにも回帰がなく、静的検査が通ったという外部状態を終了条件にできる。モデルが途中で誤った判断をしても、最終状態が条件を満たさなければ処理を継続させられる。一方、終了条件を外部から確認できない仕事では、モデル自身の自己評価に依存する割合が増え、自動実行の範囲を同じようには広げられない。
したがって、「実用的なローカル LLM」という表現にも対象となる仕事を付ける必要がある。M4 Max 128GB 上で大型モデルが二桁 tok/s で生成できるという事実から、ローカル LLM 全般が実用化したとは言えない。第 6 章で見たように、現在の構成で実用性を検証しやすいのは、仕様と終了条件が明確で、コード変更後の状態をテストや静的検査で確認できる種類の仕事である。対象をそこまで限定すれば、モデルを載せられるかというハードウェア上の条件から、仕事を最後まで任せられるかという運用上の条件までを同じ評価系へ置ける。
ここで評価の問いが変わる。「この Mac で何 B のモデルまで動くか」という問いは、依然として構成を選ぶ入口として必要である。128GB のメモリーへモデルを収容できることが確認できた後は、構成間の優劣を一件の仕事の完了時間や検証結果で比べる段階へ移る。次に問うのは、そのモデルへ実際のリポジトリーと要求を渡したとき、何回の推論と操作を経て、何分または何時間で終了条件へ到達し、その結果をどの手段で検証できたかである。生成速度が低ければ一回ごとの反復時間が増え、モデル能力が不足すれば再試行回数が増える。メモリー容量が不足すれば長いコンテキストを保持できず、検証手段がなければ正しく終了したかを確定できない。それぞれ異なる制約が、最終的には一件の仕事が閉じるまでの時間、成功率、検証可能性として現れる。
ローカル LLM の実用性は、要求された仕事について必要な状態を観測し、外部環境を操作し、失敗すれば修正を重ね、最後に独立した検証条件を満たすところまで、許容できる時間と計算資源で到達できるかで判断する。M4 Max の 128GB ユニファイドメモリー、大型 MoE、低ビット量子化、長文脈処理、ローカル推論ランタイムの組み合わせによって、2026 年 9 月時点では、この単位で実用性を評価するためのハードウェアと推論性能の前提が成立しつつある。エージェント作業として実用時間内に閉じるかは、対象となる仕事ごとに総完了時間、完了率、再試行回数、検証結果を測って判断する必要がある。
参考文献
- id774, MacBook Pro でローカル LLM を実用化する条件（2026-07-17）. https://blog.id774.net/entry/2026/07/17/5102/
- Apple, Apple introduces M4 Pro and M4 Max（2024-10-30）. https://www.apple.com/newsroom/2024/10/apple-introduces-m4-pro-and-m4-max/
- MLX, Unified Memory. https://ml-explore.github.io/mlx/build/html/usage/unified_memory.html
- id774, 量子化について詳しく解説する（2026-08-07）. https://blog.id774.net/entry/2026/08/07/5472/
- Elias Frantar, Saleh Ashkboos, Torsten Hoefler, Dan Alistarh, GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers（2022）. https://arxiv.org/abs/2210.17323
- Qwen Team, Qwen3.8-Flash-Next: A New Architecture, Towards Ultimate Cost-Efficiency（2026-08-26）. https://qwen.ai/blog?id=qwen3.8-flash-next
- William Fedus, Barret Zoph, Noam Shazeer, Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity（2022）. https://www.jmlr.org/papers/v23/21-0998.html
- Albert Q. Jiang et al., Mixtral of Experts（2024）. https://arxiv.org/abs/2401.04088
- Tri Dao, Daniel Y. Fu, Stefano Ermon, Atri Rudra, Christopher Ré, FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness（2022）. https://arxiv.org/abs/2205.14135
- Yushi Bai et al., LongBench: A Bilingual, Multitask Benchmark for Long Context Understanding（2024）. https://aclanthology.org/2024.acl-long.172/
- Cheng-Ping Hsieh et al., RULER: What’s the Real Context Size of Your Long-Context Language Models?（2024）. https://arxiv.org/abs/2404.06654
- Shunyu Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models（2023）. https://arxiv.org/abs/2210.03629
- Carlos E. Jimenez et al., SWE-bench: Can Language Models Resolve Real-World GitHub Issues?（2024）. https://proceedings.iclr.cc/paper_files/paper/2024/hash/edac78c3e300629acfe6cbe9ca88fb84-Abstract-Conference.html
- John Yang et al., SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering（2024）. https://arxiv.org/abs/2405.15793
- id774, AI に仕事を任せるには、モデルの外側を設計する（2026-08-21）. https://blog.id774.net/entry/2026/08/21/5544/
- oMLX, Qwen3.8-Flash-Next-oQ4e-mtp on M4 Max (40c)（2026-08-28）. https://omlx.ai/benchmarks/performance/pcqhpxqy
- id774, Bonsai 8B でローカル LLM をミニマムから始める（2026-07-24）. https://blog.id774.net/entry/2026/07/24/5125/