LinuxエンジニアのためのローカルLLM入門：AlmaLinuxで構築する生成AI基盤

近年、ChatGPTをはじめとする大規模言語モデル（LLM）の波がIT業界全体を席巻しています。多くの企業が生成AIを利用した業務効率化や新規サービス開発に乗り出していますが、そこで最大の障壁となっているのが「機密情報の漏洩リスク」と「クラウドAPIの莫大なランニングコスト」です。これらの課題を根本から解決するアプローチとして、自社のオンプレミス環境やローカルサーバー上でAIを稼働させる「ローカルLLM（Local Large Language Model）」が大きな注目を集めています。

本連載「LinuxエンジニアのためのローカルLLM」では、エンタープライズ要件を満たすセキュアで安定したベースOSとして「AlmaLinux 9/10」を採用し、高セキュアかつハイパフォーマンスなローカルAI基盤を構築する手法を全8回にわたって徹底的に解説していきます。第1回となる本記事では、ローカルLLMの全体像、AIを支えるハードウェアのメカニズム、そして主要な推論エンジンのアーキテクチャ比較といった「インフラレイヤーの視点」から基礎を固めます。

---

1. なぜ今、インフラエンジニアがローカルLLMを学ぶべきなのか？

生成AI技術の進化により、ビジネスにおけるAI活用は「PoC（概念実証）」のフェーズから「本番環境での本格稼働」へと移行しつつあります。アプリケーション開発者がフロントエンドやプロンプトの調整に注力する一方で、AIモデルを安定して動かし続けるための「基盤」に対する要求は日増しに高まっています。

1.1. 生成AIの普及とエンタープライズが抱える課題

現在、多くの企業がOpenAIのChatGPT（API）やAmazon Bedrock、Google Gemini APIなどのクラウドベースのLLMサービスを利用しています。これらのサービスはインフラ管理をクラウドベンダーに任せることができるため、導入のハードルが非常に低いというメリットがあります。しかし、エンタープライズ規模で利用を拡大していくにつれ、以下のような深刻な課題が浮き彫りになってきます。

• データガバナンスとコンプライアンスの壁： 金融機関、医療機関、あるいは独自の技術情報を持つ製造業などでは、機密情報（顧客データ、非公開のソースコード、特許情報など）をサードパーティのクラウドサーバーに送信することは、セキュリティポリシーや各種法令（GDPR等）によって厳しく制限されています。
• 予測不能なAPIコスト（従量課金の罠）： クラウドLLMは通常、処理したテキストの量（トークン数）に応じて課金されます。社内チャットボットが全社員に普及したり、RAG（検索拡張生成）システムによって大量の社内ドキュメントを読み込ませるようになると、月額のAPI利用料が数百万円から数千万円規模に跳ね上がるケースが続出しています。
• ベンダーロックインと可用性のリスク： 特定のクラウドサービスに依存することは、サービスプロバイダ側の障害や、予告なしのモデルの仕様変更（非推奨化など）による影響を直接受けることを意味します。

1.2. クラウドAPIとローカルLLMのアーキテクチャ比較

これらの課題をクリアするために、Meta社の「Llama 3」やGoogleの「Gemma」、Mistral AIのモデルなど、オープンソース（オープンウェイト）として公開されている高性能なLLMを自社のインフラ（オンプレミスサーバーやプライベートクラウド）で稼働させるアプローチが急速に普及しています。これが「ローカルLLM」です。

ローカルLLMアーキテクチャの最大の強みは、「データが自社のネットワーク（ファイアウォール）から一歩も外に出ない」という完全なコントロール権を手に入れられる点にあります。また、ハードウェア（GPUサーバーなど）の初期投資やデータセンターのラック費用はかかりますが、稼働後はどれだけ推論を行っても追加のトークンコストは発生しないため、損益分岐点を超えれば圧倒的なコストパフォーマンスを発揮します。

1.3. インフラエンジニアの既存スキルが直結する理由

ここで重要なのが、ローカルLLM環境の構築・運用は、データサイエンティストよりもインフラエンジニアの領域に近いという事実です。

ローカルLLMにおいて、モデル（数十GB単位のバイナリファイル）をストレージからメモリ、そしてGPUのVRAMへとロードし、クライアントからのHTTPリクエストを処理して結果を返すという一連のフローは、大規模なデータベースサーバーのキャッシュ運用や、高負荷なWebアプリケーションのチューニングと本質的に似ています。インフラエンジニアが長年培ってきたLinuxOSの深層理解が、ここで最大限に活かされるのです。

