review13_qa: review13 事前確認 3 点への回答

作成日: 2026-08-13 対象: review13_q.md の確認項目 1〜3

アーキテクトからの確認項目(review13_q)

１）zxell_prep/train_compare_tokenizers.py について
TRAIN_CHAR_BUDGET の各言語の文字数上限の算定根拠はどういったことですか？

２）roadmap.md について
L(500M)の学習に使うクライアントですが、RTX2060だと学習可でしょうか？RTX2060×１台（＋ GTX1050×１台）だと計算期間の試算は何日くらいになるでしょうか？

３）model_architecture.drawio について
学習のフローはこの図でよく分かりました。モデル完成後のイメージになりますが、たとえば質問に対する回答を行うフローという観点からモデルのアーキテクチャを図示（別ファイルの*.drawio）するとどうなりますか？

1) TRAIN_CHAR_BUDGET(各言語の文字数上限)の算定根拠

結論から言うと、厳密な最適化式から出した値ではなく、次の 3 つの制約・方針を満たすように置いた設計値です(きりのよい数字なのはそのためです)。妥当性は後段の評価(48k/64k の chars/token 計測)で事後確認しています。

根拠 1: 日本語を「自然比 1.5% → 約 19%」に増量する(最重要)

フェーズ0 実測では、記事数比で ja は 10.6% ある一方、文字数比ではわずか 1.5% です(本文が平均 472 字と短いため)。BPE の語彙学習は文字数ベースで進むので、自然比のまま学習すると 48k 語彙のうち日本語サブワードにほとんど枠が割り当てられず、「1 文字 = 1 トークン」に近い非効率なトークナイザになります。

そこでトークナイザ学習に限り ja を約 13 倍(1.5% → 19.1%)に増量しました。低リソース言語を増量サンプリングするのは多言語トークナイザの定石です(XLM-R などと同じ考え方)。効果は報告のとおりで、ja 1.95 字/トークン・意味単位の分割(「政府は/水曜/日に/…」)が得られています。

根拠 2: en/de/fr は「順位は保ちつつ差を縮める」平坦化

en をそのまま自然比で入れると de/fr の語彙が痩せるため、欧州 3 言語の中でも 65:23:10 → 44:31:25 に平坦化しています(温度サンプリングでいう α ≈ 0.3 相当の強めの平坦化)。en>de>fr の順位自体は残しているので、コーパスの主力である en の圧縮効率を大きくは損ねません(実測 en 4.19 字/トークンは英語トークナイザとして標準的な水準です)。

根拠 3: サンプル在庫と学習コストの上限

• 各言語の上限はサンプルに実在する文字数の範囲内に置いています(在庫: en 830M / de 292M / fr 129M / ja 112M 字)。fr の 70M は在庫 129M の約半分、ja の 65M は在庫 112M に対する実質「使えるだけ使う」に近い水準です(コードのコメント「65M 字なければ有るだけ使う」はこの保険です)。
• 合計 約 340M 字は、GPU なしのサーバ機で SentencePiece BPE が現実的に回る規模として設定しました(実測: 1 モデル約 4 分で学習完了。仮に全在庫 1.36G 字を使っても品質はほぼ変わらず、時間とメモリだけ増えます)。

なお、この配分はトークナイザ学習専用です。モデル本体の学習データの言語構成は自然比のまま(確定事項 11)で、そちらとは独立です。

2) RTX 2060 で L(500M)は学習可能か・計算期間の試算

結論

• 学習可能です(標準的な RTX 2060 = VRAM 6GB を想定。省メモリの工夫は必須ですが、roadmap 3.3 の「フェーズ3 ゲート: VRAM 6GB 以上」をちょうど満たす 1 台目になります)。
• 計算期間の試算は 1 エポック(6.1B トークン)で約 33〜53 日、Chinchilla 適正の約 10B トークン(≈1.6 エポック、review13 の「2 エポック弱」)まで回すなら約 53〜87 日 ≒ 2〜3 か月です。
• GTX 1050 は L の学習には参加できない(VRAM 2GB では勾配・optimizer 状態が載らない)ため、日数は RTX 2060 単独で決まります。仮に計算だけ寄与できたとしても実効 +0.5 TFLOPS(+8〜12%)で 1 週間短縮程度です。実際の役割分担としては、GTX 1050 に eval・検証・前処理タスクを持たせて RTX 2060 を学習専任にするのが効きます。

