zxell.ai ロードマップ策定のための整理資料

作成日: 2026-08-10 対象リポジトリ: zxell-ai/zxell（現状: FastAPI によるタスク配布サーバの雛形 zxell_server のみ）

本資料は「分散処理に特化した独自 AI モデルをイチから作る」というプロジェクト目的に対して、ロードマップを策定するために必要な事項――前提の定量把握、設計方針の選択肢と推奨案、課題・リスク、フェーズ分けの骨子、未決事項――を整理したものである。

1. プロジェクト目的の再整理と成功基準

1.1 目的の分解

プロジェクト定義を分解すると、達成すべきことは次の 3 層になる。

モデル層: ニュースコーパス（5 年分・40〜45GB・英独仏日）を学習した言語モデルをイチから（事前学習済みモデルを使わずに）作る。
分散層: 低スペックなクライアント複数台に処理を分散させ、ハイエンド GPU サーバなしで学習を成立させる（プロジェクトの独自性の核）。
知見層: 「どのくらいの知能になったか」を体験・計測し、有意・定量的な知見（データ量×計算量×分散方式 → 能力の関係）を得る。

重要なのは、このプロジェクトの成果物は「モデルそのもの」だけではなく 「低予算・分散環境でどこまで到達できるかの定量的な知見」 である点。したがって、比較対象（ベースライン）と計測方法を最初から設計に組み込む必要がある。

1.2 成功基準（案）

区分	指標	目標イメージ
モデル能力	検証データのパープレキシティ	単一マシンで学習した同規模モデルと同等（劣化 10% 以内）
モデル能力	新規記事の要約品質（ROUGE-L / BERTScore、人手評価）	手元の「記事＋要約」ペアを正解として定量評価
モデル能力	人物・出来事に関する QA	コーパス内の事実に関する自作 QA セットで正答率を計測
分散効率	クライアント N 台でのスループット向上率	台数に対するスケーリング曲線を取得（線形が理想）
分散効率	通信量 / 学習トークン	同期式データ並列比で 1/100 以下（後述の低通信方式で達成）
運用	クライアント離脱・故障時の学習継続	任意のクライアントが落ちても学習が止まらない
可視化	処理状況ダッシュボード	タスク・クライアント・損失曲線・スループットをリアルタイム表示

「単一マシンで学習した同規模モデル」との比較がプロジェクトの科学的価値を決めるため、 小規模モデルでの単一マシンベースラインを必ず先に作る（フェーズ 1 参照）。

2. 前提の定量把握（ここが設計のすべてを決める）

2.1 データ量 → トークン数

テキスト 40〜45GB。英語が過半数（約 4 バイト/トークン）、独仏も同程度、日本語は UTF-8 で 3 バイト/文字・約 1.5〜2 文字/トークン。
ざっくり 8〜12B（80〜120 億）トークン と見積もられる。重複除去・クリーニング後は 2〜3 割減る想定で、実効 6〜9B トークンを作業仮説とする。
実測はフェーズ 0 の最初のタスク（トークナイザ学習後に正確に数える）。

2.2 トークン数 → 適正モデル規模

Chinchilla 則（パラメータ数 ≒ トークン数 ÷ 20）に従うと、 6〜9B トークンに対する計算最適なモデルは 300M〜500M パラメータ級。これは GPT-2 Medium（355M）〜 GPT-2 Large（774M）に相当する。
推論をクライアントの低スペック機でも動かしたいなら、より小さいモデル（100〜300M）を長めに学習する「過学習気味・推論効率重視」の LLaMA 型の割り切りも合理的。
結論（推奨）: 段階的に 3 サイズを用意する。
- S: 約 30M（パイプライン検証・スモークテスト用。1 台でも数時間で回る）
- M: 約 125M（GPT-2 Small 相当。分散方式の比較実験の主力）
- L: 約 350〜500M（最終ターゲット。全データ投入）

2.3 必要計算量と「台数 × 日数」の試算

学習 FLOPs ≒ 6 × パラメータ数 × トークン数で概算する。

