200台サーバーのローカルllmクラスターを構築

Large-language-model（LLM）APIはとても強力ですが、コストが高いものです。一方、ローカルでLLMを推論させる場合、ハードウェアさえ手元にあればほぼ無料で動かせます。本記事では、オフィスで眠っていたApple Siliconラップトップを活用し、200台の推論クラスターを構築して本番トラフィックの25 %を処理するまでの道のりを紹介します。しかもデータセンター契約は一切ありません。

ネタバレ: あるほこりだらけの会議室から始まり、最後は午前3時にオフィスのネットワークを総配線し直すことになりました。

フェーズ1：眠れるMacBookに息を吹き込む

オフィスの棚には、誰も使っていない M1 MacBook Pro（32 GB RAM）が12台並んでいました。時間がたてば資産価値は下がるだけ――そこで私は「これをLLM推論サーバーにしよう」と提案。CEOはコスト削減のアイデアを気に入り、私たちはすぐに行動を開始しました。

スタック構成

特別なものはありません。

• Ollama でモデル提供（4つ試した中で最終的に採用）

• 1台のMacBookに HAProxy を入れ、シンプルなラウンドロビン負荷分散

• Prometheus + Grafana でメトリクスとダッシュボード

• 6 m²の会議室が“データセンター”なので、冷却用の安い卓上ファン

• MacBookは1台ずつ設置

フレームワーク比較

1週間で12台のMacBookが30Bモデルをローカルで動かし、本番トラフィックの約5 %を処理できるようになりました。

フェーズ2：Mac Studioの寄り道 ― “大きい＝速い”とは限らない

成功すると欲が出るもの。マネジメントは「メモリが多ければスループットも上がる」と考え、Mac Studio（512 GB RAM・80-core GPU）を6台購入。各Mac StudioでMacBook 8台分の性能を期待しました。

しかし現実は、LLMの速度はほぼGPUコア数に比例し、Amdahlの法則が示すようにパイプラインの一部は並列化できません。その結果、Mac Studio 1台はMacBookの約3–4倍しか速くありませんでした（8倍ではない）。

教訓は得ましたが、6台のMac Studioでトラフィックカバー率は約25 %に増えました。

フェーズ3：200台のMac miniとAnsibleの歓喜

なぜMac mini？

コスト分析の結果、Mac mini（20-core GPU）2台で1台のMac Studioよりもトークンあたりのコストパフォーマンスが高いと判明。200台を一括購入しました。

自動プロビジョニング

200台を手動セットアップなど論外。そこでAnsibleを導入しました。

（以下は例。本番環境はもっと複雑です）

# プレイブックの抜粋
- hosts: mac
  tasks:
    - name: Install Ollama
      homebrew:
        name: ollama
        state: present
    - name: Configure model
      shell: ollama pull mistral:7b-instruct
    - name: Register with HAProxy
      template:
        src: haproxy.cfg.j2
        dest: /usr/local/etc/haproxy/haproxy.cfg

最初の50台が一気に稼働した瞬間はまさに魔法のよう。あとは繰り返しでOKです。

午前3時のネットワーク大混乱

最大の難所はネットワークでした。サーバー群用に専用VLANが必要でしたが、手元のYamahaルーターのマニュアルは中途半端な翻訳PDF、前任のネットワーク技術者は退職済み。ポート設定を1つミスっただけでオフィスWi-Fiが全滅。12時間、コーヒー3ポット、VLANタグ付けの猛勉強の末、無事に両ネットワークが復旧しました。

今後の計画

ラック化スケール – 200台は収まっているものの、エアフローとケーブル管理が限界。次は42Uラックと本格PDUを導入予定です。

パート2ではVLAN奮闘記の詳細と、クラスターを支えるGrafanaダッシュボードを紹介します。お楽しみに！

読んでくれてありがとう！

質問やコメント、あなたの失敗談などあればぜひ教えてください。情報交換しましょう。