VPS で LLM をセルフホスト。
GPU なし。API キーなし。プロンプトは施設の外に出ない。

言語モデルをローカルで動かすことについて書かれた文章のほとんどはグラフィックカードの話であり、手元にあるのが仮想マシンだけなら役に立たない。役に立つ考え方は、GPU をめぐる議論が示唆するよりずっとシンプルで、一文に収まる——1つのトークンを生成するために、高密度モデルはその重みをすべてメモリから読み出さなければならない。一部ではなく、全部を、トークン1つにつき1回。

この一つの事実だけで、性能に関する問いはすべて片が付く。生成速度を決めるのは借りたコア数ではなく、マシンが RAM からモデルをどれだけ速くストリームできるかだ。つまり、一円も使う前に、封筒の裏で計算できる上限がある。

tokens per second  ≈  memory bandwidth (GB/s)  ÷  model size (GB)

量子化された 8B モデルは約5 GB を占める。現実的に20 GB/s 前後をストリームできる仮想化ホストでは、上限は1秒あたり約4トークンで、実際に観測される数字はおそらくその半分から3分の2ほどになる。おおむね1秒に3語。これは失望すべきことではなく、この仕事についての事実として受け止めるとよい——チャット画面には遅いが、ドキュメントを分類して JSON を1行返す仕事には十分すぎるほどだ。

コア数は今も重要だ。ただし、多くの人が思っている理由とは違う。 スレッド数を増やすのは、メモリ経路が飽和するまでは効果がある。このクラスのマシンでは、それはたいてい4〜8スレッドあたりという早い段階で起きる。その先では、余分なコアは遊んでいるだけで、すべてが RAM を待っている状態になる。だから16コアの箱がテキスト生成において4コアの箱の4倍速いということにはならず、速度を期待してコア数にお金を払うことが、間違ったティアを買ってしまう一番よくある原因になる。

読むのは速く、書くのは遅い。 すべてのリクエストには2つの段階があり、振る舞いはまったく異なる。プロンプトの処理——プレフィル——は入力全体を一度に扱う計算律速の行列演算であり、生成よりも何倍も速く終わる。答えを生み出す方は、これまで説明してきたメモリ律速の部分で、トークンを1つずつ生成する。だから、2,000語の文書を渡して3文で返してもらうのは無理のない仕事だが、2,000語のエッセイを書かせるのはそうではない。この非対称性を踏まえてプロンプトを設計すれば、CPU の箱はトークンレートから想像するよりずっと快適に感じられる。

モデルサイズはいつもの Q4_K_M 量子化によるもので、ほとんど気づかれない程度の品質と引き換えに、メモリを半分以下に抑える。速度列は上の割り算から導いたオーダー（目安）であり、ベンチマークではない——ステップ03の狙いは、この表を含め、どんな表も信じるのではなく、自分自身のマシンを計測することにある。

仕事から逆算する。モデルにやらせたいことを決め、それをこなせる最小サイズを選び、そのサイズが Q4_K_M でどれだけ場所を取るかを調べ、そこにオーバーヘッドを足す。

RAM needed  =  model file  +  KV cache  +  ~2 GB for the system

  3B  Q4_K_M  ≈  2.0 GB        KV cache at 8k context   ≈  0.5–1 GB
  8B  Q4_K_M  ≈  4.9 GB        KV cache at 32k context  ≈  2–4 GB
 14B  Q4_K_M  ≈  9.0 GB
 32B  Q4_K_M  ≈ 20.0 GB
 70B  Q4_K_M  ≈ 40.0 GB

KV キャッシュは、みんなが忘れがちなオーバーヘッドだ。 会話の中にすでにあるトークンはすべてメモリに保持され、モデルが再計算しなくて済むようになっている。この保存領域は、許可するコンテキストの長さに応じて大きくなる。コンテキストを2倍にすれば、これもおよそ2倍になる。4k コンテキストでは収まっていたモデルが、32k では収まらなくなることがあり、しかもそれは最初のリクエストではなく10回目のリクエストで失敗するので、計算違いというより謎の不具合のように見えてしまう。