モデル	トークン	総FLOPs	実効4 TFLOPS×1台¹	×5台	×10台
S: 30M	3B	5.4e17	約 1.6 日	約 8 時間	約 4 時間
M: 125M	8B	6.0e18	約 17 日	約 3.5 日	約 1.7 日
L: 500M	8B	2.4e19	約 70 日	約 14 日	約 7 日

¹ 「実効 4 TFLOPS」はミドルレンジ GPU（RTX 3060 / 4060、GTX 1660 等）が MFU 30〜40% で持続的に出せる現実的な値。RTX 4070 クラスなら 2〜3 倍速い。

この試算から導かれる設計上の結論:

L モデルは分散なしでは現実的でない（1 台で 2 か月超）。 → 分散化はプロジェクトの飾りではなく必須要件であり、目的と手段が整合している。
CPU のみのクライアントは学習の主力にはなれない （実効 ~100 GFLOPS では GPU の 1/40 以下）。 → CPU クライアントには前処理・データ検証・評価・冗長検算タスクを割り当てる「役割分担型」の分散設計にする（3.7 参照）。
参加クライアントの目安: GPU 搭載機 5〜10 台が集まれば L モデルが数週間で学習可能。

2.4 通信量の見積り（分散方式選定の根拠）

500M パラメータの勾配は fp16 で約 1GB。同期式データ並列（毎ステップ全勾配交換）は家庭用回線（上り 10〜50Mbps）では 1 回の同期に数分〜数十分かかり、完全に成立しない。
したがって「ローカルで H ステップ学習 → 差分（擬似勾配）だけを低頻度で送る」方式が唯一の現実解。H=100〜500 とすれば通信は 1/100〜1/500 になり、さらに 8bit 量子化＋Top-k スパース化で差分を 100〜250MB 程度に圧縮できる。 → 30〜60 分に 1 回の同期なら家庭用回線で運用可能。

3. 設計方針案

3.1 全体アーキテクチャ（ハブ＆スポーク型）

プロジェクト定義の「統括サイトから GET し、結果を POST する」構図をそのまま採用する。ボランティアコンピューティング（BOINC / Folding@home）と同じ構造であり、 NAT 越え不要・クライアント実装が単純・統制が効く、という利点が P2P 型（Petals / SWARM 等）より本プロジェクトの規模に合っている。

[中央サーバ（統括サイト）]
  ├─ コーディネータ API（FastAPI）: タスク割当 / 結果受領 / クライアント管理
  ├─ パラメータサーバ: 最新モデル重みの保持・外側最適化（差分の集約適用）
  ├─ オブジェクトストレージ: データシャード / 重みスナップショット / チェックポイント
  ├─ メタデータ DB（PostgreSQL）: タスク・クライアント・メトリクスの状態管理
  └─ ダッシュボード（可視化）

[クライアント（複数・低スペック・異種混在）]
  ├─ GPU ワーカー: シャードを GET → ローカル学習 H ステップ → 差分を POST
  ├─ CPU ワーカー: 前処理 / トークン化 / 検証 / 評価タスク
  └─ （任意）外部データ収集ワーカー: 外部サーバから GET した結果を POST（制約 3 の拡張）

3.2 分散学習方式の比較と推奨

方式	概要	通信	異種混在耐性	離脱耐性	本件適合
同期データ並列 (DDP)	毎ステップ全勾配交換	極大	×	×	不可（2.4 参照）
非同期パラメータサーバ	勾配を随時送信、鮮度劣化あり	大	△	○	△
Local SGD / DiLoCo 型	H ステップ局所学習→差分集約（外側は Nesterov 等）	小（1/H）	○	○	◎ 推奨
フェデレーテッド平均 (FedAvg)	重み平均。DiLoCo の単純版	小	○	○	○（第一段階として）
Branch-Train-Merge	言語/カテゴリ別に独立学習→統合	極小	◎	◎	○（言語別で併用候補）
パイプライン分割 (Petals/SWARM 型)	モデルを層で分割し中継	中	△	△	△（500M 級では不要）

推奨: DiLoCo 型（Local SGD ＋外側モーメンタム）を本命とする。

