LLM

30秒で分かる

• LLMは次に来るトークンを予測するモデルです。文章生成は、この予測を1トークンずつ繰り返した結果です
• パラメータ数（7B、30B、70B）はモデルの規模を表し、そのままメモリ消費量に直結します
• Denseは毎回すべてのパラメータを使い、MoEは一部だけを使います。同じ「30B」でも動作が違います
• コンテキスト長は一度に扱える入力＋出力の長さで、伸ばすとメモリを大きく消費します
• 設計に必要な数値はすべて、モデルに同梱される config.json に書かれています

仕組み

トークンとパラメータ

LLMは文章をトークンという単位に分割して扱います。英語ではおおむね単語に近い単位、日本語では1〜3文字程度が1トークンになることが多く、モデルによって効率が異なります。

パラメータは、学習で獲得した重みの数です。「7B」は70億個を意味します。1パラメータをBF16（2バイト）で保持すれば、それだけで14GBです。

処理は2段階に分かれる

LLMの推論は、性質のまったく異なる2つのフェーズで構成されます。この違いを理解していないと、性能問題の切り分けができません。

フェーズ	やること	律速するもの	体感される指標
プリフィル	入力全体を一度に読み込む	演算性能	TTFT（初回応答）
デコード	1トークンずつ生成する	メモリ帯域	tok/s（生成速度）

プリフィルは入力トークンをまとめて処理できるため、GPUの演算器を使い切れます。一方デコードは1トークンずつしか進められず、そのたびに重み全体をメモリから読み出すため、演算性能ではなくメモリ帯域が上限を決めます。詳細はGPUを参照してください。

Dense と MoE

Dense（すべてのパラメータを毎回使う）
  入力 → [ 全パラメータ 30B ] → 出力
         読むバイト数 = 30B分

MoE（一部のエキスパートだけを使う）
  入力 → [ ルーター ] → [ 選ばれたエキスパート 3B ] → 出力
         メモリに置く = 30B分 / 読むバイト数 = 3B分

MoE（Mixture of Experts）は、内部を複数の「エキスパート」に分割し、トークンごとに一部だけを選んで使う構造です。「30B-A3B」という表記は、総パラメータ30B・アクティブパラメータ3Bを意味します。

コンテキスト長

一度に扱えるトークン数の上限です。入力と出力の合計であり、伸ばすほどKV Cacheが線形に増えます。

RAGを使う場合、検索した文書をプロンプトへ詰め込むため、入力は自然と長くなります。「モデルが128Kまで対応している」ことと「128Kで実用的な速度が出る」ことは別問題です。

設計に効く数字と落とし穴

config.jsonから取る値

サイジング（Level 2）で必要になるのは次の4つです。

キー	意味	使い道
num_hidden_layers	レイヤ数	KV Cacheの計算
num_attention_heads	Attentionヘッド数	head_dimの算出
num_key_value_heads	KVヘッド数	KV Cacheの計算（GQAの効き目）
hidden_size	隠れ層の次元	head_dim = hidden_size ÷ heads

num_key_value_heads が num_attention_heads より小さければ、そのモデルはGQAを採用しており、KV Cacheが大幅に節約されています。

落とし穴

• 日本語のトークン効率はモデルで異なる：同じ文章でもトークン数が2倍違えば、コンテキスト消費も課金対象トークン数も2倍になります。候補モデルの比較では、同じ日本語文書で実際のトークン数を数えてください
• ライセンスは「オープン」でも一律ではない：商用利用の可否、利用者数の上限、出力の利用条件がモデルごとに違います
• ベンチマークのスコアは日本語性能を保証しない：英語中心の評価で高得点でも、日本語の社内文書で使えるとは限りません。Level 0で作る想定質問セットで必ず自前評価します
• コンテキスト長の上限＝実用範囲ではない：長文になるほどKV Cacheが増え、同時実行数が削られます