ここに緩やかな性能劣化というものはない。 合計が RAM を超えると、カーネルは行儀よく遅くなったりはしない。トークン1つごとにモデルの重みをディスクとの間でページングし始める。4秒で終わるはずの生成が4分になり、ロードアベレージは十の桁まで上がり、箱の上の他のすべて——データベース、Web サーバー、あなたの SSH セッション——も道連れになる。メモリに収めることは最適化ではない。必須条件だ。

パネルでは、注文 → VPS → 計算が示したティア、イメージは Debian 12。アカウント開設にメールアドレスは不要、身分証明書もどの段階でも求められず、請求は Monero、Bitcoin、Lightning、その他対応している資産のいずれかで決済する——これは普通の Web サーバーよりもここでは重要な意味を持つ。理由は匿名 VPS ホスティングの柱ガイドで説明されており、下のプライバシーの章ではそれをプロンプトに具体的に当てはめている。

モデルを pull する。最初の計測には、現行の 8B クラスの instructモデルならどれでもよい——サイズが近いので、計測結果はモデルではなくハードウェアについて語ってくれる。

ollama pull llama3.1:8b        # ~4.9 GB at Q4_K_M
ollama list
ollama ps                      # nothing resident yet

次に、タイミング表示をオンにして1回生成を実行する。重要な数値は eval rate——プロンプトを読み終えたあとに1秒あたり生成されるトークン数だ。

ollama run llama3.1:8b --verbose "Reply with exactly one sentence about the Baltic Sea."

total duration:        14.2s
load duration:          3.1s
prompt eval count:        24 token(s)
prompt eval rate:      92.11 tokens/s      ← reading: fast
eval count:               38 token(s)
eval rate:              3.42 tokens/s      ← writing: the real ceiling

2行、2つの異なる世界。読み込みは1秒あたり90トークン前後、書き込みは3.5トークンほどだった。この比率こそ、計算の章で見た非対称性を、自分自身のマシンで測った値であり、今日集める中で最も役に立つ一つの事実だ。意味するところはこうだ——この箱には長い入力を渡し、短い出力を求めよ。

同じ計測を API 経由で行う方法。2つか3つのモデルサイズを比較するスクリプトを組みたいなら、実際にはこちらが欲しいはずだ。

apt install -y jq

curl -s http://127.0.0.1:11434/api/generate -d '{
  "model":  "llama3.1:8b",
  "prompt": "List three Nordic capitals.",
  "stream": false
}' | jq '{
  tokens: .eval_count,
  seconds: (.eval_duration / 1000000000),
  rate: (.eval_count / (.eval_duration / 1000000000))
}'

一段下のサイズと一段上のサイズを測ったら、そこで止める。 3B と 14B を pull し、同じプロンプトをそれぞれに通し、3つの速度を書き留める。これでこのマシンでのトレードオフのコストが正確にわかる——たいていは各方向でほぼ倍という数字になる——ので、印象ではなく仕事ごとに選べるようになる。そのうえで、使わないモデルは削除する。どれも数ギガバイトあるからだ。

どのモデルでも、初回実行には一つ注意点がある。出力の中の load duration は、重みをディスクから RAM に読み込むのにかかった時間だ。これが発生するのはモデルがまだ常駐していないときだけであり、それを制御しているのが OLLAMA_KEEP_ALIVE だ。速度を比較するときはこれを含めないこと。そして驚く必要もない——NVMe なら数秒で、しかも1回きりだ。

Ollama は自身の API に加えて、/v1 で OpenAI 互換のインターフェースを提供している。連携の話はこれで全部だ——OpenAI 向けに作られたもの、公式 SDK、フレームワークのラッパー、自動化ノードは、ベース URL とキーを変えるだけで動く。それ以外は何も変わらない。

curl -s https://llm.example.com/v1/chat/completions \
  -H "Authorization: Bearer THE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3.1:8b",
    "messages": [{"role":"user","content":"Reply with the word OK."}]
  }' | jq -r '.choices[0].message.content'

Python から見ると、ホスト型のセットアップと違うのは冒頭の2行だけだ。

from openai import OpenAI

client = OpenAI(
    base_url="https://llm.example.com/v1",
    api_key="THE_TOKEN",
)

r = client.chat.completions.create(
    model="llama3.1:8b",
    messages=[{"role": "user", "content": "Classify: 'the invoice is overdue'"}],
)
print(r.choices[0].message.content)

