辞書：知識に住所がある
「富士山」の知識は「富士山のページ」に書いてあります。書き込んだものをそのまま取り出す仕組みなので、必要なページだけ開けば済みます。
知識1件 = 決まった場所に1件
DBC AI Academy 第1回 / interactive guide
LLMは、
1トークンずつ
考えている。
トークンとは、LLMが文章を扱うための文字のかたまりです。入力から次の1トークンが出るまでを、実際に動かしてのぞいてみましょう。
inference console
user > 富士山の高さは
model> 3,776
step > 1 token / pass
AIの知識データ小数を圧縮して保存
KV CACHE会話の作業メモ
GPU / CPU大量の計算
Did you know?
たった1トークンのために、
LLMはモデル全体を1周する。
文章を一度に完成させるのではなく、この「モデル1周」をトークンごとに何度も繰り返しています。
1 TOKEN1周
一般的なDense型（モデル全体を使う方式）のLLMは、1トークン作るたびに各レイヤーの重みを使い、最初から最後まで順番に計算します。
学習で調整される 0.52489654 のような小数1つを「パラメータ」と呼び、これは「重み」とも呼ばれます。重みとパラメータは同じものの別名です（英語では weights と複数形）。8Bの「B」はBillion（ビリオン＝10億）の略なので、8Bモデルには約80億個の重み（パラメータ）があります。
なぜ関係ある部分だけ読まないの？
重みは、辞書のように「関係ある知識だけ引き出す」索引ではなく、計算式の係数だからです。たとえば「y = 0.7×a − 1.2×b + 0.3×c」という式で y を求めるとき、3つの係数はどれも省けません。すべて掛けて足し合わせて、はじめて答えが出ます。LLMはこの式が桁違いに大きくなったものです。
しかも、辞書なら「富士山」のページだけ開けば済みますが、LLMには知識の「ページ」がありません。富士山の高さという知識は、どこか特定の重みに書かれているのではなく、たくさんの係数の値の組み合わせ全体に溶け込んでいます。「関係ある部分」を指させないので、選んで読むことがそもそもできない。これが、1トークンごとにモデル全体を読む理由です。この「溶け込み」は、次の節のミニモデルで実際に触って確かめられます。
では、「毎回すべてのメモリにアクセスする」の？
パソコンの全メモリを読むわけではありません。主に使うのは、モデルの重みが置かれた領域と、ここまでの会話を記録したKVキャッシュです。実際にRAMやVRAMからどう読み出すかは、CPU・GPUのキャッシュや推論方式によって変わります。
メモリ全体でのLLMの領域（GPU搭載PCの例・模式図）
GPUのメモリ（VRAM）
パソコン本体のメモリ（RAM）
毎トークン読むのは、色の付いた「重み」と「計算メモ」の領域です。OSや他のアプリの領域には触れません。Apple Siliconのように1枚の共有メモリの機種では、この2段が同じメモリに同居します。
1トークンが生まれるときの
メモリの動き
左側のメモリから重みと会話の計算メモを読み、中央のGPU・CPUで計算すると、右側に次の1トークンだけが出てきます。
MEMORY / MODEL
AIの知識データ
学習時：浮動小数点数
実行時：4-bitなどへ量子化
MEMORY / CONVERSATION
会話の計算メモ
ここまでの会話の途中計算
専門用語：KVキャッシュ
GPU / CPU
次に続くものを計算
何層もの計算を順番に通過
NEXT TOKEN
次の1トークン
から文章の末尾に追加
パラメータとは別物
Where is the knowledge?
「富士山の高さ」は、
どの重みに書いてある？
答えは「どこにも書いていない。それでも全体に入っている」。前の節の「関係ある部分を選んで読めない」理由を、実際に触って確かめましょう。
LLMの重み：知識に住所がない
学習は「書き込み」ではなく、巨大な計算式を実例に合わせて少しずつ曲げる作業です。1件の知識は、全部の重みをわずかに動かした「痕跡」として残ります。
知識1件 = すべての重みへ薄く分散
Mini model lab
重み2個のミニモデルに、
8個の点を覚えさせる。
丸い点が学習データ（覚えさせたい実例）、黄色い直線がモデルの答えです。このモデルが持つ重みは「y = a×x + b」の a と b の2個だけ。LLMは、これが80億個規模まで増えたものです。点をドラッグしたり、空いた場所をクリックして点を増やしたりしてみてください。
どの点も、a と b の「中」には保存されていません。それでも、すべての点が a と b の値に影響しています。この「どこにもないが、全体にある」が、知識が重みに溶けている状態です。
空いた場所をクリック／タップ＝実例を追加。点をドラッグ＝実例を修正。灰色の点線は、直前の操作をする前の直線です。
y = a × x + b
重み a（傾き）0.00
重み b（底上げ）0.00
学習データ 8 点を、重み 2 個で記憶中
実際のLLMの学習は、直線ではなく何層も重なった複雑な式を使い、実例ごとに「間違いが減る方向へ全重みを少しずつ動かす」操作を膨大に繰り返します。このラボはその最小の模型です。
半分にしても、全体が残る
写真は半分に切ると半分の絵が消えますが、ホログラムは半分にしても全体像がぼやけて残ります。重みの一部を失ったり丸めたりしたときのLLMの壊れ方は、写真型ではなくホログラム型です。
量子化が成り立つ理由
80億個の重みを一律に丸めても、特定の知識が1件ずつ消えるのではなく、モデル全体がわずかに粗くなるだけ。先ほどの「重みを丸める」ボタンで見た変化の、80億個版です。
だから、毎回全部読む
「関係あるページ」がそもそも存在しないので、選んで読むことができません。どの1トークンの計算にも、すべての重みが計算式の係数として参加します。
Two phases of inference
実は、処理には
2つの段階がある。
入力を読むときと、回答を作るときでは、トークンの処理方法と体感速度の指標が異なります。
入力をまとめて読む
入力された複数のトークンをまとめて計算し、これから回答を作るためのKVキャッシュを準備します。
ローカルLLMは？まとめて計算
体感指標：TTFT / 最初の1トークンが出るまで
回答を1つずつ作る
モデルの全レイヤーを通して次の1トークンを選び、会話とKVキャッシュへ追加して繰り返します。
次の1個次の1個次の1個
体感指標：tokens/sec / 1秒間に生成する数
トークンから次のトークンまで
トークンとパラメータは別物です。1つの入力が、どのようにモデルの計算へ入るかを正式な用語で追ってみます。
TEXT UNITトークン文字のかたまり
INTEGERトークンID辞書内の番号
VECTOR埋め込みベクトル数百〜数千個の数値で表現
MODEL全レイヤーで計算重みとKVキャッシュを使用
OUTPUT次のトークン候補の確率から選択
なぜ毎回、全レイヤーを通るのか
後ろのレイヤーは前の計算結果を受け取るため、途中を飛ばせません。ボタンを押して、新しいトークンの数値表現がモデルの最初から最後まで進む様子を確認できます。表示するトークンの区切りは模式例です。
レイヤー = LLM内部の計算ステージ
物理的な部品ではなく、入力された数値を受け取り、加工して次へ渡す処理のまとまりです。
ATTENTIONどの言葉を参照するか調べる
文脈の中で関係の強いトークンから情報を集めます。
MLP / FEED FORWARD集めた情報を変換する
重みを使った行列計算で、次のレイヤーへ渡す特徴を作ります。
各レイヤーはそれぞれ異なる重みを持ちます。後ろのレイヤーは前の出力を必要とするため、順番に通る必要があります。
富士山の高さは
LAYER 01Attention + MLP
LAYER 02前段の結果をさらに変換
LAYER 03 ... N-1同じ構造を繰り返す
FINAL LAYER次の候補を作る
KV CACHE / L1
KV CACHE / L2
KV CACHE / L3 ... N-1
KV CACHE / FINAL
過去の計算はKVキャッシュに保存済み。新しい1トークンを待っています。
Interactive token journey
1トークンの旅を
動かしてみよう。
「次へ」を押すたびに、ローカルLLM内部の処理が1段階進みます。入力欄の文章は自由に書き換えられます。
Memory estimator
メモリは、
「本棚＋机」。
AIの知識データ（重み）は巨大な本棚、会話の計算メモ（KVキャッシュ）は会話中だけ広がる机です。重みはもともと浮動小数点数ですが、量子化すると小さな本棚へ圧縮できます。
AIの知識データ（重み）= 本棚
基本的に、学習で調整された小数1つが1パラメータ＝1つの重みです。回答中に学習内容が書き換わるわけではありません。
量子化 = 数値を丸めるモデル圧縮
重みを16-bitから8-bitや4-bitへ近似し、必要なメモリと読み出すデータ量を減らします。8Bモデルの重みは単純計算で16-bitなら約16GB、4-bitなら約4GBです。細かな値を丸めるため元の数値へ完全には戻らず、回答品質がわずかに変化する場合があります。
会話の計算メモ（KVキャッシュ）= 机
過去のトークンから得た途中計算を保存し、毎回のやり直しを減らします。
一時領域 = 計算中の作業スペース
推論エンジンやGPUによって必要量は変わります。
ROUGH MEMORY ESTIMATE
概算8B / 80億
4-bit
4K tokens
必要メモリの目安
約 5.7 GB
重みの生データ：8B × 4-bit ÷ 8 ≈ 4.0GB
AIの知識データ 約4.8GB（生データ約4.0GBに、圧縮を元に戻すための補正値などを上乗せ）＋ 会話の計算メモ・作業領域 約0.9GB。実装やモデル構造によって変動します。
容量：モデルが載るか
VRAMに収まらなくても、重みの一部をRAMへ逃がせば動く場合があります。ただし、高速な場所から遠ざかるほど生成は遅くなります。
重みの容量 ≈ パラメータ数 × bit数 ÷ 8
帯域幅：どれだけ速く読めるか
デコードは重みを繰り返し使うため、メモリ帯域幅がtokens/secを左右します。実際の速度には計算性能や実装効率も影響します。
理論上限の目安 ≈ メモリ帯域幅 ÷ 重みの容量
Memory offload lab
重みがGPUメモリから、
あふれたら？
同じ8B・4-bitモデル（必要メモリ約5.7GB、うち重み約4.8GB）を、一般的な離散GPU搭載PCで動かす説明用の例です。スライダーを動かし、1秒間に進める生成量を比べてください。
ほんの一部がVRAMからあふれただけなら、必ずしも急落しません。 RAMへ逃がす量に応じて徐々に遅くなるのが基本です。RAMまで不足してSSDの読み直しが続くと、そこで数十〜数百倍の急落が起こり得ます。
最初の一段を試してください。 0.2GBだけRAMへ逃がす例では、いきなり3倍には落ちません。
GPU VRAM4.8GB
システムRAM使用なし
SSD / スワップ使用なし
すぐ文章が伸びる目安 30〜100 tokens/s
VRAM基準
60 tok
選択中
60 tok
代表速度60 tok/s
100トークンの待ち時間約1.7秒
VRAM基準との比較基準
重みと計算をGPU内で完結できる構成です。メモリ帯域が広く、8Bモデルなら会話の文字が滑らかに伸びる速度を狙えます。
棒は「同じ1秒で進める量」。数値は機種・実装・文脈長で大きく変わります。
SSDのメモリマップは、RAMに余裕があれば最初の読み込みを助けるだけで、毎トークンSSDを読むとは限りません。ここで極端に遅いのは、RAMが足りず同じ重みをSSDから何度も読み直す「スワップ地獄」の状態です。Apple SiliconなどのユニファイドメモリはCPUとGPUが同じ高速メモリを共有するため、このVRAM対RAMの例がそのまま当てはまりません。
Context lab
会話を長くすると、
机も広がる。
コンテキストを増やすと過去の内容を多く保持できますが、KVキャッシュもほぼ比例して増えます。スライダーで変化を確認してください。
4K tokens
CONTEXT4K
KV CACHE 相対量1×
過去の参照量基準
Choose your model size
何Bなら、
どこまでできる？
Bは能力の絶対値ではなく、モデル規模を示す目安です。表のモデルサイズを選ぶと、向いている用途と弱点が切り替わります。
SELECTED SIZE8B4-bit実行 約5〜7GB
日常用途のバランス型
文章作成、要約、RAG、基本的なコード支援などをローカルで試しやすい規模です。
複雑な数学や大規模コード変更、事実性が重要な回答には確認が必要です。
| 規模 | 向いている用途 | 苦手・注意点 | 4-bit実行目安 |
|---|
表は最近の指示調整済みDenseモデルを想定した目安です。実行メモリには重みと基本的な作業領域を含み、長いコンテキストのKVキャッシュは別途増えます。能力はモデル世代・学習データ・日本語性能・追加学習でも変わります。
8Bより16Bの方が賢い？
同じ世代・設計・学習条件のDenseモデル同士なら、一般に16Bの方が複雑な指示、推論、知識の扱いで安定しやすい傾向があります。ただし、B数は知能の点数ではなく、性能を保証する順位でもありません。
大きさが効きやすい場面複雑な推論・長文統合
大小が逆転する要因世代・学習品質・用途特化
大きくする代償必要メモリ・待ち時間
新しく良質に学習された8Bが古い16Bを上回ったり、特定用途へ追加学習した8Bが汎用16Bより強かったりします。日本語の学習量、量子化、プロンプトとの相性も結果を左右します。単純な要約や定型抽出では差が小さく、複雑な推論ほど差が表れやすいため、実際の用途に近い課題で比較するのが確実です。
結論：16Bは8Bより賢い傾向はある。ただし「2倍のB数 = 2倍の知能」ではなく、モデル名・世代・学習方法・量子化まで含めて判断します。
8Bモデルで試せる4つの仕事
用途を切り替えると、入力・出力例と人間が確認すべきポイントを比較できます。
INPUT
TYPICAL OUTPUT
DenseとMoEは「B」の読み方が違う
全パラメータを使うDenseと、選ばれた専門家だけを使うMoEを切り替えて比較します。
BLOCK 1
BLOCK 2
BLOCK 3
BLOCK 4
BLOCK 5
BLOCK 6
BLOCK 7
BLOCK 8
総パラメータ8B
1トークンで使う量ほぼ8B
特徴全体を使用
Dense型では、1トークンごとにモデル全体のレイヤーを通ります。ページ前半の「1トークン＝1周」は主にこの方式の説明です。
身近なクラウドAIは何B級？
公式値と推測値を同じものとして扱わないため、確度を色分けしています。行を選ぶと根拠と8Bモデルとの比較を確認できます。
公式・仕様公開未確認の推測根拠の弱い範囲
調査時点：2026.08.26。出典：GPT-3公式、gpt-oss公式、GPT-4推測の扱い。現在のGPTとClaudeの数値は公式未確認です。
Energy question
please と thank you だけで、
電力コストは膨大になる？
2025年、「ユーザーが打つ please や thank you のために数千万ドルの電力費がかかっている」と、クラウドAI企業のCEOが冗談交じりに述べて話題になりました。「ありがとう」も特別扱いはされません。トークンに分割され、返答の1トークンごとにモデル全体（MoEなら有効分）を読みます。ここまでの知識で、この問いを分解してみます。
「ありがとう」と送る1往復で、どれくらい電力を使う？
入力と返答をあわせて約20トークンの短いやり取りを仮定し、モデル規模ごとの消費電力量を並べます。行を選ぶと数値の根拠を確認できます。
公式・公表値仮定にもとづく概算
調査時点：2026.08.27。出典：Google公表値（2025.08）、OpenAI CEOブログ（2025.06）。クラウドの公表値は、公表当時の標準的な利用における平均・中央値です。「ありがとう」だけの1往復はこれより小さく、長く考えてから答える推論モードや最新の大型モデルの1回は、生成トークン数が多いぶんこれより大きくなり得ます。
クラウドの1回分は、単純な比例計算では出せない
クラウドは大量の要求を1つのGPU群でまとめて計算し、重みの読み出しを共有します。1回あたりの消費は素朴な「規模×トークン数」より小さくなり、正確な値は外部から計算できません。
効くのは総パラメータでなく「1トークンで有効な量」
MoEでは毎トークン読むのは選ばれたExpertだけです。「大きいモデルほど消費も大きい」という比例関係は、Dense同士の比較でだけ素直に成り立ちます。
公表値は少なく、測り方で数倍変わる
GPUだけを測るか、冷却や待機中の設備まで含めるかで数値は大きく変わります。この図では公式の公表値と、仮定にもとづく概算を色分けしています。
答え：1回は小さい。膨らむのは「積」。
1往復はLED電球を数秒〜数分点けられる程度です。ただし、仮に世界で1日10億回の「ありがとう」があれば、0.3Wh × 10億回 = 30万kWh。日本の一般家庭 約3万世帯の1日分に相当します（回数は説明用の仮定です）。CEOの「数千万ドル」も、小さな1回と莫大な回数の積の話です。
ローカルなら、実測できる
ローカルLLMは自分のPCで動くため、ワットチェッカーやOSの電力表示で「ありがとう」1回分の消費を実際に測れます。公表を待たず自分の環境で確かめられるのは、ローカルならではの利点です。
Myth vs. reality
ここを間違えやすい。
ローカルLLMを理解するときの、代表的な3つの勘違いです。
「毎回、文章全体をゼロから考え直す」
KVキャッシュに過去の途中計算を残すため、生成済みの全文を毎回まったく同じように再計算するわけではありません。
「1トークン = 1文字、または1単語」
日本語でも、1文字になる場合、複数文字がまとまる場合、まれな文字が複数に分かれる場合があります。同じ文章でもモデルの辞書によって分け方は異なります。
「メモリ容量だけ大きければ速い」
容量は「載るかどうか」、帯域幅は「毎秒どれだけ読めるか」。速度にはGPU/CPUの計算力とメモリ帯域の両方が関係します。
Knowledge check
5問で、理解を
確かめよう。
正解することより、理由を説明できることがゴールです。
YOUR PROGRESS
01 / 05
8Bモデルの「B」は何を表す？
選択肢を1つ選んでください。
One more token
この小さなループを、
文章が終わるまで繰り返す。
いままでの文脈
モデルを1回通す
次の1トークン
また繰り返す