Aelion Twelve（A12）
スーパーマネージド PTZ テクノロジー ホワイト ペーパー

まとめまとめ

A12 は、異種 GPU コンピューティング リソース用のスケジューリングおよびサービス プラットフォームです。クラウド GPU クラスター、プロフェッショナル IDC とアイドル状態のワークステーション/エッジ GPU を組み合わせます。アクセス、検証、測定、スケジューリングを統合し、タスクの特性に応じて相互接続された高速の集中クラスターで高い通信強度で大規模なモデルのトレーニングを維持します。低通信強度の推論、検索拡張 (RAG)、効率的なパラメーター微調整 (LoRA/QLoRA)、およびバッチ処理タスクをよりコスト効率の高い分散リソースに割り当て、モデル サービス (MaaS)、エージェント アプリケーションを提供します。 (AaaS) と、統合されたタスク インターフェイス上の完全な開発者ツール チェーン。

このホワイト ペーパーでは、現在検証されている設計、または明確なエンジニアリング パスを持つ設計のみについて説明し、次の 3 つの執筆規律に準拠しています。すべてのパフォーマンス指標は、実際の測定結果ではなく設計目標です。すべての安全機構には、その境界と故障状態も記述されています。プロジェクトの主題と歴史に関するすべての情報は開示リストの形式で提示され、開示前に信頼性の根拠として使用されることはありません。

キーワード: 異種コンピューティング能力のスケジューリング。信頼できるリソースの検証。ハイブリッドコンピューティング電源。モデルサービス。エージェントアプリケーション

初め第1章 産業背景と問題定義

1.1 AIコンピューティング電源の構造的現状

生成 AI のワークロードは急速に多様化しています。基本モデルの事前トレーニングとフルパラメータの微調整には高周波数の勾配同期が必要であり、必然的に NVLink/InfiniBand レベルのクラスター相互接続に依存します。一方、推論、埋め込み、再ランク、RAG データ処理、LoRA/QLoRA 微調整などのタスクは、通信強度が 1 ～数桁低く、単一マシンまたは小規模クラスター上の閉ループで完了できます。 2 種類の負荷はインフラストラクチャに対する要件が大きく異なりますが、長い間「同じ供給方法」によって提供されてきました。

同時に、コンピューティング電源の供給側は 3 層構造になります。超大規模クラウド プラットフォームは、標準化されているものの比較的高価なマネージド コンピューティング パワーを提供します。プロフェッショナル AI IDC と企業所有のクラスターは高速相互接続を備えていますが、使用率は変動します。世界中には依然として消費者グレードおよびワークステーション グレードの GPU が数千万台存在しますが、それらは信頼できるアクセスおよびスケジューリング メカニズムが欠如しているためにアイドル状態になっています (この規模は、正確な統計ではなく、公的業界標準に基づいた推定参考値です。この章の業界データは、構造的な判断を説明するために使用されています)。問題は「コンピューティング能力が足りない」ことではなく、さまざまな物理的条件におけるコンピューティング能力が適切なワークロードに編成されていないことです。

1.2 混合供給の組織効率の問題

上記の 3 つの供給層を統合オーケストレーションするには、次の 4 つのエンジニアリング上の問題を解決する必要があります。

• 異種混合の適応: NVIDIA、AMD、その他のアクセラレータ カードのドライバー、ランタイム、オペレーター ライブラリの違いにより、コストをかけずに上位層のタスクを移行することが困難になります。 「完全に無意味な統一」を主張する解決策は、適応という実際の作業負荷を回避することになります。
• 信頼できるリソース: オープンアクセス環境では、リソースの偽装、ビデオ メモリのオーバーブッキング、および繰り返しの宣言が行われる可能性があります。ノードの自己報告情報のみに依存するだけでは、スケジューリングに必要な信頼を確立するには不十分です。
• SLA と弾力性の矛盾: アイドル状態のエッジ GPU のオンライン速度は不安定で、エンタープライズ レベルのオンライン サービスを直接実行すると可用性の崩壊につながります。集中リソースを完全に使用することで、アイドル状態のコンピューティング能力の使用が放棄されます。
• 経済的持続可能性：トークンの排出補助金の供給だけに依存するモデルは、実需要が不十分な場合、「排出量販売圧力－インセンティブの失敗」のサイクルに陥ることになる。

1.3 A12の解決策（概要）

上記の問題に対する A12 の解決策は 4 つのポイントに要約でき、その実現可能性の境界は対応する章で 1 つずつ説明されています。

• 通信量に応じて分割されたスケジューリングアーキテクチャ：通信量の多いタスクは集中クラスタに固定され、通信量の少ないタスクは分散リソースに移動されます（第3章、第5章）。
• 階層化されたリソースの信頼性検証システム: 「ステートメント検証 + 実際の測定チャレンジ + ランタイム テレメトリ + タスク レベルの検証 + 過去の評判」の組み合わせで信頼を確立し、単一の「絶対的な偽造防止」メカニズムには依存しません (第 4 章)。
• デュアルトラック供給モデル: 柔軟なベストエフォート モードは割り込み可能なタスクを実行し、専用保証モードは SLA サービスを実行します。この 2 つは物理的に分離されています (第 4 章と第 5 章)。
• 実際のサービス収益に基づいた経済モデル: プラットフォーム収益が優先され、トークンはインセンティブおよび決済証明書として機能し、再購入と破棄は収益に関連付けられており、厳しい上限があります (第 8 章)。

2番第 2 章 プロジェクトの位置付けとガバナンスの透明性

2.1 プラットフォームの位置付けに関する声明

A12 は、「集中運用 + 分散実行」というアーキテクチャ上の位置付けを採用しています。プラットフォームは、運営主体によるリソース アクセスの検証、タスクのスケジューリング、請求と決済、紛争処理、セキュリティ リスクの管理を集中的に担当します。コンピューティング リソース自体は世界中 (個人、機関、IDC、エッジ ノード) に分散されており、タスクの実行はリソースの場所で分散された方法で完了し、スケジューリングの決定は各ノードのリアルタイムのステータスに基づいて行われます。ユーザーが A12 を選択する理由は、このプラットフォームが、統合インターフェイスと信頼できる検証を備えた分散型異種コンピューティング能力の使用に伴う組織コストを削減するためです。

このプラットフォームは次のことを約束します。すべてのスケジュールと請求のルールは公開されており、確認できます。タスク メータリング レコードはテナントによってエクスポートおよび監査できます。将来的にオンチェーン認証と決済が導入される場合、それらは透明性を高めるためのオプションのプロトコル層としてのみ使用され (§8.6 を参照)、プラットフォームの運用責任主体は変更されません。

2.2 プロジェクト主体およびチームの開示（必須開示リスト）

注: 責任ある役職は、事業体内の機能部門であり、その機能を実行するために事業体によって指定された担当者、外部コンサルタント、または代理店によって引き受けられます。対応する担当者が現場に到着する前に、運営主体の責任者によって補充されます。特定の責任主体は発表ページにリストされています (コンサルタントとアウトソーシングの構成については、§2.5 人的資源の保証、D-20 を参照)。約束日は、運営主体の責任者の承認後に発効します。リズム キャリバー: 約束した日付が評価ノードであり、期限を過ぎると、次の期限超過処理ルールがトリガーされます。付録 C の毎週の更新はプロセスの開示であり、進捗状況を記録しますが、新しい評価時点を構成するものではありません。どちらも約束された日付に基づいています。 ②③ (公式メールアドレスとオフィスのアドレス、法的連絡チャネル) はゼロコスト項目です - 第三者の協力に依存せず、承認や外部検証も必要ありません - そのため、約束日はこのバージョンのリリース (2026-09-21) から 5 営業日以内、移行発表ページの最初のバージョンと同じ日に設定されます。 ①⑦ チームメンバーはプラットフォームのバックエンドと協力する必要があり、約束日は 2026 年 10 月 15 日です。 ④⑤⑥⑧ 外部機関や規制プロセスからの協力が必要であり、約束日は上記の通りです。厳しい観察ポイント: 最初のポイントは 2026-09-21 (②③ コストゼロの項目と、実行能力をテストするための発表ページの最初のページ)。 2 つ目は 2026-10-31 (D-04 投資家の証拠と D-08 メイン ドメイン名、主題の検証可能性の実質的な変更点)。 3 番目は 2026-11-30 (D-05 特許番号および D-06 コード リポジトリ、技術資産の信頼性) です。期限を過ぎた場合の処理​​: 約束日までに何らかの問題が終了しない場合、事業体は期限を過ぎた理由、現在の進捗状況、約束日の修正をその日から 5 営業日以内に公表ページで説明し、同時にこの表と付録 C を更新する必要があります。同じ事項が 2 回連続して期限を過ぎた場合は、別の是正声明を発表する必要があります。改訂日は、元の日付から 30 日以内でなければなりません（外部機関の協力を必要とする事項を除き、そのような事項には組織的なフィードバックサイクルも示さなければなりません）。

2.3 命名の歴史と技術領域の配置

命名の歴史: Aelion Twelve はプロジェクトおよびその運営主体の名前です。 Axiur Twelveは、2021年にこのプロジェクトに投資し、同時に特別な開発チームを設立する戦略的投資家です。これは、Aelion Twelve との投資家と投資プロジェクトとの関係を形成します。 2 つの名前の「12」は、投資完了時に使用されたプロジェクト コードに由来しており、これは投資の歴史から残された自然なネーミングの痕跡です。投資契約書や資本注入証明書などの書面文書も対象情報開示の範囲に含まれます（§2.2 を参照）。

Technical territorial layout: The patent layout of core computing power scheduling technology is consistent with the composition of the R&D team. The person in charge of distributed systems (Tunde Akinwale) and the person in charge of GPU infrastructure (Amara Okoye) are based in Nigeria, and the relevant research and development work is completed in Nigeria. Therefore, the patent application is first submitted in the place where the invention is completed, and then promoted in order of the importance of the target market to China (the application has been approved) and the United States (expected to be by the end of 2026).これは、多国籍の研究開発チームにとって従来のローカル レイアウト戦略です。具体的な進捗状況は、特許番号/出願番号の発表に応じて決定されます (§2.2 を参照)。

命名とシンボルの利用可能性: トークン シンボル A12 とプロジェクト名 Aelion Twelve の商標および主流トレンド プラットフォームの一意性の検索は、リリース前に完了しました。検索範囲と結果 [リリース前に補足および開示 · D-09] により、既存のプロジェクト/商標と競合しないことが保証されます。

2.4 コンプライアンスの取り組み

このプラットフォームは、ユーザー識別 (KYC) および制裁リストのスクリーニングに準拠しています。コンピューティング能力テナントの使用状況のレビューとコンテンツのコンプライアンス ルール (§4.7 を参照)。データ保護と国境を越えた送信のコンプライアンス評価。デジタル資産が関係する管轄区域では、トークン関連の活動は必要な許可を取得した後にのみ実行されます。運営主体の登録が完了しました（カナダ）。 MSB および SEC 関連のライセンスの申請が進行中です。ライセンスを取得するまでは、上記のライセンスに関連するビジネスは実行されません。

ライセンス進捗状況の観察ポイント：「ライセンス取得前に開発なし」を外部から観察できるように、運営主体は公告ページにMSB登録申請段階、SEC関連ライセンス等の申請段階、受理番号の開示方法、完了予定時期の範囲、現状を箇条書きにしたライセンス状況表を整備する。最初のライセンス ステータス テーブルのリリース日は、移行公表ページ (§2.2 を参照) のリリース日までに行われ、その後は毎月更新されます。更新された責任職は、事業体の法務およびコンプライアンスの責任者です（外部法律事務所が関与する事項については、責任法律事務所も表にマークされています）。ライセンスを伴う事業開始の発表には、ライセンスのステータスに対応するクエリ リンクを添付する必要があります。リンクに障害が発生した場合、代替検証方法として「規制当局名 + 受理/受理番号 + 規制当局の公式照会ポータル」を使用すると、リンクは 5 営業日以内に修復または交換されます。

2.5 資金とリソースの透明性に関する取り決め

公開テストのインセンティブ、第三者による会計検証、契約セキュリティ監査、コンピューティング電源の調達とノード共有、チームの報酬などはすべて、運営主体の自己資金に依存しています。 「自己資金」の記載を確認できるようにするため、以下の対応を行っております。

上の表は、「確約された支出とリソースの保証」の唯一の基準です (同じセクションに 2 セットの数字が含まれることを避けるために、元の並列リストの基準はこのバージョンでは削除されています)。それぞれの確約された支出は、明確な資金源、上限口径、および追跡番号 (D-10 から D-20) に対応しています。読者は付録 C の番号に従って項目ごとに確認できます。この表は「勘定科目－上限額－源泉」という検証可能な枠組みを設けており、評価可能な枠組みを確立しております。この値は、追跡表（付録 C）で発表された後に評価可能になります。運営主体自身の資金規模の範囲（D-17）と今後 12 か月の資金ギャップ（D-19）が発表される前に、この記事は支払い能力が外部から評価できるとは主張しません。クローズドループの優先順位: D-19 (今後 12 か月の資金ギャップと補充方法) は、この表で最も優先度の高い項目としてリストされています。資金の絶対規模が商業上の機密保持により開示に適していない場合、D-17 は範囲口径または「顧客に別途提供され、検証可能な記録として保持されている」確認書という形で満たすことができます。

三番目第 3 章 システムアーキテクチャの概要

3.1 設計原則

システム設計は 4 つの原則に従い、それぞれが許容可能なエンジニアリング上の影響に対応しています。

