Part I. モデルの内部

0. 前提：モデルの中身はプログラムではない

一番の誤解ポイント。モデルの中に if 文や条件分岐は書かれていない。 あるのは数値の表と、掛け算だけ。

入力の文章はまず数値の並び（ベクトル）に変換される。それを層（レイヤー）と呼ばれる数値の表に何十回も通す。掛けて足して、掛けて足して。最後に「次に来る確率が高いトークン」が出てくる。それだけ。

人間が書いたのは「どういう形の表を何枚重ねるか」という骨組みだけで、 表に入る数値そのものは学習が決めたもの。これが重み。

モデルと GPU の関係

モデル = やる計算の内容（数値の表）
GPU = 掛け算を実行するハードウェア

レシピとオーブンの関係。GPU は与えられた掛け算を高速にこなすだけで、何も判断していない。

この動画はモデルが数値の表と、掛け算だけということが視覚的でわかりやすい

数学のことは一切わからないけど。。

https://youtu.be/tc8RTtwvd5U?si=H8tmIxSauS2smosO

トークン

モデルが文章を扱う最小単位。英語なら1トークンが約0.7単語、日本語は1文字が 1〜2トークン程度（トークナイザ次第で変わる）。

モデルは1トークンずつ生成する。 「今」を出し、それを見て「日」を出す。この1回1回が独立した計算で、料金も速度もこの回数で決まる。

1. 1つの層の中身

Transformer という骨組みでは、各層がだいたい二つの部品でできている。

アテンション層

「このトークンを処理するとき、文章の中の他のどのトークンが関係あるか」を計算する部分。

「その銀行の口座を開いた」で「銀行」を処理するとき、「口座」に強く注目して金融機関の意味だと判断する。「川の銀行」なら別の語に注目する。 文脈を読む能力の源はここ。

FFN（フィードフォワード層）

アテンションが「どこを見るか」を決めた後、その情報を単独で加工する部分。単純な大きい数値の表。

	パラメータの量	役割
アテンション	少なめ	文脈を読む。理解能力の源
FFN	大半	情報を加工する。知識の格納場所

パラメータ数で言えば大半が FFN 側。だから後述の MoE が疎化する対象はここになる。 総量が大きい場所を削れば効く、という話。

2. アテンションのコストは二乗で増える

新しいトークンを1個出すたびに、そのトークンから見てそれまでの全トークンとの関連度を計算し直す。文が長くなるほど比較相手が増える。

文章の長さ	比較回数（概算）
1,000トークン	約50万回
10,000トークン	約5,000万回
1,000,000トークン	約5,000億回

長さが10倍になると計算は100倍。 二乗で効く。

これが「1Mコンテキストは素直なアテンションでは計算的に成立しない」と言われる理由。 1Mを名乗るモデルは何らかの工夫を入れている。関連しそうなトークンだけに絞って比較することで、増え方を二乗から線形寄りに落とす（スパースアテンション）。

KVキャッシュ

過去のトークン側の計算結果を保持しておく領域。毎回作り直さずに済む。ただし「新しいトークンと過去の全部を比較する」回数自体は減らない。

→ コンテキストが長いとメモリも計算も食う。 モデル本体が載っても長文で溢れる原因。

3. MoE（Mixture of Experts）

エキスパートの正体

Dense型では各層に大きな FFN が1個。 MoE ではそれを小さめの FFN 数百個に分割して並べ、そのうち数個だけを使う。

エキスパートとは、この FFN の1個分のコピーのこと。 それ以上の意味はない。

最大の誤解ポイント

エキスパートは「医療専門」「コード専門」のように分かれていない。

人間が「お前は法律担当」と割り振ったものではなく、学習の過程で勝手に分業が生まれただけ。しかも多くの場合、個々のエキスパートが何を担当しているのか人間には解釈できない。

「エキスパート」という名前が完全にミスリード。実態は「数百個ある同じ形の計算ブロックのうち何個かを選んで使う仕組み」。

ルーターの正体

ルーターもニューラルネットの一部。人でもプログラムでもない。やっているのは、