JSON を求めれば、JSON が返ってくる。 自動化にとって最も役立つ機能は制約付き出力だ。Ollama はモデルの振る舞いに期待するのではなく、答えを妥当な JSON に強制できる。これにより、小さなモデルは信頼できない語り手から頼れるパーサーへと変わる——無人で動き続けるワークフローと、40件に1件壊れるワークフローの違いはここにある。

curl -s http://127.0.0.1:11434/api/generate -d '{
  "model":  "llama3.1:8b",
  "prompt": "Extract the total and the currency: Invoice 4021, 1 249,90 EUR due 30 days.",
  "format": "json",
  "stream": false
}' | jq -r .response
# → {"total": 1249.90, "currency": "EUR"}

自動化スタックでも同じことが言える。n8n には専用の Ollama ノードがあり、その OpenAI ノードはカスタムのベース URL を受け付けるので、既存のワークフローは認証情報を1つ編集するだけでローカル推論に移行できる。n8n セルフホスティングガイドが自動化エンジン自体を扱っている。できるなら、この2つは別々の箱で動かすこと。アイドル時でも700 MB を使うエンジンと、5ギガバイトを欲しがるモデルは、8ギガバイトのマシンの上では相性の悪い同居人だからだ。

そしてエンベディングのエンドポイント——この箱が本領を発揮する場所だ。 エンベディングモデルは生成モデルよりも2桁小さく、チャンクごとに1回のパスを行うだけで何も生成しないので、CPU は瞬時と感じられる速さで処理する。

ollama pull nomic-embed-text      # ~275 MB

curl -s http://127.0.0.1:11434/api/embed -d '{
  "model": "nomic-embed-text",
  "input": ["the first chunk of a document", "the second chunk"]
}' | jq '.embeddings | length'

ここまでの話はすべて生成についてであり、CPU が苦手とする部分だ。検索は、たいていの実用的なシステムのもう半分であり、この構図をまるごと反転させる——だからこそ、このページで最も安いティアでも、そこでは一度もトークンを生成しなくても、本当に価値のあることができる。

エンベディングモデルは、テキストの一部をベクトルに変換する。サイズはギガバイトではなく数百メガバイト単位で測られ、チャンクごとにちょうど1回の順伝播を行うだけで、メモリ帯域幅に縛られるトークンごとのループも存在しない。8B モデルが1秒に3語しか書けない同じ箱の上で、エンベディングモデルはドキュメントライブラリを、ファイルコピーのような速さで処理していく。

その形。 ドキュメントを数百語程度のチャンクに分割する。各チャンクを一度エンベディングし、ベクトルを保存する。質問時には質問自体をエンベディングし、最も近いチャンクを数個見つけ、それを質問と一緒にモデルへ渡す。保存先に特別なものは要らない——ベクトル拡張を備えた SQLite データベースだけで、単一の VPS 上で数万チャンクをまかなえるし、pgvector を使った PostgreSQL ならそれをはるかに超える規模でも対応できる。専用のベクトルデータベースは後になって欲しくなるぶんには結構だが、初日から必要な依存関係ではない。

これが速度よりも重要な理由。 それぞれの半分が何に触れるかを見てほしい。生成のステップが目にするのは、1つの質問といくつかの段落だ。エンベディングのステップが目にするのは<em>あなたが持つすべてのドキュメント</em>——アーカイブ全体、すべての契約書、すべてのメモ、すべてのメッセージが、チャンクごとにモデルを通過していく。そのステップをホスト型エンドポイントに対して実行すれば、インデックス化のためにコーパス全体が第三者に送信されたことになる。自分のマシン上で実行すれば、何一つ動かない。

これは、最先端モデルの品質を手放したくない人にとって本当に良いハイブリッド構成になる。ローカルでインデックス化し、ローカルで検索し、答えが優れていなければならないときだけ、質問と検索で得た3つのチャンクをホスト型モデルに送る。コーパスは手元に留まり、その薄い一部だけが、必要なときに限って外へ出る。

このサイトの2つの隣人が、そのパターンを具体的に示している。セルフホストした SearXNG は、検索レイヤーにコーパスではなくオープンウェブ向けのプライベートなフロントエンドを与える。セルフホストしたドキュメントストアはそこにコーパスを与える。この両方に加えてモデルも、ホスト型サービスの1シート分より月額が安いティアに収まる。