• 物理トポロジーの親和性: タスクのスケジューリング先は、「分散化の度合い」ではなく、その通信コンピューティング特性によって決まります。トレーニング タスクは高帯域幅のクラスターに留まりますが、推論タスクはエッジに沈みます。
• 異種ハードウェアの抽象化: 統合されるのはタスク送信インターフェイスと測定機能であり、基礎となる実行環境ではありません。メーカー間の違いは、隠されるのではなく、明確な適応マトリックスを通じて開示されます。
• 階層化された検証可能性: 信頼は、複数のレイヤーのメカニズム (ステートメント、実際の測定、テレメトリ、ミッション検証、評判) の重ね合わせから生まれ、単一のレイヤーがバイパスされてもシステミック リスクにはなりません。
• 垂直バリュー チェーン: CaaS (コンピューティング能力) → MaaS (モデル サービス) → AaaS (エージェント アプリケーション) により、層ごとに価値が追加されます。プラットフォームの収益は、バリューチェーンが上流に進むにつれて、単価と粘着性が増加します。

3.2 4層アーキテクチャ

各層は標準インターフェイスで分離されています。コントロール プレーン (スケジューリング、メータリング、決済) はデータ プレーン (モデルの実行、データ送信) から分離されています。タスクが配置されているクラスター内ではデータ プレーンの送信が優先され、コントロール プレーンは大規模なテンソル データの転送を担当しません。

図 3-1 A12 の 4 層システム アーキテクチャ: 垂直バリュー チェーンにより層ごとに価値が追加され、コントロール プレーンとデータ プレーンは分離されています

3.3 生態学的役割

3.4 設計参照システム (イーサリアムとファイルコインからのエンジニアリングのインスピレーション)

A12 のメカニズム設計は、2 つの大規模に検証された分散システム ホワイト ペーパーのエンジニアリング パラダイムを大きく利用していますが、そのコンセンサス メカニズムをコピーするものではありません。イーサリアムの検証の目的は台帳のステータスであり、ファイルコインの検証の目的はストレージの正確性であり、A12 の検証の目的はコンピューティング プロセスとパフォーマンスです。検証対象の違いが仕組みの違いを決定します。

マッピング関係は次のとおりです。

4番目第 4 章 レイヤ 1: リソースへのアクセスと信頼性の検証

4.1 設計原則と境界 (重要な記述)

オープン環境におけるリソース検証には「絶対的な偽造防止」はありません。 A12 の設計目標は、不正行為の総合コスト (検出確率 × 損失) を不正行為のメリットよりも大幅に高くし、異常なノードを継続的に特定してダウングレードできるようにすることです。この目的のために、このプラットフォームでは「3 つの禁止事項」を明確に示しています。

• デバイスの ID として「シリコン物理指紋」は使用されず、指紋に基づいて永続的にブロックされることもありません (物理的特性は温度、電圧、経年変化によって変動するため、安定して再現できず、永続的な罰をサポートすることもできません)。
• 物理世界のアナログ量を証明するためにゼロ知識証明を使用しないでください (証明システムは「特定の計算が正しい」ことは証明できますが、「特定の物理的イベントが発生した」ことは証明できません)。
• 検証のためにテナント モデルの重みやデータにアクセスする必要はありません (テナントのプライバシーを保護するため)。

4.2 5層の信頼性検証システム

図 4-1 A12 の 5 層の信頼検証システム: 階層化および重畳されており、単一層のバイパスはシステミック リスクを構成しない

5層検証システムのL2層とL3層では、以下に説明するように定量化可能な統計的判定手法を採用しています。

L2能力測定用の判定モデル。プラットフォーム検証クラスターは、ランダムなベンチマーク チャレンジを生成します: ランダム行列 A ∈ ℝ^(m×k)、B ∈ ℝ^(k×n) (要素は一様分布に従い、シードは VRF ビーコンから導出されます)、ノードは指定された精度 (FP16/BF16) でターゲット GPU 上で GEMM 計算 C = A × B を実行し、結果の概要 (SHA-256(C)) と実際の時間を返します。 T. 2 つの統計セットを使用して以下を決定します。

• 正確性: クラスターを検証してリファレンス実装でサンプリングの概要をレビューし、相対的なフロベニウス ノルム誤差 ‖C − C_ref‖_F / ‖C_ref‖_F ≤ ε (ε は精度レベルに応じて設定され、FP16 は通常 10⁻² 程度で、浮動小数点の非結合性とさまざまな演算子の実装によって引き起こされる法的逸脱をカバーします) を必要とします。
• パフォーマンスの合理性: T_hat = 2・m・k・n / η_peak は、測定されたスループットのベースライン η_peak (m、k、n はチャレンジ GEMM の行列サイズ) に基づいて導出される、予想される時間のかかる値であり、(1−δ)・T_hat はその妥当な下限です。測定された消費時間がこの下限 (T < (1-δ) · T_hat) よりも小さい場合、「計算能力の誤った報告」または「事前計算キャッシュ」攻撃であると判断されます。著しく遅いタスクはチャレンジの通過には影響せず、SLA および評判メカニズムによって処理されます (§4.5 および §5.3 を参照)。
• ベースライン校正と汚染防止: η_peak は、公式リファレンス ハードウェア ギアのプラットフォーム検証クラスターによって定期的に測定および校正され、ベースライン テーブルは公開され、バージョン管理されます。リンクされていないノードの履歴測定値の直接集計は、低品質のサンプルがベースラインを下げて検出失敗を引き起こすことや、高品質のサンプルがベースラインを上げて実際のノードを誤って損傷することを防ぐために、ベースライン ソースとして使用されません。
• 高性能ノード誤判定保護: 実際の測定値がベースラインよりも優れていることは法的な状況です (機能アップグレード、§4.6 を参照)。誤警報プロセスは、実際の測定値が物理的な下限値を下回った場合にのみトリガーされます。判定されたオペレータは、遠隔再テストおよび手動レビュー（実測記録と動作環境説明の提出）を申請できます。レビュー期間中、関連する収入は保留ステータスで凍結されます。誤認は完全に凍結解除され、否定的な評判の記録には含まれません。

複数の行列サイズ (1K² から 16K³) と精度の組み合わせがランダムに選択されるため、ノードが単一スケールでのみターゲットを絞った最適化を実行することは不可能になります。

L3 ランタイム テレメトリの異常検出。指数加重移動平均 (EWMA) は、使用率、メモリ使用量、温度、消費電力などのタイミング指標のベースラインを維持するために使用されます。

s_t = α·x_t + (1 − α)·s_{t−1}

ここで、α は平滑化係数 (通常 0.05 ～ 0.2) です。瞬時値がベースラインから 3σ を超えて逸脱し (σ は履歴残差の EWMA 分散によって推定されます)、K サンプリング ウィンドウにわたって継続する場合、テレメトリ異常イベントとしてマークされます。異常なイベントは蓄積され、オペレーターの評価に組み込まれ (§4.5 を参照)、対応するタスクの暗号化密度のサンプリング検査がトリガーされます。この方法の境界も明確です。テレメトリーで検出されるのは「統計的矛盾」であり、改ざん手段の完全な証明にはなりません。これが、単一の判断点ではなく 5 層の重ね合わせが必要な理由です。

プロトコルの形式化への挑戦。 L2 チャレンジの生成と公開は、コミット-公開パラダイムに従います (このパラダイムは、イーサリアムの乱数ビーコンやファイルコインのウィンドウ化証明と同じ起源を持っています)。検証クラスターは、最初に各ラウンドでチャレンジのコミットメントを発表し、次にシードを公開します。ノードはその後、クラスターの「選択的質問なし」を個別に監査および検証できます。

このうち (y, π) は VRF 出力と証明、sk_V / vk_V は検証クラスター署名キー ペアで、第三者は vk_V を使用してシードの正当性をオフラインで検証できます。コミットメント値には、seed_q とパブリック パラメーター (ε、δ) のみを含める必要があることに注意してください。A_q と B_q は、seed_q から導出されます。コミットメントが含まれている場合、マトリックスのコンテンツはコミットメント段階でロックされ、「最初にコミットして後で明らかにする」という選択的質問を生成しない設計は無効になります。チャレンジ検証の参照決定プロセスは次のとおりです (最終的な実装ではなく、回路図の疑似コード)。

4.3 バリデーターネットワーク (明確な権利、責任、コスト)

• 検証クラスター: プラットフォームによって構築および運用されるコア検証クラスターは、すべてのサンプリング再実行とベンチマーク チャレンジの生成、発行、決定を担当します。そのコストはプラットフォームのサービス料金に含まれており、テナントに対して透過的にリストされます。
• 自主的な検証ノード: 評判の高いノードは検証ネットワークへの参加を申請でき、デポジットを約束する必要があり (金額は実行される検証ワークロードに関連付けられます)、効果的な検証が完了したことに基づいて支払われます。検証エラーがあった場合、または検証されたノードと共謀した場合、デポジットは没収され、検証資格は永久に取り消されます。
• ランダム ビーコン: チャレンジ シードは、検証可能なランダム関数 (VRF) を使用して検証クラスターによって生成され、シードのコミットメントは公開されます。ノードはチャレンジの内容を予測できませんが、検証クラスターは質問が選択的に選択されていないことを後で証明できます。

4.4 デュアルレールノードアクセス

エラスティック ノードは SLA サービスを提供しません。エンタープライズ レベルの可用性は、専用リソース プールの冗長展開によって保証されます。これにより、「キーボードとマウスがアクティブになるとすぐにオフラインになる」ことと「オンライン サービス」の間の矛盾がアーキテクチャ的に排除されます。

4.5 アンチウィッチおよびアンチオーバーブッキングメカニズム

• オペレーターアカウントシステム: すべての評判、決済、処罰はオペレーター (自然人または法人) によって集約されます。同じ事業者名の複数のデバイスのパフォーマンスが結合されて計算されます。単一のデバイスのデフォルトが、オペレーター全体の評判と決済サイクルに影響を及ぼし、「多数の新しい ID を登録し、それぞれが一度悪事を働く」ことで損失を切り分けることが不可能になります。
• グローバル リソース リースとクロスアイデンティティ メモリは相互に排他的です。各 GPU は、「デバイスのシリアル番号 + オペレーター アカウント」をキーとしてプラットフォーム台帳に登録されます。リソースがタスクによってロックされている間は、同じキーを使用して 2 番目の販売可能なリソースを作成することはできません。さらに重要なことは、デバイスのシリアル番号は台帳レベルでグローバルに一意であることです。同じシリアル番号を同時に 1 つのオペレータ アカウントにバインドすることのみが許可されており、どのアカウントを使用して宣言されたとしても、有効なリースは最大 1 つしか存在しません。シリアル番号のアカウント バインディングの変更は両当事者によって確認される必要があり、30 日間のクーリングオフ期間が設定されます。これにより、「1 枚の物理カードが 3 つの ID と交換され、それぞれがすべてのメモリを 1 回宣言する」ことが、後続の検出に依存することなく台帳レベルで相互に排他的になります。同じ物理デバイスの繰り返しの宣言 (仮想化分割後のマルチ ID 宣言を含む) は、アカウント レベルのレビューをトリガーします。 L1 ステートメントの検証では、ハードウェアの組み合わせ (GPU モデル、総ビデオ メモリ、PCIe/NUMA トポロジ、VBIOS バージョン、シリアル番号) が収集され、クロスアカウントの重複チェックにも使用されます。重複チェックとレビュー信号のみに使用され、デバイス ID の認証や永続的なブラックリストの基礎としては使用されません (§4.1「3 つの禁止事項」と一致)。この相互排他を外部から観察できるようにするために、クロスアイデンティティ重複排除統計 (宣言されたデバイスの数/重複排除後のデバイスの数/差分) が各段階の受入レポートの「ノード スケール」フィールドに含まれ、公開されます (§9.2.1 を参照)。
• トポロジカル クラスタリングの疑いの検出: PCIe トポロジ、NUMA 構造、宣言されたリソースのドライバーとファームウェアの組み合わせに対してクラスター分析を実行し、「同じ物理マシンであると疑われる複数の ID」を期限付きで観察し、手動レビューをトリガーします。トポロジー機能はクラスターの検出とスケジューリングの参照にのみ使用され、デバイス ID の証明としては使用されません。誤審の保護と異議申し立てのチャネル: 準拠した複数のマシンのオペレーター (インターネット カフェ、学校のコンピューター室、小規模スタジオ、代理店の IDC) は、当然ながら同じハードウェアとファームウェアの組み合わせを備えており、機器リスト、購入伝票、その他の資料を提出してオペレーターの身元審査を申請できます (処理期限は 7 営業日で、結果は発表されます)。評判モデルは、「不正な判決」（ペナルティと没収）と「クラスター疑惑」（ストリームの観察のみ、ペナルティなし、永続的なウェイト削減なし、レビューに合格するとウェイトは元に戻ります）を区別します。
• 新しいノードの収入成長曲線: 収入の上限と段階的なリリースが最初の 30 日間に新規登録オペレーターに実装されるため、新規アカウントの一括登録による 1 回限りの不正行為による予想収入はゼロに近くなります。上限は、整合性レコードの蓄積に伴って徐々に増加します。
• 収益遅延リリースプール: ノード収益は 3 つの状態でフローします: 獲得 → 保留中 → リリース。保留中の監視期間中 (タスクの値に応じて 1 ～ 72 時間に分割)、ランダムな検査と紛争が処理されます。契約違反が検出された場合、対応する保留中の収入は没収され、損害を受けたテナントへの補償に使用されます。高額の SLA ビジネスには別個のデポジットが設定されます。§4.4 を参照してください。

