GPU VRAM on KnightLiブログ

民生用グラフィックカードでエージェントを実行するコストの計算方法: 電気代、減価償却費、およびタスクあたりのコスト

Sat, 11 Jul 2026 10:30:00 +0800

コンシューマーグレードのグラフィックスカードがローカルエージェントを実行する価値があるかどうかを知りたい場合、「グラフィックスカードのコスト」だけを調べることはできません。また、API の 100 万トークンあたりの単価を比較することもできません。エージェントはモデル、ツール、ブラウザを繰り返し呼び出します。長いコンテキスト、失敗した再試行、およびアイドル状態のスタンバイはすべて、実際のコストを変更します。

最も現実的な方法は、コストを電気代、ハードウェア減価償却費、サポート機器、手動メンテナンスの 4 つの項目に分割し、同時に「成功した各タスク」と「100 万個の出力トークンあたり」に従って計算することです。

まず計算したいコストを決定します

口径	答えるのに適した質問	見逃しやすいアイテム
増分コスト	私はすでにゲーム機を持っています。空き時間にエージェントを実行するとどれくらいの費用がかかりますか?	グラフィックスカードはすでにあるのですが、減価償却費に含まれますか?
全額負担	地元代理店専用のマシンを購入するのは費用対効果が高いですか?	ホスト、メモリ、SSD、冷却および減価償却
タスクあたりのコスト	ドキュメントとコードのタスクを自動化するにはどれくらいの費用がかかりますか?	失敗、再試行、および手動レビュー
スループットコスト	自己構築の推論サービスを構築するための 100 万トークンあたりのコストはいくらですか?	トークン、KV キャッシュ、アイドル時間を入力します

グラフィックスカードが元々ゲームやその他の作業に使用されていた場合は、最初に増分コストを計算する方が正確です。エージェント用にマシン全体を購入した場合にのみ、マシン全体の減価償却費が全額含まれます。

月額合計費用の計算式

まず、月次キャリバーを使用します。データを取得するのが最も簡単です。

月度总成本 = 电费 + 硬件月折旧 + 配套服务费 + 人工维护成本

电费 = 实测整机平均功耗(kW) × 实际运行小时数 × 电价(元/kWh)
硬件月折旧 = (购入总价 - 预估残值) ÷ 使用月数
单次成功任务成本 = 月度总成本 ÷ 月成功任务数
每百万输出 token 成本 = 月度总成本 ÷ 月输出 token 数 × 1,000,000

「マシン全体の平均消費電力」は、グラフィックスカードの公称 TBP だけを調べるのではなく、ソケットの電力メーターまたは UPS から可能な限り取得する必要があります。エージェントは、CPU、メモリ、SSD、ファン、モニターでも実行されます。 GPU の消費電力のみを使用すると、電気代が過小評価されます。逆に、マシンがスタンバイ状態であってもタスクを処理していない期間は、純粋な推論コストに混入すべきではなく、別個に記録するのが最善です。

置換可能なパラメータの例

実際のエージェントのワークロードでマシンの平均消費電力が 280 W と測定され、1 日 6 時間、1 か月に 30 日稼働すると仮定します。現地の電力料金は 0.8 元/kWh として計算されます。この目的のために購入したハードウェアは 7,000 元、36 か月で償却され、残存価値は無視されます。

1
2
3

电费 = 0.28 × 6 × 30 × 0.8 = 40.32 元/月
硬件折旧 = 7,000 ÷ 36 = 194.44 元/月
月度基础成本 = 234.76 元/月

今月、受け付けたタスクが 600 件完了した場合、基本コストはタスクあたり約 0.39 元となります。ここでの「完了」はモデルの返却としてのみカウントされるものではありません。スクリプトの実行の成功、作業指示の完了、手動検査の合格などのビジネス結果に基づく必要があります。

これは単なる計算例であり、普遍的な価格ではありません。消費電力量、使用時間、電気料金、購入金額、タスク量などを自分のデータに置き換えてこそ意味があります。

エージェントの見積もりが通常のチャットよりも難しいのはなぜですか?

チャットモデルはトークンによって請求されることが多く、エージェントのコストは実行パスにも影響されます。

タスクには、計画、検索、ツールの呼び出し、結果の読み取り、および複数回の修正が含まれる場合があります。
コンテキストが長くなるほど、より多くの KV キャッシュが占有されます。ビデオメモリが不足すると、速度が低下し、CPU/RAM がアンロードされ、さらには再試行が発生します。
ブラウザの自動化、コードテスト、ファイル処理により、GPU が常に完全に負荷されていない場合でも、タスク時間が長くなる可能性があります。
マルチエージェントの並列化によりスループットは向上しますが、メモリ競合、キューイング、および障害率も増加する可能性があります。
最初のトークンの遅延を減らすために、常駐モデルではアイドル時の消費電力が増加します。

したがって、エージェントのコストを表すために短い質問と回答のトークンを使用しないでください。少なくとも一連の実際のタスクを選択し、それらを 1 週間連続して実行し、入出力トークン、成功率、再試行回数、実時間、およびマシン全体の電力消費量を記録します。

同時に見るべき2つのユニット

成功したすべてのタスク

これはビジネス上の意思決定に最も近いものです。「現地エージェントがPRを自動処理する」「データを一括収集する」「カスタマーサービスドラフト作成」などの固定プロセスを比較するのに適しています。

`1`	`每个成功任务成本 = (本周期全部成本) ÷ 成功且验收通过的任务数`

失敗したタスクは分子から削除できません。それらが消費する電力、推論時間、および手動のトラブルシューティングが、ローカルシステムの実際の運用コストとなります。

100万トークンあたり

これは、オンプレミスの推論サービスとクラウド API を比較しながら、入力と出力を区別するのに適しています。多くのエージェントの入力には長いツールログと履歴コンテキストが含まれており、入力トークンは出力トークンよりもはるかに多くなります。出力トークンのみで割ると、数値は大きくなります。より信頼性の高いアプローチは、入力、出力、および合計トークンを同時に記録し、同じ統計的精度を維持することです。

自分のデータを収集する方法

最初から複雑な監視システムを構築する必要はありません。まずテーブルを作成し、実行ごとに次のフィールドを記録します。

分野	記録方法
開始時間と終了時間	エージェントログまたはタスクキュー
マシン全体の消費電力	スマートコンセント、電力メーターまたはUPS
入出力トークン	推論サービスのログまたはクライアント統計
成功、失敗、再試行	タスクのステータスとエラーログ
手動レビュー時間	作業命令、PR、または抜き打ち検査記録
モデルと定量化されたバージョン	同じデータセット内に異なるモデルを混在させないでください。