2. ローカルLLMを支えるハードウェア要件とインフラレイヤーの視点

ローカルLLMを導入する際、最も慎重にならなければならないのがハードウェアリソースのサイジングです。通常のWebサーバーと異なり、AIの推論には特定のハードウェアリソース（特にVRAMとメモリ帯域）への極端な依存が存在します。要件を満たさないサーバーにモデルをデプロイすると、システムが完全にハングアップするか、実用に堪えないほどレスポンスが遅延します。

2.1. モデルサイズと必要VRAM容量の計算ロジック

LLMの規模は「パラメータ数（パラメータ＝ニューラルネットワークの重み）」で表現されます。例えば「8B」は80億（Billion）パラメータを意味します。このパラメータをハードウェア上で扱うためには、GPUのVRAM（ビデオメモリ）にモデル全体を展開する必要があります。VRAMにモデルが収まりきらない場合、推論速度は致命的に低下します。

一般的な16ビット浮動小数点（FP16/BF16）フォーマットでモデルをロードする場合、1パラメータあたり2バイトのメモリを消費します。これに加え、推論時に入力されたプロンプトや文脈（コンテキストウィンドウ）を保持するためのKVキャッシュ（Key-Value Cache）と呼ばれるメモリ領域が必要です。おおよその計算式は以下のようになります。

【FP16時のVRAM要件の目安】
必要VRAM(GB) ≒ ( パラメータ数(B) × 2バイト ) ＋ コンテキスト用バッファ(約2〜4GB)

• 8Bクラス（Llama 3 8Bなど）： 16GB + 4GB ＝ 約20GBのVRAMが必要。
• 70Bクラス（Llama 3 70Bなど）： 140GB + 数GB ＝ 約150GB以上のVRAMが必要。

2.2. 量子化技術（Quantization）がインフラに与えるインパクト

前述の計算通りであれば、70Bクラスの強力なモデルを動かすためには、数百万〜数千万円もするデータセンター向けGPU（NVIDIA A100 80GBを複数枚など）が不可欠になってしまいます。ここでインフラエンジニアの救世主となるのが「量子化（Quantization）」という技術です。

量子化とは、モデルのパラメータ精度を16ビットから8ビット、4ビット、あるいはそれ以下へと圧縮する技術です。精度を少し落とす代わりに、必要なVRAM容量を劇的に削減できます。現在、ローカルLLM界隈では以下のような量子化フォーマットが主流です。

• GGUFフォーマット： llama.cppで主に使用される形式。CPU推論や、CPUとGPUでメモリを分割するオフロード処理に優れる。
• AWQ / GPTQ / EXL2フォーマット： GPUでの高速な推論に特化した量子化形式。vLLMなどの本番向け推論エンジンで広く利用される。

例えば、4ビット量子化を行えば、1パラメータあたりの消費メモリは約0.5バイトにまで縮小します。これにより、8Bクラスのモデルであれば 4GB ＋ コンテキスト ＝ 約6〜8GBのVRAMで稼働可能になり、安価なコンシューマー向けGPU（NVIDIA RTX 3060 12GBなど）1枚でも十分な速度で推論サービスを提供できるようになります。

2.3. CPU、メモリ、ストレージ（NVMe SSD）とPCIeバスのボトルネック

VRAMばかりに目が行きがちですが、インフラの全体最適化を考えると、周辺のコンポーネントも極めて重要です。

1. ストレージ（NVMe SSDの必須化）： 数GB〜数十GBのモデルファイルをストレージからメモリにロードする速度は、サービスの起動時間やモデル切り替え速度に直結します。HDDや低速なSATA SSDでは、起動プロセスだけで数分間ブロックされる事態になります。PCIe Gen4/Gen5対応の高速なNVMe M.2 SSDまたはエンタープライズ向けU.2 SSDが必須要件です。
2. システムメモリ（RAM）： 少なくともVRAMと同等、理想的には2倍以上の物理メモリ（RAM）を搭載する必要があります。モデルをロードする際、一旦システムメモリに読み込まれてからGPUへ転送されるため、ここでスワップが発生するとシステム全体が致命的な遅延を起こします。
3. PCIeバス帯域： 複数のGPUを搭載するサーバーの場合、CPUとGPU間、あるいはGPU同士をつなぐPCIeのレーン数（x16かx8か）と世代（Gen4かGen5か）が推論の並列処理におけるボトルネックになるケースがあります。

2.4. OOM（Out of Memory）のメカニズムとオフロードの罠