評判の定量的モデル (設計目標)。オペレーターの評判値 R ∈ [0, 100] は、「指数忘却 + タスクのフィードバック」に従って更新されます。

R_{t+1} = λ·R_t + (1 − λ)·r_task

このうち、r_task ∈ [0, 100] は単一タスクの評価 (包括的な検証合格ステータス、パフォーマンス偏差、SLA 達成度)、λ ∈ (0, 1) は忘却係数です。λ が 1 に近づくほど、履歴の重みが大きくなり、偶発的なジッターが平滑化されますが、回復が遅くなります。 λ が 0 に近づくほど、新しいスコアの影響が大きくなり、最近の変更に対する感度が高くなり、回復が速くなります。この設計は、「安定性」と「応答性」の間で評判のバランスを保っています。長期間良好な記録が時折発生するジッターを平滑化しますが、劣化が続くと R は最近のパフォーマンス レベルに単調に収束します。デフォルトに対する追加のペナルティ乗数: 確認されたデフォルト イベントごとに、R に減衰係数 κ (値 0.8、リスク管理ルールによって調整可能) が直接乗算され、オペレータ レベルのレビュー プロセスに記録されます。レピュテーション R のスケジューリングの重みとアドミッション マッピングの関係 (たとえば、R < 60 は SLA リソース プールに入ることが禁止されます) は設計目標であり、フェーズ 0 の内部テストでの調整後に発表されます。

ペナルティ関数は Filecoin の担保/スラッシュ モデルを利用していますが、「マイナス エクイティ」口座を避けるために、ペナルティ制限は厳密にオペレーターの保管デポジットを超えません。

このうち、V_disputed は係争中のタスクの値、m_violation は責任決定倍数 (初期値 1.0、違反が繰り返される場合は累進的)、D_escrow(o) はオペレーターの保管デポジットです。ペナルティ額はデポジットの厳密な上限であり、超過分はプラットフォーム不正使用補償基金が負担し、オペレーターは無限責任を負いません。

(収益の保管と没収に関する契約レベルのコメント §8.6 プロトコル層 - この機能はステージ 4 の成果物であり、現在提供されているものとして誤解されることを避けるために、プロトコル層の章で統一された方法で示されています。)

4.6 動的能力評価 (CU)

ノードの包括的な能力スコアは次のように定義されます。

このうち、P は計算ベンチマーク スコア、B はメモリ帯域幅スコア、M はメモリ容量スコア、N はネットワーク品質スコア、R は履歴信頼性スコアです。重み w_P、w_B、w_M、w_N、w_R はタスク タイプに応じて調整され (トレーニング タスクは P/N の重みを増加させ、オンライン API は N/R の重みを増加させます)、w_P+w_B+w_M+w_N+w_R=1 を満たします。各サブ項目は、メーカーの公称値ではなく、L2 の実測値と L3 テレメトリに基づいています。

異種ハードウェア間の比較可能性を確保するために、各サブ項目は最初に最小値と最大値が [0, 1] に正規化されます。

このうち、X_min / X_max は、外れ値の伸びを抑制するために、同世代のハードウェア ギアの測定された分布分位数 (P5 / P95) から取得されます。正規化されたスコアは、上記の式によって重み付けおよび合計されて CU(i) ∈ [0, 100] が得られ、その後、調整されたカットオフ ポイントに従って Tier-S/A/B/C に分割されます。カットオフ ポイントの選択は、「エシュロン内の CU の分散を最小にし、エシュロン全体でのタスク合格率の最大差」の原則に従い、フェーズ 0 の内部テストで調整後に公表されます。実際のタスク通過率 (ハードウェア仕様テーブルは、キャリブレーション前の一時的な分割の基礎として使用されます)。

ノードは、測定された CU に応じて、Tier-S/A/B/C の 4 レベルの階層に分割されます。遂行できるタスクの階層と範囲は、§5.4 のスケジュール制約表に示されています。どの階層のタスク テーブルも、ハードウェア仕様との検証可能な一貫性を維持します。

4.7 ノード所有者 (サプライヤー) の保護とコンテンツのコンプライアンス

ノード所有者に対するプラットフォームの義務はテナントの義務と同等です。

• 最小権限の実行: テナント タスクはコンテナ分離環境 (cgroups v2 + Seccomp + 読み取り専用ルート ファイル システム) で実行され、ノード デーモンは非特権ユーザーとして実行されます。分離により攻撃対象領域は大幅に削減できますが、リスクを完全に排除することはできません。プラットフォームはこれに対して保険をかけており、虐待補償基金を設立しています。
• 使用レビュー: テナント登録は KYC を完了する必要があります。タスク イメージはホワイトリスト ウェアハウスを通じて配布され、ノードは外部イメージを取得することを禁止されます。暗号通貨のマイニング、ポート スキャン、ガベージ トラフィックなどの用途は禁輸リストに含まれており、テレメトリによって検出されます。
• 悪用補償: プラットフォームのリスク管理の不備によりノード所有者が損失を被った場合、契約に従って悪用補償基金から補償が行われます。
• 自由に終了: ノードはいつでも終了でき、終了はリリース済み状態になった特典の引き出しには影響しません。
• 機密コンピューティングの展望 (研究プロジェクト): 「ノード メモリ内のテナント コードと重みのプライバシー保護」に焦点を当て、Trusted Execution Environment (TEE)、つまりビデオ メモリとコンピューティング プロセスをハードウェア レベルで暗号化できる CC (Confidential Computing) モードをサポートするデータ センター GPU に基づいて機密コンピューティング ルートを追跡し、ノード所有者自身がテナント データを読み取ることができないようにします。この機能は特定のハードウェア世代とメーカーのサポートに依存しており、研究範囲に含まれています (§9.3 を参照)。エコシステム内で適格な機器の規模が形成されるまでは、これはコミットメント項目にはなりません。それ以前は、コンテナの隔離 + 使用状況のレビュー + 補償基金が依然として主な保護の組み合わせとなります。

5番目第 5 章 レイヤ 2: スケジューリングとリソース プーリング

5.1 ハードウェア アダプテーション レイヤー (HAL) - 正直な異種混合戦略

A12 は、根本的な違いを排除すると主張するのではなく、ハードウェア抽象化レイヤーを通じてタスク送信インターフェイスを統合します。明確に述べられています：

• 統合インターフェイス: テナントは、特定の GPU モデルを選択せず​​に、統合されたタスクの説明 (モデル、データ、コンピューティング能力要件、レイテンシー、予算の制約) を送信します。
• バックエンドの異質性: 基礎となる実行は、各メーカーのドライバー、コンパイル ツール チェーン、およびオペレーターの実装に依存します。ロードマップでは、NVIDIA CUDA スタックが実稼働環境で利用可能になることが約束されています。 AMD ROCm スタックは実験的なサポートとともに提供されます。国内チップの適応については調査項目として挙げ、実際のプロジェクトの進捗状況に応じて別途お知らせいたします。
• このプラットフォームでは、サードパーティの商標に類似した製品名は使用しません。

5.2 デュアルパススケジューリング

スケジューラは、タスクの通信計算比率 α_comm に基づいてパスを選択します。

• α_comm ≥ 1 (通信制限): 集中コンピューティング センター (クラウド プラットフォーム GPU クラスター、プロフェッショナル AI IDC、HPC) にディスパッチされます。A12 は、標準アダプターを通じてこれらのリソースにアクセスし、テナント独自の価格比較とスプライシングを置き換える統合オーケストレーションを提供します。
• α_comm < 1 (コンピューティング制限): WAN の高頻度の同期を回避するために、ローカル閉ループ タスク (推論、埋め込み、LoRA/QLoRA、バッチ処理) を実行するために A12 分散リソース プール (検証済み IDC、ワークステーション、およびエッジ ノード) をスケジュールします。

α_comm の 2 つの時間コンポーネントは、古典的な Hockney 通信モデルと Roofline スループット推定を使用してモデル化されます。

• 通信時間: T_comm ≈ T_startup + m / BW + o(m)、ここで、m はシングルステップ同期で送信されるデータ量 (たとえば、フルパラメータ トレーニングでは、同期されるパラメータのバイト数 × 同期数にほぼ等しい)、BW はリンクの実効帯域幅 (実測値、非公称)、T_startup は固定起動遅延 (WAN の場合は通常 10 ～ 100 ミリ秒、NVLink/IB の場合は通常 10 μs 未満)、o(m) プロトコル スタックの追加項目。
• 計算時間: T_compute = FLOPs / η_eff、ここで FLOPs はシングルステップ浮動小数点演算の量 (フルパラメーター トレーニングは約 6 × パラメーター量 × トークン数)、eta_eff は測定された実効計算能力スループット (ルーフライン モデルに基づく算術強度制約の対象となり、通常はピーク計算能力の 30% ～ 60%) です。

例として、7B パラメータ モデルの完全なパラメータ微調整を考えてみましょう。データ並列処理では、各ステップで約 28GB の同期が必要です (FP16 の重み + オプティマイザのステータスは実装によって異なります)。25Gbps WAN リンク (実効帯域幅 ≈ 3GB/s) でのシングルステップ通信には、およそ 9.3 秒かかります。 InfiniBand 400Gbps (実効 ≈ 45GB/s) クラスターでは、同じ同期量は 1 未満です。秒 - 通信時間は桁違いに異なりますが、このスケールでのシングルステップ計算はわずか数秒です。これは、「通信量の多いタスクは集中クラスタに留まるべきである」の定量的根拠です。強調する必要があるのは、25Gbps は専用線/データセンターの相互接続レベルに属するということです。ホーム アップリンク 1Gbps (実効 ≈ 110 MB/秒) に基づいて再計算すると、同じ 28GB の同期ボリュームにはステップあたり約 265 秒かかり、上記の例より 30 倍近く長くなります。この結論は、実際のエッジ帯域幅分布の例よりもはるかに極端です。スケジューラの α_comm パラメータ ライブラリは、ターゲットのサプライエンド帯域幅分布 (アップストリーム P50/P90、国境を越えた遅延) に従って構築され、推定誤差に対するフォールト トレランスを保持します。しきい値の両側の境界タスクは、実際の測定レビューによって決定されます。スケジューラはタスク投入時にα_commを推定してライブラリに落とし込み、実際のタスク実行の観測値と比較し、帯域幅やスループットのパラメータライブラリを継続的に修正します。 5 つの典型的なタイプのタスクのオフロード推定を図 5-1 に示します。

図 5-1 デュアルパスのスケジューリングとオフロードの基礎: α_comm しきい値の両側は、それぞれ集中クラスターと分散リソース プールです。

5.3 スケジュールの決定と SLA モデル

スコアリングのスケジュールは複数の目的に重み付けされます。

重みはタスクの種類に基づいて動的に調整されます。スケジューリング ソリューションは、エンジニアリングにおける制約フィルタリング + 貪欲スコアリングの 2 つのステップに簡略化されます。まず、ハード制約 (エシュロン アドミッション、SLA アドミッション、メモリ/トポロジ マッチング、レピュテーションしきい値) に従って候補セットをフィルタリングし、次にスコアに従って残りの候補を並べ替えて、最適なものを選択します。全体的な複雑さは O(N log N) で、1000 レベルのノード規模では 1 つの意思決定が数ミリ秒で完了します。多目的重みの長期最適化は研究項目としてリストされており、最初のバージョンにはコミットされていません。

SLA 可用性のための冗長な計算。単一ノードの月間可用性が A₀ で、アクティブ ノードとバックアップ ノードが独立して展開され、独立した電源とネットワーク コンセントを備えていると仮定すると、全体的なサービス可用性は次のようになります。

A = 1 − (1 − A₀)²

A₀ = 99.5% を例にとると、デュアルマシン冗長化後は、A = 1 − 0.005² = 99.9975%、つまり月間の累積非可用性時間は約 3.6 時間から約 1.1 分に圧縮されます。プラットフォームは、これに基づいて容量計画を実行します。目標可用性 A* は、必要な単一ノード可用性 A₀* = 1 − √(1 − A*) から推定されます。専用リソース プール内のアクティブとバックアップのペアの数が A₀ ≥ A₀* ≥ 販売された SLA 注文数 + 安全マージンを満たす場合にのみ、新しい注文が受け入れられます。マージンが不十分な場合、新しい SLA 注文は過剰販売ではなく拒否されます。これは、容量レベルでの §4.4 デュアルレール絶縁の実装です。上記の 99.5% および 99.9975% は、設計ベースライン口径の計算例であり、実際の測定結果ではなく設計目標でもあることを強調しておく必要があります。これらの例は、冗長合成の大きさの関係を説明するために使用されており、99.9975% は外部コミットメント値ではありません (外部コミットメントの下限については、以下の SLA ターゲット値フレームワークを参照してください)。

コントロール プレーンの可用性 (A_プラットフォーム)。上の式はリソース ノード側の冗長性のみをカバーしています。スケジューリング、メータリング、決済、検証クラスタなどのコントロール プレーン コンポーネントはプラットフォームによって自己構築および運用され、その可用性は個別にモデル化されます。コントロール プレーンは複数のアベイラビリティ ゾーンに展開され、WSS ゲートウェイはマルチアクティブです。検証クラスターが利用できない場合、チャレンジの発行は自動的にランダム検査モードにダウングレードされ、保留中の収益のリリースは延期され、ノードのデフォルトは考慮されません。外部からコミットされたサービス レベルの可用性 = A_platform × A_node。その設計目標値を下記「SLA目標値フレームワーク」に示します。正式なコミットメント値は、正式リリース バージョンとともに発表され、追跡番号 D-23 として登録されます。コントロール プレーン障害時の請求ルール: 障害期間中は請求が一時停止され、SLA に達した注文は補償条件に従って実行されます。テナントはプラットフォームの障害に対して支払いを行いません。