ベースラインとして 20 ～ 50 の代表的なタスクから始めます。次に、短いコンテキスト、長いコンテキスト、多くのツール呼び出し、および多くの再試行を含むタスクを個別にテストして、メモリとモデルの選択がコストに与える影響を確認します。ビデオメモリの計画は、ローカルモデルの定量化とビデオメモリの選択と組み合わせて判断できます。

誤解を招かないように減価償却を計算する方法

減価償却に対する唯一の答えはありませんが、まず前提条件を書き留める必要があります。

既存のグラフィックスカード: 電気代と追加のメンテナンスは増分コストとしてのみ計算できます。グラフィックスカードの機会費用を、より控えめな全額費用として設定することもできます。
新しく購入した機器: グラフィックスカード、ホスト、メモリ、SSD、ラジエーターが一緒に含まれている必要があります。グラフィックスカードの価格をただばら撒かないでください。
寿命: 24、36、または 48 か月が有効です。重要なのは、同じ仮定を使用してオンプレミスとクラウドを比較することです。
残価: 機器の再販が見込まれる場合、推定残価を購入価格から差し引くことができます。不確実な場合は 0 に設定すると、結論はより保守的になります。

NAS または小規模ホストは通常、消費電力が少なくなりますが、メモリ、冷却、拡張機能によってモデルと同時実行性も制限されます。このルートを検討する場合は、まず NAS 導入 Ollama の性能判断を読んでください。

クラウド API と比較する場合は、単価だけを比較しないでください

クラウド側はタスクあたりのコストに変換することもできます。

`1`	`云端每任务成本 = 模型 API 费用 + 工具/API 费用 + 必要的存储与网络费用 + 人工复核成本`

通常、ローカルは次のような状況に適しています。

毎日安定して予測可能なワークロードがあり、マシンの使用率は高くなります。
データを外部サービスに送信できないか、送信することが期待されていません。
すでに動作する GPU があるため、追加コストは主に電気代になります。
自己保守可能なモデル、ドライバー、サービス、およびクラッシュ回復は許容されます。

多くの場合、クラウドは次のような状況に適しています。

負荷は散発的であり、マシンはほとんどの時間アイドル状態になります。
タスクには、ローカルビデオメモリをはるかに超える大規模なモデル、非常に長いコンテキスト、またはピーク同時実行性が必要です。
チームはドライバー、モデルのアップグレード、監視、トラブルシューティングを引き受ける気はありません。
タスクの結果は価値が高く、最も強力なモデルまたはマルチモーダル機能が最初に必要です。

ローカル展開は、2 つのオプションから選択するだけではありません。安定したプライバシーに配慮したステップはローカルに配置されます。複雑で低頻度のステップ、またはより強力なモデルを必要とするステップはクラウドに呼び出され、多くの場合、総コストの制御が容易になります。

実際的な決定ライン

ローカルの毎月の固定コストを F として記録し、タスクごとの変動電力およびメンテナンスコストを v として、クラウドのタスクごとのコストを c として記録します。 c > v の場合、ローカル損益分岐点を達成するために必要なタスクのおおよその量は次のとおりです。

`1`	`每月盈亏平衡任务数 = F ÷ (c - v)`

c が v 未満またはそれに近い場合、規模の関係でローカルの料金が大幅に安くなるわけではありません。現時点では、プライバシー、遅延、制御性、オフライン機能をさらに考慮する必要があります。この計算式は単なる財務フィルターであり、依然として失敗率と手動によるレビュー時間が必要です。

よくある誤解

グラフィックスカードの消費電力のみに注目してください: マシン全体の電力、スタンバイ、および冷却にも支払う必要があります。
名目上のトークン/秒をスループットと考えてください: 実際のエージェントは、コンテキスト、ツール、ネットワーク、テストステップによって速度が低下します。
失敗したタスクを無視する: 最も頻繁に再試行されるプロセスは、多くの場合コストブラックホールです。
モデル料金のみが計算されます: ブラウザー、検索、ベクターライブラリ、ストレージ、人間によるレビューの料金も適用される場合があります。
異なるモデルのデータの混合: 量子化バージョン、コンテキストの長さ、同時実行性が異なるため、結果を水平方向に比較することはできません。

要約する

消費者向けのグラフィックカードでエージェントを実行するコストは、「1 時間あたり数キロワット時の電力」だけで答えられるべきではありません。まずマシン全体の測定された電力消費量を使用して電気コストを計算し、次に独自の減価償却の仮定に従ってハードウェアコストを追加し、最後に成功したタスクの数と償却するトークンの量を使用します。実際のワークロードの期間を継続的に記録した後、ローカルでの実行を継続するか、ビデオメモリを拡張するか、一部のステップをクラウド API に引き渡すかを明確に判断できます。

NAS 導入の Ollama パフォーマンスが不十分かどうか: CPU、メモリ、グラフィックスカードの判断方法

Sat, 11 Jul 2026 09:40:43 +0800

NAS は Ollama を導入できますが、「インストールできる」ことと「すぐに使用できる」ことは別のことです。

目的が、時折の要約、ファイルの Q&A、ホームオートメーション、および低頻度の API 呼び出しを作成することである場合、x86 NAS は CPU を使用して小規模モデルを実行できます。チャットソフトウェアなどの継続的な会話、7B/8B コードモデルの実行、または複数のサービスコールを行いたい場合、鍵となるのはハードドライブの数ではなく、ビデオメモリ、メモリ、放熱です。

最初に結論を言いましょう:

**利用可能な GPU を持たない NAS は、小型モデルや低頻度のタスクに適しています。 Ollama によって正しく認識された NVIDIA GPU のみが、日常サービスとして 7B/8B モデルを使用するのに適しています。 **

まず、NAS がどのカテゴリに属しているかを確認してください

製品プロモーションページで「AI チップ」「NPU」「4K トランスコーディング」だけを見てはいけません。 Ollama が高速化できるかどうかは、システム、ドライバー、コンテナーの権限、およびハードウェアが実際の実行環境で認識されるかどうかによって決まります。

NASのステータス	適合性	より実用的な用途
ARM CPU、8GB RAM、利用可能な GPU なし	限定	最小限のモデル、単純な分類、オフラインタスク
x86 CPU、8GB RAM、利用可能な GPU なし	かろうじて使える	1B–3B 定量モデル、低頻度テキスト処理
x86 CPU、16GB ～ 32GB メモリ、利用可能な GPU なし	テスト可能	3B–7B 低量子化モデルですが、一般に応答が遅くなります
x86 NAS + 8GB NVIDIA ビデオメモリ	毎日利用可能	7B/8B 定量チャット、軽量コード支援、シングルユーザー API
x86 NAS + 12GB 以上の NVIDIA ビデオメモリ	より適切な	8B モデルの方が快適で、一部の 14B 定量的モデルはコンテキストに基づいて選択できます。