そのトークンのベクトルを、小さな数値の表に掛ける
エキスパートの数だけスコアが出る（896個あれば896個の点数）
点数が高い上位数個を選ぶ

これだけ。この「小さな数値の表」も学習で決まったもので、 人が書いた振り分けルールは存在しない。

「総1.6T / 1トークンあたり48Bアクティブ」の意味

総パラメータは1.6兆、1トークンで実際に動くのは480億個（約3%）。残りは触られない。

MoE の本質は「切り離し」

コスパの話ではなく、知識の量（総パラメータ）と1トークンの計算量（アクティブ）を切り離したこと。

Dense型では「賢くする＝パラメータを増やす＝計算量も比例して増える」が鎖でつながっていた。MoE はこれを切った。

何が決まるか	何で決まるか
1トークンあたりのコスト・速度	アクティブパラメータ
必要なメモリ量	総パラメータ

払っている代償

メモリ。 どのエキスパートが呼ばれるか事前に分からないので、全部を載せておく必要がある
ルーティングの難しさ。 振り分けを誤ると性能が落ちる。エキスパート間の負荷の偏りも問題になる

→ 「計算は安いがメモリは高い」という交換。これが「API では激安なのに家では動かせない」現象の正体。

4. Dense / MoE / スパースアテンションは別の軸

混同しやすいので分けて持つ。

Dense型は全部フル稼働。 アテンションも FFN も毎回全部動く。それが「密」の意味。

MoE と名乗るモデルでも、疎にしているのは FFN だけで、アテンションは Dense のままというのが標準的。 つまり MoE の内部にも「密な部品」がある。

	アテンションは全部見る	アテンションも疎にする
FFN が1個（Dense）	昔の標準的なモデル	あまり見ない組み合わせ
FFN を分割（MoE）	今の主流。多くの大型モデル	1Mコンテキストを狙うモデル

MoE という語は FFN の構造だけを指している。 アテンションについては何も言っていない。だから「MoE かつスパースアテンション」は成立する。両方やっていても MoE と呼ぶ。

用語の罠：「スパース MoE」の sparse

これはエキスパートの選択が疎（896個のうち16個だけ使う）という意味で、アテンションのことではない。同じ「疎」が二か所で使われるので混乱する。

5. 用語の罠：「重み」の二つの意味

日本語でも英語でも紛らわしいので切り分けておく。

呼び方	何か	いつ決まるか
パラメータとしての重み（weights）	学習で決まった数値の表。「重みを公開する」の重み	学習時に固定。推論中は変わらない
アテンションの重み（attention weights）	「このトークンはあれに強く注目」という関連度	毎回の推論で計算される。入力次第で変わる

モデルの重みは動かない。動くのはアテンションのスコア。 1.6兆個の数値は固定されたままで、入力が変わるとその上で計算される注目度が変わる。

6. 「容量」とは何の容量か

パラメータ数 = そのモデルが保持できる区別の細かさの上限。

数値の表が大きいほど、より多くのパターン、より細かい違いを覚えておける。ディスク容量やメモリ容量の話ではない（結果としてファイルサイズには反映されるが）。 表現力・記憶量の上限という意味。

経験的に、パラメータを増やすと性能が上がる傾向が確認されている。だから各社は増やしたい。でも Dense だと計算量も比例して増えて、1トークンあたりの単価が上がる。

だから「容量を増やしても推論コストが増えない」の正確な言い方は、

覚えていられる量を増やしても、1トークンを出すために動く計算量は増えない構造にした

1.6兆個の数値を持っているので細かい区別ができる。でも1トークンごとに触るのは 480億個分だけなので、計算代は480億個相当しか払わない。

Part II. 数字とライセンス

7. 数字の読み方（混同しやすい）

用語	意味	注意
総パラメータ	モデル全体の規模	必要メモリを決める
アクティブパラメータ	1トークンで動く分	コストと速度を決める
コンテキストウィンドウ	一度に参照できる入力の量	出力の上限とは別の数字
最大出力	1回の応答で出せる上限	1Mコンテキストでも出力は128K、などがある

公称と実測はずれる

公称コンテキスト512Kのモデルが、独立測定では実効384K程度、という例がある。 「有効コンテキスト」は公称値と別物として扱う。長文を投げる設計では必ず実測を探す。