各クライアントは最新重みを GET → 手元シャードで H ステップ（AdamW）学習 → 重み差分 Δ を圧縮して POST。
サーバは複数クライアントの Δ を集約し、外側最適化（Nesterov モーメンタム）でグローバル重みを更新。DeepMind の DiLoCo 論文で、通信 1/500 でも同期学習に匹敵する品質が示されており、本件の回線制約に正面から合致する。
段階導入: まず FedAvg（単純平均）で MVP を動かし、外側最適化・圧縮を順次追加。この「方式の差し替えで品質がどう変わるか」自体が本プロジェクトの知見になる。
補助戦略として、日本語など少数言語は Branch-Train-Merge （言語別サブモデル→統合 or 言語別に得意なエキスパート化）を実験候補に残す。

取り組むべき研究課題（＝知見の源泉）:

非 IID 問題: クライアントごとに担当シャードの言語・カテゴリが偏ると平均化が劣化する。 → シャード割当をランダム化し「各クライアントが全言語をまんべんなく見る」設計にする。
ステイルネス: 遅いクライアントの Δ は古い重み基準になる。 → Δ に基準重みバージョンを添付し、古すぎる Δ は減衰係数を掛ける or 破棄。

3.3 通信・タスク設計（現行サーバの発展形）

現行 zxell_server の GET/POST 構造を活かしつつ、タスクの粒度と種類を再定義する。

タスク粒度: 現状は「記事 1 件」だが、学習では細かすぎる。「シャード（トークン化済み・数十〜数百 MB）× ローカルステップ数 H」を 1 タスクの単位にする。
タスク種別（type フィールドで区別）: 1. preprocess: 生記事のクリーニング・トークン化（CPU 向け） 2. train: シャードでの局所学習と Δ 返送（GPU 向け） 3. eval: 検証シャードでの損失・要約品質計測（CPU/GPU） 4. verify: 他クライアントの結果の抜き打ち再計算（信頼性担保、3.7 参照）
API（案）:
- POST /api/clients/register … クライアント登録（スペック自己申告＋簡易ベンチ結果）
- GET /api/tasks/next?client_id= … 能力に応じたタスク払い出し（リース期限付き）
- GET /api/weights/{version} … 重みスナップショット取得（実体はオブジェクトストレージの署名付き URL）
- POST /api/results … Δ / 前処理結果 / 評価結果の提出（基準重みバージョン必須）
- GET /api/status … ダッシュボード用の全体状況
リース方式: タスクには期限を付け、期限切れは自動で pending に戻す（現状の「processing のまま永久ロック」問題の解消）。
重み配布の帯域対策: 全量 GET は 0.6〜1GB/回。同期間隔を長めに取る、差分配布（前バージョンとの diff）、将来的には BitTorrent 的なクライアント間配布も検討。

3.4 モデル設計

アーキテクチャ: GPT 系デコーダオンリー Transformer（自前実装）。 RoPE / RMSNorm / SwiGLU 等の現代的構成を採用しつつ、規模は 2.2 の S/M/L。コンテキスト長は 1024（S/M）→ 2048（L）。ニュース記事の大半は 2048 以内に収まる。
トークナイザ: 英独仏日の混合コーパスで BPE（または Unigram）を自前学習。語彙 48k〜64k。日本語の圧縮効率を検証データで確認する（多言語トークナイザの設計自体が知見テーマの一つ）。
学習タスク: 次トークン予測による事前学習 →「記事＋要約」ペアで要約 SFT（手元データがそのまま高品質な教師データになる。この資産は本プロジェクトの大きな強み） → QA は「コーパスから自作した QA セット」で評価（生成は補助ツールを検討）。
画像（サムネイル・メイン画像）: 第 1 期スコープから除外を推奨。マルチモーダル化は計算量・設計複雑度を大きく増やす。将来フェーズの拡張候補（キャプション生成 / CLIP 型対照学習）として温存する。

3.5 データパイプライン