この表は展開を判断するための出発点であり、パフォーマンスを保証するものではありません。 CPU モデル、メモリチャネル、モデル形式、コンテキストの長さ、同時実行数、NAS システムの制限、および熱放散によって実際の結果は異なります。

まずは「記憶」と「推論」を分けて見てみましょう。

NAS の大容量ハードディスクは、主にモデルファイルストレージの問題を解決します。多くの GGUF、Ollama モデルレイヤー、ドキュメントライブラリを保存できます。推論速度は主に次の項目によって決まります。

CPU コアのパフォーマンスとメモリ帯域幅。
システムメモリがモデルとランタイムをインストールするのに十分かどうか。
GPU が利用可能かどうか、およびビデオメモリがモデルとコンテキストに対応できるかどうか。
PCIe レーン、ドライバー、コンテナーが透過的に正しく送信されるかどうか。
コンテキストの長さ、モデルの量子化、同時実行性、および出力の長さ。

「NAS に 40TB のハードドライブが搭載されている場合、NAS は 32B モデルを実行できますか?」に対する答えは次のとおりです。通常は、ファイルは確実に配置できますが、許容可能な速度で推論できない可能性があります。

CPU のみの NAS: 導入する価値があるのはいつですか?

GPU がなくても Ollama を実行することは可能です。公式の Docker イメージは純粋な CPU ブートをサポートしています。

docker run -d \
  -v ollama:/root/.ollama \
  -p 11434:11434 \
  --name ollama \
  ollama/ollama

CPU のみに適したもの:

夜間のバッチ要約、文書分類、タグ抽出。
ホームオートメーションにおける低頻度のテキストタスク。
API 呼び出し、RAG パイプライン、権限ロジックを検証します。
初期トークンのレイテンシや生成速度の影響を受けない個人用ツール。

以下にはあまり適していません:

複数人チャットサービス。
ロングタイムコードエージェント。
大規模なモデルは継続的に生成されます。
リアルタイムの音声アシスタントまたは高頻度の Web Q&A。

CPU のみの正しい戦略は、最初に小さなモデル、短いコンテキストを使用し、同時実行性を制限することです。最初に最大のモデルをダウンロードし、その後「NAS に依存してゆっくり計算する」ことでクラウドのようなエクスペリエンスが得られることを期待しないでください。

少なくともどのくらいのメモリを確保する必要がありますか?

システムメモリは、モデルの重み付けだけでなく、NAS 自体、ファイルキャッシュ、Docker、ダウンロードタスク、フォトインデックス、コンテナー、KV キャッシュにも使用されます。

実際的な原則: **大量のスワップが開始されるまで、Ollama が NAS メモリを使い果たさないようにしてください。 ** スワップが頻繁に介在すると、応答時間が大幅に低下し、ファイル共有などのサービスにも影響が生じます。

メモリ	提案
8GB	小規模なモデルと軽量のテストのみが推奨されます。 NAS が複数のサービスを実行している場合は、より慎重になります。
16ギガバイト	CPU のみのローカルアシスタントの開始点として使用でき、小規模なモデルまたは低量子化バージョンを優先します。
32GB	7B レベルの少量モデル、RAG、および複数の軽量コンテナの共存により適しています
64GB以上	より大きなモデルや長いドキュメントの CPU/ハイブリッドオフロードには適していますが、十分な高速な生成には対応しません。

モデルファイルサイズは下限値にすぎません。モデルの読み込み、コンテキスト、およびランタイムは引き続きメモリを消費するため、実行できるかどうかを「ファイル 8GB、マシン 8GB」に依存しないでください。

エクスペリエンスにおける最大の違いは、NVIDIA GPU で見られます。

NAS が x86 Linux で、サポートされている NVIDIA グラフィックスカードを備えている場合、Ollama は GPU アクセラレーションを使用できます。 Ollama は、NVIDIA コンピューティング機能 5.0+ およびドライバー 531+ のサポート範囲を公式にリストしており、その中には RTX 30 シリーズもサポートリストに含まれています。

Docker ソリューションでは、ホストが最初に NVIDIA Container Toolkit を構成し、次に GPU パラメーターを使用してコンテナーを開始する必要があります。

docker run -d \
  --gpus=all \
  -v ollama:/root/.ollama \
  -p 11434:11434 \
  --name ollama \
  ollama/ollama

コンテナーが開始されたら、大規模なモデルを直接ダウンロードするのではなく、GPU 透過伝送自体を検証します。

`1`	`docker run --gpus all ubuntu nvidia-smi`

このコマンドでグラフィックスカードが適切に表示されない場合、Ollama コンテナーは GPU を使用できません。このとき、まずドライバー、Container Toolkit、Docker ランタイム、および NAS システムが PCIe GPU 透過伝送をサポートしているかどうかを確認する必要があります。

NAS のコアグラフィックス、NPU、トランスコーディング機能を直接使用できますか?

これはデフォルトでは想定できません。

多くの NAS のコアグラフィックスは、主にビデオのデコード、トランスコード、またはグラフィック出力に使用されます。一部のデバイスによってアドバタイズされる NPU は、メーカー独自のアプリケーションに対してのみ公開される場合があります。 Ollama で使用できるかどうかは、Ollama がサポートするバックエンド、オペレーティングシステム、ドライバー、およびデバイスの権限によって異なります。

導入前に実際の証拠を確認する必要があります。

ホストが GPU デバイスを認識できるかどうか。
nvidia-smi または対応する製造元の検出ツールをコンテナー内で実行できるかどうか。
Ollama ログには GPU の使用状況が明確に示されていますか。
同じプロンプトで、GPU と CPU の速度の差は妥当ですか?

この証拠が見つからない場合は、CPU のみの予想に従って計画を立ててください。デバイスに「トランスコーディングエンジン」が搭載されているという理由だけで、個別のグラフィックスパフォーマンスに基づいてモデルを購入しないでください。

NASを故障させないためのモデルの選び方

NAS 導入の核心は、最大のモデルを追求することではなく、まず共通のタスクを安定して完了させることです。

シーン	モデル選択のアイデア
家族文書の概要、分類、簡単な質問と回答	まずは 1B ～ 4B モデルを試してください
中国語チャット、軽量スクリプト、シングルユーザー API	8GB のビデオメモリがある場合は、7B/8B 量子化モデルを試すことができます。
長いコード、複雑なエージェント	より大きなメモリのホストまたはクラウドを優先します。通常の NAS CPU だけに依存することはお勧めできません。
埋め込み/RAG	通常、組み込みモデルは軽量で NAS に適しています。生成されたモデルはオンデマンドで呼び出されます
複数の人から同時に電話がかかってきた	最初にキューと同時実行の制限を行い、すべてのリクエストが大規模なモデルを並列で直接ロードしないようにします。

