【付録 第1回】インフラエンジニアが知るべきローカル生成AIの基礎：LLMのメカニズムとアーキテクチャ

本編の連載「LinuxエンジニアのためのローカルLLM」では、全8回にわたり、AlmaLinux上でのNVIDIAドライバの構築から、vLLMやOllamaを用いた推論エンジンのデプロイ、QdrantによるRAG構築、そしてPrometheus/Grafanaを用いた監視・運用まで、極めて実践的な「インフラ構築手順」を解説してきました。

本編を通じて具体的な構築スキルは身についたと思いますが、システムを真の意味で安定運用し、高度なトラブルシューティングを行うためには、土台となる「AIモデル自体の仕組み」や「生成AIの根幹となるアーキテクチャ」への深い理解が不可欠です。そこで今回は【付録】として、2回構成で「ローカル生成AIの基礎と利点」を総まとめします。

リナックス先生、連載の通りに手を動かしてサーバーは作れましたし、社内からも「すごい！」と褒められました。でも、「LLMって中でどうやって文章を作ってるの？」「パラメータって要するに何？」と聞かれると、実はよく分かっていなくて上手く答えられないんです……。インフラエンジニアもAIの中身を知っておくべきですか？

コウ君、素晴らしい気づきですね。インフラエンジニアがAIの「ブラックボックス」をそのままにしておくと、パフォーマンスチューニングの際にカンに頼るしかなくなり、思わぬリソース枯渇（OOM）を招きます。データサイエンティストのような高度な数式を理解する必要はありませんが、AIが「メモリやCPU/GPUをどのように消費して計算しているのか」というアーキテクチャの基礎は、プロとして絶対に知っておくべき知識です。

付録第1回となる本記事では、「生成AI（Generative AI）とはそもそも何なのか」「LLMの心臓部であるTransformerアーキテクチャの概要」、そして「パラメータやトークンといった基本用語がインフラリソースにどう直結するのか」を、インフラエンジニアの視点で徹底的に解剖します。

📚 本連載のカリキュラム（付録：全2回）

【付録第1回】インフラエンジニアが知るべきローカル生成AIの基礎：LLMのメカニズムとアーキテクチャ（本記事）
【付録第2回】クラウドAPIとの比較でわかるローカル生成AIの圧倒的利点と導入戦略

1. 生成AI（Generative AI）とは何か？インフラ視点の再定義
2. インフラリソースに直結するLLMの基本用語
3. ローカルAIを構成するソフトウェアスタック階層
4. クラウドAIとローカルAIのハイブリッド運用アーキテクチャ
5. まとめと次回の予告

📚 本連載のカリキュラム（付録：全2回）

1. 生成AI（Generative AI）とは何か？インフラ視点の再定義
1. 1.1. 従来の機械学習（判別AI）と生成AIの違い
2. 1.2. LLMの心臓部「Transformer」アーキテクチャ
2. インフラリソースに直結するLLMの基本用語
3. ローカルAIを構成するソフトウェアスタック階層
1. 3.1. スタックの階層構造
2. 3.2. トラブルシューティングの原則
4. クラウドAIとローカルAIのハイブリッド運用アーキテクチャ
1. 4.1. 各アプローチの強みと弱み
2. 4.2. 適材適所のハイブリッド・ルーティング設計
5. まとめと次回の予告
1. ▼ 【AIインフラの基礎知識をキャリアに活かそう】 ▼

1. 生成AI（Generative AI）とは何か？インフラ視点の再定義

世間では「AI」という言葉がバズワードとして濫用されていますが、システムインフラを構築・運用する立場としては、「従来の機械学習（判別系AI）」と「現在の生成AI（生成系AI）」のアーキテクチャの違いを明確に区別できなければなりません。

1.1. 従来の機械学習（判別AI）と生成AIの違い

2010年代にブームとなった「ディープラーニング（深層学習）」の主な用途は、データの判別・予測（Discriminative）でした。たとえば、「入力された画像が猫か犬かを判定する」「工場のセンサーデータから故障の予兆を検知する」「迷惑メールをスパムフォルダに振り分ける」といったタスクです。

