Gemma 4へ2万文字を渡すと遅い？XServer VPS 4GBで2,000・8,000・20,000文字を実測

【PR】この記事にはA8.netのアフィリエイト広告を含みます。

先に結論：XServer VPS 4GB単体では、Ollama公式のGemma 4 E2Bへ2万文字を渡して要約するところまで進めませんでした。2,000・8,000・20,000文字の全条件に加え、context 2048の最小入力でもモデルロード中にOOMです。長文処理が遅い以前に、公式Q4_K_Mモデルの実行時バッファが3GiBの安全上限へ収まりません。今回の判定は解決しないです。

2026年9月1日、4 vCPU・4GB RAM・GPUなしのXServer VPSへOllama 0.33.2を隔離起動し、CPU 2コア、RAM 3GiB、追加swapなしで実測しました。公開中のCaddy、FastAPI、PostgreSQLを止めず、モデル取得から4回のOOM、後片付けまで記録しています。

Gemma 4で2万文字を要約すると本当に遅い？

十分なメモリへモデルをロードできれば、長い入力のprefillが待ち時間を増やします。しかし4GB VPSでは、その比較以前にモデルロードで失敗しました。

Zennの「ローカルLLMで長文を要約しようとしたら、とてつもなく時間がかかった話」では、Ubuntu 22.04、VRAM 4GB、Ollama、Gemma 4 E2Bへ約2万文字を渡し、最初のtokenまで数分、完了までさらに数分かかったと報告されています。モデルの一部だけをGPUへ載せ、残りをCPUで処理した条件です。

今回のVPSはGPUがなく、同じハードウェアではありません。GPU＋CPUの遅さを再現するのではなく、「4GB RAMのCPU環境なら、どの入力長まで到達できるか」を実機で確認しました。

Gemma 4 E2Bとは？必要メモリは2GB？

E2Bの「2B」は、そのまま2GBのRAMで動くという意味ではありません。GoogleのGemma 4 model cardでは、E2Bは2.3B effective、埋め込みを含む総パラメータは5.1B、contextは128Kです。

Ollama公式のgemma4:e2bは7.2GB、5.12B、Q4_K_Mと表示されています。今回VPSのAPIが返した実ファイル容量も7,162,405,886 bytesでした。「Effective 2B」「モデル配布容量」「実行時RAM」は別の数字です。

[PR]
VPSでいろいろ試すなら『XServer VPS』

RedditではGemma 4 E2BのRAMをどう減らした？

Redditのr/LocalLLaMAには、16GB RAMのHP PavilionでGemma 4 E2Bが7.4GBを使い、12〜15 token/秒だったという検証依頼があります。投稿者はcontextを2048へ制限し、RAM削減と応答改善を報告しました。

これはユーザー投稿であり、全環境で平均2GBになる保証ではありません。そこで今回はcontext 32768の長文試験だけでなく、context 2048の最小入力も別に実行しました。それでも3GiB制限でOOMになったため、今回の公式Ollamaパッケージではcontextを縮めるだけではロードできませんでした。

Zennの環境とXServer VPSの違い

この違いがあるため、Zennの所要時間と今回の秒数を直接比較しません。今回分かったのは、GPUなし4GB VPSの限界です。

実験前のCPU・RAM・ストレージ状況

4GB全量をAIへ渡すと公開サービスへ影響し得るため、テスト用コンテナを3GiBへ制限しました。

DockerとOllamaの実験条件

temperature 0、seed 42、thinking無効、keep_alive 0秒を固定しました。本文は同じ日本語文を反復し、PowerShellで正確に2,000・8,000・20,000文字へ切り出しています。

モデルのダウンロードに必要だった容量

Ollamaのpullは成功し、モデル用Dockerボリュームは7.162GBになりました。VPSのディスク使用量は15GBから22GBへ増えました。150GB NVMe SSDには十分収まりましたが、ダウンロードできることとRAMへロードできることは別です。

2,000・8,000・20,000文字の実測結果

4回ともAPIは「llama-server process has terminated: signal: killed」を返しました。20,000文字が最短に見えますが、推論が速かったわけではありません。全試行が入力を評価する前に終了したため、killされるタイミングの揺れです。

なぜGemma 4 E2Bをロードできなかった？

Ollamaログに表示されたモデル用バッファが3GiB上限を超えたためです。

モデルファイルはQ4量子化済みでも、実行時にはモデル展開やrepack用の領域が必要でした。`E2B`という名称から2GBで動くと判断すると、今回のようにロード前提を外します。

swapで遅くなった？

今回のGemma 4コンテナはswapしていません。cgroupのmemory.swap.peakは0でした。ホスト全体のswap使用量は実験前3MB、4回後128MB、コンテナ削除後126MBへ増えましたが、テストコンテナのswapと断定できません。

したがって今回の直接原因は「swapで極端に遅い」ではなく、「コンテナ上限でOOM kill」です。ホストswap増加のプロセス別帰属は未計測として残します。

既存のWebサービスは止まらなかった？

Caddy、FastAPI、PostgreSQLは4回のOOM中も稼働し、最後のready確認も`database=ok`、`artifact_storage=ok`でした。Dockerの3GiB制限により、Gemma 4の子プロセスだけを失敗させ、公開環境への波及を避けられました。

検証後は専用コンテナと7.162GBのモデルボリュームを削除し、ディスク使用量は15GBへ戻しました。

XServer VPS 4GBでGemma 4を使う現実的な方法

4GB VPS単体でGemma 4 E2Bをローカル推論する構成は採用しません。今回の用途では、次の分離が現実的です。

1. XServer VPSで調査ジョブ、認証、進捗、成果物を管理する
2. 2万文字を数千文字のチャンクへ分割する
3. 十分なRAMやGPUを持つ自宅PC、または外部推論APIへ送る
4. 部分要約をVPSへ戻し、統合要約と一次情報を保存する

この構成ならVPSの常時稼働性を活かせますが、Gemma 4の計算資源そのものを4GB VPSが代替するわけではありません。

初心者が迷いやすいポイント

• `E2B`を「必要RAM 2GB」と読み替えない
• モデルのダウンロード成功を、ロード成功と思わない
• context上限が大きくても、実メモリが足りるとは限らない
• ホストswapとコンテナswapを分けて計測する
• OOMまでの秒数を推論速度として比較しない
• 公開サービスと実験コンテナのRAM上限を分ける

結論：XServer VPSでGemma 4の長文問題は解決する？

4GBプラン単体では解決しません。公式Gemma 4 E2Bは7.2GBで、今回のOllamaログではモデル関連バッファが合計6,192.53MiBと表示されました。3GiB制限ではcontext 2048の最小入力さえロードできず、2,000・8,000・20,000文字はすべてOOMです。

一方、XServer VPSは「無理なモデルを公開サービスから隔離して試す」「長文を分割する」「自宅GPUへジョブを渡す」司令塔には使えます。Gemma 4の推論先は別に用意し、4GB VPSには制御と記録を担当させるのが、今回の実測に基づく構成です。

[PR] AI実験用VPSの最新料金・仕様を確認する
VPSでいろいろ試すなら『XServer VPS』

実験日：2026年9月1日。Gemma 4、Ollama、量子化、必要RAMはバージョンや実行バックエンドで変わります。導入前にGoogleとOllamaの公式情報を確認してください。ZennとRedditの数値は各投稿者の環境での報告であり、今回のVPS結果と同一条件ではありません。