SLA 目標値フレームワーク (フェーズ 2 アウトバウンド販売の前提条件)。外部からコミットされたサービス レベルの可用性の目標値は、正式リリース バージョンで発表されます。この記事では、最初に設計目標を示します。排他的保証モードのサービスレベル可用性 A_service ≥ 99.5%、その中で、コントロール プレーン A_platform ≥ 99.9%、およびノー​​ド側合成可用性 ≥ 99.6% (A = A_platform × A_node に従って合成)。 3 つの基準は次のように明確です。まず、99.5% は外部コミットメントの下限であり、期待される運用価値ではありません。キャパシティ プランニングは、上記の式の A* 逆解 A₀* ロジックに従って実行されます。これは、設計ベースライン A₀ = 99.5% (月次キャリバー) の下での理論的な合成値である 99.9975% という前の例と矛盾しません。下限と理論上の合成値との差が、外部約束の安全マージンです。次に、A₀ の設計ベースラインは月次 99.5% (排他的保証モードのアクティブ ノードとバックアップ ノード) です。 A = 1 − (1 − A₀)² の逆解によれば、外部からコミットされたノード側の合成可用性 ≥ 99.6% は、A₀* ≥ 93.68% に相当します。 93.68% は、外部コミットメントの下限に対応する逆数値であり、単一ノードの設計ベースラインではありません。実際の容量計画は、99.5% のベースライン実行に基づいています。 3 番目に、統計ウィンドウ: A_service、A_platform、および A_node はすべて自然月 (月次ウィンドウ) に基づいて計算されます。年間可用性は、12 自然月の算術平均です。 SLAの報酬は自然月を会計周期としています。上記の値はすべて、実際の測定結果ではなく設計目標です。目標値が正式に発表される前に、プラットフォームは一般向けに SLA を含むサービス契約を締結しません。フェーズ 2 での SLA 商用化は、この発表に基づいて絶対的な前提条件となります。プラットフォーム障害時には、「障害は請求されない」請求および補償ルールが目標値と同時に発表されます。

供給側の経済性と独占的なプール余剰の処理。フレキシブル モードでの 1 台の RTX 4090 クラス デバイスの月間収益範囲、電気代と減価償却率、および「アイドル/再販」機会費用の比較計算表 [リリース前発表 · D-24] - この計算は、§9.2 のノード保持およびスケール目標の最初の基礎となります。専用プールが標準に達し、マスター/バックアップのペアが販売済みの注文を長期間超過した場合、アイドル容量はエラスティック プールに転送されて割り込み可能なタスクを引き受けるか、一方的なアイドル状態を避けるために容量予約契約に従ってエンタープライズ テナントとの間で決済されます。

スケジューリング意思決定のリファレンス実装は次のとおりです (制約付きフィルタリング + 貪欲スコアリング、疑似コードが示されています)。

スケジューリング価格設定メカニズム: タスク価格設定は、「公開基本価格 + 品質ボーナス」構造を採用しています。基本価格は、公的ルールに従って需要と供給に応じて変動します (EIP-1559 の価格発見のアイデアを参照、§3.4 を参照)。品質ボーナスは、リソース階層 (Tier-S/A/B/C) および SLA レベルに従って課金されます。すべての価格パラメーターは公開されており、アンダートーンを避けるためにチェックできます。

5.4 リソース階層スケジューリング制約テーブル

エシュロンと実行できるタスク範囲の対応関係は次のとおりです (§4.6 の CU 分類と一致します)。

5.5 タスクのライフサイクルと紛争処理

タスク ステート マシン: 保留中 → スケジュール済み → 実行中 → (一時停止) → 完了 / 失敗 / 紛争。係争中の凍結タスクは保留中の収益に対応し、インタラクティブなリプレイの位置付けに入ります。つまり、検証クラスター上でタスクのスライスをリプレイし、責任者 (ノード、プラットフォーム、またはテナントの入力) を特定し、責任に応じて報酬を分割します。

図 5-2 A12 タスクのライフサイクル ステート マシン: 係争中のタスクは保留中の収入を凍結し、インタラクティブ リプレイに入り、責任者を特定します。

5.6 テナント向けコンソールと安全なサンドボックス ランタイム

従来のクラウド プラットフォームに劣らないテナント エクスペリエンスを提供するために、レイヤー 2 はテナント インタラクション レイヤーと安全な実行環境をカプセル化します。以下は設計目標であり、合格指標はフェーズ 0 の内部テストで明らかにされます。

• Web ターミナルとファイル チャネル: ノードが登録されると、ディスパッチ ゲートウェイへの送信暗号化 WebSocket (WSS) 接続がアクティブに確立され、リバース プロキシ トンネルが形成されます。テナント コンソールは、Web ターミナル エミュレーション コンポーネントを使用してノードに直接接続するため、パブリック ネットワークの IP ポート マッピングやキー配布プロセスが不要になり、あらゆる NAT/ファイアウォール環境と互換性があります。コンソールは同時にオンライン ノートブック サービスとファイル ストレージ サービスのエージェントとして機能し、HTTP チャンキングとブレークポイント再開を使用してアップロードして、大容量のデータ セットとトレーニング スクリプトの信頼性の高い送信を保証します。
• コンテナ化された第 2 レベルのインスタンスのスケジューリング: 従来の仮想マシン モードを使用する代わりに、軽量コンテナ ランタイムがサンドボックスとして使用されます。プラットフォームには、合理化された基本イメージ (Ubuntu LTS + CUDA + PyTorch 推論スタック + 共通の依存関係) がプリセットされており、アイドル期間中にイメージの読み取り専用レイヤーがプリロードされます。タスクが開始されると、数メガバイトのカスタマイズされたレイヤーのみがリアルタイムで取得されます。設計目標: 単一インスタンスのコールド スタート時間 ≤ 10 秒 (同じリージョン、ミラー キャッシュ ヒット層。クロスリージョンまたはキャッシュ ミスのシナリオはノードのアップストリーム帯域幅に基づいて異なるターゲットに分割され、実際の測定データはパブリック アクセプタンス レポートの対象となります)。
• 物理レベルのクォータ分離: cgroups v2 と Seccomp を使用して、コンテナーの CPU、メモリ、および IO 帯域幅にハード制限を設定します。 NVIDIA コンテナ ランタイムを使用して、割り当てられた GPU デバイスのみがコンテナ内に表示されるようにします。この分離により攻撃対象領域が大幅に減少し、サイドプロセスがテナントメモリを読み取るのを防ぐことができますが、コンテナエスケープを完全に排除することを約束するものではなく (残留リスクについては第 10 章を参照)、プラットフォームは悪用補償基金を使用してコストをカバーします。

6番目第 6 章 レイヤ 3: モデルサービス (MaaS)

6.1 モデルのアクセスとバージョン管理

統合されたモデル レジストリには、モデルのソース、バージョン、重みの概要、動作環境、評価結果が記録されます。エンタープライズ プライベート モデルはホストされるだけであり、知的財産権の所有権は変更されません。この取り組みは、§4.7 のセキュリティ メカニズムと§5.6 の分離対策によって制限されます。エラスティック ノード モードでの IP 保護はコンテナの分離に依存します (コンテナのエスケープを完全に排除することを約束するものではなく、残留リスクは §4.7 の保険および悪用補償基金によってカバーされます)。 IP 分離に対する強い要求があるテナントには、排他的保証モードを使用するか、§4.7 の将来を見据えた TEE 機密コンピューティング層 (研究プロジェクト) を採用することが推奨されます。モデルを棚に置くには、使用目的、既知の制限、評価ベンチマークを記録し、プラットフォーム測定システムに関連付けるモデル カードを提出する必要があります。

6.2 垂直型インダストリ モデル パイプライン

プラットフォーム計画は、「垂直方向の 1 つの方向」アプローチでモデル層の競争力を確立します。最初の垂直方向は、Web3 コードとセキュリティ エンジニアリングです (開示されたチームの背景と一致しています。このセクションのすべての指標は計画目標であり、完了した事実ではありません)。

• コーパス管理: 構造化データ収集パイプラインを構築し、オープンソース契約ウェアハウス、公開脆弱性開示コミュニティ、チェーン上の検証済み契約のソース コードを収集してライセンスを取得します。事前トレーニング コーパスは、構文ツリー フィルタリング、おおよその重複排除、および手動サンプリングの後に形成されます。スケールターゲット: トレーニング前コーパスの最初のバッチ ≥ 10B トークン。ライセンス ガバナンス: ライセンス ホワイト/ブラックリストの確立 - 許容ライセンス (MIT/Apache/BSD) が優先的に含められます。 GPL/AGPL およびその他のコピーレフト ライセンス コーパスの包含境界、および「トレーニング ウェイトが二次的著作物を構成するかどうか」の法的基準は、特別な法的見解の対象となります [法的見解: リリース前に補足および公表 · D-25]。重複排除とライセンスの審査ルールは、コーパス パイプラインのドキュメントとともに開示されます。 10B トークンはスケールの最初のバッチであり、モデルのスケールはチンチラのスケール法則とコーパスの量 (効率を優先した中小規模のパラメーター ギア) と同期して計画されます。データ予算と後続のバッチのスケジュール [補足およびリリース前に発表 · D-26]。
• 継続的事前トレーニング (CPT) と教師あり微調整 (SFT): 現場での継続的事前トレーニングの開始点としてオープンソース コード ベース モデルを使用し、教師あり微調整用に「欠陥位置 → 攻撃パス構築 → 結果予測 → パッチ提案 → 回帰テスト」のマルチステップ推論命令セットを重ね合わせます。トレーニングは、第 5 章のデュアルパス ルールに従って、集中型コンピューティング センター (Tier-S echelon) で実行されます。トレーニングの規模 (インスタンスの数、並列戦略、コンテキストの長さ) はステージの予算とともに発表され、固定のコミットメントは行われません。
• ツール コール アライメント (DPO): モデルの出力は外部ツール サンドボックス (コンパイル テスト フレームワーク、静的分析ツール) に接続され、ツールの実行結果を使用して優先データが構築され、「ゴースト脆弱性」の誤検知を減らすための直接の優先最適化が行われます。このメカニズムは決定論的な改善です。モデルの結論はツールによって検証可能でなければなりません。

2 つのトレーニング段階の目的関数は次のとおりです (設計目標口径)。

SFT ステージでは、マスクされたクロスエントロピー損失が使用されます。アシスタントの応答部分については損失のみが計算され、プロンプト単語部分はマスクされます。

L_SFT(θ) = − (1/|y|) · Σ_{t=1}^{|y|} log p_θ(y_t | x, y_{&lt;t})

ここで、x は入力 (複数ステップの推論命令テンプレートを含む)、y はターゲット出力シーケンス、|y| です。はターゲット シーケンスの長さ、p_θ はパラメーター θ でのモデルの条件付き確率です。複数ステップの推論命令セット (欠陥の位置 → 攻撃パスの構築 → 結果の予測 → パッチ適用の提案 → 回帰テスト) は構造化されたテンプレートに編成されているため、損失は推論チェーンと結論の生成品質に集中します。

DPO ステージは、ツールの実行結果に基づいてプリファレンス ペア (y_w、y_l) を構築します。y_w はツール レビューに合格した出力 (コンパイル パス、テスト パス、静的解析の確認)、y_l はツールによって拒否された出力です。参照モデル p_ref の制約の下で最適化されています。

L_DPO(θ) = − E_{(x, y_w, y_l)} [ log σ( β·log(p_θ(y_w|x)/p_ref(y_w|x)) − β·log(p_θ(y_l|x)/p_ref(y_l|x)) ) ]

ここで、σ はシグモイド関数、β は参照モデルからの偏差の強度係数 (通常は 0.1) で、独立した報酬モデルのトレーニングを暗黙的に置き換えます。このルートの工学的重要性は、優先信号が手動アノテーションの主観的な判断に依存せず、ツール実行の客観的な結果によって固定されており、「ゴースト脆弱性の誤検知の削減」を 1 回限りのパラメーター調整結果ではなく、再現および回帰できる最適化目標にすることです。

トレーニング規模の計画: チンチラのスケーリングの法則。垂直モデルのトレーニング予算は、目標損失 L、モデル パラメーターの数 N、トレーニング トークンの数 D によって決定され、チンチラのような経験的形式に従います。

このうち、E は既約誤差、A、B、α、β はタスクに関連する経験係数です。この式は、データを増やさずにモデルを単純に拡大したり、モデルを拡大せずにデータを単に拡大したりすると、限界収益逓減の領域に入ることを示しています。これに基づき、プラットフォームは「モデルサイズ ↔ コーパスサイズ ↔ 計算能力バジェット」の三元計画を立て、ステージバジェットに応じたトレーニング規模（インスタンス数、並列戦略、コンテキスト長）を公開し、固定的なコミットメントは行いません。