モデルが大きすぎると、NAS の一般的な症状は直ちに障害が発生するのではなく、読み込みに時間がかかり、最初のトークン生成が遅くなり、生成速度が遅くなり、システムメモリが継続的に増加することであり、最終的にはファイルサービスとコンテナの安定性に影響を与えます。

推奨される展開構造

ほとんどの家族や小規模チームでは、NAS を「データと光の推論ノード」として使用することをお勧めします。

NAS
├─ Ollama：小模型、Embedding、低频 API
├─ 文档与向量库：私有文件、备份、RAG 数据
├─ 反向代理：局域网访问控制
└─ 监控：CPU、内存、GPU、容器日志

高显存主机或云端
└─ 大模型、长上下文、复杂 Agent、高并发推理

この分業は、すべての推論を NAS に強制するよりも安定しています。機密ファイルはローカルに残り、重いタスクはより適切なデバイスにルーティングされます。

導入前の 5 分間のテスト

最初に数十 GB のモデルをダウンロードしないでください。まず次のプロセスに従って判断します。

NASのアーキテクチャ、Dockerのサポート、メモリ残量を確認します。
Ollama コンテナを起動し、http://NAS地址:11434 にアクセスできることを確認します。
小さなモデルを用意し、5 ～ 10 個の決まった質問を続けて質問します。
CPU、メモリ、スワップ、ディスク IO、GPU の使用状況を観察します。
次に、実際の要件に近いモデルに切り替えて、コンテキストと同時実行性を徐々に高めます。

次のコマンドを使用して、コンテナーリソースを表示できます。

`1`	`docker stats ollama`

NVIDIA GPU を使用している場合は、次のことも同時に観察してください。

`1`	`nvidia-smi`

モデルの実行時にファイル共有、写真の提供、またはバックアップのタスクが著しく遅くなる限り、現在のモデルまたは同時実行性は NAS には適していないため、モデルのサイズを小さくするか、推論を他のマシンに移動する必要があります。

ネットワークとセキュリティを無視しないでください

Ollama のデフォルトのローカルサービスポートは 11434 です。 LAN 上の他のデバイスからこのポートを呼び出せるようにするには、まず NAS ファイアウォールまたはリバースプロキシ層でアクセス制御を実装し、未認証の推論ポートをパブリックネットワークに直接公開しないでください。

特に、NAS に家族の写真、バックアップ、ドキュメント、プライベートファイルがある場合、モデルサービス、ファイルサービス、および管理バックエンドは異なるアクセス許可境界を使用する必要があります。 LAN 上で通話を完了できる場合、パブリックネットワークポートを開く必要はありません。

要約する

Ollama が NAS 導入に十分であるかどうかは、次のように判断できます。

只做摘要、分类、Embedding
-> CPU-only NAS 可以尝试

想要 7B/8B 模型的日常交互体验
-> 需要可用 GPU，优先看显存

想做长上下文、复杂 Agent 或多人并发
-> 更适合高显存主机或云端推理

まず小規模なモデルを使用してリソースと安定性を検証し、次にグラフィックスカードを追加するか、メモリを拡張するか、推論ノードを分割するかを決定します。 NAS はプライベートデータや軽量モデルサービスをホストするのに最適ですが、自然な大規模モデルサーバーではありません。

参照:

vLLM KV キャッシュのメモリが不十分な場合の対処方法: ビデオメモリ、コンテキスト、同時実行性のトラブルシューティング

Sat, 11 Jul 2026 09:36:02 +0800

vLLM の開始時に次のエラーが発生する場合、通常はモデルの重みのダウンロードが壊れているためではありません。

`1`	`The model's max seq len ... KV cache is needed, which is larger than the available KV cache memory`

これは、モデルの重みと実行時のオーバーヘッドがビデオメモリを占有すると、設定した最大コンテキスト長に合わせて KV キャッシュを準備するには残りのスペースが十分ではないことを意味します。最も直接的な処理シーケンスは次のとおりです。 **最初に --max-model-len を削減し、次に同時実行性を確認し、最後にメモリ使用率の改善、KV キャッシュの定量化、または容量の拡張を検討します。 **

--gpu-memory-utilization を最初から 1 にしないでください。これにより、vLLM は初期化を通過できる可能性がありますが、実際のリクエスト、CUDA グラフ、またはその他のプロセスがビデオメモリをめぐって競合すると、OOM が発生しやすくなります。

まず理解してください: なぜ KV キャッシュがビデオメモリをいっぱいにするのか

モデルの重みは「モデルをロードできるかどうか」を決定し、KV キャッシュは「モデルが同時に記憶できるトークンの数と処理するリクエストの数」を決定します。トークンが生成または読み取られるたびに、アテンション層は対応するキー/値の状態を保存する必要があります。

したがって、KV キャッシュの使用量は次の項目で増加します。

max_model_len: 許可される最大コンテキストが長くなるほど、キャッシュ要件も大きくなります。
同時リクエストの数: 各同時リクエストは独自のコンテキスト空間を占有します。
モデル構造: レイヤーの数、KV ヘッドの数、非表示サイズ、データ型はすべてキャッシュサイズに影響します。
キャッシュ精度: 通常、デフォルトはモデルのデータ型に従います。 FP8 などの低精度キャッシュはスペースを節約できますが、互換性と品質の限界があります。

最も見落とされているのは同時実行性です。各リクエストに 8K コンテキストしか与えられていない場合でも、複数のリクエストが同時に実行されている場合、KV キャッシュの総需要は依然として急速に増加します。

まずはログからどのような問題なのかを判断します

起動ログには通常、次の 3 つの重要な情報が含まれています。

モデルによって指定された、またはユーザーが構成した最大シーケンス長。
KV キャッシュに必要な GiB 数。
KV キャッシュに現在利用可能な実際のスペースと、vLLM によって推定される実現可能な最大長。

ログに「最大長 32768 には 10GiB KV キャッシュが必要ですが、現在は 4GiB のみです」と表示されている場合は、最初にモデルが 32K をサポートしているかどうかを心配する必要はありません。モデル サポート は、カードが現在の構成で 32,000 のリクエストを処理できることを意味するものではありません。

まず、ログによって提供される推定最大長に注目し、最初のテストをその長さの約 60% ～ 80% に設定し、その後長さを増やしていきます。

最優先: 低い `--max-model-len`

これは、成功率が最も高く、影響が最も予測しやすい調整です。たとえば、モデルはネイティブで 32K をサポートしており、実際のビジネスでは通常の会話、ショートコード、小さなドキュメントのみを処理する場合、8K から始めることができます。