これらのモデルは、インフラ視点で見ると「軽量かつ計算コストが予測可能」という特徴がありました。数MB〜数十MBのモデルをメモリにロードし、入力データに対して1回の推論（Forward Pass）を行うだけで結果が出力されるため、WebサーバーのCPUだけでも十分にリアルタイム処理が可能でした。

対して、現在のChatGPTやLlama 3に代表される生成AI（Generative AI）は、データの「判別」ではなく、ユーザーのプロンプトを起点として「新しいデータ（テキスト、画像、音声など）を確率的に生成し続ける」モデルです。LLM（大規模言語モデル：Large Language Model）の場合、「与えられた文脈の次に続く最も確率の高い単語（トークン）を予測し、出力する」というサイクルを、文章が完成するまで延々とループさせます。

⚠️ インフラ負荷の非連続的な増大
生成AIのこの「ループ処理」こそが、インフラに爆発的な負荷をかける原因です。出力が1000文字の文章であれば、GPUは「次の一文字を予測する計算」を1000回繰り返す必要があります。さらに、生成が進むにつれて「過去の文脈（コンテキスト）」が蓄積していくため、計算量とメモリ消費量（第5回で解説したKVキャッシュ）がリニアに増大し続けます。従来の判別AIとは次元の違うI/O帯域とVRAMが要求されるのはこのためです。

1.2. LLMの心臓部「Transformer」アーキテクチャ

現在のLLMがここまで高度な自然言語処理を行えるようになった技術的ブレイクスルーが、2017年にGoogleの研究者らが発表した「Transformer（トランスフォーマー）」と呼ばれるニューラルネットワーク・アーキテクチャです。

Transformer以前の主流であったRNN（再帰型ニューラルネットワーク）などは、文章を「先頭から順番に1単語ずつ」しか処理できませんでした。これは、文が長くなると昔の情報を忘れてしまう問題（勾配消失）と、並列計算ができないためGPUの性能を活かせないという致命的なハードウェア上の欠点を持っていました。

Transformerは、「Self-Attention（自己注意機構）」というメカニズムを導入することでこの問題を解決しました。
Self-Attentionは、入力された文章内のすべての単語間の関連性を「同時に、一気に計算する」仕組みです。例えば「The animal didn’t cross the street because it was too tired」という文における「it」が「animal」を指しているのか「street」を指しているのかを、周囲の単語の文脈から数学的な重み付け（Attention）によって判断します。

なるほど、「同時に一気に計算できる」から、並列処理が得意なGPUと相性が良くて、ここまで大規模なモデルが作れるようになったんですね！

まさにその通りです。Transformerのアーキテクチャは、巨大な行列の掛け算（Matrix Multiplication）の塊です。数千個のコアを持ち、単純な行列計算を並列で実行することに特化したNVIDIA GPUのアーキテクチャと完璧に合致したため、LLMは指数関数的な進化を遂げることができました。ソフトウェア（Transformer）とハードウェア（GPU）の幸福なマリアージュと言えますね。

2. インフラリソースに直結するLLMの基本用語

生成AIの運用において、データサイエンティストや開発者から「8Bのモデルを動かしたい」「コンテキストは32kで」「4ビット量子化で十分」といった要件が提示されます。インフラエンジニアは、これらの用語を「物理的なサーバーのメモリ容量、GPUのVRAM、ストレージI/O」に翻訳し、正確なサイジング（リソース見積もり）を行わなければなりません。

2.1. パラメータ（Parameters）とモデルサイズ

LLMの能力を示す最も基本的な指標が「パラメータ数」です。
パラメータとは、Transformerのニューラルネットワークを構成する「重み（Weights）」と「バイアス（Biases）」の総数であり、モデルが学習を通じて獲得した「知識の結晶」です。
単位には「B（Billion＝10億）」が用いられます。例えば「Llama 3 8B」は80億個のパラメータを持ち、「Qwen2.5 72B」は720億個のパラメータを持っています。

このパラメータ数は、インフラエンジニアにとって「必要なディスク容量」と「起動時に消費する最小VRAM容量」に直結します。
パラメータは通常、16ビット浮動小数点（FP16 または BF16）で保存されています。16ビットは2バイトですので、物理的なファイルサイズは以下の計算式で概算できます。