コンプライアンス境界: モデル機能は補助的な参照ツールとして位置付けられ、その出力は開発支援と内部セキュリティ評価に使用されます。 CVSS 評価付きの正式な監査レポートは外部には発行されず、そのようなサービスは資格のあるパートナーによって発行される必要があります。連絡プロセスが開始され、少なくとも 1 人の適格なパートナーとの署名が完了し、ターゲットのパブリック ベータ版が開始される前に名前が公開されています。製品ラインは署名前に正式に商品化されず、協力の進捗状況は公式ウェブサイトで段階的に更新されます（第 10 章の将来予想に関する記述の対象）。

6.3 OpenAI互換APIゲートウェイ

ゲートウェイは OpenAI インターフェイス標準に厳密に従っており、既存のアプリケーションのゼロコード移行を実現します。

• 標準エンドポイント: /v1/chat/completions、/v1/models、および /v1/embeddings の下位互換性を提供し、サーバー側イベント (SSE) ストリーミング リターンをサポートします。 OpenAI SDK、LangChain、または LlamaIndex を統合したアプリケーションでは、ゲートウェイのアドレスとキーを置き換えるだけで済みます。
• 動的負荷分散: ゲートウェイは、各リソース階層に応じて推論キューの深さを割り当てます。長いコンテキストの高負荷タスクは Tier-A 以上のリソースにルーティングされ、高頻度の短いタスクはエッジ リソース プールにルーティングされます。設計目標: パブリック ベータ期間中の最初の単語遅延 (TTFT) の中央値は、≤ 400ms (≤ 8K コンテキスト ギア。32K の長いコンテキスト ギアは、パブリック ベータ測定データとは別に設定されます)。
• 負荷分散アルゴリズム: 同じ階層内で「Power of Two Choices」戦略が採用されます。2 つの候補インスタンスがランダムに選択され、リクエストはキューの深さが小さい方に送信されます。この戦略はグローバル最小値の取得を必要とせず、O(1) の通信オーバーヘッドがありますが、キューの長さをグローバルなランダム指数分布から多項式減衰まで短縮できます。古典的なキュー理論の結論は、システム負荷が飽和に近づくと、二次選択によって平均キューの長さが O(n) から O(log log n) に短縮されるということです。 「常に最も空のインスタンスを選択する」グローバル スキャン ソリューションと比較して、スケジューラ独自の低レイテンシと水平スケーラビリティは、1,000 レベルのインスタンス スケールでの非常に小さなロングテール コストと引き換えに、ゲートウェイ TTFT の目標に一致します。

キュー理論のキャパシティ プランニング。リクエストが近似ポアソン プロセス、単一インスタンスのサービス レート μ、および同時インスタンスの数 c で到着すると、キュー待機時間は Erlang C の公式 (M/M/c モデル) で求められます。

このうち、T_prefill(s) はプレフィルフェーズの計算時間 (コンテキスト長 s に比例して増加)、C(c, ρ) は Erlang C の待機確率です。このモデルは、2 つのエンジニアリング上の決定に使用されます。1 つは、TTFT ターゲット (400 ミリ秒) を前提として、各エシュロンに必要な同時インスタンスの最小数 c を逆決定するためです。 2 つ目は、キューの深さが飽和 (ρ → 1) に近づく前に拡張をトリガーすることです。これは、ロード バランサーがキューの深さをルーティング信号として使用するための理論的基礎です。パブリックベータ期間中に、測定された到着率λでμを校正した後、容量計画表が発表されます。

6.4 推論パフォーマンスエンジニアリング: 連続バッチ処理とコールドスタートの最適化

• 反復レベルの連続バッチ処理: 反復の粒度でリクエストを動的に挿入および終了します。リクエストが終了すると、そのビデオ メモリ ページはすぐにリサイクルされます。新しいリクエストは準備完了キューに入り、次の反復が挿入されるまで待機するため、静的バッチ処理の「バレル効果」が排除されます。設計目標: GPU 実効負荷率 ≥ 75% (パブリック アクセプタンス レポートの実測値の対象)。
• ビデオ メモリ ページング管理: ページング キー/バリュー キャッシュ (PagingAttendant タイプのソリューション) を採用し、KV キャッシュを固定長のビデオ メモリ ページに分割し、ページ テーブルとの論理マッピングを維持します。不連続な物理割り当てをサポートし、断片化率を削減します。プレフィックス ビデオ メモリ ブロックを共有するためのマルチラウンド ダイアログ ブランチをサポートします。
• コールド スタート キャッシュ: 基本モデルの読み取り専用の重みを各リソース プール ノードにプリロードします。ユーザー定義の LoRA 重み (通常はわずか数十 MB) が近くにプルされ、分散キャッシュを介してホットスイッチされ、同じ GPU 上のマルチテナントとマルチモデルのシームレスなスイッチングをサポートします。

KV キャッシュ容量計画 (設計目標)。ページング管理の容量要件は次のように見積もられます。

M_KV = 2 × L × H_kv × d_head × s × b × bytes_per_elem

このうち、2 は K/V キャッシュ、L はレイヤー数、H_kv はキー値ヘッドの数 (GQA グループ化を使用してアテンションをクエリする場合、H_kv ≪ アテンション ヘッドの数。これによりキャッシュが大幅に圧縮される可能性があります)、d_head は各ヘッドの次元、s はシーケンス長、b は同時バッチ サイズ、bytes_per_elem は精度バイト数です。 32K コンテキストを伝送する 80 レイヤー、H_kv = 8、d_head = 128、FP16 モデルを例にとると、シングル シーケンス KV キャッシュ ≈ 2 × 80 × 8 × 128 × 32768 × 2B ≈ 10.7 GB - この大きさは、モデルの重みそのものではなく、KV キャッシュが長いコンテキスト サービスのビデオ メモリのボトルネックになることが多いことを示しています。ページング メカニズムにより、断片化率の上限が「シーケンスあたり 1 ページ未満」 (通常のページ サイズ 16 トークン、理論上の無駄 ≤ ページ サイズ × シーケンス数) に低下し、プレフィックス共有により、同じシステム プロンプト ワードを使用した複数回の会話と要求が物理ページの同じバッチを再利用できるようになります。

連続バッチ処理のスループット モデル。 GPU ペイロード レートは、ターゲット オペレーターの実際の実行時間の割合として定義されます。

Util = T_busy / (T_busy + T_idle + T_overhead)

静的バッチ処理では、T_idle は「バッチ内で最も遅いリクエストを待機している高速リクエスト」に由来します (バレル効果)。バッチが大きくなるほど、廃棄物の重量も重くなります。連続バッチ処理では、反復粒度でバッチが再編成されるため、T_idle はゼロに近づき、残りのオーバーヘッドはスケジューリング自体 (T_overhead、ミリ秒レベル) のみになります。 KV キャッシュのオンデマンド割り当てと組み合わせることで、スケジューラは、「バッチ サイズの上限 × シーケンス長の上限」で構成されるメモリ エンベロープ内の同時シーケンスの数を動的に最大化できます。これは、注目を集める数字ではなく、75% のペイロード レート設計目標 (パブリック アクセプタンス レポートでの実測値の対象) のメカニズムの源です。

ルーフラインパフォーマンスモデル。シングルカード推論のピーク スループットは、演算強度 I (FLOPs/バイト) の影響を受けます。

このうち、π_peak はピーク演算能力、β_mem はメモリ帯域幅です。演算強度の低いタスク (主にメモリに依存する復号化フェーズなど) の実際のスループットは、ピークの計算能力ではなく β_mem·I によって決まります。これは、「トークンあたりのメモリアクセス量の削減」を追求する、KVキャッシュ圧縮、低精度推論、PagesAttention、連続バッチ処理などの技術の理論的基盤となっています。パフォーマンス エンジニアリングの先見性 (研究項目、§9.3 を参照)。推論最適化コミュニティの主要な方向性は、以下を含む MaaS レイヤーの継続的な進化ルートとして追跡されます。

• 投機的デコード: 小規模モデルの製図と大規模モデルの並列検証の生成方法を使用して、出力品質を変えずにデコード遅延を数回圧縮します。そのドラフト検証構造は、A12 検証クラスタ アーキテクチャに自然に適合します。
• 低精度推論 (FP8/FP4): KV キャッシュと行列乗算をハードウェアのネイティブ低精度形式で実行し、ビデオ メモリ占有と帯域幅要件を均等に圧縮します。 §6.4 の M_KV 式によれば、FP8 は、同じカードが同時に伝送できる長いコンテキスト シーケンスの数を直接 2 倍にすることができます。
• プレフィル/デコード分離アーキテクチャ (分散サービング): 最初のワード生成 (計算集約) とその後のデコード (帯域幅集約) を異なるリソース プールに分割します。これは、A12 の「通信計算比率による分割」スケジューリング哲学と同じです。
• KV キャッシュ階層オフロード: HBM → DDR → NVMe の 3 レベルのキャッシュ階層。温度を考慮したページ移行により、サービス可能なコンテキストの長さを拡張します。
• セマンティック キャッシュ: セマンティックに繰り返されるリクエストに対してキャッシュされた回答を直接再利用し、ナレッジ ベースの Q&A 負荷におけるコンピューティング電力消費を大幅に削減します。
• MoE Expert Parallel: ハイブリッド エキスパート モデルのクロスノード分散とエキスパート重みの動的ルーティングにより、「数百億のパラメータ レベル モデルを分散リソース プールで提供する」ことが可能になります。これは、分散コンピューティング パワー ネットワークとスタンドアロン ソリューションを差別化する機会となります。

その中で、グラフィックス メモリの使用量に対する GQA と低精度推論メカニズムの定量的な効果を図 6-1 に示します (残りのメカニズムの利点は、容量の上限とスループットの向上という形で反映されます。第 5 章を参照)。

図 6-1 KV キャッシュ容量モデル: GQA の圧縮効果とビデオ メモリ使用量の低精度 (80 層モデル、シングル シーケンス)

6.5 モデル市場と測定と決済

• 料金は、通話数、トークンの数、コンピューティング能力の期間またはサブスクリプションに基づいて計算されます。決済はデフォルトで法定通貨または安定通貨建てで、A12 トークンは手数料割引およびインセンティブバウチャーとして使用されます (第 8 章を参照)。
• モデル開発者は通話に基づいて収益を分配し、分配率はモデル掲載契約で合意および発表されます。測定記録は監査のためにエクスポートできます。

7番目第 7 章 レイヤ 4: エージェントとアプリケーション (AaaS)

7.1 ビジュアル エージェント オーケストレーション キャンバス

エンジニアリング開発能力を持たないユーザーのために、ローコードのドラッグ アンド ドロップ エージェント オーケストレーション システムが提供されます。

• 構成可能なノード: トリガー クラス (Webhook、タイミング、イベント モニタリング、ダイアログ ボックス)、推論クラス (レイヤー 3 モデルまたは外部モデルの呼び出し、パラメーターはリアルタイムで調整可能)、ツール クラス (コード実行、SQL クエリ、外部 API、静的分析)、制御クラス (分岐、ループ、解析、障害回復と補償)。
• ワークフロー DSL コンパイル: フロントエンド キャンバスが有向グラフにレンダリングされます。コンパイラーは接続性と循環依存関係を検証し、それを宣言型ワークフロー定義 (JSON/YAML) に変換し、バージョン管理可能な資産として保存します。
• DAG 実行エンジン: バックグラウンドのステートレス実行エンジンは、トポロジー順序に従ってノードをスケジュールし、非依存ノードは同時に実行され、依存ノードはコンテキスト状態ツリーを通じて中間結果を渡します。実行記録は、異議申し立ての再生プロセス全体を通じて保持されます。

