8GB機でモデル切替は何秒損するか【Raspberry Pi 5・Jetson・RTX 4060 Laptop実測】

「小さいモデルで素早く返し、必要なときだけ大きいモデルに切り替える」——ローカルLLMを複数使い分ける発想はよく聞きますが、メモリが8GBしかない機材で実際にモデルを切り替えると何秒かかるのか、その待ち時間は毎回同じなのかも気になるところです。Raspberry Pi 5・Jetson Orin Nano Super・RTX 4060 Laptopの3台で、Ollamaのモデル切替を48回のロード試行として実際に確認し、そのたびに何が起きるかを記録しました。

結論

• 48試行のうち、ロード失敗は5件でした。失敗5件はすべてJetsonで発生し、内訳はGemma 3 4Bの読み込みが4件、Qwen3 1.7Bの読み込み（同時常駐ペア）が1件です。残る43件の成功試行のうち、モデルの追い出し（evicted）が発生したのは5件（Jetsonで4件・RTX 4060 Laptopで1件）でした。失敗5件はresidencyが記録されておらず、evicted評価の対象外です。Raspberry Pi 5は16試行を通じて失敗もevictedも一度も起きませんでした。
• Raspberry Pi 5 8GBは、8Bクラスの初回ロードに64.2〜71.5秒。ただし既定モード（Ollama任せ）では一度載れば追い出されず、2回目以降の切替はload_msで0.4〜1.1秒まで縮みます。「切替のたびに1分」ではなく「最初の1回だけ1分」でした（図1・図2）。
• Jetson Orin Nano Super 8GBは、秒数以前の問題が起きました。前日の単体ベンチでは16.21 tok/sで正常に生成できたGemma 3 4Bが、この日は切替試験で4回中4回ロード失敗（HTTP Error 500、CUDAメモリ確保エラー）。GPUメモリの断片化と整合する結果で、「何秒損するか」ではなく「そもそも動かないことがある」というのが実測結果です（図1）。
• RTX 4060 Laptop 8GBは、8Bクラスを含めても両モデル常駐でスラッシングなし。8Bの初回ロード6.5秒、2回目以降は0.3秒台まで縮み、48試行の中でもっとも「切替コストを感じにくい」機材でした。
• 同じ「8GB」でも、機材アーキテクチャで挙動は正反対でした。Raspberry Pi 5とJetsonに同一ペア（Gemma 3 1B + Qwen3 1.7B）を通したところ、Pi5は一度もevictedが起きなかった一方、Jetsonのforce-coldモードでは4回中3回evictedとスラッシングを起こしています。

実測条件（3セッション・12run・48試行）

Ollamaでモデルを切り替えたときのロード時間・追い出し（eviction）の有無を、計測スクリプトで記録しました。1機材＝1セッション、1セッションにつき4つのrun、1runにつき4回のロード試行（cycles=2のA→B→A→Bプロトコル）という構成で、3機材×4run×4試行＝48ロード試行（3セッション・12run）を2026-07-16に実施しています。

用語: run＝1ペア×1モードあたりの計測単位（4試行で1run）。cycle＝A→Bの1往復（ロード2回）を指す単位（cycles=2が既定値で、A→B→A→Bの2往復＝計4試行/ペアです）。load_ms＝モデルロードに要した時間（本記事の「秒数」はこれを基準にしています）。total_ms＝load＋プロンプト評価＋生成の合計（参考値）。evicted＝ロード直前に常駐していたペア相手のモデルが、ロード直後の常駐一覧から消えていたこと（スラッシングの兆候。判定対象はペア相手のモデルのみで、ペア外の他モデルの追い出しは追跡していません）。force-cold＝毎回強制アンロードしてから再ロードするモード。cold＝新規ロード、warm＝常駐後の再アクセスを指します。

• ペアの種類は2つ: 「エスカレーション」（各機材で用意した中で最小級の軽量モデルと、その機材で動く最大級モデルを行き来する、小→大への切替を想定したペア。最小モデルはRaspberry Pi 5・Jetsonがqwen2.5:0.5b、RTXはlfm2.5-230mと機材ごとに異なります）と、「同時常駐」（比較的軽量なモデル同士を頻繁に往復するペア。Raspberry Pi 5・Jetsonはgemma3:1b+qwen3:1.7b、RTXはlfm2.5-230m+ministral-3:3bと、こちらも機材ごとに異なります）。
• モードは2つ: 「既定」（Ollama自身のkeep_alive任せ、明示的な追い出し指定なし）と、「--force-cold」（切替のたびにkeep_alive:0で強制アンロードしてから再ロードする、常に再読み込みが起きる負荷テスト用の設定）。
• 新規モデルのpullはなし。全run、各機材の既存ollama listのモデルのみを使用しています。