1
2

vllm serve Qwen/Qwen3-8B \
  --max-model-len 8192

それでも十分でない場合は、もう一度試してください。

1
2

vllm serve Qwen/Qwen3-8B \
  --max-model-len 4096

モデルカードの公称 128K、256K、またはそれ以上のコンテキストをサービスパラメータに直接書き込まないでください。シングルカード導入の場合、実際に利用可能な長さは、重量、ビデオメモリ、同時実行性、およびキャッシュの精度によって異なります。

実際的な出発点:

ビデオメモリと使用量	最初に試行するコンテキストの長さ
12GB～16GB シングルカード、クラス 8B モデル	4096 または 8192
24GB シングルカード、7B ～ 14B モデル	8192 または 16384
24GBシングルカード、30Bレベル量子化モデル	4096 から始める
長文/RAG/マルチユーザーサービス	表に従うだけではなく、ログの推定とストレステストに基づいて意思決定を行います。

これらの値は、メモリの使用量ではなく、トラブルシューティングの開始点です。 KV キャッシュのサイズはモデル間で大幅に異なる場合があります。

2 番目の優先事項: 同時実行性とバッチ処理を制限する

サービスを開始できるからといって、同時実行性が高い条件下でサービスが安定するとは限りません。まず、同時実行性を小さい値に制御します。

1
2
3

vllm serve Qwen/Qwen3-8B \
  --max-model-len 8192 \
  --max-num-seqs 4

--max-num-seqs は、1 回の反復で処理できるシーケンスの数を制限します。数値を大きくするとスループットが高くなる可能性がありますが、KV キャッシュとスケジューリングのプレッシャーも大きくなります。

リクエストに長いプロンプトが含まれることが多い場合は、--max-num-batched-tokens にも注意する必要があります。一度に処理できるトークンの最大数を決定します。この値が高すぎると、プレフィルフェーズでより多くのリソースが即座に占有される可能性があります。トラブルシューティングの際は慎重に行い、安定性を確認してから徐々に拡張してください。

ストレステストは次の順序で実行することをお勧めします。

単一リクエスト、4K コンテキスト、サービスの安定性を確認しました。
単一リクエスト、8K コンテキスト、最初のトークンのレイテンシとビデオメモリを観察します。
2 つの同時リクエストにより、OOM がないことが確認されます。
次に、max_num_seqs またはバッチトークンの数を徐々に増やします。

コンテキスト、同時実行性、バッチおよびモデルの量子化を同時に調整しないでください。調整しないと、ビデオメモリを使い果たす原因となっているパラメータを特定することが困難になります。

3 番目の優先事項: `--gpu-memory-utilization` を適切に設定する

--gpu-memory-utilization は、現在の vLLM インスタンスで使用できる GPU メモリの割合を 0 ～ 1 の値で指定します。vLLM は、スペースのこの部分に基づいて重み、ランタイム、および KV キャッシュを計画します。

例えば：

vllm serve Qwen/Qwen3-8B \
  --gpu-memory-utilization 0.90 \
  --max-model-len 8192 \
  --max-num-seqs 4

エラーメッセージが明らかに「利用可能な KV キャッシュが少なすぎます」と表示され、GPU 上に他のプロセスがない場合は、0.90 から 0.92 または 0.94 まで試すなど、小さなステップで改善できます。一度に少しずつ追加して、実際のリクエストでテストしてください。

以下の状況ではデッドリフトを高く上げることはお勧めできません。

同じカード上で、デスクトッププログラム、別の推論サービス、またはトレーニングタスクも実行されます。
使用可能なビデオメモリは起動後に変動します。
CUDA グラフ、ビジョンモデル、または同時実行性の高いプレフィルを使用する場合、スパイクが発生する傾向があります。
初期化チェックの失敗だけでなく、実行中の CUDA OOM が発生しました。

複数のインスタンスが同じ GPU を共有する場合は、すべてを 0.9 に設定するのではなく、インスタンスごとに明示的なバジェットを設定する必要があります。

FP8 KV キャッシュ: グラフィックスメモリを保存する前にモデルとバージョンを確認してください

vLLM は、--kv-cache-dtype によるキャッシュデータタイプの変更をサポートしています。 CUDA 11.8 以降の環境では、次のような FP8 関連のオプションを使用できます。

1
2
3

vllm serve Qwen/Qwen3-8B \
  --kv-cache-dtype fp8 \
  --max-model-len 16384

FP8 KV キャッシュはキャッシュ使用量を大幅に削減できますが、完全に無料のスイッチとは考えないでください。

まず、現在の vLLM、CUDA、およびハードウェアがこのデータ型をサポートしていることを確認します。
モデルチェックポイントが適切な KV スケールを提供するかどうかは、結果に影響します。存在しない場合は注意して評価する必要があります。
長いコンテキスト、複雑な推論、ツール呼び出し、構造化された出力はすべて、デフォルトのキャッシュ精度に対してテストする必要があります。
不適切な大きなモデルをグラフィックスカードに適合させたいだけの場合は、通常、最初にコンテキストを下げるか、より適切なモデルに変更する方が安定します。

したがって、より推奨される順序は、最初にデフォルトの精度を使用して 4K/8K を安定して実行し、次に FP8 がビジネスで必要なコンテキストまたは同時実行性を実際に取得できるかどうかをテストすることです。

KV キャッシュサイズを手動で指定する場合の優先順位を把握する

新しい vLLM は、GPU あたりの KV キャッシュサイズをバイト単位で正確に指定するための kv_cache_memory_bytes を提供します。これは、複数のサービスがカードを共有し、固定のグラフィックスメモリバジェットを必要とするシナリオに適しています。

注: キャッシュバイト数を明示的に設定すると、gpu_memory_utilization によるキャッシュサイズの自動推論がオーバーライドされます。両方を相加的な利益とは考えないでください。まず、「比例予算」を使用するか「固定キャッシュ予算」を使用するかを決定します。

固定予算は、運用とメンテナンスの明確な制約があるサーバーに適しています。単一マシンのトラブルシューティングには --gpu-memory-utilization と --max-model-len を使用する方が直感的です。

CPU オフロードで何が解決でき、何が解決できないのか?

新しいバージョンの vLLM は、KV キャッシュの一部を CPU にオフロードするか、LMCache などのバックエンド処理キャッシュレイヤーと組み合わせることをサポートします。これにより、GPU キャッシュが不十分な場合に容量を拡張できますが、PCIe/メモリ転送と遅延が犠牲になります。

以下の場合に適しています。