クリーニング: HTML 残骸・ボイラープレート（定型フッタ等）除去、文字コード正規化。
重複除去: ニュースは通信社配信の重複が非常に多い。MinHash / SimHash による近似重複除去は品質への影響が大きく、必須工程とする。
正規化・統計: 言語判定、言語別・カテゴリ別・年別の分布把握（可視化対象）。
トークン化 → シャーディング: 固定長シーケンスにパックし、数十〜数百 MB のシャードに分割してオブジェクトストレージへ。シャードには checksum とメタデータ（言語構成・トークン数）を付与。
分割: 学習/検証/テストを時系列も考慮して分離（例: 最終数か月をテストに回すと「新しい記事の要約」評価が自然にできる）。

この前処理自体を preprocess タスクとして分散させれば、分散基盤の最初の実運用テストになる（学習より失敗コストが低い）。

3.6 サーバ実装: 現行プロトタイプの評価と改修方針

現行 zxell_server（FastAPI + SQLAlchemy + PostgreSQL）は方向性として正しい。ただしロードマップ上、以下の改修が必要:

#	現状	問題	改修方針
1	タスク＝記事 1 件（TrainingData）	学習単位として細かすぎ、DB が 40GB の本文を抱える	本文はオブジェクトストレージのシャードへ。DB はメタデータとタスク状態のみ
2	`status=processing` に期限なし	クライアント離脱でタスクが永久ロック	リース期限＋期限切れ自動再キュー
3	`post_result` が result_json を破棄	演算結果が残らない	結果の永続化・検証・集約処理の実装
4	認証なし	誰でも偽結果を POST できる	クライアント登録制＋トークン認証（最低限 API キー）
5	DB 接続情報がハードコード	秘匿情報の漏えい・環境差異	環境変数化（pydantic-settings）
6	`orm_mode`（Pydantic v1 記法）	v2 では動かない	`from_attributes` へ移行、依存関係を固定
7	重み配布の仕組みなし	学習の分散に必須	重みバージョン管理＋署名付き URL 配布
8	排他制御なし（`filter().first()`）	複数クライアントに同一タスクを二重払い出し	`SELECT ... FOR UPDATE SKIP LOCKED` 等で排他払い出し

中央サーバは高性能 GPU を必要としない（集約と配布が主）ため、安価な VPS ＋オブジェクトストレージ（S3 互換）で賄える。 帯域（重み配布 × クライアント数）がコストの主変数になる点だけ注意。

3.7 クライアント設計と信頼性

配布形態: Python パッケージ（pip install zxell-client 一発で参加）を第一候補に。 PyTorch ベース。将来、ブラウザ参加（WebGPU）は魅力的だが第 1 期では見送り。
能力申告と自動ベンチ: 初回登録時に簡易ベンチマークを走らせ、 GPU/CPU・VRAM・回線速度に応じてタスク種別と H（ローカルステップ数）を調整する。
結果の検証（悪意・バグ対策）: ボランティア型分散の古典的課題。 1. Δ のノルム・統計量の外れ値検知（壊れた Δ の混入防止） 2. 抜き打ち二重計算（同一タスクを複数クライアントに与えて突合） 3. 検証損失の継続監視（Δ 適用後に悪化したらロールバック＋提出元の信頼度を下げる）
- クライアントごとに信頼スコアを持ち、スコアに応じて検証頻度を変える。
外部サーバから GET したデータの POST（制約 3 の「なおよい」要件）: クライアント経由の新規データ収集はアーキテクチャ的には preprocess タスクの変種として自然に載る。ただし収集対象サイトの規約・著作権の確認が先（5 章）。

3.8 可視化（要件 4 への対応）

2 つの異なる可視化要求を区別して設計する。