各機材のOllamaバージョンと実行方式は次のとおりです。

「8GB」は、Raspberry Pi 5・Jetson Orin Nano Superはユニファイドメモリ（システムRAM）、RTX 4060 LaptopはGPU VRAMの容量を指します（RTXのシステムRAMは別途32GB搭載）。

RTX 4060 LaptopだけOllama 0.32.0と、他2機材（0.31.1）よりマイナーバージョンが新しい状態での計測です。モデル切替やメモリ管理の挙動はOllamaのバージョンに依存することがわかっており（関連記事）、後述するRTXの「相性の良さ」の一部がバージョン差に起因する可能性は否定できません。3機材を完全に同じバージョンで揃えた再計測は今後の課題です。

実測1: Raspberry Pi 5 8GB — evictedゼロ、切替コストの正体は初回コールドロード

選定ペアは、エスカレーション=qwen2.5:0.5b（397MB、Qwen2.5 0.5B）+lfm2.5:8b（5.2GB、LFM2.5 8B A1B）、同時常駐=gemma3:1b（815MB、Gemma 3 1B）+qwen3:1.7b（1.4GB、Qwen3 1.7B）です。

4run・16試行を通じてevictedは一度も発生しませんでした（0/16）。失敗も0/16です。2ペアとも、モデルの重み合計（エスカレーション約5.6GB・同時常駐約2.2GB）が計測開始時の空きメモリ（available 7.4GB）に収まったため、CPU推論・ユニファイドメモリのRaspberry Pi 5では自然な追い出しが起きなかったとみられます。

切替コストの実体は「初回コールドロード」に集中しています。8Bクラス（lfm2.5:8b）の初回ロードは既定64.2秒・force-cold 71.5秒、1〜1.7Bクラス（gemma3:1b・qwen3:1.7b）の初回ロードは既定18.3〜19.2秒、force-coldはGemma 3 1Bが13.1秒・Qwen3 1.7Bが4.1秒でした。ただし既定モードでは2回目以降、両モデルが常駐したままload_msでの切替が0.4〜1.1秒まで高速化します（エスカレーションcycle2は0.5秒・0.6秒、同時常駐cycle2は1.1秒・0.4秒。生成完了までのtotal_msでは1.1〜2.5秒でした）（図2）。

• 初回（8Bモデル・cycle1）64.2秒
• cycle2・エスカレーション①0.5秒
• cycle2・エスカレーション②0.6秒
• cycle2・同時常駐①1.1秒
• cycle2・同時常駐②0.4秒

既定モード・cycles=2（1runは4試行のA→B→A→B）。初回（8Bモデル・lfm2.5:8b）だけ64.2秒と突出し、cycle2（2巡目）の再ロードはエスカレーション・同時常駐どちらのペアも1.1秒以下。「切替のたびに1分」ではなく「最初の1回だけ1分」でした。

一方--force-coldは「相手モデルは残したまま、切替先のモデルだけ毎回強制的にアンロード→再ロードする」という設定のため、8Bモデル（lfm2.5:8b）はforce-coldで観測した2件（cycle1=71.5秒、cycle2=68.7秒）とも高コストのままでした（cycles=2のため、再訪問として観測できたのはcycle2の1件のみです）。OSのファイルキャッシュが効きそうな場面ですが、Raspberry Pi 5の8Bモデルではこの高コストが縮みませんでした。これは後述するRTX 4060 Laptopの8Bモデル（cold 6.5秒→2回目以降0.3秒台）と対照的で、同じ「force-coldで毎回強制リロード」でも機材によって縮み方がまったく違う、という機材差として記録に値します。

実測2: Jetson Orin Nano Super 8GB — 「実績のあるモデル」が4回中4回ロード失敗

選定ペアは、エスカレーション=qwen2.5:0.5b（397MB）+gemma3:4b（3.3GB、Gemma 3 4B。この機でロード実績のある最大モデルとして選定）、同時常駐=gemma3:1b+qwen3:1.7b（Raspberry Pi 5と同一ペア）です。電力モードはMAXN_SUPER。計測開始直前のtegrastatsはlfb（largest free block）6x4MB——空きメモリの表示（available 6.5GB）に反し、連続確保可能なメモリの塊は小さいという、GPUメモリの断片化シグナルを示していました（図3）。

使用中のブロック空きブロック（点在）

空き合計は約6.5GB分（tegrastats観測: available）――表示の上ではモデルの重みより十分足りている。