【パラメータ数からモデルのベースサイズを計算する基本式】
モデルサイズ (GB) = パラメータ数 (Billion) × 2 (バイト)

例：8Bモデルの場合
8 × 2 = 約 16 GB のディスク容量およびベースVRAMが必要

例：70Bモデルの場合
70 × 2 = 約 140 GB のディスク容量およびベースVRAMが必要

この計算式を知っていれば、開発者から「70Bのモデルを検証用サーバー（VRAM 24GB）にデプロイして」と依頼された瞬間に、「そのままでは絶対にVRAMに乗り切らない（OOMになる）」と即座に判断し、リソースの再設計や後述の「量子化」を提案することができます。

2.2. トークン（Tokens）とコンテキストウィンドウ

LLMは入力されたテキストを「文字」や「単語」そのものではなく、「トークン（Token）」と呼ばれる細かい破片に分割（トークナイズ）して処理します。
英語の場合、1トークンは概ね 3〜4文字（0.75単語）程度に相当します。日本語の場合はモデルのトークナイザーの学習状況に大きく依存しますが、ひらがなや漢字が細かく分割されるため、1トークンが1〜2文字に相当し、英語よりもトークンを多く消費する傾向があります。

インフラ視点で重要なのは「コンテキストウィンドウ（Context Window）」という概念です。
コンテキストウィンドウとは、LLMが「一度の会話（セッション）で記憶しておける最大トークン数」のことです。初期のモデルは2048トークン程度でしたが、現在では8k（8192）、32k、あるいは128kといった長大なコンテキストをサポートするモデルが主流です。

systemdの思想と機能　Linuxを支えるシステム管理のためのソフトウェアスイート【電子書籍】[ 森若和雄 ]

価格:3080円
(2026/7/17 19:17時点)
感想(0件)

⚠️ コンテキスト拡張によるKVキャッシュ爆発
「長い文章を読めるなら、コンテキストウィンドウは大きければ大きいほど良い」と思われがちですが、インフラにとっては死活問題です。第5回で解説した「KVキャッシュ」は、処理したトークン数に比例してVRAMを消費します。コンテキストウィンドウを32k（約3万2千トークン）に設定して大量の社内PDFを読み込ませると、KVキャッシュだけで数十GBのVRAMを食いつぶし、他のユーザーのリクエストが一切処理できなくなります。RAG基盤を設計する際は、本当に必要なコンテキスト長を見極め、vLLMの --max-model-len パラメータ等でハードリミットをかけることが安定運用の鉄則です。

2.3. 量子化（Quantization）の概念

先ほどの計算式で、70Bモデルを動かすには140GBものVRAMが必要だと述べました。これでは数百万円のデータセンターGPU（A100等）を複数枚搭載したサーバーでしかAIを動かせません。
そこで、ローカル生成AIを一般企業や個人のインフラにまで普及させた最大の立役者が「量子化（Quantization）」という圧縮技術です。

量子化とは、モデルのパラメータ（16ビット浮動小数点）の精度を意図的に落とし、8ビット（INT8）や4ビット（INT4）、さらには3ビットや2ビットの整数値に丸め込む技術です。
例えば、全てのパラメータを4ビット量子化（4-bit Quantization）した場合、1パラメータあたりの消費メモリは 0.5バイトとなります。

【4ビット量子化時のモデルサイズ計算式】
モデルサイズ (GB) = パラメータ数 (Billion) × 0.5 (バイト)

例：70Bモデルを4ビット量子化した場合
70 × 0.5 = 約 35 GB のベースVRAMにまで圧縮される！

驚くべきことに、パラメータの表現精度を16ビットから4ビットに落としても、LLMの推論能力（賢さ）は極端には劣化しません。これにより、本来なら140GB必要な70Bクラスの強力なモデルが、安価なコンシューマー向けGPU（RTX 3090/4090 24GB）を2枚積んだだけのサーバーで快適に動作するようになります。