後者の「システムメモリへのオフロード」が発生した場合、推論のたびにGPUがPCIeバスを経由してメインメモリにデータを取りに行くことになります。GPUの内部メモリ帯域（数百GB/s〜数TB/s）と比較して、PCIeの帯域（数十GB/s）は圧倒的に遅いため、推論速度（Tokens per second）が数十分の一にまで急激に低下します。「動いているけど、文字が1文字出力されるのに数秒かかる」といった事態に陥るため、インフラ管理者は nvidia-smi などのコマンドを用いて、VRAMの使用率を常に監視し、最適なモデルと量子化の組み合わせを選定するチューニングが求められます。

3. エンタープライズAI基盤としてのAlmaLinux 9/10の優位性

ローカルLLMを検証する際、インターネット上の多くのチュートリアルはUbuntuを前提として書かれています。確かにUbuntuはAI開発者にとってコミュニティの情報が多く使いやすいですが、企業のインフラとして長期運用を前提とする場合、RHEL（Red Hat Enterprise Linux）クローンであるAlmaLinux 9（および次期10）が圧倒的なアドバンテージを持ちます。

3.1. RHELクローンとしての安定性と10年間の長期サポート（LTS）

企業インフラにおいて最も忌避されるのが「頻繁なOSのメジャーアップグレード」と「突然のサポート打ち切り」です。AlmaLinux 9は2032年までのライフサイクルが保証されており、長期間にわたってセキュリティパッチが提供されます。
AIモデルや関連するライブラリ（Python, PyTorchなど）は非常に早いサイクルでアップデートされますが、土台となるカーネルやシステムライブラリ（glibcなど）が安定していなければ、バージョンアップのたびにGPUドライバとの不整合など予期せぬ障害に見舞われます。RHEL系OSの厳格なパッケージングポリシーは、このようなインフラの揺らぎを最小限に抑えます。

3.2. SELinuxとfirewalldによるAIモデル・APIの保護

ローカルLLMサーバーは、社内の機密データを処理する「情報の心臓部」となります。万が一、LLMのフロントエンドアプリケーションに脆弱性がありサーバーへの侵入を許した場合でも、被害を局所化する多層防御が必要です。

• SELinux： デフォルトで有効になっている強制アクセス制御（MAC）により、推論プロセスの権限を最小限に制限します。AIツールが意図しないシステム領域のファイル（/etc/shadowなど）を読み取ろうとしたり、不正なシェルを起動しようとしたりする行為をカーネルレベルでブロックします。
• firewalld： LLM推論エンジン（Ollamaの11434ポートやvLLMの8000ポートなど）は、多くの場合デフォルトでHTTPの平文通信を行います。firewalldを用いてこれらのポートへの直接アクセスを遮断し、Nginxなどを通じたHTTPS（TLS）と認証プロキシ経由のアクセスのみを許可するネットワークゾーン設計を容易に構築できます。

3.3. パッケージ管理（dnf）とPython仮想環境・コンテナ環境の隔離戦略

AI環境の構築においては、OSレベルのパッケージ（NVIDIAドライバ、CUDA Toolkitなど）は dnf で一元管理し、Python依存のAIアプリケーションは以下のいずれかの方法で完全に隔離するのがベストプラクティスです。

1. コンテナ化（Podman / Docker）： NVIDIA Container Toolkitを連携させ、OS環境を汚さずに隔離されたコンテナ内で推論エンジンを起動する。
2. Python仮想環境（venv / Conda）： システムのPython環境とは完全に独立したディレクトリにライブラリ群をインストールし、環境変数を切り替えて実行する。

AlmaLinuxはPodmanをネイティブでサポートしており、デーモンレスでセキュアなコンテナ運用が可能である点も、インフラ視点での大きなメリットとなります。

4. 主要なローカルLLM実行エンジンのアーキテクチャ比較

インフラ基盤が整ったら、次はその上で「どの推論エンジン（ミドルウェア）を稼働させるか」を選定する必要があります。WebサーバーにおけるApacheとNginxの違いのように、各AI推論エンジンには得意・不得意の明確なアーキテクチャの違いが存在します。

4.1. Ollama：マイクロサービス向け、Dockerライクな手軽さと管理性

現在、ローカルLLM環境のデファクトスタンダードとも言えるのがOllama（オラマ）です。Go言語ベースで開発されており、バックエンドの推論エンジンとして後述のllama.cppをラップして使いやすくした構造を持っています。