↓

✕大きな重みが必要とする連続領域（例）― 上のどの隙間にも収まらない

実際に確保できた最大の連続ブロックは4MB×6（lfb・tegrastats観測）。空きの合計ではなく連続した塊の大きさが足りないと、読み込みに失敗しうることを示しています。

※ 概念図です（積み木の数・並びは実際のメモリ配置そのものではありません）。tegrastats観測値（available 6.5GB・lfb 6x4MB）は実測2節の計測開始直前の値。journalctl診断による内訳（重み3.1GB成功／KVキャッシュ 174MiB失敗など）は事後診断であり、詳細は本文「実測2」節を参照してください。

エスカレーションペアのgemma3:4bロードは、既定モード2回・force-coldモード2回の計4回とも失敗しました（4/4、いずれもHTTP Error 500）。特筆すべきは、このgemma3:4bが前日2026-07-15の単体ベンチ（切替試験とは別プロトコル）で16.21 tok/sの正常な生成に成功していたモデルだという点です。「一度も載ったことがない」のではなく、「単体ベンチでは載った実績があるのに、当日の切替試験では4回とも載らなかった」——GPUメモリの断片化が固定的な閾値ではなく、日や時間帯によって変わる動的な現象であることを示唆しています。

失敗の中身も一定ではありませんでした。journalctl診断（別ソース、read-only取得）で比較できた既定モードの1件は、重み本体（3.1GB）の読み込み自体は成功したものの、画像入力に対応するためのCUDAグラフキャプチャ処理で「CUDA error: out of memory」が発生。約90秒後のforce-coldモードの1件では、今度はKVキャッシュ用のわずか174MiBのバッファ確保で失敗しました。同一モデル・同一ペアで、90秒ほどの間に失敗する箇所そのものが変わったことは、断片化状態が数十秒〜数分オーダーで揺れ動くことと整合する所見です。

同時常駐ペア（Raspberry Pi 5と同一ペア）でも、既定モードのcycle=1でgemma3:1b→qwen3:1.7bのロードが失敗しました。診断ログでは、Ollama内蔵のスケジューラが「他のモデルを全部追い出してリトライする」という自己修復ロジックを2回動作させても解消せず、最終的に失敗として記録されています。ただし直後のcycle=2では同一の切替が成功しており、失敗は再現性のある恒久障害ではなく、一過性のものでした（断片化状態への依存が疑われますが、この1件だけでは確定できません）。force-coldモードでは4回とも成功しましたが、evictedは4回中3回発生——Raspberry Pi 5では同一ペアが一度もevictedしなかったのと対照的で、同じ8GB機でもCPU推論のPi5とCUDA/断片化に敏感なJetsonとで挙動が正反対になることが分かります。

実測3: RTX 4060 Laptop 8GB — 8Bを含めても両常駐、スラッシングなし

選定ペアは、エスカレーション=lfm2.5-230m（Q8_0、LFM2.5 230M）+granite3.3:8b（Granite 3.3 8B Instruct、現存する7〜8B級モデルの中で容量僅差の最大として選定）、同時常駐=lfm2.5-230m+ministral-3:3b（Ministral 3 3B）です。

4run・16試行で失敗は0件。8Bクラス（granite3.3:8b）を含めても、両モデル常駐でスラッシングは観測されませんでした。初回のコールドロードは6.5秒、既定モードでの再訪問（常駐後の再アクセス）は0.3秒台まで高速化しています（8B cold 6.5秒→warm 0.3秒台）。force-coldモードでの強制アンロード後の再ロードも同じく0.3秒台でしたが、ロード直前に強制アンロードしているため常駐状態からの再アクセスではなく、OSのファイルキャッシュ等の効果と考えられます（用語表のwarm＝常駐後の再アクセスとは条件が異なります）。

唯一のevicted（同時常駐・既定モードcycle1、lfm2.5-230m→ministral-3:3b、load_ms=7224.3）は、このペア単体の奪い合いというより、直前のエスカレーションrunの終了時に常駐していたgranite3.3:8bが、ministral-3:3bの読み込みに伴って追い出された「run間の持ち越し」である可能性があります。ただし、この解釈はRaspberry Pi 5・Jetsonのログにあるような明示的な常駐スナップショットがRTXのログに含まれていないため、確定情報ではなく推定にとどまります。

3機材を並べてわかること

48試行中の失敗5件は、すべてJetson Orin Nano Superに集中しました。Raspberry Pi 5・RTX 4060 Laptopはいずれも16/16成功です。同じ「8GB」という数字でも、CPU推論・ユニファイドメモリのRaspberry Pi 5、CUDA/断片化に敏感なJetson、独立GPUのRTX 4060 Laptopとでは、切替時に何が起きるかがまったく異なりました（図4）。