非常に長いコンテキストリクエストが発生する場合があります。
ビジネスは、初期トークンの遅延が長くても許容できます。
十分なシステムメモリがあり、実際のストレステストが実施されています。
最高のスループットを追求するのではなく、長いプロンプトに対して機能低下パスを作成したい。

「モデルの重みを下げることができない」という問題を隠すのには適していませんし、同時実行性やコンテキストの上限の管理を置き換えることもできません。すべてのリクエストが頻繁にスワップアウトおよびスワップインされると、スループットが大幅に低下することがよくあります。

複製可能なトラブルシューティングテンプレート

保守的な構成から始めます。

vllm serve Qwen/Qwen3-8B \
  --gpu-memory-utilization 0.90 \
  --max-model-len 4096 \
  --max-num-seqs 2

オーダーリクエストが安定して処理できることを確認したら、以下の順序で調整してください。

4096 上下文稳定
-> 8192 上下文稳定
-> max_num_seqs 从 2 调到 4
-> 调整 max_num_batched_tokens
-> 再测试 FP8 KV Cache 或 CPU offload

各ラウンドでは、利用可能な KV キャッシュトークンの数、最初のトークン遅延、生成されたトークン/秒、およびピークビデオメモリの 4 つのデータが記録されます。こうすることで、最適化によってスループットが向上しているのか、それとも単に OOM を延期して同時実行性を高めているのかを知ることができます。

よくある誤解

誤解 1: モデルは長いコンテキストをサポートしているため、サービスを完全に有効にする必要があります

モデルの機能の上限とグラフィックスカードの保守性の上限は別のものです。サーバーの max_model_len は、ハードウェアおよびビジネスの上限に従って設定する必要があります。

誤解 2: 問題を解決するには `gpu_memory_utilization` を 1 に設定します

これにより安全マージンが減少しますが、KV キャッシュ自体の必要性は減少しません。実行時のスパイクにより CUDA OOM がトリガーされる可能性が高くなります。

誤解 3: 同時実行性に関係なく、重みの量子化のみを削減する

重みの量子化によりビデオメモリを解放できますが、同時実行性とコンテキストにより KV キャッシュが急速に拡大します。サービス構成では、リクエストの長さと数の両方を制限する必要があります。

誤解 4: CPU オフロードは、長いリクエストを拒否するよりも明らかに優れています

レイテンシが重要な場合、頻繁なオフロードは、より大きなメモリを備えたノードに長いリクエストを明示的にルーティングするよりも悪い可能性があります。まず、ビジネスの遅延とコストの境界を定義します。

要約する

vLLM KV キャッシュにメモリが不足しています。最も信頼性の高い処理優先度は次のとおりです。

降低 max_model_len
-> 限制 max_num_seqs 与 batch
-> 小步调整 gpu_memory_utilization
-> 验证 FP8 KV Cache
-> 最后考虑固定缓存预算或 CPU offload

最初は短いコンテキストと低い同時実行構成で安定して動作させ、その後ビジネスデータに応じて徐々に拡張していきます。モデルの重み、KV キャッシュ、同時実行性、および実際のコンテキストの長さを個別に検討する限り、ほとんどの「メモリ不足」問題をより迅速に特定できます。

参照:

Ollama マルチモデルスイッチングの構成方法: 常駐、ビデオメモリ、Modelfile のチュートリアル

Sat, 11 Jul 2026 09:32:06 +0800

Ollama がいくつかのモデルをインストールした後、多くの人が最初に抱く疑問は、チャット、コード、翻訳、埋め込みモデルを素早く切り替えるにはどうすればよいかということです。 2 番目の質問は、多くの場合、より現実的です。別のモデルに切り替えた直後に、前の質問がビデオメモリから消えるのはなぜですか?

結論から始めましょう。Ollama は各モデルを個別に提供する必要はありません。毎日の切り替えには ollama run <模型名> を使用します。 ollama ps を使用して、現在メモリ内にあるモデルを確認します。 ollama stop <模型名> を使用して不要なモデルを解放します。複数のモデルを同時に常駐できるかどうかは、ローカルディスクにダウンロードされるモデルの数ではなく、使用可能なビデオメモリまたはメモリにモデルが収まるかどうかによって決まります。

最も一般的に使用される切り替えコマンド

まず、このマシンによってダウンロードされたモデルをリストします。

`1`	`ollama ls`

チャットまたはコードモデルを開始します。

`1`	`ollama run qwen3:8b`

別のモデルに変更する必要がある場合は、別の名前を直接実行します。

`1`	`ollama run qwen3:4b`

または、テストのために埋め込みモデルに切り替えます。

`1`	`ollama run embeddinggemma "测试一段文本"`

モデルファイルはローカルに残り、切り替え時に再ダウンロードされません。モデルを初めてロードするときに、重みをビデオメモリまたはシステムメモリに入れる必要があります。モデルがまだメモリに保持されている場合は、再度呼び出す方が速くなります。

`ollama ps`: まずビデオメモリを誰が占有しているかを確認します。

切り替えがスムーズでない場合は、まず以下を実行してください。

`1`	`ollama ps`

実行中のモデル、またはメモリ内にまだ常駐しているモデルがリストされます。ここで注目すべき最も興味深い点は、モデル名、設置面積、プロセッサの場所、有効期限です。

中型のグラフィックカードしか持っておらず、2 つの大きなモデルを続けて起動すると、Ollama は 2 番目のモデル用のスペースを空けるために最初のモデルをアンインストールすることがあります。これは通常のリソーススケジューリングであり、モデルが失われるわけではありません。モデルはまだディスク上にあるため、次の呼び出し時に再ロードされます。

自然に期限切れになるのを待ちたくない場合は、事前に停止できます。

`1`	`ollama stop qwen3:8b`

次に、ollama ps を使用して、ビデオメモリが解放されたことを確認します。

デフォルトの滞留時間: 5 分

Ollama のデフォルトでは、モデルが最後に使用されてから約 5 分間保持されます。この設計は継続的な質問に適しています。最初の読み込みはわずかに遅く、後続のリクエストでは同じモデルを繰り返しビデオメモリに戻す必要がありません。

ビデオメモリが少ないマシンで複数のモデルを順番に使っていると、5分も経つと実際には「1台を動かし終わったばかりで、まだビデオメモリが戻っていない」という感覚になるかもしれない。現時点での制御方法は3つあります。

方法 1: 1 回の呼び出し後すぐにアンインストールする

API 経由で keep_alive を 0 に設定します。

curl http://localhost:11434/api/generate -d '{
  "model": "qwen3:8b",
  "prompt": "用一句话解释 KV cache",
  "keep_alive": 0
}'

これは、モデルが大きく、ビデオメモリが不足し、各タスクが独立している状況に適しています。

方法 2: モデルを長期間常駐させておく