• アーキテクチャの強み： Dockerと非常に似た操作感（ollama run, ollama pull）を提供し、モデルのダウンロード、量子化、システムへのロードを全て自動化します。バックグラウンドでデーモン（システムサービス）として常駐し、OpenAI互換のREST APIエンドポイントをデフォルトで提供するため、社内の他のWebアプリケーションからHTTPリクエスト経由で容易に連携できます。
• インフラ視点の評価： AlmaLinuxの systemd との親和性が高く、サービス化・自動起動の設定が極めて簡単です。開発用や小規模チームの検証環境など、「手っ取り早く安全にAPIを立ち上げたい」用途において最強の選択肢となります。

# systemdを用いたOllamaのサービスステータス確認（AlmaLinux環境）
sudo systemctl status ollama.service

# Ollamaサービスのログをリアルタイム監視し、異常終了やエラーを検知
sudo journalctl -u ollama.service -f

4.2. llama.cpp：C++ベースの軽量性、CPU推論とエッジデバイスへの応用

Pythonの重厚な依存関係（PyTorchなど）を一切排除し、純粋なC++で高速動作を目指して開発された推論エンジンがllama.cppです。

• アーキテクチャの強み： GGUFフォーマットのモデルを使用し、GPUが存在しない環境でもシステムのCPUとメインメモリをフル活用して推論を行います（AVX2などのCPU拡張命令をサポート）。また、VRAMの容量が足りない場合に、一部のレイヤーだけをGPUに処理させ、残りをCPUで処理する「オフロード機能」の制御が非常に細かく設定できます。
• インフラ視点の評価： 依存ライブラリがほぼ不要であるため、非常にコンパクトなバイナリ一つで動作します。リソースの限られたオンプレミスの仮想サーバー（VM）やエッジデバイス（店舗の小型サーバーなど）で、コストをかけずに推論機能を提供したい場合に威力を発揮します。

4.3. vLLM：PagedAttentionによる本番環境向け高スループット推論サーバー

UC Berkeleyの研究チームから生まれたvLLMは、Ollamaやllama.cppとは完全に異なる思想、すなわち「高トラフィックな本番環境でのスループット最大化」を目的に設計されています。

• アーキテクチャの強み： LLMの推論においてメモリの無駄遣いの原因となる「KVキャッシュ」の断片化を防ぐため、OSの仮想メモリページングに似た「PagedAttention」という独自技術を実装しています。これにより、限られたVRAMの利用効率を極限まで高め、多数のユーザーから同時にリクエストが来た場合（並行バッチ処理）でも、スループット（システム全体の処理能力）を数倍〜数十倍に引き上げます。
• インフラ視点の評価： 社内全域からアクセスされるチャットボット基盤や、大量のRAGドキュメントをバッチ処理するデータパイプラインなど、数十〜数百の同時アクセス（RPS）が想定されるエンタープライズの本番サービスを構築する場合、vLLMは必須のインフラ技術となります。ただし、構築にはCUDAやPyTorch、コンテナ技術のより深い知識が求められます。

5. まとめと次回の予告

本記事「【第1回】LinuxエンジニアのためのローカルLLM入門」では、自社インフラにAI基盤を構築するための第一歩として、以下の重要なインフラ視点について解説しました。

• 生成AIのエンタープライズ導入において、セキュリティ、コスト、コンプライアンスの課題を解決する最適解が「ローカルLLM」である。
• ローカルLLMの安定稼働には、ハードウェアの知識（VRAM容量の計算、量子化、PCIeのボトルネック回避、OOM対策）が不可欠であり、インフラエンジニアのスキルがそのまま活きる。
• RHELクローンである「AlmaLinux 9/10」は、長期サポート、SELinuxによる堅牢なセキュリティ、安定したパッケージ管理により、エンタープライズAIのベースOSとして最適である。
• 実行エンジンは用途（検証、エッジ、高スループット本番環境）に応じて、Ollama、llama.cpp、vLLMをアーキテクチャレベルで適切に使い分ける必要がある。

ここまでで、ローカルLLMを構築するための「設計図」と「全体像」を掴むことができました。しかし、実際にサーバーを立ち上げ、AIモデルをロードするためには、Linuxの奥深くに足を踏み入れる必要があります。

次回、【第2回】AlmaLinux 9/10の初期構築とNVIDIA CUDA環境の最適化では、実際のサーバーを用いてAlmaLinuxのセットアップから開始します。多くのエンジニアが躓く「NVIDIAドライバの競合問題」や「CUDA Toolkitのクリーンなインストール手順」、「nouveauドライバのブラックリスト化」など、現場で直面する生々しいトラブルシューティングを交えながら、実践的なコマンド構築手順を徹底解説します。ご期待ください！