ローカルAIとChatGPTの比較。本当にどこまで近づいたのか

ローカルAIは、明確な確認手順を持つ限定的な作業に適した選択肢です。ChatGPTやClaudeに任せる作業を置き換えるには、モデル性能、利用可能なメモリ、出力を調査して検証するエージェントがそろう必要があります。

ワークステーションに収まるモデルでも、試行を繰り返すには適切なツールと十分な速度が必要です。この記事では、ベンチマーク結果、メモリ見積もり、完了した作業の証拠を分けて扱います。

重要なポイント #

• 性能: 参照スコアは特定の評価条件を示します。ローカルの量子化ビルドの結果ではありません。
• メモリ: ウェイト、コンテキストキャッシュ、ランタイムの余裕をまとめて見積もります。
• 速度: エージェント会話の再生はサービング性能を測ります。正しさは測りません。
• 検証: エージェントには要求された結果に合うチェックが必要です。
• 選択: ハードウェアを買う前に、反復作業、修正時間、総費用を比較します。

スコアを文脈の中で読む #

Artificial Analysis Intelligence Indexは複数の評価を参照スコアにまとめます。 モデルランキング とローカルハードウェアの結果から、2026年10月6日に確認した項目を示します。

インデックスポイントは知能や作業成功率の割合ではありません。GLMとClaudeの13ポイント差は、コーディング結果の13%差を示しません。同じモデルを比べるときは推論設定も影響します。

公開された評価方法 はテスト条件を説明します。一部の評価にはツールとエージェント基盤が含まれます。スコアはその条件で得た結果として扱います。別のアプリで動く圧縮ローカル版へ直接移さないでください。

ChatGPTとClaudeは製品です。一方、この表は選択した基盤モデルを比較しています。契約、選択モデル、使えるツール、作業コンテキストにも差があります。繰り返す作業を一つ選び、完全な構成を試してください。

リクエスト全体の予算を組む #

メモリ適合性は三つの割り当てから始まります。モデルウェイトは学習済みパラメータを保存します。キー・バリュー、つまりKVキャッシュは推論中の注意機構のデータを保持します。ランタイムバッファなどのソフトウェアが残りの容量を使います。

Required memory = resident weights + context cache + runtime allowance
Available memory = physical capacity - operating system and application reserve

量子化はウェイトの保存精度を下げます。低い精度は必要メモリを減らしますが、品質はモデルと量子化ビルドに依存します。キャッシュ精度は別設定です。Q4ウェイトファイルは、4ビットキャッシュを意味しません。

ウェイトだけの概算では、270億パラメータを16ビットで保存すると約50.3 GiBです。8ビットでは約25.1 GiB、4ビットでは約12.6 GiBです。公開ファイルサイズにはメタデータ、パッキング、混合精度も影響します。配置計画には実際のファイルを使います。

Qwen3.8-27Bのモデルカード と GLM-5.3のモデルカード は異なるアーキテクチャを説明します。Mixture-of-Expertsモデルは各トークンで一部のパラメータだけを有効にしますが、残りのウェイトにも保存領域が必要です。オフロードは配置とレイテンシを変えます。ウェイトを消しません。

公開ファイルから始める #

ダウンロードサイズはパラメータ数より具体的な出発点です。Unslothが公開するQwenとGLMのビルドは、量子化の選択で容量がどう変わるかを示します。

ファイルの出典: Qwen Q4_0 、 Qwen Q8_0 、 GLM UD-Q4_K_XLの分割ファイル 、 GLM UD-IQ2_Mの分割ファイル 。値は2026年10月6日に確認した丸めた一覧です。GiB変換では10進バイトを2³⁰で割ります。

これはウェイトファイルのサイズであり、常駐メモリ全体の測定値ではありません。ロード、キャッシュ、一時バッファ、追加モデル部品が実行中のプロセスに影響します。29 GBのダウンロードを30 GiBの割り当てと直接比べず、単位を変換してください。

コンテキストで適合性が変わる #