VRAM 6GB に載るか(内訳試算)

fp16 混合精度 + 8bit optimizer + 勾配チェックポインティング + 小マイクロバッチ(1〜2)× 勾配蓄積、の構成で:

ぎりぎりですが収まる計算です。溢れる場合は optimizer 状態の CPU 退避で確実に収まります(速度は落ちます)。注意点として、Turing 世代は bf16 非対応なので fp16 + loss scaling で回すことになり、発散の監視が必要です(S/M で先にハイパラを固める段取りどおりなら大きなリスクではありません)。もし手に入るのが RTX 2060 の 12GB 版なら、バッチを増やせて上記の試算より 1〜2 割速くなる見込みです。

期間試算の根拠

roadmap 3.3 と同じ「学習 FLOPs ≒ 6 × パラメータ × トークン」で:

• RTX 2060 は Tensor Core あり。fp16(FP32 累積)ピーク ≈26 TFLOPS、MFU を 15〜25% と置くと 実効 4〜6.5 TFLOPS(GTX 1050 の実効 0.5 TFLOPS の約 8〜13 倍)。MFU を GTX 1050 の 30% より低めに置くのは、6GB 制約で小バッチになることと勾配チェックポインティングの再計算オーバーヘッドを織り込むためです。

roadmap 3.3 の「GTX 1050×2 台で約 230 日(非現実的)」が、RTX 2060 1 台で 2〜3 か月に変わるイメージです。同級 GPU を計 3 台にできれば(DiLoCo の並列化効率 8 割と見て)1 か月前後まで縮みます。なお 2〜3 か月の連続稼働になるので、チェックポイント定期保存(フェーズ4 計画済み)が前提です。

3) 質問 → 回答(推論)フローのアーキテクチャ図

作成しました: model_inference.drawio(model_architecture.drawio と同じ配色・粒度で、drawio / diagrams.net で開けます)。

図の要点は次のとおりです。

• ネットワークもトークナイザも学習時と完全に同一で、変わるのは「使い方」だけです。学習時は正解列を一括入力して全位置の次トークン予測 loss を並列計算(teacher forcing)→ 重み更新、推論時は重みを固定し、自分の出力を次の入力に継ぎ足しながら 1 トークンずつ逐次生成します。図はこの「生成ループ」を中央レーンに置いています。
  • ループ: 現在のトークン列 → Embedding → Transformer × N → 最終位置の次トークン確率 → サンプリング(temperature / top-p)で 1 個決定 → 列末尾に追加 → EOS か最大長まで繰り返し
  • 高速化の要は KV キャッシュ(過去トークンの K/V を保存し、毎回の forward は新規 1 トークン分だけ計算)
• 左レーンはサービング側の流れです: 質問 → デモ UI / 推論 API(フェーズ4 実装)→ SFT と同じテンプレートでプロンプト組み立て → sp_bpe_48k で encode → 生成ループ → decode → 回答表示。
• 前提として 1 点だけ: 事前学習のみのベース LM は「続きを書く」能力しか持たないため、質問に回答という形で応えるにはフェーズ4 の SFT(要約 SFT + QA テンプレート)を経る必要があります。図では紫のノートにこの旨を明記しました。
• 配置の目安も図中に入れています: L(500M)の推論は fp16 重み ≈1GB + KV キャッシュ ≈0.25GB(ctx 2048 フル時)なので、GTX 1050(2GB)でも推論は可能です(学習と違い勾配・optimizer 状態が不要なため)。サーバ機の CPU 推論も動作はしますが低速です。

図を開いて分かりにくい箇所があれば、次回レビューで加筆します。