トークン単価の横並び比較は厳密にはできない

トークン数は各社のトークナイザで数えるので、A社の1トークンとB社の1トークンは同じ量の文章ではない。$/1M の比較は「だいたいの桁」までしか意味がない。

8. 重みとオープンウェイト

重み（weights）とは

モデルの中身は巨大な数値の表。2840億パラメータなら2840億個の数値。ファイルとしては数十〜数百GB。これがモデルの全部。

学習とは数百億円のGPU時間をかけてこの数値を決める作業。「重みを公開する」とはその数値ファイルをアップロードすること。レシピを配るのではなく、完成品そのものを配っている。

誰が公開するのか

学習した会社自身。漏洩ではなく自発的な公開。動機は混在している。

本業が別にある（AIを安くすること自体が本業に有利）
地政学的な価格攻勢、輸出規制への対抗
採用と評判の広告

公開は義務ではなく選択。「能力が伸びすぎたので公開を保留する」という判断も実際に起きる。

ライセンスの層（「オープンウェイト」は一語だが中身は全然違う）

形態	できること
MIT	著作権表示を残せば複製・改変・商用・再配布まで自由
Apache 2.0	ほぼ同じ＋特許条項
独自ライセンス	条件付き。読まないと分からない
非商用ライセンス	業務で使えない

チェックする癖をつける。「オープン」と書いてあっても非商用のものがある。

法的に未確定な論点

重みという数値の羅列に著作権が及ぶのかは、世界的に確定していない。 人間の創作性がどこにあるのか整理しきれていない。だから各社は著作権ライセンスの形式を借りつつ、実質は利用規約という契約で縛る設計にしている。独自ライセンスが乱立している理由はこれ。

Part III. 市場とエコシステム

9. 価格が決まる仕組み

ここが一番応用が効く部分。性能ではなく市場構造が価格を決めている。

独占型

そのモデルを売れるのは開発元1社だけ。他社は同じものを提供できない。価格は「原価＋利益」ではなく顧客が払う意思のある額で決まる。

コモディティ型

重みが公開されると、GPUを持つ会社が誰でも同じモデルを売れる。出力が同一なので品質で差別化できず、競争軸は価格・速度・レイテンシだけになる。価格は限界費用（電気代＋GPU償却＋薄いマージン）まで押し下げられる。

ガソリン、DRAM、鉄と同じ挙動。

同世代のモデルで単価が100倍以上違うとき、性能が100倍違うわけではない。 独占かコモディティかの差を見ている。

MoE の疎化で限界費用そのものも下がり続けているので、この圧力は今後も続く方向。

10. レイヤー構造（誰が間に立っているか）

「モデルを作る会社」と「モデルを売る会社」は別。ここを混同しない。

自分のマシン
 └ エージェント/クライアント（ローカルで動く。CLIやアプリ）
     └ ルーター/プロキシ（複数プロバイダを束ねる中継。ここが1ホップ目）
         └ 推論プロバイダ（GPUを持ち、他人の重みをサーバに載せて売る）
             └ モデル（開発元が作ったもの）

推論プロバイダはモデルを一切作っていない。 ガソリンスタンドが石油を掘っていないのと同じ。

データポリシーは「和集合」になる

自分に適用される保持・学習の条件は、経由した全事業者のポリシーの和。中継が「ログしません」と言っても、下流のプロバイダが学習に使う設定なら使われる。経路を1本ずつ確認する。

無料の対価はデータ

無料枠やステルス配布（コードネームで匿名公開されるモデル）は、プロンプトと応答が開発元に記録され学習に使われるのが前提のことが多い。規約に明記されているが気付きにくい。

中抜きというより明示的な物々交換。理解した上で使い分ければいい。

Part IV. 運用の実務

11. 思考量（reasoning effort / thinking level）

近年のモデルは「どれだけ考えるか」を呼び出し側で指定できる。 low / medium / high / xhigh / max のような段階。

これが重要なのは、同じモデル名でも設定次第で別物になるから。 同一モデルの最低設定と最高設定で、実力が別モデル並みに離れることがある。コストも数倍変わる。