同じコードモデルを 1 日中使用している場合は、keep_alive を負の数に設定できます。

curl http://localhost:11434/api/generate -d '{
  "model": "qwen3:8b",
  "keep_alive": -1
}'

こうすることで、手動で ollama stop を実行するか、サービスが再起動されるまで、モデルはメモリ内に残ります。十分なビデオメモリがない場合は、複数の大規模モデルに対してこれを設定しないでください。

方法 3: デフォルトの常駐時間をグローバルに変更する

OLLAMA_KEEP_ALIVE は Ollama サービスに設定できます。たとえば、すべてのモデルをデフォルトで 30 秒間保持したい場合は、次のようにします。

`1`	`OLLAMA_KEEP_ALIVE=30s`

Windows では、Ollama はユーザーまたはシステムの環境変数を継承します。セットアップが完了したら、トレイから Ollama を終了し、[スタート] メニューから再起動する必要があります。 Ollama が Linux 上の systemd によって管理されている場合は、サービス環境変数を設定し、サービスを再起動します。

API リクエストの keep_alive はグローバル OLLAMA_KEEP_ALIVE をオーバーライドするため、タスクごとに異なるポリシーを設定する方が適しています。

マルチモデル永続性の鍵: `OLLAMA_MAX_LOADED_MODELS`

OLLAMA_MAX_LOADED_MODELS は、同時にロードできるモデルの数を制限するために使用されます。たとえば、サービスで最大 1 つのモデルのみを保持したいとします。

`1`	`OLLAMA_MAX_LOADED_MODELS=1`

この設定の目的は、モデルを回転させたときに長時間ビデオメモリがいっぱいになることを避けるためですが、「大きなモデルをグラフィックスカードに無理やり収める」方法ではありません。 GPU 推論中、新しいモデルは、利用可能なビデオメモリに完全に収まる場合にのみ、他のモデルと同時に存在できます。そうしないと、Ollama は古いモデルをアンロードするか、モデルをより遅いメモリパスに配置します。

単一の 8GB、12GB、または 16GB グラフィックスカードの場合、通常、より安定した戦略は次のとおりです。

シーン	提案
毎日 1 つのチャットモデルのみを使用する	`OLLAMA_MAX_LOADED_MODELS=1`、5 分以内に保持します
小規模モデルチャット + 埋め込み	まずは両方の実際の占有状況を確認してください。同時に置ける場合は量を増やしてください。
コードモデルと一般モデルを交互に使用	二重常駐にこだわらず、業務に応じて切り替えて主体的に行動しましょう `ollama stop`
サーバーのマルチユーザー呼び出し	モデルサイズ、ビデオメモリ、リクエスト量を組み合わせて、同時実行数とキューを設定します。

同時実行性を無視しないでください: コンテキストもメモリを消費します

マルチモデルの問題はモデルの重みだけの問題ではありません。並列リクエストごとに、コンテキストと KV キャッシュのリソース消費量が増加します。

Ollama は、次の 2 つの関連する環境変数も提供します。

1
2

OLLAMA_NUM_PARALLEL=1
OLLAMA_MAX_QUEUE=512

OLLAMA_NUM_PARALLEL は、同じモデルで並列処理できるリクエストの数を制御します。同時実行数が増加すると、コンテキストの長さに応じて必要なリソースも増加します。単一のカードをローカルで使用する場合、多くの場合、デフォルトのままにするか、明示的に 1 に設定すると、トラブルシューティングが容易になります。同時実行性を高める際には、複数のモデルをロードしないでください。

OLLAMA_MAX_QUEUE は、ビジー時にキューに入れることができるリクエストの数です。キューイングを解決するだけであり、ビデオメモリは増加しません。

Modelfile を使用してさまざまな目的の固定エイリアスを作成する

同じ基本モデルに対してシステムプロンプトワード、温度、またはコンテキストポリシーを常に繰り返し設定する場合は、Modelfile を使用して複数のローカルエイリアスを作成できます。重みのセット全体を複製するのではなく、モデルに基づいてさまざまな構成を定義します。

たとえば、コードに偏った構成ファイル Modelfile.code を作成します。

1
2
3

FROM qwen3:8b
SYSTEM 你是一个中文编程助手。先说明修改思路，再给出可运行的最小代码。
PARAMETER temperature 0.2

モデルのエイリアスを作成します。

`1`	`ollama create qwen3-code -f Modelfile.code`

次に、直接実行します。

`1`	`ollama run qwen3-code`

書き込み指向のバージョンを作成することもできます。

1
2
3

FROM qwen3:8b
SYSTEM 你是中文写作助手，回答前先给结论，再给必要的结构化说明。
PARAMETER temperature 0.7

1
2

ollama create qwen3-write -f Modelfile.write
ollama run qwen3-write

注: qwen3-code と qwen3-write は、同じ基本方向を共有していますが、実行時には異なるモデル構成になります。ビデオメモリが不足している場合は、同時に無限に常駐できると想定しないでください。

タスクごとにモデルを切り替えるためのスクリプトまたは API を提供します

API では、モデル名自体がルーティングフィールドになります。スクリプトはサービスを再起動する必要はなく、タスクに応じて別の model を渡すだけです。

curl http://localhost:11434/api/chat -d '{
  "model": "qwen3-code",
  "messages": [
    {"role": "user", "content": "解释这段 Python 的异常处理逻辑"}
  ],
  "stream": false,
  "keep_alive": "10m"
}'

一般的な役割分担は次のとおりです。

小規模モデル: 分類、書き換え、要約、簡単な質問と回答。
コードモデル: ウェアハウスを解釈し、スクリプトを生成し、エラーを修正します。
埋め込みモデル: ベクトル検索、チャットを担当しません。
大規模モデル: 複雑な問題があり、オンデマンドでロードされ、使用後にリリースされます。

コードのタスクルーティングに「どのモデルを選択するか」を記述することで、すべての作業を 1 つの大きなモデルに詰め込むよりも速度とメモリの制御が容易になります。

Windows でよくある落とし穴

環境変数が変更されましたが、有効になりませんでした

Windows で OLLAMA_KEEP_ALIVE、OLLAMA_MAX_LOADED_MODELS、または OLLAMA_MODELS を変更した後は、実行中の Ollama トレイプログラムを終了して再起動する必要があります。通常、PowerShell を再度開くだけでは十分ではありません。

モデルファイルがシステムディスクに集中します

OLLAMA_MODELS を設定すると、モデルディレクトリを別のディスクに移動できます。次に例を示します。

`1`	`OLLAMA_MODELS=D:\OllamaModels`

Ollama を保存して再起動します。既存のモデルを移行する前に、ディスク容量とディレクトリのアクセス許可を確認してください。ボリュームを変更するためだけに古いディレクトリを削除しないでください。