運用可視化（処理状況） — 必須要件:
- タスクキューの状態（pending / processing / done / failed の推移）
- クライアント一覧（稼働状況・処理速度・信頼スコア・地域）
- 学習曲線（グローバル損失・検証パープレキシティ・言語別損失）
- スループット（全体 tokens/sec、通信量、重みバージョンの進行）
- 実装: サーバに /api/status を設け、フロントは軽量な Web ダッシュボード（もしくは Grafana + Prometheus）。フェーズ 2 の MVP から最小構成で組み込む （後付けにすると分散システムのデバッグが不可能になるため）。
モデル内部の可視化（教育・体験） — 参考挙例「Spreadsheets are all you need」の系譜:
- あのプロジェクトは GPT-2 の全計算をスプレッドシート上で追える教材。本件では「学習済みモデルの 1 推論を層ごとに追える簡易ビューア」「アテンションの可視化」「チェックポイント間の出力品質の変化を並べる年表」など、 “どのくらいの知能になったか”を体験する UI としてフェーズ 4 で実装する。
- S モデル（30M）なら重みを CSV/スプレッドシートに書き出して同様の教材化をすることも現実的。

4. 評価計画（「有意・定量的な知見」の担保)

共通ベンチ: 検証パープレキシティ（言語別に分解して記録）。
要約: テスト期間の記事に対し生成要約 vs 付属要約で ROUGE-1/2/L・BERTScore。多言語なので言語別に集計。少数サンプルの人手評価も併用。
QA: コーパス内の人物・出来事から QA セットを構築（数百問規模）し、正答率と「知らないことを知らないと言えるか」を計測。
分散方式の比較実験（本プロジェクト固有の知見）:
- 同一 M モデル・同一データで、(a) 単一マシン学習、(b) FedAvg、(c) DiLoCo 型、(d) 同期間隔 H・クライアント数・圧縮率を振った条件、を比較。
- 「通信量 1/100 で品質劣化はどの程度か」「台数スケーリングの限界」を曲線で示す。
チェックポイント考古学: 学習途中のスナップショットを保存し、能力（要約・QA・言語別）の獲得順序を可視化する（3.8 の体験 UI と接続）。

5. 課題・リスク一覧

5.1 法務・データ（最重要。技術より先に決める）

省略: 法務・データのリスク分析の表(決定事項は review01 の回答を参照)

5.2 技術

リスク	内容	対応方針
非 IID・平均化劣化	クライアント別データ偏りで集約が劣化	シャードのランダム割当、外側モーメンタム、M モデルでの事前検証
ステイル勾配	遅延クライアントの古い Δ	重みバージョン添付・減衰・破棄ルール
通信帯域	重み配布 1GB/回 × 台数	同期間隔の調整、差分・量子化配布、CDN/署名付き URL
不正・故障クライアント	偽 Δ・壊れた Δ で学習破壊	外れ値検知・抜き打ち検算・ロールバック（3.7）
学習の発散	低頻度同期特有の不安定性	S/M モデルでハイパラ探索してから L に進む段取りを厳守
再現性	非同期分散は本質的に非決定的	シード・タスク割当・Δ 履歴の完全ログ化（可視化とも接続）
VRAM 制約	低スペック GPU（6〜8GB）で L モデル学習	混合精度・勾配チェックポインティング・小バッチ＋勾配蓄積で 500M は搭載可能。それ以上は当面狙わない

5.3 運用・体制

リスク	内容	対応方針
クライアントが集まらない	分散の前提が崩れる	まず手持ち・知人の数台で closed 運用。参加の見返り（ダッシュボードでの貢献可視化、クレジット）を設計
中央サーバ費用	帯域・ストレージ課金	安価 VPS + S3 互換で開始し、帯域を監視。試算をフェーズ 0 で実施
電気代・稼働時間	ボランティア機の実稼働率は低い	リース方式で断続参加を前提化。夜間のみ参加等を許容する設計
スコープ肥大	マルチモーダル・大規模化への誘惑	本資料のフェーズゲート（各フェーズの判断ポイント）で統制

6. ロードマップ骨子（フェーズ案）

各フェーズに「ゴール」「主な成果物」「次へ進む判断ポイント」を定義する。期間は GPU クライアント 3〜5 台参加を仮定した目安。

フェーズ 0: 定量把握と法務整理（2〜4 週間）

データ棚卸し: 実トークン数・言語/カテゴリ/年分布・重複率の計測とレポート化
法務方針の決定（5.1）: closed 運用の範囲、配布形態、公開方針
コスト試算: サーバ・ストレージ・帯域の月額見積り
判断ポイント: データ品質と法務方針が確定していること

