Go言語とトイモデルで学ぶTransformerの気持ち / fukuokago23-transformer

2026.07.21 Fukuoka.go#23
https://fukuokago.connpass.com/event/397937/
Demo site: https://transformer-flow-lab.lolipop-now.app/

Transcript

1. Go言語とトイモデルで学ぶ Transformerの気持ち 三宅悠介 / Pepabo R&D Institute, GMO Pepabo, Inc. 2026.07.21 Fukuoka.go#23
2. シニア・プリンシパルエンジニア 三宅 悠介 / @monochromegane Yusuke Miyake ペパボ研究所 研究員、博士（情報科学） https://blog.monochromegane.com 2
3. 目次 1. はじめに 2. Transformerの気持ち 3. 計算とメモリの工夫 4. まとめ 3
4. 1. はじめに
5. 背景 • AI前提のサービス設計が広がり、LLMサービングの機会が増えている • オープンウェイトのLLMも性能が向上し、自前でのサービング（セルフ ホスト）が現実的な選択肢に • Go言語などを扱うサーバーサイドエンジニアも、サービング対象＝モデル の「気持ち」を知ることが重要 5
6. 気持ちを知っておきたい理由 • LLMサービングのボトルネックは、計算量とGPUメモリ • Attentionは系列長が伸びるほど計算が重くなる（長い文脈ほど高コスト） • KV cacheは生成のたびに増え続け、メモリ使用量を大きく左右する • 内部の「気持ち」が分かると、レイテンシ・スループット・メモリの勘所が 掴める → パフォーマンスエンジニアリングの第一歩 6
7. 気持ちの知り方 • Transformerは、いまのLLMの基幹アーキテクチャ • 文章を「トークン」の列として、次の1トークンずつ予測して生成する • その心臓部がAttentionで、各トークンが過去トークンに「注意」を向ける • この「過去トークン」の計算結果（Key/Value）を使い回す仕組みがKV cache • しかしながら、数式だけでは内部の動きは直感的に分かりにくい • → Go言語とトイモデルで、手を動かして理解しよう 7
8. 2. Transformerの気持ち
9. トイモデルで見るTransformerの動き Transformer Flow Lab トークンごとのAttention / KV cacheの動きをブラウザ上で可視化 transformer-flow-lab.lolipop-now.app ※ 本発表とこのトイモデルではFFN・正規化・埋め込みなどは扱いません 9
10. テキスト生成のおおまかな流れ (1/3) 入力トークン列を通し、次のトークンを予測 10
11. テキスト生成のおおまかな流れ (2/3) 予測したトークンも入力に加え、また予測 11
12. テキスト生成のおおまかな流れ (3/3) EOSが出るまで、これを繰り返す 12
13. 過去トークンへの「注意」のしくみ • テキスト生成は、トークンを1つずつ予測して並べる流れ（自己回帰） • Transformerの心臓部がAttentionで、過去トークンから必要な情報を集める •「どうやって集める？ 」「何のために？ 」が、直感的に掴みにくい • それを担うのがQ/K/V 13
14. Q/K/Vの役割 • 各トークンを、役割の違う3つのベクトルに変換する • Q（Query）＝ いま探したいこと • K（Key）＝ 各トークンの目印 • V（Value）＝ 取り出したい中身 • 例：「猫が寝ている。それは疲れていた」 • Q/Kが品詞的な観点を学習しているとする（実際は複数の観点を持つ＝マルチヘッド） •「それ」のQ（指している名詞は？ ）に「猫」のK（この場合は名詞）が 最も強くヒットし、Vから猫の意味を多めに取り込む 14
15. Q/K/Vの役割 • 各トークンを、役割の違う3つのベクトルに変換する • Q（Query）＝ いま探したいこと • K（Key）＝ 各トークンの目印 • V（Value）＝ 取り出したい中身 • 例えるなら、キーの完全一致ではなく「近さ」で引けるmap • map[K]Vは、一致したキーの値を1つだけ返す • Attentionは、QとKの近さに応じてすべてのVを混ぜて返す 15
16. QとKの関連度合い 現在トークンのQと各過去トークンのKを照合し、向きが近いほど高スコア いま探したいこと（Q）に関係する過去トークンほど、強く注目したい 16
17. 関連度合いによるVの重み付け スコアを重みに変換し、各トークンのVを重み付けして足し合わせる 関係が強いトークンの中身（V）ほど、多く取り込みたい 17
18. 足し合わせた結果としての出力 重み付けしたVを足し合わせた1本のベクトルを出力とする このトークンが過去から何を読み取ったかを1本に凝縮したもの 18
19. Qの変化と出力の連動 Qの向きを変えると、スコア→重み→足し合わせた結果まで連動して変わる（実 際はトークンごとにQ/K/Vがセットで変わる） 文脈に応じて、様々な合成を得られる 19
20. 3. 計算とメモリの工夫
21. GPUの概略図 例：7Bモデル（fp16）を載せた場合 GPU SMの中身 SM SM SM モデル重み 14 GB 7B×2バイト（fp16） 計算のたびに 読み書き CUDA core ×多数 Tensor core Tensor core 共有メモリ（SRAM）：小容量 HBM/GDDR（VRAM） 24 GB 8k文脈×1リクエスト KV cache 4 GB （詳しくは後述） 一時メモリ 約2 GB 計算の途中結果の置き場 空き 4 GB Streaming Multiprocessor（SM）が計算し、 VRAM上の重み・KV cache・途中結果を読み書きする 21
22. 毎回すべてを計算する素朴な実装 type Ctx struct{ tokens []Token; ks, vs []Vec } // Attention操作（関連度 → 重み → 足し合わせ） func attend(q Vec, ks, vs []Vec) Vec { w := softmax(scores(q, ks)) return weightedSum(w, vs) } // 素朴な実装（毎ステップ、全トークンから K・V を作り直す） func step(ctx *Ctx, tok Token) Vec { ctx.tokens = append(ctx.tokens, tok) ctx.ks, ctx.vs = nil, nil for _, t := range ctx.tokens { // 毎回すべて計算 ctx.ks = append(ctx.ks, projK(t)) ctx.vs = append(ctx.vs, projV(t)) } return attend(projQ(tok), ctx.ks, ctx.vs) } KV cache: Off（全部compute） 毎ステップ、過去トークン分のK・Vを作り直している 22
23. K・V計算の冗長性 • 生成が進んでも、過去トークンのK・Vは変わらない（新しく計算するのは 新トークンの分だけ） • なのに素朴な実装は、毎ステップK・Vを作り直している → ムダ • 次のブロックのK・Vは前の出力から作るので、実際は次ブロックへ渡す 出力も作り直している • 一度計算したK・Vを保存して使い回せばよい ＝ KV cache 23
24. KV cache type Ctx struct{ tokens []Token; ks, vs []Vec } // Attention操作（関連度 → 重み → 足し合わせ） func attend(q Vec, ks, vs []Vec) Vec { w := softmax(scores(q, ks)) return weightedSum(w, vs) } // KV cache を用いた実装 func step(ctx *Ctx, tok Token) Vec { ctx.tokens = append(ctx.tokens, tok) ctx.ks = append(ctx.ks, projK(tok)) // 新トークンぶんだけ追記 ctx.vs = append(ctx.vs, projV(tok)) // 過去は再計算しない return attend(projQ(tok), ctx.ks, ctx.vs) } KV cache: On（過去はreused） K・V生成を「追記」に変えるだけ。ブロックに流すのは最新トークンのみ 24
25. 遠いトークンの必要性 • 全トークンとの関連度合いを見なくても、直近トークンだけで多くは事足り る（という仮定） • 直近wトークンだけ見れば、計算量が減る ＝ Sliding window Attention • KV cacheも直近w件だけ残せば、容量が一定になる • 例：7B級・fp16で約0.5 MB/トークン → 8kで約4 GB、w=1024なら約 0.5 GB 25
26. Sliding window Attention // KV cache を用いた実装に、Sliding window を適用 func step(ctx *Ctx, tok Token, w int) Vec { ctx.ks = append(ctx.ks, projK(tok)) ctx.vs = append(ctx.vs, projV(tok)) if len(ctx.ks) > w { // 直近 w 件だけ残す ctx.ks = ctx.ks[len(ctx.ks)-w:] ctx.vs = ctx.vs[len(ctx.vs)-w:] } return attend(projQ(tok), ctx.ks, ctx.vs) } Window=3（直近だけ残す） KV cacheに「直近w件だけ残す」を足すだけ。容量・計算が一定に 26
27. 実用モデルを支える発展的な方式 • KV cacheはもはや標準で、様々な推論高速化の方式が利用されている • KV cacheの共有（GQA）や圧縮（MLA）、量子化による、さらなる容量削 減 • 過去を固定サイズの状態に畳み込む線形アテンションと、忘却機構による高 度化 • 線形アテンションと通常のAttentionを組み合わせるハイブリッド構成 • FlashAttentionやPagedAttentionなど、GPU・推論サーバー側の高速化 27
28. 4. まとめ
29. まとめ • トイモデルとGo言語でTransformerの仕組みを概観した • Attentionによって、あるトークンの表現が過去トークンとの組み合わせで 得られることを示した • この機構の実用化のために、計算量やメモリ使用量を削減する方式があるこ とも示した • これらの「気持ち」を掴むことが、サービング性能を考える第一歩 • 本日のトイモデルは「ロリポップ！デプロイナウ」で公開しています • lolipop.jp/deploy-now 29