インフラエンジニアは、GGUF（llama.cpp向け）、AWQ/GPTQ/EXL2（vLLM向け）といった量子化フォーマットの特性を理解し、手持ちのハードウェアリソース（VRAM容量、メモリ帯域）と、業務で求められる推論精度（品質）のギリギリの妥協点を見つけ出すサイジングスキルが求められます。

3. ローカルAIを構成するソフトウェアスタック階層

ローカル生成AIのシステムは、単に「アプリをインストールして動かす」という単純なものではありません。ハードウェアからAIモデルに至るまで、幾重ものソフトウェアスタック（階層）が密接に連携して動作しています。インフラエンジニアとしてトラブルシューティングを行うためには、問題がどのレイヤーで発生しているかを切り分ける「スタックの全体像」を脳内にマッピングしておく必要があります。

「GPUが認識されない」とか「Pythonのライブラリが競合した」とか、エラーが出てもどこを直せばいいのか迷ってしまいます。Linuxのカーネルなのか、Dockerなのか、それともOllamaの問題なのか……。

AIインフラは依存関係のピラミッドです。下の層がぐらついていると、上の層は絶対に正常に動きません。下位レイヤーから順番に健全性を確認していくのが、プロのトラブルシューティングの基本ですよ。

3.1. スタックの階層構造

AlmaLinux環境におけるローカルLLMの典型的なスタックは、下から上へ以下のように構成されています。

ハードウェア・レイヤー： CPU（AVX拡張命令）、システムメモリ（RAM）、ストレージ（NVMe SSD）、GPU（NVIDIA PCIe / NVLink）。
OS・カーネルレイヤー（AlmaLinux）： Linuxカーネル、nouveauの無効化（ブラックリスト化）、システムパッケージ（dnf）。
ハードウェアドライバ・レイヤー： NVIDIAプロプライエタリドライバ（DKMS）。ここで nvidia-smi が機能しなければ、上位のAIアプリはGPUを認識できません（連載第2回で解説）。
ミドルウェア・コンテナランタイム： CUDA Toolkit、Podman/Dockerエンジン、NVIDIA Container Toolkit。これにより、コンテナ内部からGPUへのパススルーが可能になります。
推論エンジン・レイヤー（AIフレームワーク）： vLLM（PagedAttention）、llama.cpp、Ollama、Hugging Face TEI。ここで初めて、AIのモデルを読み込んで行列計算を行うプロセスが立ち上がります。
アプリケーション・レイヤー： Nginx（リバースプロキシ・TLS終端・Basic認証）、OpenAI互換APIエンドポイント、ユーザー向けのチャットUI（Open WebUIなど）。

3.2. トラブルシューティングの原則

例えば「Ollamaのコンテナが起動しない」という障害が発生した場合、いきなりOllamaのログ（レイヤー5）を見るのではなく、以下のように下位から切り分けを行います。

dmesg | grep NVRM でGPUハードウェア自体にPCIeエラーが出ていないか？（レイヤー1）
nvidia-smi を実行し、ホストOSでドライバが正常にロードされているか？（レイヤー3）
podman run --rm --device nvidia.com/gpu=all ubuntu nvidia-smi を実行し、コンテナ内からGPUが見えているか？（レイヤー4）

この階層構造を意識したアプローチを身につけることで、高度に複雑化したAIインフラの障害対応を、論理的かつ迅速に解決できるようになります。

4. クラウドAIとローカルAIのハイブリッド運用アーキテクチャ

ここまでローカルLLMの基礎と技術的アーキテクチャについて解説してきましたが、実際のビジネス現場において「すべてのAI処理をローカルLLMに統一すべき」という極端なアプローチは、インフラエンジニアとして推奨できません。OpenAI（ChatGPT）やGoogle（Gemini）、Anthropic（Claude）などのクラウドAI APIにも、ローカルLLMにはない圧倒的な利点が存在するからです。

4.1. 各アプローチの強みと弱み

