「GPU のない VPS で言語モデルは動くのか」は、この 2 年で最もよく尋ねられた問いのひとつです。2026 年半ばの答えははっきりしています。動きます。ただしモデル、量子化、そして処理内容を正しく選べば。オープンウェイトの小型モデルは今年大きく進み、数ギガバイトのメモリから使える品質を引き出すことは、もはや珍しくありません。

CPU のみの環境で検討に値するモデル

  • Gemma 4 E4B：Google の比較的新しいオープンウェイト小型モデルで、多様な入力に対応し、下限では約 3 GB で動きます。今のところ CPU のみの構成で最も興味深い選択肢です。
  • Qwen3.5 4B：処理全般でよく釣り合い、中国語にも強く、汎用の安全な既定としてよく選ばれます。
  • Phi-4-mini-instruct：Microsoft の小型路線で、控えめなハードウェアと分析寄りの処理を明確に狙っています。
  • SmolLM3 3B：非常に小さく、最も余裕のないインスタンス向け。
  • Llama 3.2 3B：生態系が成熟し資料も豊富で、出発点として良好です。

おおよそのメモリの目安として、4B 級のモデルは Q8 量子化でおよそ 4.5 GB の利用可能メモリを要し、Q4 ではおよそ半分になります。したがって8 GB のインスタンスが快適な出発点、4 GB が下限で低ビットの量子化が必須、1 GB の入門インスタンスは手元での推論には現実的ではありません。

実現を支える道具

CPU での推論は llama.cpp の上に成り立っており、AVX、AVX2、AVX512、AMX、ARM NEON といった命令経路に最適化されています。Ollama はその上でモデルの管理と HTTP の口を簡単に提供し、VPS への配置では最も手間の少ない層です。導入して 1 行でモデルを取得し、アプリを手元の口に向けるだけです。

先に決めておく三つのこと

  • CPU の推論は遅い——処理を合わせる：CPU での毎秒のトークン数は GPU より大きく劣ります。要約、分類と付与、内容の点検、まとめ処理といった同時実行の少ない非同期の仕事に向き、同時接続の多い実時間の対話には向きません。
  • メモリは助言ではなく硬い制約：入らなければ単に読み込みに失敗します。小さなインスタンスに swap を足せば技術的には動きますが、処理量は使い物にならない水準まで落ちます。実際に使えるメモリを基準に見積もってください。
  • 決める前に計算する：常時稼働の 8 GB の VPS と、トークン単位で払う API のどちらが得かは呼び出し量次第です。自前で持つ本当の価値はたいてい、データが自分のサーバーから出ないことと、費用が読めることにあります。

理にかなった組み合わせ

多くの人が落ち着くのは混合です。頻度が高く難度の低い、そして機微に触れる処理は自分の VPS の小型モデルで動かし、頻度は低いが強い推論を要する処理はクラウドの API に回す。CPU に何もかもさせようとせず、データの境界だけは保てます。

SharkCloud は入門から上位までのメモリ段階を、香港、日本、米国などのノードで提供しています。まず小さなプランでモデルを試し処理量を測り、うまくいくと分かってから拡張できます——検証していない計算資源に先に払う必要はありません。