• Raspberry Pi 5: メモリに収まる範囲では追い出しが起きない。既定モードでは、切替コストは主に初回ロードに集中する「初回だけ」の税金でした。
• Jetson: 空きメモリの表示上は足りていても、連続確保できる塊（tegrastats観測でlfb 6x4MB）が小さいと、ロードが失敗しやすくなる（断片化と整合する所見）。しかも同じgemma3:4bが、前日の単体ベンチでは成功し当日の切替試験では失敗するというように、日によって結果が変わる。
• RTX 4060 Laptop 8GB: 8Bクラスを含めても常駐が安定しやすく、48試行中もっとも「切替を意識しなくて済む」結果でした。

Raspberry Pi 5 8GB

初回コスト

64.2〜71.5秒（8Bクラス・既定/force-cold）

2回目以降

0.4〜1.1秒（既定モード・常駐後）

◎低リスク

失敗0/16・evicted 0/16

Jetson Orin Nano Super 8GB

初回コスト

秒数以前の問題（実績あるGemma 3 4Bが4/4失敗）

2回目以降

evicted 3/4（force-cold）・断片化リスクが継続

⚠高リスク

48試行中の失敗5件はすべてJetsonに集中

RTX 4060 Laptop 8GB

初回コスト

6.5秒（8Bクラス・初回コールド）

2回目以降

0.3秒台（既定モード・常駐後）

◎低リスク

失敗0/16・evicted 1/16（run間持ち越しの推定）

「初回コスト」はコールドロードの実測値、「2回目以降」は常駐後の切替コスト。リスクは48試行の失敗・evicted実績に基づく評価（詳細は本文「3機材を並べてわかること」参照）。

小さいモデルと大きいモデルを自動で使い分けるような運用を8GB機でやる場合、気にすべきは「切替のたびに何秒待つか」よりも先に、「そのロードは確実に成功するか」であることが今回の実測から見えてきます。Ollama自身にも「ロード失敗時に他モデルを全部退避してリトライする」という自己修復ロジックがあることをログで確認しましたが（Jetsonの同時常駐・既定モード）、これも2回動作させて解消しないケースがありました。断片化が起きやすい機材では、ロード失敗を想定したリトライ・フォールバック経路を用意しておく必要がありそうです。

この実測の限界と読み方

• 試行規模は小さいです。各条件（ペア×モード）はcycles=2＝4試行のみです。「evicted 3/4」「failed 1/4」といった比率は、1件の結果が変わるだけで大きく動く分母の上での数字であり、母数の大きい統計として一般化はできません。
• 成功値はlegacy backfillで記録され、rawログは非公開です。全12run・48試行はいずれもcapture.method: legacy_backfillで記録されており、元のrawログ（raw_available: false）は非公開です。失敗5件は構造化ログに残らず、標準エラー出力を人手で読んで集計しています。
• 48試行の一次データ（JSON）は、公開データセット v1.7.0 に含まれています。本記事のload_ms・evicted・成功／失敗などの集計元になったsession→run→attempt構造の実測レコードは、switch.jsonとしてオープンデータ（CC BY 4.0）で確認・ダウンロードできます（journalctl由来の失敗詳細は含みません）。
• Jetsonの失敗詳細（3.1GB・174MiBなど）はjournalctlによる事後診断です。計測スクリプトが直接記録したのはHTTP Error 500のみで、重みサイズやバッファ確保量などの内訳は、別ソースであるjournalctl（read-only取得）から追加で確認したものです。
• 「48試行」はロード試行の回数で、48回の実切替を毎回確認したという意味ではありません。各試行ログの「from」はA→B→A→Bプロトコル上のラベル（protocol_from_tag）であり、実際にfromモデルが常駐していたことを毎回確認したものではありません。
• すべて2026-07-16の1日・1回のセッションです。Jetsonのgemma3:4bが前日の単体ベンチでは成功し、当日の切替試験では4回とも失敗したこと自体が、日によって結果が変わりうることを示しています。同じ機材・同じペアを別日に再計測すれば違う結果になる可能性があります。
• RTX 4060 LaptopのみOllamaバージョンが異なります（0.32.0、他2機材は0.31.1）。モデル切替の挙動はバージョン依存であることが分かっており、RTXの結果の一部にはバージョン差の影響が混ざっている可能性があります。
• --force-coldは実運用の既定挙動ではありません。毎回強制的にモデルをアンロードしてから再ロードする、負荷テスト用の設定です。実際のOllama運用（既定モード）では、メモリに余裕がある限りモデルは常駐し続けるため、記事中の「force-coldでの毎回◯十秒」がそのまま日常運用のコストになるわけではありません。
• 機材ごとにモデルの組み合わせが完全には揃っていません。同時常駐ペア（Gemma 3 1B + Qwen3 1.7B）はRaspberry Pi 5とJetsonで共通ですが、エスカレーションペアの大モデル（Pi5=LFM2.5 8B A1B・Jetson=Gemma 3 4B・RTX=Granite 3.3 8B Instruct）と、RTXの同時常駐ペア（LFM2.5 230M + Ministral 3 3B）は機材ごとに異なるモデルです。各機材で「現存する最大級・実績のあるモデル」を選んだ結果のため、機材間の数字を厳密な同一条件比較として読むことはできません。
• RTX 4060 Laptopの唯一のevictedはrun間持ち越しの推定であり、確定情報ではありません（上述）。
• num_predict=16という短い生成長で計測しています。この記事の数値は主にロード時間（load_ms）を対象にしたもので、長時間の生成スループットを測るものではありません。

