- はじめに — 大きなモデルではなく、小さなモデルを手で
- 第 0 部 — 最初の教訓：ウォームアップなしのベンチマークは 38 倍の嘘をつく
- 第 1 部 — microGPT：GPT をゼロから、28 秒で
- 第 2 部 — OCR 対決：専用モデル vs 汎用 VLM
- 第 3 部 — 音楽生成：8 秒の音楽を 1.9 秒で
- おわりに — 小さなモデルの時代、GPU 一枚あれば十分だ
- 参考資料
はじめに — 大きなモデルではなく、小さなモデルを手で
最近の話はどれもこれも 700B パラメータ、数千枚の GPU です。しかしコンピュータサイエンスを 学ぶ には、その正反対がいい — 手のひらほどのモデルを GPU 一枚で直接学習させ、分解し、限界に出会うこと。ちょうど RTX 5090（Blackwell、32GB）一枚が SSH の向こうにあったので、小さなモデル三つを直接動かしてみました： ゼロから学習する char-level GPT、専用 OCR vs 小型 VLM の対決、そしてテキスト・トゥ・ミュージック。すべての数値は実測です。そしてその過程で出会った正直な落とし穴たちが、実は結果よりも良い教材でした。
第 0 部 — 最初の教訓：ウォームアップなしのベンチマークは 38 倍の嘘をつく
モデルを動かす前に、GPU がちゃんと回るか bf16 行列積で確認しました。最初の測定値は 6.1 TFLOP/s。5090 がこんなはずはないのに… と思い、ウォームアップループを入れて測り直しました。
First (no warmup) Measured properly
bf16 matmul 6.1 TFLOP/s 231.8 TFLOP/s ← 38x difference
犯人は 最初の呼び出しに cuBLAS の初期化・カーネルのオートチューニングが丸ごと入り込んだこと です。GPU ベンチマークの鉄則 — 数回ウォームアップ（warmup）し、torch.cuda.synchronize() でカーネルが実際に終わるのを待ってから測ること。231.8 TFLOP/s は 5090 の bf16 dense スペック（約 210 TFLOPS）ともぴたりと合います。この記事のすべての遅延（latency）測定には、このウォームアップが入っています。
ちなみにこのサーバーを使うための事前の苦労もありました：5090 は Blackwell sm_120 アーキテクチャなので、旧バージョンの PyTorch は「CUDA 利用可能」と言っておきながら、カーネルがなく静かに失敗します。torch 2.10.0+cu128（CUDA 12.8 ビルド）でようやく sm_120 がアーキテクチャ一覧に入りました。最新の GPU を使うときは、半分がこの環境との闘いです。
第 1 部 — microGPT：GPT をゼロから、28 秒で
まず Karpathy の nanoGPT の系譜に沿って、 char-level GPT を純粋な PyTorch でゼロから 学習させました。シェイクスピアのテキスト 1MB を文字単位（vocab 65 個）で食わせ、6 層・6 ヘッド・384 次元のトランスフォーマー（約 10.75M パラメータ）を 2000 ステップ回しました。
iter 1 | train 3.7921 | val 3.8103 | 10.0k tok/s
iter 500 | train 1.5798 | val 1.7738 | 1006.2k tok/s
iter 1000 | train 1.2769 | val 1.5302 | 1119.1k tok/s
iter 1750 | train 1.1221 | val 1.4425 | 1174.8k tok/s ← val minimum
iter 2000 | train 1.1150 | val 1.4552 | 1184.7k tok/s ← val rebounds (overfitting begins)
trained 2000 iters in 28.0s | peak VRAM 1.73 GB | 1.17M tokens/s
28 秒、VRAM 1.73GB。 loss は 3.79 から 1.12 まで下がり、生成サンプルはこんなシェイクスピア風になります：
The people, could be speak'd of this course,
Who shall be at bold well away and a chief.
Second Citizen:
This in the morniest hour of Turningh; down princ
文法は雑でも、セリフの形式・人物名・古風な言い回しを文字単位で学んだのが見えます。そしてここに隠れた教訓がひとつ — val loss が 1750 ステップの 1.4425 から 2000 ステップで 1.4552 に反発 しました。train loss は下がり続けるのに val が上がる、教科書どおりの 過学習の始まり です。1MB のデータに 10M パラメータなら、すぐに丸暗記を始めますね。早期終了（early stopping）を実物で見る瞬間です。トランスフォーマー構造をより大きな絵で見たいなら、 AI モデル開発ライフサイクル編 と合わせて読んでみてください。
中核となるコードは、今どきの PyTorch らしく簡素です — アテンションは手でマスキングせず、flash attention カーネルに任せます：
# 因果的セルフアテンション: is_causal=True が三角マスクの代わりになる
y = F.scaled_dot_product_attention(q, k, v, is_causal=True)
第 2 部 — OCR 対決：専用モデル vs 汎用 VLM
一番おもしろい実験です。同じ画像に 専用 OCR（Microsoft TrOCR） と 小型ビジョン・言語モデル（Qwen2-VL-2B） を当てて真っ向勝負させました。指標は CER（Character Error Rate、低いほど良い）。テスト画像は英語一行、ハングル一行、そして韓・英・数字が混ざったレシートです。
Model Image Latency CER Read result
──────────────────── ──────── ─────── ────── ──────────────────────────────
TrOCR-printed English 69ms 0.791 THE QUICK BROWN FOX ... LAY DOG
TrOCR-printed Korean 40ms 1.429 CHANGE @ SUBJECT EXCLIP
TrOCR-handwritten English 44ms 0.000 The quick brown fox ... lazy dog
Qwen2-VL-2B (VLM) English 90ms 0.000 The quick brown fox ... lazy dog
Qwen2-VL-2B (VLM) Korean 143ms 0.071 다람쥐 헌 챗바퀴에 타고파
Qwen2-VL-2B (VLM) Receipt 453ms — (KR/EN/num multi-line nearly perfect)
ここから三つの話が出てきます。
第一に、指標を額面どおりに信じないでください。 TrOCR-printed の英語 CER が 0.791 だから「ひどい」と結論づけると間違いです。実際の出力は THE QUICK BROWN FOX JUMPS OVER THE LAY DOG — ほとんど正しく読み、 すべて大文字で 出しただけです（そして lazy の z をひとつ落としました）。CER は大文字と小文字を別の文字として数えるので、大文字化ひとつでスコアが 0.79 まで水増しされたのです。大文字小文字を無視すれば CER は 0.05 程度です。 指標が悪いからモデルが悪いのではなく、指標が何を数えているかを知る必要があります。
第二に、専用モデルは狭いです。 TrOCR はラテン文字だけで学習されているので、ハングルの画像には CHANGE @ SUBJECT EXCLIP のような完全な妄言を出します（CER 1.429 — 挿入エラーのせいで 1 を超えます）。モデルが「知らない」と言えず、知っている文字に無理やり押し込むこと、ドメイン外入力の典型的な失敗です。
第三に、おもしろい逆転 — 「手書き用」の TrOCR-handwritten が印刷体の英語を CER 0.000 で完璧に、しかも大文字小文字まで正しく読みました。「印刷体用」のモデルが大文字でつぶしたものを、「手書き用」が正確に当てたのです。名札（モデル名）が性能を保証しません — 実データで測るまでは分かりません。
そして汎用 VLM の圧勝：Qwen2-VL-2B は英語を完璧に、ハングルは一文字（챗/쳇）だけ間違え、何より 韓・英・数字が混ざったレシートを改行まで生かして ほぼそのまま写しました。おまけに「このレシートをそのまま写して」という 自然言語の指示 を理解します — 専用 OCR にはできないことですね。
まとめると 専用 vs 汎用の古典的なトレードオフ です：
Dedicated OCR (TrOCR) General-purpose VLM (Qwen2-VL-2B)
────────── ─────────────────────── ─────────────────────────────
Speed 40~69ms (fast) 90~453ms (slow)
VRAM 1.39 GB (small) 4.49 GB (3x)
Language Latin only Multilingual
Layout Single line only Multi-line, tables, mixed
Instruction Not possible Instructable in natural language
一行のラテン文書を超低遅延・低コストで大量処理するなら専用 OCR、多言語・複雑なレイアウト・柔軟さが必要なら VLM — 感覚はこんな具合です。
第 3 部 — 音楽生成：8 秒の音楽を 1.9 秒で
最後はテキスト・トゥ・ミュージックです。Meta の MusicGen-small（587M）にプロンプトを二つ投げました。
Prompt Gen time Music len Real-time factor
──────────────────────────────────────────────── ──────── ──────── ──────────
"upbeat lofi hip hop beat, warm piano, relaxing" 1.90s 7.9s 4.19x
"epic orchestral cinematic trailer, drums, brass" 1.85s 7.9s 4.30x
peak VRAM 1.37 GB
8 秒の音楽を 1.9 秒で — 実時間の 4.2 倍の速度で生成しました。MusicGen はオーディオを EnCodec トークン（毎秒約 50 個）に変え、言語モデルのように自己回帰で吐き出し、最後にまた波形へデコードします。LLM がテキストトークンを吐くように音楽を「トークン」として吐くこと — 生成 AI の文法がここでもそのままです。成果物は 32kHz モノラル WAV で保存され、実際に再生するとプロンプトどおりのローファイビートとオーケストラが出てきます。
おわりに — 小さなモデルの時代、GPU 一枚あれば十分だ
三つの実験の共通点：すべて 5GB 未満の VRAM で、秒単位で終わりました。
Experiment Parameters VRAM Key figure
──────────── ───────── ───────── ────────────────────────
microGPT 10.75M 1.73 GB 2000-step training in 28s
TrOCR 334M 1.39 GB single line read 40~69ms
Qwen2-VL-2B 2B 4.49 GB receipt transcription 453ms
MusicGen 587M 1.37 GB 8s of music in 1.9s
大きなモデルがヘッドラインを持っていきますが、 学び、実験するのに良い場所はこの小さなモデルたち です。GPT をゼロから学習させて過学習を目で見て、OCR 対決で「専用 vs 汎用」と「指標の落とし穴」を体で覚え、音楽生成で生成 AI のトークン文法を確認すること — このすべてが、ノートではなく 30 秒、GPU 一枚あればできます。マルチ GPU へ移る次の段階が気になるなら、 分散学習プラットフォーム編 が続きの話です。そして手で直接動かしてみたモデルだけが、本物の感覚として残ります — ベンチマークの数字ひとつも、ウォームアップなしでは 38 倍の嘘をつくのですから。
参考資料
현재 단락 (1/64)
最近の話はどれもこれも 700B パラメータ、数千枚の GPU です。しかしコンピュータサイエンスを *学ぶ* には、その正反対がいい — 手のひらほどのモデルを GPU 一枚で直接学習させ、分解し、...