モデルが削除されたのかと思った

切り替え後、ollama ps を持つ古いモデルは表示されません。これは、単にメモリからアンロードされたことを意味します。ダウンロードしたモデルは ollama ls で引き続き確認できます。ローカルモデルファイルは、次のコマンドを実行することによってのみ削除されます。

`1`	`ollama rm qwen3:8b`

単一のカードに適したデフォルト戦略のセット

消費者向けグラフィックスカードが 1 つしかなく、複数のモデルを頻繁に切り替える場合は、次の戦略から始めることができます。

1
2
3

OLLAMA_MAX_LOADED_MODELS=1
OLLAMA_KEEP_ALIVE=2m
OLLAMA_NUM_PARALLEL=1

次に、タスクごとに qwen3-code、qwen3-write、または埋め込みモデルを呼び出します。大規模なモデルを実行する必要がある場合は、最初に ollama stop を実行して不要なモデルを停止します。長いコンテキストまたは大きなファイルに遭遇した場合は、同時実行数と常駐数を減らします。

この構成の目的は、グラフィックスカードができるだけ多くのモデルを同時にロードできるようにすることではなく、各スイッチを予測可能にし、グラフィックスメモリが長期間忘れられるモデルでいっぱいにならないようにすることです。

要約する

Ollama マルチモデルスイッチングのコアコマンドは 4 つだけです。

ollama ls
ollama run <模型名>
ollama ps
ollama stop <模型名>

さまざまな目的に合わせてモデルをより適切に管理したい場合は、Modelfile を使用してエイリアスを作成します。ロードとリリースを制御したい場合は、keep_alive、OLLAMA_KEEP_ALIVE、OLLAMA_MAX_LOADED_MODELS を使用します。まずビデオメモリに応じて同時居住者数を決定し、次にマルチモデルルーティングと同時実行性を考慮します。構成はより安定します。

参照:

GPU VRAM on KnightLiブログ

民生用グラフィック カードでエージェントを実行するコストの計算方法: 電気代、減価償却費、およびタスクあたりのコスト

まず計算したいコストを決定します

月額合計費用の計算式

置換可能なパラメータの例

エージェントの見積もりが通常のチャットよりも難しいのはなぜですか?

同時に見るべき2つのユニット

成功したすべてのタスク

100万トークンあたり

自分のデータを収集する方法

誤解を招かないように減価償却を計算する方法

クラウド API と比較する場合は、単価だけを比較しないでください

実際的な決定ライン

よくある誤解

要約する

NAS 導入の Ollama パフォーマンスが不十分かどうか: CPU、メモリ、グラフィックス カードの判断方法

まず、NAS がどのカテゴリに属しているかを確認してください

まずは「記憶」と「推論」を分けて見てみましょう。

CPU のみの NAS: 導入する価値があるのはいつですか?

少なくともどのくらいのメモリを確保する必要がありますか?

エクスペリエンスにおける最大の違いは、NVIDIA GPU で見られます。

NAS のコア グラフィックス、NPU、トランスコーディング機能を直接使用できますか?

NASを故障させないためのモデルの選び方

推奨される展開構造

導入前の 5 分間のテスト

ネットワークとセキュリティを無視しないでください

要約する

vLLM KV キャッシュのメモリが不十分な場合の対処方法: ビデオ メモリ、コンテキスト、同時実行性のトラブルシューティング

まず理解してください: なぜ KV キャッシュがビデオ メモリをいっぱいにするのか

まずはログからどのような問題なのかを判断します

最優先: 低い --max-model-len

2 番目の優先事項: 同時実行性とバッチ処理を制限する

3 番目の優先事項: --gpu-memory-utilization を適切に設定する

FP8 KV キャッシュ: グラフィックス メモリを保存する前にモデルとバージョンを確認してください

KV キャッシュ サイズを手動で指定する場合の優先順位を把握する

CPU オフロードで何が解決でき、何が解決できないのか?

複製可能なトラブルシューティング テンプレート

よくある誤解

誤解 1: モデルは長いコンテキストをサポートしているため、サービスを完全に有効にする必要があります

誤解 2: 問題を解決するには gpu_memory_utilization を 1 に設定します

誤解 3: 同時実行性に関係なく、重みの量子化のみを削減する

誤解 4: CPU オフロードは、長いリクエストを拒否するよりも明らかに優れています

要約する

Ollama マルチモデル スイッチングの構成方法: 常駐、ビデオ メモリ、Modelfile のチュートリアル

最も一般的に使用される切り替えコマンド

ollama ps: まずビデオ メモリを誰が占有しているかを確認します。

デフォルトの滞留時間: 5 分

方法 1: 1 回の呼び出し後すぐにアンインストールする

方法 2: モデルを長期間常駐させておく

方法 3: デフォルトの常駐時間をグローバルに変更する

マルチモデル永続性の鍵: OLLAMA_MAX_LOADED_MODELS

同時実行性を無視しないでください: コンテキストもメモリを消費します

Modelfile を使用してさまざまな目的の固定エイリアスを作成する

タスクごとにモデルを切り替えるためのスクリプトまたは API を提供します

Windows でよくある落とし穴

環境変数が変更されましたが、有効になりませんでした

モデル ファイルがシステム ディスクに集中します

モデルが削除されたのかと思った

単一のカードに適したデフォルト戦略のセット

要約する

民生用グラフィックカードでエージェントを実行するコストの計算方法: 電気代、減価償却費、およびタスクあたりのコスト

NAS 導入の Ollama パフォーマンスが不十分かどうか: CPU、メモリ、グラフィックスカードの判断方法

NAS のコアグラフィックス、NPU、トランスコーディング機能を直接使用できますか?

vLLM KV キャッシュのメモリが不十分な場合の対処方法: ビデオメモリ、コンテキスト、同時実行性のトラブルシューティング

まず理解してください: なぜ KV キャッシュがビデオメモリをいっぱいにするのか

最優先: 低い `--max-model-len`

3 番目の優先事項: `--gpu-memory-utilization` を適切に設定する

FP8 KV キャッシュ: グラフィックスメモリを保存する前にモデルとバージョンを確認してください

KV キャッシュサイズを手動で指定する場合の優先順位を把握する

複製可能なトラブルシューティングテンプレート

誤解 2: 問題を解決するには `gpu_memory_utilization` を 1 に設定します

Ollama マルチモデルスイッチングの構成方法: 常駐、ビデオメモリ、Modelfile のチュートリアル

`ollama ps`: まずビデオメモリを誰が占有しているかを確認します。

マルチモデル永続性の鍵: `OLLAMA_MAX_LOADED_MODELS`

モデルファイルがシステムディスクに集中します