Qwenのアテンションキャッシュで計算例を示します。 公開設定 は、64層、4層ごとのフルアテンション、4個のキー・バリューヘッド、ヘッド次元256を指定します。

Full-attention KV bytes per token:
16 layers × 4 KV heads × 256 dimensions × 2 (K and V) × 2 bytes
= 65,536 bytes

8,192 tokens  = 0.5 GiB
32,768 tokens = 2.0 GiB

この計算上のキャッシュ構成は、1シーケンスの16ビットキーと値を仮定します。線形アテンション状態、ランタイムバッファ、アロケータのオーバーヘッド、画像や投機的デコードの任意部品は含みません。これらにも予備容量が必要です。

計画用の例として、丸めたウェイトサイズに残りの割り当て用3–5 GiBを加えます。この余裕は仮定です。選択したランタイムで測定した値に置き換えてください。

30 GiBの使用可能な割り当てならQ4例には余裕があります。この仮定ではQ8例は超過します。実測した予備容量が小さければ境界は変わります。短いプロンプトが成功しても、長いコーディングセッションの容量を証明しません。

同時リクエストも別の要素です。Ollamaは並列リクエストによるコンテキストメモリの増加と、キャッシュ精度の個別設定を説明しています。Q8キャッシュはF16キャッシュの約半分、Q4は約4分の1のメモリを使います。品質のトレードオフはモデルごとに異なります。 OllamaランタイムFAQ を参照してください。

割り当てにハードウェアを合わせる #

RTX 5090は32 GBの専用グラフィックスメモリを持ちます。128 GBのDGX Sparkは共有メモリを使います。Artificial Analysisは両構成をハードウェア結果で説明しています。容量は大きな割り当てを可能にしますが、サービング速度は証明しません。

GLM UD-Q4_K_XLはキャッシュ追加前に三つの容量をすべて超えます。約222.6 GiBのIQ2ウェイトも128 GBシステムを超えます。256 GBのMacでは、GPUから利用できる割り当てと残りのオーバーヘッドで実現性が決まります。 Appleの仕様 はハードウェアの選択肢を示します。推論割り当ては保証しません。

仮に240 GiBを使えるなら、IQ2ウェイト後に約17.4 GiB残ります。192 GiBではウェイトだけで不足します。どちらもOSの既定値、圧縮キャッシュ対応、有用なスループット、許容できるIQ2品質を証明しません。この用途で購入する前に、実際のランタイム構成を確認してください。

速度は別の結果 #

Artificial Analysisのローカル推論ベンチマークは、168回のモデルターンを記録したワークロードで再生します。 ラップトップとワークステーションの結果 は、テストしたQwen3.8 27B構成について次の時間を示します。

RTXの結果はSparkの約5分の1です。サービング構成が影響するため、これは普遍的なハードウェア比率ではありません。テストされたサービングビルドも上のGGUF計画例とは異なります。

再生時間にはツール実行が含まれず、記録された応答長を強制します。生成された回答が元の作業を解決したかは評価しません。MacBookの測定値からMac Studioの性能も導けません。

エージェントにフィードバックを与える #

エージェント実行システムは、ツール、コンテキスト、アクションループ、検証を提供します。モデルはその中でアクションを書き、選びます。CSV出力では、プロジェクトファイルの読み取り、コード変更、テスト実行、発生したエラーの受信が有用です。

例示的な出力作業を考えます。これは測定実験ではありません。エージェントはダウンロード機能を書きますが、日付形式を間違えます。目視確認では問題を見逃します。テストが出力ファイルを開き、日付を要求形式と比較します。エージェントは失敗を受け、フォーマッターを変更して検査を再実行します。

LangChainは GPT-5.2-Codexを固定し、Terminal Bench 2.0で52.8%から66.5%への変化を報告しています。 エージェント工学レポート は、検証ガイダンス、環境コンテキスト、反復編集の検出、推論予算の変更を説明します。

作業に合うチェックを選ぶ #