クラウドAI APIの強み： GPT-4oやClaude 3.5 Sonnetなど、数兆パラメータ規模の超巨大モデル（フロンティアモデル）が持つ圧倒的な推論能力。複雑な論理推論、プログラミングコードの生成、高度な要約などにおいて、現時点ではローカルLLMの追随を許しません。インフラ管理が不要で、すぐに使い始められる点も魅力です。
クラウドAI APIの弱み： データの社外送信リスク（機密保持の懸念）、トークン数に応じた青天井の従量課金、そしてベンダー側の障害やモデルの仕様変更にシステム全体が振り回されるロックインのリスクです。
ローカルLLMの強み： 連載で構築してきた通り、「完全なデータ・ガバナンス（機密データが外に出ない）」と、「定額のランニングコスト（どれだけ推論してもAPI代はゼロ）」が最大の利点です。
ローカルLLMの弱み： オープンモデル（Llama 3 8B〜70Bクラス）は進化が著しいものの、依然としてトップクラスのクラウドAPIには推論能力で一歩譲ります。また、GPUサーバーの初期構築費と運用保守（電気代、トラブル対応）のコストがかかります。

4.2. 適材適所のハイブリッド・ルーティング設計

エンタープライズのAIインフラ設計における最適解は、「クラウドAPIとローカルLLMを要件に応じてルーティング（振り分け）するハイブリッド・アーキテクチャ」の構築です。

インフラエンジニアは、API Gatewayや専用のAIオーケストレーションツール（LiteLLMなど）をシステムの前段に配置し、以下のようなトラフィック制御を実装します。

機密性の高い処理（RAGなど）はローカルへ： 社内の非公開ドキュメント、顧客の個人情報、ソースコードなどをプロンプトに含める処理は、ポリシーベースのルーティングで強制的に自社のローカルLLM（AlmaLinux上のvLLM等）へ振り分けます。
単純で大量のバッチ処理はローカルへ： ログデータのフォーマット変換、大量のテキストの翻訳、感情分析など、高度な推論能力は不要だがトークン数が膨大になるタスクは、APIコストを削減するためにローカルLLMで処理させます。
複雑で機密性の低い推論はクラウドへ： 「新しいマーケティング戦略のアイデア出し」「一般的な技術に関する質問」「高度なコーディング支援」など、自社の機密情報を含まず、かつ最高品質の回答が求められるタスクのみを、クラウドのGPT-4oやClaude 3 APIへルーティングします。

このようなインフラレイヤーでのインテリジェントなルーティング設計を行うことで、「セキュリティ」「コスト」「AIの品質」という3つのトレードオフを完璧なバランスで両立させることが可能になります。これこそが、次世代のインフラエンジニアに求められるAIアーキテクチャ設計の真骨頂です。

5. まとめと次回の予告

本記事「【付録第1回】インフラエンジニアが知るべきローカル生成AIの基礎」では、システム運用の土台となるAIのメカニズムについて、以下の重要な概念を解説しました。

生成AIとインフラ負荷： 従来の判別AIとは異なり、Transformerアーキテクチャによる自己回帰的なトークン生成ループが、インフラ（GPU・メモリ帯域）に予測困難かつ莫大な負荷をかける理由を学んだ。
リソース・サイジングの基礎式： 「パラメータ数」と「量子化（ビット数）」から、必要なVRAM容量とディスクサイズを論理的に計算し、ハードウェア要件を導き出す手法を習得した。
ソフトウェアスタックの構造理解： ハードウェアからコンテナ、推論エンジンに至るまでの依存関係階層を理解し、トラブル発生時に「どのレイヤーに原因があるか」を切り分けるアプローチを身につけた。
ハイブリッド・アーキテクチャ： クラウドAIとローカルAIのトレードオフを理解し、セキュリティとコストを最適化するAPIゲートウェイ・ルーティングの概念を学んだ。

これらの基礎知識をインストールしたことで、本編で構築したAlmaLinux上のAI基盤が、単なる「手順書のコピペ」ではなく、意味を持った「堅牢なシステム」として脳内にマッピングされたはずです。

次回の【付録第2回】クラウドAPIとの比較でわかるローカル生成AIの圧倒的利点と導入戦略では、ビジネス要件やコンプライアンス（法令遵守）の観点から、企業がなぜ巨額のコストをかけてでもローカルLLMを導入すべきなのか、その説得力ある導入戦略とROI（投資対効果）の考え方について、さらに深く掘り下げて解説します。お楽しみに！