この記事の実測条件

• 全run共通でcycles=2（A→B→A→B、1runにつき4ロード）。
• 各ペア×［既定モード（Ollama任せ・keep_alive指定なし）／--force-cold（毎回keep_alive:0で強制アンロード後リロード）］の計4run。
• num_predict=16・temperature=0。
• 新規pullなし。全run、各機材の既存ollama listのモデルのみを使用。
• Raspberry Pi 5・Jetson Orin Nano Super = on-device実行（機上SSHログイン→127.0.0.1:11434へローカル実行）。RTX 4060 Laptop = on-host実行（対象PC上に計測スクリプトをSSH経由でscp・実行）。いずれもネットワーク越しの呼び出しではなく、計測対象機自身の上でOllama APIを呼んでいます。
• 計測日は2026-07-16。Ollamaバージョンは前掲の表のとおり機材で異なります（Raspberry Pi 5・Jetson=0.31.1、RTX 4060 Laptop=0.32.0）。

よくある質問

Q. 結局、8GB機でモデル切替は何秒かかりますか？

A. 機材と条件で大きく異なります。Raspberry Pi 5は8Bクラスの初回ロードに64.2〜71.5秒かかりますが、既定モードなら2回目以降はload_msで0.4〜1.1秒に縮みます。RTX 4060 Laptop 8GBは8Bクラスでも初回6.5秒・2回目以降0.3秒台とさらに軽いです。Jetson Orin Nano Superは「何秒」という以前に、実績のあるモデルが4回中4回ロードに失敗するケースを実測しました。

Q. なぜ同じ8GB機なのに、Jetsonだけロード失敗が起きたのですか？

A. tegrastatsの観測（lfb 6x4MB）が示すGPUメモリの断片化と整合する結果です。空きメモリの合計は足りていても、連続して確保できるメモリの塊が小さいと、CUDAのメモリ確保がエラーになる場面が複数回記録されました。Raspberry Pi 5はCPU推論・ユニファイドメモリで自然な追い出しが起きず、RTX 4060 Laptopは16試行でロード失敗を観測していません（ただしRTXについて断片化の状態そのものは計測していません）。

Q. --force-coldは普段のOllama運用でも起きる挙動ですか？

A. いいえ。--force-coldは、切替のたびに強制的にモデルをアンロードしてから再ロードする、この計測専用のオプションです。普段のOllama運用（既定モード）では、メモリに余裕がある限りモデルは常駐し続けるため、記事中の「force-coldでの毎回数十秒」がそのまま毎回のコストになるわけではありません。

Q. この結果はどのくらい信頼できますか？

A. 各条件4試行・1日1回という小規模な実測です（詳細は前述「この実測の限界と読み方」）。Jetsonのgemma3:4bが前日の単体ベンチでは成功し、当日の切替試験では4回とも失敗したように、日によって結果が変わることがあります。傾向をつかむための実測データとして読んでいただき、断定的な成功率・失敗率としては扱わないことをおすすめします。

この機材を入手する

• Raspberry Pi 5 8GB：Amazonで見る広告・Amazon／楽天で見る広告・楽天
• Jetson Orin Nano Super 8GB：Amazonで見る広告・Amazon／楽天で見る広告・楽天
• RTX 4060 Laptop搭載ノートPC：Amazonで見る広告・Amazon／楽天で見る広告・楽天

実売価格は変動するため、最新の価格はリンク先で確認してください。