チェックの合格が示すのは、そのチェックが対象にした範囲だけです。CSVテストで列名を検証しても、日付形式、引用符、Unicode、アクセス制御は未検証です。検証方法を決める前に要求結果を定義してください。

τ-bench研究は、ツール、ユーザー、ドメインルールと対話するエージェントを評価します。 研究論文 は、最終データベース状態を期待結果と比較します。流暢な確認文だけでは取引の完了確認にならない理由が分かります。

ローカルでもオフラインとは限らない #

ローカル推論はモデルが動く場所を決めます。周辺アプリケーションは、文書、検索クエリ、トレース、ツール結果の送信先を決めます。リモート検索やクラウドツールにつながるローカルコーディングモデルは、ネットワーク接続されたシステムです。

Ollamaはローカル実行ではプロンプトや回答を受け取らないと説明し、クラウド機能を無効にする方法を文書化しています。これはランタイム固有の説明であり、接続されたすべてのエージェントのプライバシー保証ではありません。モデルのエンドポイントと各連携を ランタイムの文書 で確認してください。

ハイブリッドワークフローには明確な引き渡しルールが必要です。例えば、私文書の抽出はローカルに保ち、承認済みの集計結果だけをホスト型分析へ送ります。外部へ出る資料を確認してください。名前、顧客情報、機密の所見が残れば、要約にも機密情報が含まれます。

購入前にテストする #

終了条件が明確な反復作業を選びます。ツールを含め、使っているホスト型製品とローカル構成を比較します。同じ入力と受け入れ条件を与え、代表例で複数回繰り返します。

1. 構成を記録: 正確なモデルファイル、量子化、バックエンド版、コンテキスト上限、推論設定。
2. 成功を定義: 期待する成果物、必要な動作、禁止する副作用。
3. 完了を測定: 経過時間、合格したチェック、失敗試行、手動修正。
4. 所有コストを含める: ハードウェア、電気代、API料金、保守、作業時間。
5. 失敗を分類: 推論エラー、メモリ不足、レイテンシ、コンテキスト不足、検証不足。

評価した品質とレイテンシが要件を満たす作業にはローカル推論が合います。追加性能が失敗やレビュー作業を減らすなら、ホスト型モデルも有用です。ハイブリッドでは、どのデータを外部へ出せるかを決めてから作業を割り当てます。

受け入れ済み結果ごとの費用を数える #

人による修正時間が経済性を変えます。速いローカル応答でも10分の修正が必要なら、レビューを通る遅い応答より作業時間がかかります。推論費用と受け入れ済み結果を一緒に数えてください。

Cost per accepted task =
(hardware allocation + electricity + service fees + maintenance + review time)
÷ accepted tasks

レビュー費用の例: 1時間30ドルと仮定すると、8分の修正は1作業4ドルです。100件ならレビュー時間は400ドルです。これは算術例であり、ローカルモデルの測定済み失敗率ではありません。

同等の結果を比較します。 却下された試行も時間と費用に含めます。所有ハードウェアでは、購入費を現実的な使用期間と作業量に配分します。ホスト型サービスでは、契約またはAPI費用と残るレビュー作業を含めます。

ハードウェアの詳細は ローカルモデル、GPU、コンテキストのガイド を参照してください。容量と価格は DGX Sparkメモリ比較 で確認してください。作業結果を使い、品質、速度、データ要件を満たす最小構成を選びます。

参考動画 #

参考資料 #

• AI Mechanics: Local AI vs ChatGPT: How Close Are We Really? 。
• Artificial Analysis: モデル結果 、 評価方法 、 ローカル推論結果 。
• モデル公開元: Qwen3.8-27B 、 GLM-5.3 。
• Unsloth: Qwen GGUFビルド 、 GLM GGUFビルド 。
• Ollama: ランタイム、メモリ、プライバシーの文書 。
• LangChain: エージェント工学の結果 。
• τ-bench: ツール、エージェント、ユーザー評価の研究 。