フェーズ 1: 単一マシンベースライン（3〜6 週間）

トークナイザ学習、前処理パイプライン v1、S モデル（30M）の単一 GPU 学習
M モデル（125M）を 1 台で回し、損失曲線・要約品質のベースラインを記録
評価ハーネス（パープレキシティ・ROUGE・QA 雛形）の整備
判断ポイント: S/M モデルがまともな文を生成し、評価パイプラインが自動で回ること
※このフェーズの成果が以後すべての比較基準になる。省略禁止

フェーズ 2: 分散基盤 MVP（4〜8 週間）

zxell_server 改修（3.6 の表の全項目）: リース・認証・結果永続化・シャード配布
クライアント v1（train / preprocess タスク対応）
FedAvg による S モデルの分散学習を 2〜3 台で成功させる
運用ダッシュボード v1（タスク・クライアント・損失曲線）
判断ポイント: クライアントを 1 台落としても学習が継続し、単一マシン学習と同等の損失に到達すること

フェーズ 3: 低通信方式の実装と比較実験（4〜8 週間）

DiLoCo 型（外側 Nesterov）＋ Δ 圧縮（8bit / Top-k）の実装
M モデルで方式比較（4 章の実験マトリクス）を実施し、中間レポート化
検証機構（外れ値検知・抜き打ち検算・信頼スコア）の実装
判断ポイント: 通信 1/100 条件で単一マシン比の品質劣化が許容内（目安 10%）

フェーズ 4: 本番学習と体験系（6〜12 週間）

L モデル（350〜500M）の全データ分散学習（チェックポイントを定期保存）
要約 SFT（記事＋要約ペア）、推論 API・デモ UI（新規記事を貼ると要約が返る）
QA 評価セット構築と計測、チェックポイント考古学の可視化
モデル内部可視化（Spreadsheets 系譜の体験 UI、3.8-2）
判断ポイント: 成功基準（1.2）の計測が完了していること

フェーズ 5: 知見の公開と拡張判断

技術レポート公開（分散方式比較・スケーリング曲線・多言語の学び）
拡張の意思決定: 参加者の一般公募（法務整理済みの場合）、画像対応、クライアント経由データ収集、ブラウザ（WebGPU）クライアント等

7. 未決事項（ロードマップ確定前に決めるべきこと）

法務方針（5.1）: closed / open どちらで始めるか。データ配布形態の確定。【最優先】
初期クライアント台数と内訳: 手持ち・調達可能な GPU 機は何台か（2.3 の試算の前提。L モデルの現実性を左右する）。
中央サーバの予算上限: 月額いくらまで許容するか（帯域設計に直結）。
最終モデルサイズの目標: 計算最適（〜500M）か推論効率重視（〜300M）か。
画像データの扱い: 第 1 期除外の承認（3.4 の推奨どおりでよいか）。
フレームワーク方針: 学習コア自前実装の範囲（「イチから」の解釈: モデルは自前実装、PyTorch 等の基盤利用は許容、と仮定している）。
成果物の公開範囲: コード / 重み / データ統計 / レポートのどこまでを公開するか。

8. 参考文献・参考プロジェクト

DiLoCo: Distributed Low-Communication Training of Language Models（低頻度同期の本命方式）
Local SGD / FedAvg（Federated Averaging）: 局所学習＋平均化の基礎
Branch-Train-Merge: ドメイン別独立学習と統合
Hivemind / Petals / SWARM parallelism: ボランティア型・P2P 型分散学習の先行実装
BOINC / Folding@home: ボランティアコンピューティングの運用知見（検証・信頼スコア）
Chinchilla（Training Compute-Optimal Large Language Models）: モデル規模の決め方
GPT-2 / LLaMA 系の公開実装（nanoGPT 等）: 自前実装の参照
Spreadsheets are all you need（https://spreadsheets-are-all-you-need.ai/gpt2/）: モデル内部可視化・教材化の参考（要件 4 の後半に対応）