実行スケジューリングの数学的特性は次のとおりです。ワークフローが有向非巡回グラフ G = (V, E) にコンパイルされた後、エンジンはカーン アルゴリズムを使用してトポロジカル ソートを実行し、各ノードの次数テーブルを維持します。入次数が 0 のノードは、同時実行の準備完了キューに入ります。完了した各ノードは後続の入次数を 1 つ減らし、全体の複雑さは O(|V| スケジューリングの並列度はグラフの最大アンチリンク幅によって制限され (幅 w のグラフはいつでも最大で w 個のノードを同時に持つことができます)、ワークフロー全体の完了時間には下限があります。クリティカル パスの長さ、つまりソースからシンクまでの最も長い重み付けされたパスは、各ノードの推定消費時間に重み付けすることによって計算されます。これにより、オーケストレーション キャンバスにユーザーのクリティカル パスのハイライトと推定完了間隔が表示され、「どのノードが全体の速度を低下させるか」が経験的な判断から計算可能な結論に変わります。

DAG トポロジカル ソートのリファレンス実装 (カーン アルゴリズム):

• ツール プロトコルの標準化 (将来を見据えたもの): ツール ノードは、MCP (モデル コンテキスト プロトコル) などのオープン ツール アクセス プロトコルと徐々に連携し、外部ツール メーカーが「一度適応すれば複数のプラットフォームで利用できる」ようになります。マルチエージェント ワークフロー間の A2A (エージェント間) プロトコルに基づいたタスクの委任とステータスの相互認識を探索し、組織を越えたエージェントのコラボレーションのための標準インターフェイスを予約します。上記はすべて設計目標であり、実際のプロトコル バージョンの成熟度に左右されます。

7.2 開発者ツールチェーン: VS Code プラグインと Web IDE

• コード支援プラグイン: 言語サーバー プロトコル (LSP) に基づくエディター拡張機能。レイヤー 3 推論ゲートウェイに接続し、コードの作成時にコンテキスト (Fill-in-the-Middle) で補完、ドキュメント コメント、および単体テスト生成の提案を提供します。
• 組み込み静的検査: このプラグインには、リアルタイム スキャン用の軽量 AST パーサーが組み込まれており、一般的な危険なパターンに対して組み込みアラームとワンクリック修復の提案を提供します。アラーム ルールはモデル出力のような補助参照として位置付けられており、手動監査や正式な監査レポートに代わるものではありません。
• クラウド Web IDE: ブラウザ バージョンの IDE はコンソールに埋め込まれています。ワンクリックで分離コンテナ環境を開始し、コンパイルとテストを実行できます。 §5.6 のサンドボックス ランタイムと同じ分離およびクォータ メカニズムを再利用します。

7.3 プリセット業界エージェントマトリックス

プラットフォーム計画では、すぐに展開できる 3 種類の商用エージェント テンプレートが事前設定されています (オンライン プランについては第 9 章フェーズ 3 を参照)。これらはすべて、§7.1 のオーケストレーション システムで実装され、第 6 章のモデル サービスを推論バックエンドとして使用します。

• コードおよびセキュリティ評価アシスタント: 複数役割のコラボレーション ワークフロー - プロトコル構造分析、公開脆弱性データに基づくユースケース生成、サンドボックスでの動的検証、および構造化された結果の概要。ワークフローの最下層は、ReAct や CoT などの主流の推論モードとモデル ルーティングをサポートし、入力の複雑さに応じてコストと精度のバランスを自動的にとります。出力は内部参照レポートであり、正式な CVSS 評価は含まれていません。正式な監査は資格のあるパートナーによって発行されます (まだ決定されておらず、確認後に開示されます)。
• オンチェーンデータ調査レポートエージェント: 分散型取引所の取引量、融資契約ロックアップの変更、およびクジラアドレスの変更を監視し、時系列分析を組み合わせて定量的な調査レポートを定期的に作成します。データソースとキャリバーは公開されています。調査とレポートのエージェントは、再配布の許可があれば公開データ ソースにのみアクセスします。商用データの提供者は、アクセスする前にライセンス契約への署名を完了する必要があり、認可状況は製品ドキュメントで開示されます [データソースのリストと認可状況: リリース前に補足および開示 · D-27]。
• エンタープライズ ナレッジ ベース Q&A エージェント: ベクトル データベース + ハイブリッド検索 + マルチテナント分離、企業およびコミュニティ向けの FAQ およびナレッジ Q&A。回答にはソースの追跡可能性が付いており、ソースを追跡できない質問は「回答拒否」として扱われます。

7.4 オープンプラットフォームと統合レジ

• オープン API ゲートウェイ: サードパーティ SaaS プロバイダー (IDE ベンダー、セキュリティ ツール ベンダー、データ端末など) に暗号化された API アクセスを提供し、呼び出し数、同時実行数、シート数に基づいた権限とクォータ管理をサポートし、請求書の詳細のエクスポートを提供します。
• 混合取得: 統合キャッシャーは現在、安定通貨 (USDT/USDC) を受け入れます。法定通貨決済チャネルは、必要な許可を取得した場合にのみ開設でき、取得主体と決済サービスプロバイダーがそれを決定および発表します。これ以前は、統合キャッシャーは並行した法定通貨入金チャネルを提供していませんでした。チャネルが開設された後、テナントは必要に応じて法定通貨チャネルと安定通貨チャネルのどちらかを選択できます。すべてのトランザクションはプラットフォームによって均一に測定され、調整されます。法定通貨の取得には決済サービスと資金保管の取り決めが含まれますが、これは §2.4 と同じです。必要な許可を取得するまでは該当する業務は実行されません [取得者および決済サービス提供者: 確認後の公表 · D-28]。オンチェーン自動交換やドリップ配当などの表現は使用されなくなりました。オンチェーン決済は§8.6 プロトコル層のオプション機能にすぎず、規制上の評価が通過した後に別途発表されます。

法定通貨取得の執行可能性に関する取り決め: 取得主体と決済サービスプロバイダーが決定され公表されるまでは、プラットフォームは法定通貨入金チャネルを開設せず、統一レジッシャーは安定通貨（USDT/USDC）決済のみを受け入れます。法人顧客に対する回収、返金、調整の手順は、認可を受けた取得事業体と広報ページに開示されているそのサービス条件に従うものとします。取得者の開示は開示クローズドループ追跡フォーム (§2.2、付録 C No. D-28) に含まれており、これが法人顧客向けに法定通貨チャネルを開設するための唯一の前提条件です。

7.5 AaaSの決済と会計

決済リンク: ユーザーのタスク → エージェント サービス → モデルとツールの呼び出し → コンピューティング能力の実行 → 統合測定 → 収益は貢献度に基づいてエージェント開発者、モデル当事者、コンピューティング能力当事者に分配されます。会計ルールは公開されており、記録は監査のためにエクスポートできます。

8番目第8章 トークン経済モデル

8.1 設計原則

• 実質収入を優先する: プラットフォームの価値の根幹は、トークンの流通市場価値ではなく、サービス収入です。
• 固定総額: A12 は最初に 100,000,000 個で発行され、追加発行されることはありません。
• インセンティブと決済の分離: サービス決済は法定通貨/安定通貨建てです。トークンはインセンティブの発行、料金割引、ガバナンス提案に使用され、テナントはトークンの保有を強制されません。
• すべての数学的計算: この章の各メカニズムには制約と例が付属しており、「未公開パラメーター」に依存する隠れた矛盾はありません。

8.2 トークン配布モデル

チームの0%予約インセンティブメカニズムの説明: チームはトークン株を保有していません。これは、チームの収入が流通市場のトークン価格から完全に切り離されていることを意味します。チームの通貨保有による売り圧力はなく、代理保有やダークプールもありません(チームはその名前で実現可能なトークンポジションを持っていません。これはオンチェーンの透明性と第三者監査によって検証できます)。チームと運営経費の実際の収益は、トークンの実現ではなく、運営主体の株式価値の上昇とサービス収入から得られます。この設計の代償として、チームのインセンティブと通貨価格の関係が弱まってしまいます。したがって、収益に連動した買い戻しと破棄（§8.3）を通じて、サービス収入の増加はすべての保有者の共通の利益に変換され、間接的な合意が形成されます。

エアドロップ循環の分析形式と微分形式 (t は打ち上げ後の月数):

生態系プールの年間上限を重ね合わせた後の総循環曲線を図 8-1 に示します。供給拡大速度には数学的に制限があり、買い戻しと燃焼により実際の循環は上限を下回ります。

図 8-1 トークン供給リリースモデル: 線形エアドロップ + エコロジカルプールの年間上限 (再購入と破壊により実際の流通量は減少)

8.3 買戻しと破棄のメカニズム

• 破壊の原因: プラットフォームは、前四半期の実質ネット サービス収益の 20% (初期比率はガバナンスの提案によって調整可能、上限は 30%) を使用して流通市場から A12 を買い戻し、それを破壊します。

純利益の監査基準 (基準操作の余地の排除):

このうち、GrossRevenue_q は、その四半期のプラットフォーム サービス収益の合計です (すべて CaaS/MaaS/AaaS から受け取った収益)。 C_compute_q は、コンピューティング電源の調達とノード共有のコストです。 C_infra_q は、検証クラスターや帯域幅などの直接的なインフラストラクチャ コストです。人件費、マーケティング費、管理費は控除の対象外です（営業損失が「低純利益」に転嫁されるのを防ぐため）。四半期ごとの 3 つのデータは、第三者の会計事務所による保証報告書が発行された後、破棄取引とともに公開されます。保証機関は、国際4大ネットワークのメンバーファームまたは同等規模の資格を有し、Web3やテクノロジー企業の監査経験があり、運営主体およびその関係者との独立性に問題がないことを基準として選定されます。パブリックベータ開始前に委託を完了し、代理店名を公表することを目的としています[認証代理店：確認後公式ルートを通じて発表・D-12]。

• ハードキャップ: 四半期ごとの破棄額は、その四半期の買戻し予算の 100% を超えてはなりません (つまり、四半期の実際の買戻し収益のみを破棄でき、準備金や借り入れ資金を破棄に使用することはできません)。そして、エコロジカル共同建設プールの残量が 5,000,000 未満になると、破壊は一時停止され、長期インセンティブ プールが枯渇しないように再購入部分がエコロジカル プールに注入されます (このしきい値は長期保護条項です。年間リリース制限は 10,000,000 です。5 年以上の運用後にトリガーされる可能性があると推定されています。パブリック ベータおよび初期運用段階では、 「四半期の破棄 ≤ 現在の四半期の買戻し予算」が実際の制約です)。
• 計算例: ある年のプラットフォームの純サービス収入が 2,000,000 米ドルで、その年の再購入予算が 400,000 米ドルであると仮定します。四半期ごとの執行、市場価格の購入、およびオンチェーンの公開破棄トランザクション。破壊の量は完全に実質所得によって決まります。所得ゼロは破壊ゼロを意味し、「デフレ物語を維持するために埋蔵金を売却する」インセンティブはありません。

買戻しと循環供給の会計式。四半期ごとの再購入予算と破棄数量は次のように定義されます。

このうち、VWAP_q は四半期内の取引の加重平均価格、ΔS_q は四半期内の燃焼量です。これは、単一時点での価格ではなく取引量の重み付けに基づいて実行されるため、タイミングや操作の余地が制限されます。破棄トランザクションはチェーン上で発表され、「純利益伝票→買戻しトランザクション→破棄トランザクション」という 3 つのセクションのリンクをたどることで、誰でも独立してそれを検証できます。

循環供給曲線。エアドロップ プールがオンラインになった後の累積発行部数は、§8.2 に示されているリリース式に従います (最初の月は 600 万部、その後毎月 100 万部ずつ直線的に増加し、24 か月目には上限の 3,000 万部に達します)。生態系プールの「年間放出量 ≤ 10%」という厳しい上限 (§8.2) を重ね合わせると、循環ディスクの拡大速度は数学的に制限され、これは買い戻しと破壊の縮小効果と一致します。上記の式により、「リリースリズム - 売り圧力管理 - 収益買い戻し」を独立して計算することができ、未公開のパラメータに依存する隠れた矛盾を回避できます。

8.4 エアドロップとポイント

公開テストと初期の貢献はポイントを通じて記録され、公開ルールに従ってトークンのエアドロップに変換されます。ポイントの獲得は、有効な作業負荷 (完了したタスクの量、検証合格率、オンライン時間) に関連付けられており、単純なアカウントの数とは切り離されています。エアドロッププールの 20% は発売の最初の段階でロック解除され、残りの 80% は発売時の集中的な販売圧力を避けるために 2 年以内に直線的にリリースされます (§8.2 を参照)。パブリックベータ期間中のキャリバーのコミットメント: ポイント測定キャリバーは、ローンチ後のCU・期間の決済キャリバーと同じです。変換係数は調整可能で、測定キャリバーは変更されず、変換原則はパブリックベータの開始前に発表されます。パブリックベータ期間中の決済通貨、支払主体および決済サイクル [リリース前の補足および公表・D-29] (§9.2「定時決済レート」とは、公表期間に応じた全額支払いの割合を指します)。 USDT クレジット デポジットは、高価値タスクの場合はオプションであり (いつでも引き換えることができ、引き換えると評判がリセットされます)、トークン ステーキングに依存しないパブリック ベータ ウィンドウでの悪のコストの下限を提供します。

変換係数の調整に関する制約: ポイント変換係数の調整には 3 つの制約があります。1 回の調整の振幅は ±20% を超えてはなりません。 2 回の調整の間隔は 90 日以上とする。減額の場合は 30 日前までに公告ページで発表し、その理由を説明する必要があります。すべての調整記録は検査のために保存され、調整手順と上限はガバナンス憲章（§8.7）の開示範囲に含まれており、「測定口径が変わらない」ことが「為替レベルが一方的に下方調整できる」ことを意味しないことを保証します。

初回換算係数の決定：上記の三重制約（±20%/90日前/30日前）により「既存係数の調整」が規定されます。初回係数は以下のルールに従って決定されます - 決定原理：パブリックベータ期間中の積分測定口径と打ち上げ後のCU・時間決済口径の換算基準によって固定されます。つまり、初回係数は「2つの口径の下での単位実効仕事量の等価性」「CU時間」の逆数であり、口径の切り替えによってポイントホルダーの相対位置が変化しないようにします。主体の決定：ガバナンスに関する提案を聞いた上で運営主体（プラットフォーム側）が決定し、大きな差異はガバナンス憲章に定められた手順に従う。開示時期: 遅くともパブリック ベータの開始前 (インセンティブ活動を含む)、§8.5 のインセンティブ活動規則と同時に発表され、ガバナンス憲章 (§8.7) の開示範囲に含まれます。初回係数が決定されると、その係数は三重制約によって管理され、その決定根拠と測定記録は開示クローズドループ追跡フォームとともにファイルされます。

8.5 パブリックベータのインセンティブの説明

公開テストとエアドロップは、前提条件として §2.4 に記載されているライセンスのステータスと証券の法的意見の対象となります。具体的な日付は、条件が整った後に別途発表されます。ライセンスを取得する前に、インセンティブなしのオープン ネットワーク公開テスト (トークンの発行は含まれず、ネットワークと製品の機能のみを検証します) を実行できます。トークンのエアドロップを含むインセンティブ活動は、必要なライセンスを取得し、法的意見の審査を完了した後に開始されます。インセンティブ予算の合計 (インセンティブ活動の開始時に実行): 30,000,000 A12 (つまり、エアドロップ プールの全額、配分は §8.2 のリリース リズムに厳密に従います。6,000,000 ポイントは最初のフェーズでロック解除され、残りの 24,000,000 ポイントは 2 年間で直線的にリリースされます) + 5 BTC + 900,000 USDT はすべて運営主体（プラットフォーム当事者）の自己資金により負担される。イベントルール、参加資格、報酬総額、受け取り条件はプラットフォーム公式サイトで公開されます。トークン報酬には、§8.2 のリリース規則が適用されます。法定通貨とBTCの報酬は運営予算に含まれており、総額上限があり、「インセンティブと決済の分離」の原則に抵触しません。

地理的なコンプライアンスの境界: パブリック ベータのインセンティブおよびエアドロップ活動への参加は、KYC および制裁リストのスクリーニングに合格する必要があります (§2.4 を参照)。次の地域のユーザーは、トークンのエアドロップとインセンティブの配布に参加することはできません: 国連安全保障理事会の制裁リストおよび OFAC の制裁対象地域。中国本土（国内の規制要件に従って、国内居住者にはいかなる形態のトークンインセンティブも発行されません）;プラットフォームのリスク管理によって特定されたその他の高リスク管轄区域。米国ユーザーの参加資格については、証券法的見解の公表後に発表される予定です。欧州連合 (MiCA 規制)、英国 (FCA)、シンガポール (MAS)、韓国、日本、および暗号資産に対する明確な規制要件があるその他の法域、そのアクセス状況、およびコンプライアンス経路は、公式発表の対象となります。完全な地域アクセス条件は、公式 Web サイトのイベント ルールで発表され、収集プロセス中に 2 回確認されます。

8.6 プロトコル層

このプラットフォームは、ロードマップの中核期間中に独自のパブリック チェーンを開発しません。決済と証明書のデポジットのプロトコル層は、成熟したパブリック チェーン/L2 にスマート コントラクトを展開することによって実装されます。コントラクトは、決済証明書のデポジット、破棄と公開、および (規制が許可する場合) 安定した通貨決済チャネルを担当します。独自に開発したコンセンサスチェーンは、どの段階においてもコミットメントの範囲内には含まれません。 DEX 関連の計画は 2 つの理由で中止されました。1 つは、自社で構築したオンチェーン取引所およびマーケットメイク機能が中核となる研究開発リソースの集中を妨げることであり、これは §9.1「リソースはスケジューリング プラットフォーム、コンソール、MaaS、および AaaS の 4 つの製品ラインに集中する」の原則に反します。第二に、DEX には複数の管轄区域における分散型トランザクションのライセンスに関する不確実性が伴い、コンプライアンスへのパスが明確になるまでレイアウトはありません。トークンの流動性は、オープンで透明な市場慣行に従って、伝統的な方法で専門のマーケットメイキング機関によって提供されます。初期流動性は、§8.2 流動性およびマーケットメイキングプール (10%) から注入されます。具体的なマーケットメイク機関名および協力条件はオンライン化の1週間前に公式ウェブサイトで公表されます[マーケットメイク機関：オンライン化の1週間前に確認後公表・D-30]。

破棄パブリック コントラクトの参照インターフェイスは次のとおりです (最終的な実装ではなく、フェーズ 4 の成果物が示されています。イーサリアム EIP 標準インターフェイスと OpenZeppelin の監査慣行から教訓を引き出します)。

収益管理およびスラッシュの参照契約インターフェース (破棄契約と同じプロトコル層ステージ 4 成果物表示に属しており、最終化されていません。その「収益の遅延リリース + 条件付きスラッシュ」構造は、Filecoin のマイナー権利確定/スラッシュ契約と同じ起源を持っています):

セキュリティ監査計画: フェーズ 4 の展開に入る前に、上記の契約は独立した第三者セキュリティ機関による完全な監査を完了する必要があります。選択基準は §8.3 の保証機関と一致しています (国際ネットワークのメンバー企業、または Web3 契約監査の資格を持ち、運営主体との独立性の問題はありません)。監査報告書の全文が公開される。監査が通過する前に、契約はメインネットワークを展開せず、実際の資金の保管および没収プロセスに接続されません。

8.7 ガバナンス

プラットフォーム運用の決定 (スケジュール戦略、価格設定、リスク管理ルール) は運営主体の責任です。生態学的ガバナンスは、A12 グローバル ガバナンス DAO を通じて実行されます。

DAO は、コミュニティ貢献者、業界クリエイター、技術貢献者、優秀な人材を歓迎します。グローバル ガバナンス席は合計 300 席あり、そのうち 40 席が第 1 フェーズで開設されます (公式採用発表の対象となります)。

ガバナンスメカニズム（設計目標の口径、パラメータはガバナンス憲章の発表の対象となります）：メンバーは「自己推薦申請＋コミュニティレビュー発表」によって選出され、任期は12か月で、再選は1回です。提案は投票する前にメンバーの 10% 以上の署名を取得する必要があります。一般事項は単純過半数で可決され、法定参加率は 25% 以上である。分配パラメータの調整や罰則および没収規則の変更などの主要事項は、3 分の 2 以上の多数決でなければなりません。決議は運営主体によって期限内に実施され、実施結果は公式ウェブサイトで発表されます。理由なく 3 回連続で投票を欠席したり、利益回避規則に違反したメンバーは除名されます。この技術キャリアは、オフチェーンのスナップショット投票 + オンチェーンの公開および証明書ストレージを使用します (§8.6 プロトコル層と一致し、自社構築のパブリック チェーンに依存しません)。

DAO会員の権利:

• 環境に関する提案、投票、主要なイベントのガバナンスに参加します。
• プラットフォームのルールおよび関連するガバナンスの決定に参加します。
• 環境への貢献に基づいて、対応するインセンティブを獲得します。
• 特別なポイントと関連する環境上の権利をお楽しみください。
• A12 地球規模のエコロジー構築への参加が優先されます。

DAO と運営主体間の権利と責任の境界 (「集中運営 vs DAO」の緊張を排除): DAO は、プラットフォーム運営層ではなく、エコロジーガバナンス層です。生態学的事項はDAOによって実質的に決定されますが、プラットフォームの運営に関する事項は運営主体の責任であり、DAOの勧告が受け入れられます。境界は次のとおりです。

この区分は、§2.1「集中運用 + 分散実行」の位置づけと一致しています。つまり、プラットフォーム運用の責任主体は独自かつ明確であり (「何も言わない」という装飾的なガバナンスを避けるため)、生態資源の配布権は基本的に DAO に引き渡されます (「疑似分散化」の認識を避けるため)。

ガバナンス買収防止メカニズム（設計目標の規模、詳細はガバナンス憲章の発表による）： ① 提案の二重閾値 - 単一の低コストシートが直列に接続されるのを防ぐために、提案は議席の10％以上の共同署名と提案者の最低通貨保有/評判の閾値を満たさなければなりません。 ② 一回の提案金額の上限 - 生態系プールの提案に使用できる金額 ≤ 生態系プールの未公開残高の 5% であり、大きな事項については個別に投票される。 ③ 利益回避 - 提案者およびその関係者は、自らの利益となる提案に投票することはできません。違反者の提案は無効となり、上場廃止プロセスが開始されます（「利益回避」の定義はガバナンス憲章に記載されています）。 ④ 緊急停止 - 運営主体は違法または悪質な提案の実施を最大 14 日間停止し、その理由を公表することができる。制限時間を過ぎても復元されない場合は、DAO の全投票に提出する必要があります。 ⑤ 同一基準の認証 - エコロジカルプールの発行と第 8.3 条の買い戻しおよび廃棄は、同一の第三者会計保証および開示基準に従う。 ⑥ リストの第 1 段階が最初に行われる - 選出基準と第 1 段階の 40 議席の選出リストは、DAO の発足前に発表される。

9番目第 9 章 テクノロジーロードマップ

9.1 リソース重視の原則

コア リソースは、スケジューリング プラットフォーム (レイヤー 1/2)、テナント コンソールおよびサンドボックス ランタイム、モデル サービス (MaaS、最初の垂直モデル パイプラインを含む)、および AaaS ツール チェーン (オーケストレーション キャンバス + 開発者ツール + プリセット エージェント) の 4 つの製品ラインに集中しています。残りの方向性 (クロスベンダーの深い適応、プロトコル層の深化、およびより垂直的な産業モデル) は長期的な実験項目であり、ロードマップに入る前に前段階の終了基準を通過する必要があります。

9.2 段階的なロードマップ (終了基準を含む)

9.2.1 合格報告仕様書（固定付属品）

各段階の終了時に、合格レポートが公開されます。レポートは「9 つの固定フィールド + ステージ用の追加フィールド」の 2 つの部分で構成されます。固定フィールドは段階によって調整されません。 ① ノード スケール (登録済み/アクティブ/標準ノードの数、リソース階層ごとに分割。クロスアイデンティティ重複排除統計を含む - 宣言されたデバイスの数/重複排除後のデバイスの数/差分、§4.5 のシリアル番号とのグローバルに一意かつ相互に排他的な対応)。 ② タスク量（当期のタスクの総数とタスクの種類別の分布）。 ③ 検証合格率 (§4.2 L2 および L4 レビュー校正統計による)。 ④ スケジューリング成功率（柔軟なベストエフォートモードと専用保証モードを区別する、初回スケジューリング成功の割合）。 ⑤ インスタンスのコールドスタート P50/P95。 ⑥ TTFT P50/P95 (≤ 8K コンテキスト ギア、32K ロング コンテキスト ギア シングル カラム); ⑦ GPU ペイロード レート (連続バッチ処理装置、P50 かかります)。 ⑧ 事故リスト（事故レベル、影響期間、根本原因、是正項目） ⑨ 不適合項目とその理由（この段階での Go/NoGo 基準を 1 つずつ比較し、偏差値と属性を列挙します）。ステージの追加フィールドは、リリース発表の各ステージごとにリストされており、追加のみ可能ですが、削減はできません。固定フィールドは削除または置換できません。最初の受け入れレポートは、フェーズ 0 の終了後 7 日以内、および後続の各フェーズの終了後 7 日以内にリリースされます。次のフェーズに入る唯一の条件は、前のフェーズの基準がすべて満たされ、受入レポートが公開されることです (暦日は確約ではありません)。この独占性に関する声明は、資金調達の進捗状況、市場窓口、または人材の手配による例外の対象にはなりません。

9.3 フロンティア技術の展望（研究範囲）

A12 の長期的な青写真は、一文に要約できます。世界中のすべてのアイドル状態の GPU を、統一された信頼できるインターフェイスを通じて AI バリュー チェーンに参加させ、インテリジェント エージェントをコンピューティング パワーのネイティブ コンシューマーにさせます。 「CaaS → MaaS → AaaS」という垂直方向のバリューチェーンに沿って、テクノロジーの進化は 3 つの領域に分かれています。

重点注記: この章では、プラットフォームのコア機能 (スケジューリング、推論、エージェントの実行) に直接関連する指示のみを意図的に保持します。フェデレーテッド ラーニング、差分プライバシー、準同型暗号化、モデル透かし、カーボンアウェア スケジューリング、WASM サンドボックス、ポスト量子暗号などの、より長期的または分野を超えた方向性については、この記事では説明しません。垂直産業の拡大に伴い、「すべてをやりたいのに深くは何もしない」という認識を避けるため、後続の技術ブログで別途説明します。

Horizo​​n 1: コンピューティング パワー レイヤー (現在 → 2027 年) - 分散コンピューティング パワーを「信頼でき、利用可能で、スケジュール可能」にします。

Horizo​​n 2: モデルと実行層 (2027 → 2028) - 最先端のモデル効率と分散実行を密接に結び付けます。

Horizo​​n 3: エージェントおよび経済層 (2028+) - エージェント経済のための決済インフラストラクチャ。

エージェントがコンピューティング能力の主な消費者になると、スケジューリング プラットフォームは「人々のためのクラウド」から「エージェントのためのコンピューティング能力市場」へと進化します。

• MCP/A2A ツールとコラボレーション プロトコル (§7.1 を参照): エージェントは、標準プロトコルを使用してツールを検出し、タスクを委任し、相互認識ステータスを検出します。
• テスト時のコンピューティング: CoT/ToT/マルチサンプリング投票などの戦略を通じて、モデルは困難な問題について「さらに考える」ことができ、コストと品質を引き換えることができます。スケジューリングプラットフォームは、これに基づいて「高速/標準/深さ」の 3 レベルの推論サービスを提供します。
• エージェントの自律決済: エージェントは、事前に設定された予算と戦略に基づいてコンピューティング能力 (入札、価格ロック、パッケージ) を独自に購入し、決済記録は監査可能です。これは、§8.6 のプロトコル層のスマートコントラクト決済機能に関連付けられています。
• コンピューティングのパワーファクターの市場化: 評判、エシュロン、SLA、およびリアルタイムの需要と供給が一緒になってオープンなコンピューティングパワー価格シグナルを形成し、リソースの価格設定を「リストシステム」から「市場ベースのマッチング」に進化させることができます。

前述の Horizo​​n 1 と 2 はエンジニアリングの進化の経路であり、Horizo​​n 3 は方向性のあるビジョンです。この 3 つの関係は、レイヤーごとの依存関係と段階的な検証です。信頼できるコンピューティング パワー レイヤーがなければ、効率的な実行レイヤーは存在しません。また、実行レイヤーの規模がなければ、インテリジェントな経済レイヤーの決済要件も存在しません。このセクション全体は、第 10 章の将来予想に関する記述の対象となります。

10番目第 10 章 リスク要因と免責事項

• 実行リスク: プラットフォームの提供は、コア エンジニアリング チームの可用性と安定性に依存します。チームの開示情報については、§2.2 を参照してください。読者は、完全な開示を行う前に、関連するリスクを独自に評価する責任があります。緩和: 段階的なロードマップは定量的な Go/No-Go 終了基準を設定し、各フェーズの受入レポートは §9.2.1「受入レポートの仕様」に従って発行されます (フェーズの 9 つの固定フィールド + 追加フィールド、フェーズ終了後 7 日以内にリリースされます)。
• 技術的リスク: コンテナを隔離しても、脱出リスクをすべて排除できるわけではありません。認証システムはオーバーブッキングを完全に防ぐことはできず、経済的および運用上の手段によってのみ抑制できます。クロスベンダー適応の構築期間には不確実性がある。垂直モデル パイプラインのコーパス構築とトレーニング効果には不確実性があります。緩和: コンテナの隔離 + 使用状況のレビュー + 乱用補償基金の 3 層保護 (§4.7 を参照)。オーバーブッキングを抑制するための SLA プライマリおよびバックアップの冗長性およびレピュテーションアドミッション (§5.3、§4.5 を参照)。
• 市場リスク: コンピューティング電力価格の変動、クラウド ベンダー間の競争、AI 負荷構造の変化は、プラットフォームの収益想定に影響を与える可能性があります。軽減策: デュアルパス スケジューリングはタスクの特性に基づいて最適なルートを選択し、収益構造は CaaS/MaaS/AaaS の 3 つのレイヤーをカバーし、単一市場への依存を軽減します (§5.2、§3.1 を参照)。
• 規制リスク: デジタル資産関連の活動は、管轄区域ごとに異なる要件に直面しており、トークンの利用可能な機能は監督によって調整される可能性があります。ハイブリッド取得機能とプロトコル層機能は規制上の評価の対象となります。軽減策: 管轄区域ごとのアクセスマトリックスと収集プロセスの二次検証 (§8.5 を参照)。ライセンスを伴う事業は、ライセンスを取得するまでは実行されません (§2.4 を参照)。
• スマート コントラクトのリスク: スマート コントラクトには、未発見の脆弱性 (再入可能、整数オーバーフロー、権限設定エラーなど) がある可能性があります。第三者によるセキュリティ監査が完了する前に、契約のやり取りで資金が損失するリスクがあります。軽減策: 契約には、決済伝票を預けて破棄するためのプロトコル層のオプション機能のみがあります (§8.6 を参照)。導入前に、独立した第三者による監査に合格し、監査レポートの全文を公開する必要があります。監査前はメインネットワークには接続されず、実際の資金は接続されません。
• 将来の見通しに関する記述: このホワイト ペーパーに含まれるすべての指標は設計目標であり、すべてのロードマップは計画であり、収益を約束するものではありません。実際の結果は計画と大きく異なる可能性があります。
• 免責事項: このホワイトペーパーは、投資アドバイス、証券発行文書、または法的アドバイスを構成するものではありません。第三者の商標に関する権利は、それぞれの権利所有者に帰属します。

付録付録 A 用語集

付録付録 B チャート索引

図: 図 3-1 4 層アーキテクチャの階層図 (§3.2)。図 4-1 5 層の検証システム (§4.2)。図 5-1 デュアル パス オフロード (§5.2)。図 5-2 タスクのライフサイクル ステート マシン (§5.5)。図 6-1 KV キャッシュ容量モデル (§6.4)。図 8-1 供給リリース モデル (§8.2)。

主要な表: 必須開示リスト (§2.2)。閉ループ クリティカル パスの開示 (§2.2)。 8項目の事業体情報開示状況表（§2.2）。約束された支出とリソース保証の表 (§2.5)。設計参照システム (§3.4)。リソース段階のスケジューリング制約 (§5.4)。受入レポートの固定フィールド (§9.2.1)。 DAO 運営主体の権利と責任の境界 (§8.7);トークン割り当てモデル (§8.2)。買戻しおよび破壊パラメータ (§8.3)。リスク要因 (第 10 章);用語集 (付録 A);開示クローズドループ追跡表 (付録 C)。チャートパラメータ表 (付録 D)。

付録付録 C 開示クローズドループ追跡フォーム (D-01 ～ D-30)

この表は、「開示クローズドループ追跡フォーム」の全文であり、§2.2 開示リスト表の「番号」列に 1 行ずつ対応し、全文で補足すべき事項をすべて網羅した全 30 項目からなります。運営主体の登録情報 (§2.2 の最初の行) は提供されており、公的に検証することができ、補足される数を占めません。番号付けの口径: 旧版では 21 個の番号が記載されていましたが、実際には全文で追加されるマークは 30 個あります (9 個の登録漏れ)。この版では、30 個のマークを 1 つずつ D-01 から D-30 として登録しました。これは、新たな約束ではなく補足的な登録です。この版のテキストマークは 26 に集約され、異なる章に同じ事項が繰り返し登録されている場合は、同じ番号に統合されます。分割や統合によってコミットメントの範囲が変更されることはありません。番号付けの粒度: 独立してクローズでき、外部によって独立して検証できるデータ ポイントは、独立した番号に分割されます。たとえば、「財務状況の開示」は、規模範囲 (D-17)、投資口座 (D-18)、および 12 か月の資金ギャップ (D-19) の異なるデータ ソースと商業的機密性により分割され、3 つは個別にクローズできます。同じ開示行為に対する複数のマークには、重複する番号がありません。フィールドキャリバー: 要件フォームは、問題を外の世界に提示する方法を指します。現状を「補足予定・補足・実証・公表」の3段階に分けています。コミットメント日は、目標コミットメント日（非契約コミットメント）であり、運営主体の責任者の承認後に発効します。リズム キャリバー: コミットメント日が評価ノードとなり、期限を過ぎた場合は期限超過処理ルールがトリガーされます。毎週の更新はプロセスの開示であり、約束日が優先されます。広報リンク: この列は広報ページのアンカー ポイントを示します。ルート アドレスの移行期間は aeliontwelve.vercel.app/disclosure です (§2.2 ダブル ドロップイン ポイントを参照)。完全なアドレス = ルート アドレス + アンカー ポイント。公式ウェブサイトのメインドメイン名がアクティブ化されてから 72 時間以内に、このコラムと広報ページが同時に公式ドメイン名に更新され、古いリンクはジャンプとアーカイブを保持します。発表ページの最初のバージョン (この表の 30 項目の初期ステータスを含む) は 2026 年 9 月 21 日までにオンラインになり、それ以降は毎週月曜日 (UTC) に更新され、すべての履歴バージョンが保持されます。担当職: 8 項目の対象情報については、§2.2 の 8 項目のステータス表を参照してください。残りの事項は、事業体の対応する機能責任者が負担します。期限超過の処理: 期限を過ぎてもクローズされていない案件がある場合、§2.2 の 8 項目の表の下にある規則が適用されます (理由と改訂日は 5 営業日以内に記載されます。2 回連続の期限超過については、修正指示を公開する必要があります)。このテーブルは同時に更新され、すべての履歴バージョンが保持されます。

付録付録D チャートパラメータ表（図5-1 / 図6-1）

この付録では、追跡番号 D-21 および D-22 に対応する図 5-1 および図 6-1 の再計算パラメータ テーブルを提供します (ステータス: 補足および検証保留中)。サポート パス: 表内の値は、§5.2 ホックニー通信モデル、ルーフライン スループット推定、および§6.4 M_KV 式に従って取得された設計推定値です。サポート方法は、フェーズ 0 の内部テスト中にプラットフォーム検証クラスター内の 5 種類のタスクと 2 つのモデル レベルの実測と再計算です (50 ～ 100 の NVIDIA スタック ノードが招待されます。§9.2 を参照) - 実測 T_comm/T_compute/Video メモリ使用量はこの表と項目ごとに比較され、実測記録は公告ページに保管されます。第三者も、この付録のパラメータに従って独自に再計算し、比較することができます。バージョン管理の識別: 2 つのパラメータ テーブルはバージョン管理に従って維持されます。各アップデートにはバージョン番号 (D-1.1/D-2.1 など) と日付スタンプが付いています。すべての履歴バージョンは、簡単に参照および比較できるように /archive アーカイブに保存されます。フェーズ 0 の測定サンプルが拡大するにつれて、パラメーター範囲は四半期ごとに見直され、更新されます。表 D-1 には、T_comm (帯域幅レベルに基づく) と T_compute (ハードウェア ギアの仮定を含む) という 2 つの列も用意されているため、α_comm = T_comm ÷ T_compute を段階的に再計算でき、比だけでなく分母も示されなくなりました。

表 D-1 図 5-1 パラメータ表: α_comm 推定間隔 (帯域幅ごとのビン)、T_comm/T_compute 値および分布属性 (D-21)

表 D-2 図 6-1 パラメータ表: モデルギア (7B/70B レベル)、GQA 構成および KV メモリ使用量 (D-22)

注: 両方の MHA 行は、「GQA 圧縮なし」を比較するためのベースライン行です。圧縮の前後で同じ値が得られるのは予期される動作です。ページング メカニズムはビデオ メモリの断片を削除するだけであり、圧縮は実行しません。そのため、ページングには効果がないと誤解しないでください。圧縮効果は、ベースライン行と比較した GQA 行のビデオ メモリの減少に反映されます (7B レベル 17.2 → 4.3 GB、70B レベル 85.9 → 10.7 GB)。レベル 70B は、§6.4 のテキスト例と同じ構成です (80 層、H_kv = 8、FP16 シングル シーケンス ≈ 10.7 GB)。レベル 7B は、単一カードの同時実行シナリオの典型的なギアです。 2 つのレベルは、それぞれ「圧縮効果の比較」と「1 枚のカードで同時実行を処理できる」という 2 つの再計算目標に対応します。

参照参考文献

この記事で引用した主な学術論文、技術規格、公式文書は以下のとおりです。本文中のメカニズムの名称と式口径は上記の出典に基づいています。 「設計目標」とマークされた指標はこの記事によって独自に定義されており、未検証のサードパーティの測定データは引用されていません。オンラインソースのアクセス日は 2026-09-14 に統一されます。

学術論文

• Hoffmann 他、トレーニング コンピューティングに最適な大規模言語モデル (チンチラのスケーリングの法則、§6.2 を参照)、2022 年、arxiv.org/abs/2203.15556
• Rafailov 他、Direct Preference Optimization: Your Language Model is Secretly a Reward Model (DPO、§6.2 を参照)、NeurIPS 2023、arxiv.org/abs/2305.18290
• Hu et al., LoRA: Low-Rank Adaptation of Large Language Models，2021，arxiv.org/abs/2106.09685
• Dettmers et al., QLoRA: Efficient Finetuning of Quantized LLMs，2023，arxiv.org/abs/2305.14314
• Leviathan 他、投機的デコーディングによるトランスフォーマーからの高速推論 (§6.4 を参照)、ICML 2023、arxiv.org/abs/2211.17192
• Ainslie 他、GQA: マルチヘッド チェックポイントからの一般化マルチクエリ トランスフォーマー言語モデルのトレーニング (§6.4 を参照)、2023、arxiv.org/abs/2305.13245
• Rajbhandari et al., ZeRO: Memory Optimizations Toward Training Trillion Parameter Models，SC 2020，arxiv.org/abs/1910.02054
• Shazeer et al.、法外に大規模なニューラル ネットワーク: スパースリー ゲートの混合専門家層 (MoE、§6.4、§9.3 を参照)、ICLR 2017、arxiv.org/abs/1701.06538
• Micikevicius 他、深層学習用の FP8 フォーマット (§9.3 を参照)、NVIDIA、2022、arxiv.org/abs/2209.05433
• Dao et al.、FlashAttendant: IO-Awareness を使用した高速かつメモリ効率の高い正確なアテンション (§9.3 を参照)、NeurIPS 2022、arxiv.org/abs/2205.14135
• Shah、Bikshandi、Zhang 他、FlashAttendee-3: 非同期性と低精度による高速かつ正確なアテンション (FlashAttendee-3、§9.3 を参照)、2024 年、arxiv.org/abs/2407.08608
• Williams、Waterman、および Patterson、『Roofline: An Insightful Visual Performance Model for Multicore Architectures (§5.2、§6.4 を参照)』、Communications of the ACM、2009 年、doi.org/10.1145/1506609.1506623
• Kahn, A.B.、大規模ネットワークのトポロジカル ソート (§7.1 を参照)、Communications of the ACM、5(11): 558–562、1962、doi.org/10.1145/368996.369025
• Erlang, A.K.、自動電話交換における重要度の確率理論におけるいくつかの問題の解決 (M/M/c および Erlang C キューイング モデル、§6.3 を参照)、Elektroteknikeren、13、1917

技術基準と公式文書

• ERC-20 トークン標準、イーサリアム改善提案 (§8.6 を参照)
• OpenZeppelin 契約のセキュリティ規約 (SafeERC20/Math) (§8.6 を参照)
• Solidity 公式ドキュメント (§8.6 を参照)
• モデル コンテキスト プロトコル (MCP) 仕様 (§7.1、§9.3 を参照)
• NIST ポスト量子暗号通貨 (PQC) 標準化プロジェクト (§9.3 を参照)
• WebAssembly (WASM) および eBPF (§4.7、§9.3 を参照)

設計基準フレーム

• イーサリアム ホワイトペーパー—アカウント システムとガス測定リファレンス (§3.4 を参照)
• Filecoin ホワイトペーパー - 担保の没収と保管証明のリファレンス (§3.4、§4.5 を参照)