「モデルAとモデルBどっちが強い?」という問いは、effort 設定を言わないと答えが決まらない。

12. ハーネス（agent harness）という概念

モデルと、それを動かす道具は別物。

モデル = 重み。テキストを受けてテキストを返すだけ
ハーネス = ファイル読み書き、コマンド実行、ツール呼び出し、コンテキスト管理をやる外側の器

同じモデルでもハーネスが違えば結果が変わる。ベンチマークのスコアがベンダー間で横並び比較できない主因はここ（各社が別のハーネスで測っている）。

相性がある

ハーネスのシステムプロンプトやツール定義は特定のモデルに合わせて調整されている。別モデルを差し込むと単体性能より落ちることがある。モデル側が「このハーネスに統合済み」と言うのは、その相性を意識して後段学習した意味。

事実上の共通インターフェース

主要なメッセージAPI形式がデファクト標準になりつつあり、ベースURLを差し替えるだけで別のモデルに向けられる設計が広まっている。これがモデル非依存なエージェントを可能にしている土台。

補助モデルスロットという設計パターン

メインの応答だけでなく、裏方処理に別の安いモデルを割り当てられる作りが標準化してきた。

メイン応答 → 高性能モデル
コンテキスト圧縮・要約 → 格安モデル
画像解析 → マルチモーダルモデル

コスト構造を考えるときはこの分割が効く。

13. 事前学習と事後学習

事前学習（pre-training） = 大量のテキストで基礎を作る。数百億円規模。ここが土台
事後学習（post-training） = 強化学習や環境学習で振る舞いを鍛える

同じベースモデルのまま事後学習だけを積み増して、コーディング性能を大幅に上げた事例がある。 性能向上の余地は事前学習の規模だけで決まらない、というのが近年の重要な変化。

「新しいモデル」と言われたとき、基盤が新しいのか事後学習が変わっただけなのかを見分けると、期待値の設定を間違えにくい。

14. 量子化とプロンプトキャッシュ

量子化（quantization）

数値の精度を落としてメモリを削る。FP16 → FP8 → FP4 / Q4 など。精度を落とすほど軽くなるが品質も落ちる。どこまで落として実用に耐えるかは経験値の領域。

同じモデルでも「フル精度なら数百GB、Q4なら20GB」のように必要環境が桁で変わる。 モデルの必要スペックを見るときは、どの量子化での話かを必ず確認する。

プロンプトキャッシュ

入力の繰り返し部分をサーバ側でキャッシュし、その分を割引する仕組み。キャッシュ読み出しは通常入力の1/10程度になることが多い。

エージェント用途では特に効く。ツールを1回呼ぶたびに会話全体を再送しているため、入力トークンが支配的になりやすい。エージェントのコストを見積もるときは入力側の比率が高い前提で考える。

15. ベンチマークの読み方

自己申告値が多い。 開発元が自社のハーネスで測った値をそのまま出している
横並び比較は厳密には不可。 ベンダーごとに評価環境が違う
比較相手が古いことがある。 発表時点の最新版と比べていないケースを見る
数点差は誤差の範囲。 ハーネスの設定差で動く幅
「回答を拒否した」ことでスコアが上がる指標もある。 知識が増えたのではなく分からないと言うようになっただけ、という改善もある

→ ベンチマークは方向性として読む。順位を絶対視しない。独立した第三者測定があるものは、そちらを優先する。

付録：新しいモデルが出たときのチェックリスト

Dense か MoE か。MoE なら総パラメータとアクティブパラメータ
アテンション側にも疎化の工夫が入っているか（1Mを名乗るなら必ず何かしている）
コンテキストと最大出力（別の数字。実効値は公称と違う可能性）
ライセンス（MIT / Apache / 独自 / 非商用のどれか）
重みが公開されているか（＝将来価格が下がるか、自己ホストできるか）
単価と、思考量の設定でどう変わるか
基盤が新しいのか、事後学習だけ変わったのか
どのハーネスに向けて調整されているか
経由するプロバイダのデータポリシー
ベンチの出典は自己申告か第三者測定か

LLM 周辺の標準知識

CATEGORIES