【学習ログ】ローカルでGPT OSSを動かす準備 #1 LLMの仕組みを3つのレイヤーで整理してみた
はじめに
少し前に書いたこの記事（Zenn記事）では、ローカルでLLMを動かす内容をまとめたが、今振り返ると全体的に理解が浅かったと感じている。
モデルとアーキテクチャの違いが曖昧なままだったり、推論フレームワークの役割や実行環境のメモリ要件を十分に整理できていなかったりと、知識の土台が弱いまま書いてしまっていた。
最近は、OpenAIがgpt-oss-120bとgpt-oss-20bをリリースして間もなく、多くの開発者の間で話題になっている状況。
性能面では非常に魅力的だが、20bモデルだけでも推論に16GBのメモリが必要で、自分の8GBメモリのMacBook Airでは実行が難しい。
Docker環境でもメモリ不足で落ちる可能性が高く、ローカルでの利用は現実的ではないと判断している。
そのため、LLaMA系やPhiシリーズ、Mistralのような軽量なモデルを中心に検討を進めている。
今回は、その前提を踏まえたうえで、ローカルで動かすモデルや環境を選ぶ際の基礎として、LLMを3つのレイヤー構造で整理してみる。
モデル層
モデル層は、学習済みのパラメータ（重み）と、そのモデルが持つ性能や規模を表す部分。
この層には、OpenAIのgpt-oss-120b / gpt-oss-20b、MetaのLLaMA、MistralのMistral 7B、MicrosoftのPhi-3などが含まれる。
モデルサイズが大きいほど精度は高まりやすいが、その分メモリやストレージの要求も増える傾向がある。
たとえば、gpt-oss-20bは16GBメモリ必須で、8GBメモリのMacBook Airでは動作しない。
自分も最初は「なんとかなるだろう」と軽く考えて試してみたが、Docker上でメモリ不足による停止を繰り返す結果になった。
アーキテクチャ層
アーキテクチャ層は、モデルの設計思想や構造を決める部分。
多くのgpt ossはTransformerアーキテクチャを採用し、自己注意（Self-Attention）機構やエンコーダ/デコーダ構造によって動作している。
Phi-3やMistralはデコーダ型Transformerに分類され、テキスト生成に特化した設計になっている。
この層は、入力をどの順番で処理し、どのように次の単語を選ぶかといった内部の流れを決定する役割を持っている。
推論フレームワーク層
推論フレームワーク層は、学習済みモデルを実際に動かすための基盤となる部分。
モデルのデータがあっても、この層がなければ推論は実行できない。
- vLLM：推論速度と効率化に優れている
- Ollama：セットアップが容易で、モデル管理を自動で行う
- Hugging Face Transformers：モデルの選択肢が豊富で、柔軟な実装が可能
用途や環境によって、どの推論フレームワークを採用するかは変わってくる。
まとめ
LLMは、
- モデル層（学習済みパラメータと性能）
- アーキテクチャ層（構造と設計）
-
推論フレームワーク層（実行基盤）
の3つが揃って初めて機能する。
以前はこの構造を意識せずに環境構築を進めていたが、改めて整理して理解が深まったことで、モデル選定や環境構築の判断がしやすくなった。
次回は、実際に動かす前に行うローカルマシンの容量チェックとDocker準備についてまとめる予定。
Discussion