RP2040描画モデルは正確なプログラムを実行するが、AIはホスト側に留まる
RP2040描画モデルは12,670件のハードウェアテスト向けにコンパクトなプログラムを生成したが、825,344パラメータのトランスフォーマー自体はマイクロコントローラー上では一度も動作していない。代わりに、ホストコンピューターが描画バイトコードを生成し、それをRaspberry Pi Picoへ送信して決定論的に実行させる。
この違いが、このプロジェクトの価値と限界の両方を規定している。小型デバイスが有用な生成モデルをローカルで実行できる、という新たな主張ではない。不確実なニューラル生成と、正確で制約された実行を切り分ける実験である。
このシステムは、一般的なピクセル生成のアプローチに疑問を投げかける。小型トランスフォーマーが実行可能な記述を書き、それを予測可能に振る舞う最小限のマシンに引き渡せるかを検証するものだ。ハードウェア上の結果は非常にきれいに見える一方、モデルが未知の構造を組み立てる能力については、はるかに不確かさが残る。
RP2040描画モデルは生成と実行を分離する
中心的な成果は、デバイス上でのニューラル推論ではなく、役割分担にある。
プロジェクトの公開リポジトリによると、825,344パラメータの自己回帰型トランスフォーマーはホストコンピューター上で動作する。各サンプルについて、およそ100バイトの描画バイトコードを生成する。
バイトコードは、別のプログラムが解釈するコンパクトな命令形式である。ここでは、仮想ペンの移動、線の描画、曲線の評価、整数変換の適用、回数が制限されたシーケンスの反復といった操作を記述する。
ホストはそのプログラムをRaspberry Pi Picoへ転送する。小型の仮想マシン、すなわちVMが、PicoのRP2040マイクロコントローラー上で命令を実行する。その後、標準的なシリアル通信インターフェースであるUART経由で幾何座標を返送する。
最終画像は、返送された座標から作られる。Picoはトランスフォーマーの重みを保存せず、行列計算の多いニューラル推論も実行せず、テンソルランタイムも必要としない。生成されたプログラムを解釈するだけだ。
この境界は重要である。「RP2040上のモデル」という表現は、別種の技術的達成を示唆するためだ。825,344パラメータのモデルは、ランタイムメモリを考慮しなくとも、一般的な数値形式では数MBを必要とする可能性がある。
プロジェクトの作者は、こうした主張を明確に避けている。元の議論では、トランスフォーマーはホスト側に留まり、Picoはその出力を保存・実行すると説明されている。
公開されたデモモデルは、猫、バス、花、帆船、自転車という5カテゴリーを対象にしている。自由形式のテキスト画像生成システムとして提示されているわけではない。
この限定された範囲により、結果は解釈しやすくなる。この実験は、幅広い視覚知識を主張することなく、表現、プログラム生成、制約付き実行を研究している。
モデルは、色付きピクセルの格子ではなく命令を出力する。これにより、確率的なAIと決定論的な組み込みソフトウェアの間に有用なインターフェースが生まれる。
ピクセル生成器は、見える結果に直接コミットする。一方、プログラム生成器は、別のシステムが検証、制限、実行、または拒否できるシーケンスを提案する。
この違いが、本稿の主要な緊張関係を生む。ハードウェア実行は正確かつ効率的に見えるが、正確な実行が、生成されたプログラムが意図した描画を表すことを保証するわけではない。
Picoは、不適切な自転車プログラムでも完璧に実行できる。VMが適切な制限を適用していれば、形式不正または過度に長いシーケンスを確実に拒否することもできる。
言い換えれば、実行の正しさと生成の正しさは別の性質である。このプロジェクトは両方を測定しており、その結果は異なる方向を示している。
正確な実行が最も強い成果だ
測定値はプロジェクト独自のテスト成果物に基づくものだが、Picoは一貫して参照インタープリターと一致した。
作者によれば、ハードウェアスイープ中に12,670本の生成プログラムを実行した。返されたすべてのトレースは、Pythonの参照VMと完全に一致したという。
トレースとは、プログラムが生成する順序付きの幾何情報である。完全一致とは、単に似た画像を生成したという意味ではなく、デバイスと参照実装が同一の座標を返したことを意味する。
プロジェクトの実験記録では、12,670件すべてのトレースで許容誤差ゼロの一致が報告されている。また、QEMUベースラインに対して120本中120本の適合プログラムが通過したことも記載されている。
これらは独立した再現実験ではなく、第一者による結果である。それでも、リポジトリにはインタープリター、テスト構造、記録済みトレース、技術的な検証に必要な文書が含まれている。
C言語で実装されたインタープリターは、フラッシュメモリ上で1,862バイトを占めるとされる。この値はVM単体を対象とし、バイトコードの保存領域や周辺の転送ハーネスは含まない。
実装では、VM状態のために静的にRAMを割り当てていない。測定構成におけるスタック使用量のピークは492バイトだった。
意図的に12 MHzまで下げたRP2040クロックで、報告された平均値は1描画あたり7,334サイクルだった。測定対象のQuickDrawプログラムでは、およそ0.611ミリ秒に相当する。
作者は、実行命令あたり1.959サイクルも報告している。これらの測定値はインタープリターの処理に関するものであり、ホスト上でプログラムを生成する時間は含まない。
また、ホストからデバイスへの転送時間や表示処理も除外されている。0.611ミリ秒をエンドツーエンドの生成レイテンシとして解釈すべきではない。
RP2040は、264 kBのオンチップSRAMを備えたデュアルコアArm Cortex-M0+マイクロコントローラーである。Raspberry Piは、RP2040のドキュメントで最大クロック周波数を133 MHzとしている。
このチップにはハードウェア浮動小数点ユニットがない。この制約は、曲線や変換で分数座標を一般的に利用するグラフィックスコードを複雑にしがちだ。
このVMは、固定小数点表現によって浮動小数点演算を回避している。固定小数点では小数値をスケールされた整数として保存し、実装間で予測可能な結果を生み出す。
曲線評価器は、ステップ数が2のべき乗であることを利用する。この制約下では、関連する3次ベジエ曲線の係数を、既知の分母を持つ2進分数として表現できる。
実装は、整数計算の過程でこれらの値を保持するのに十分な小数ビット数を選んでいる。この設計により、測定された幾何処理経路からクロスプラットフォームの丸め差を排除している。
決定論的な算術により、比較も非常に厳密になる。テストでは、画像類似度スコアや各頂点付近の許容誤差を必要としない。
参照実装とデバイスは、同一のトレースを出力するか、出力しないかのいずれかである。この二値的な結果は、視覚的な類似性の主観的評価よりも監査しやすい。
実機テストでは、ホストシミュレーションが見逃した少なくとも1種類の問題が明らかになった。プロジェクト文書では、ベアメタル起動時における周辺クロック初期化の競合状態が説明されている。
この観察は、シリコン上でテストする判断を裏付ける。インタープリターは数学的に正しくても、転送処理や起動シーケンスが実際のボード上で信頼できない可能性がある。
それでも、現時点の証拠には明確な境界がある。テストベンチに適切な電流測定機器がなかったため、作者は1描画あたりの消費エネルギーを測定していない。
リポジトリには、学習済みチェックポイントも同梱されていない。ユーザーはVMを実行し、記録済みキャプチャを再生できるが、ライブでのモデル生成には別途入手したチェックポイントが必要となる。
こうした制約は実行結果を無効にするものではない。外部レビュー担当者が直ちに再現できる範囲と、なお作者の提供物に依存する部分を定義するものだ。
プログラムはピクセルにはない制御を提供する
実行可能な出力により、モデルの振る舞いは制約付きランタイムが検査・制御できる対象となる。
描画プログラムは、操作、制御フロー、幾何学的構造を明示する。ラスター画像が示すのは、最終的なピクセル配置だけである。
この違いは小型デバイスで重要になる。ランタイムは、終了までに許可される最大命令数である燃料制限を設けられる。
ループのネスト、呼び出し深度、変換深度、座標範囲、出力量も制限できる。こうした制約により、モデルが不適切なシーケンスを生成しても、その振る舞いを有限に保てる。
プロジェクトのVMは、完成した描画を保存するのではなく、頂点をストリーミングする。これにより作業メモリへの負荷が減り、リアルタイム制御向けに設計されたデバイスの特性にも適合する。
このアプローチは、計画と実行を分離する他のシステムに似ている。より大きなマシンが高コストな推論を担い、より小さなコントローラーがコンパクトな中間表現に従う。
このパターンは、すでにロボティクス、コンピューター数値制御、プロッター、組み込みインターフェースで見られる。ここでの珍しさは、100万未満のパラメータを持つトランスフォーマーで中間プログラムを生成する点にある。
描画バイトコードは、この実験に特に適している。線、曲線、反復モチーフは視覚的な結果を持ちながら、その実行は汎用プログラミング言語より単純に保てる。
不適切な画像予測は、見栄えの悪い画像を生む。不適切なプログラムは、終了性、有効性、実行時安全性について追加の問題をもたらす。
VMは、意図的に制限された命令セットによって、こうした疑問の一部に答える。任意のメモリアクセスや、一般的なオペレーティングシステムサービスは提供しない。
そのため、このシステムは通常の生成コードよりも、ドメイン固有言語に近い。ドメイン固有言語は、危険または曖昧な操作を減らしつつ、限定されたタスクを支援する。
その結果、制約付きの契約が生まれる。モデルは描画を提案し、インタープリターは固定されたルールのもとで、そのバイト列が何を意味するかを決める。
この契約は、スケッチ以外にも可能性を広げる。同様の構成は、ツールパス、ペンプロッターのコマンド、LEDパターン、簡単なアニメーション、制約付きのインターフェースレイアウトを表現できるかもしれない。
ただし、こうした用途には個別の検証が必要となる。Pico上で幾何情報を正確に扱えることは、安全なモーター動作や物理機械の信頼できる制御を証明するものではない。
対象領域によって、重要となるエラーも異なる。わずかに崩れた花は無害だが、不適切なアクチュエータ経路は装置を損傷させる可能性がある。
したがって、このプロジェクトで最も汎用性の高い着想はアーキテクチャにある。確率的な生成は、信頼された実行境界の外側に置くことができる。
組み込み側のコンポーネントは、小さく、テスト可能で、決定論的なままにできる。プログラムを提案したモデルの複雑さを引き継ぐ必要はない。
この分離により、開発者が障害をデバッグする方法も変わる。生成されたバイト列を検査し、Pythonで再生し、トレースを比較し、デバイス固有の振る舞いを切り分けられる。
ピクセルのパイプラインでは、構造がニューラル活性化の内部に隠れがちである。プログラムのパイプラインでは、明示的な操作上の意味を持つ成果物が残る。
その成果物はログとして記録し、バージョン管理できる。デバイスが受け取る前に、既知のルールに照らして検査することも可能だ。
エンジニアリングチームにとって、これは画像生成器というよりコンパイラパイプラインに近い。モデルは不確実なフロントエンドとして働き、VMは厳格な実行バックエンドとして機能する。
この類推を過度に拡張すべきではない。従来のコンパイラーは明確に定義されたソーステキストを変換するのに対し、このトランスフォーマーは学習済み分布からプログラムをサンプリングする。
それでも、この境界には価値がある。従来型ソフトウェアコンポーネントに、生成された出力が実行できる内容を統制する権限を与えるからだ。
小規模モデルによるプログラム生成は、依然として構成で失敗する
インタープリタは正確に実行するが、transformerは未知の関係性を確実に正確に生成できるわけではない。
このプロジェクトの実験は、予測損失が低くても、サンプリングされたプログラムの信頼性が自動的に高まるわけではないことを示している。この隔たりこそ、本成果を完成済みのシステムではなく研究として扱うべき主な理由である。
ベースラインのフラットな自己回帰モデルは、描画1件あたり489.2ビットという収束済みのテスト損失を報告している。テスト損失が測るのは予測の不確実性であり、サンプリングされた描画が望ましい幾何学的関係を満たすかどうかではない。
著者は、概ね同一のパラメータ予算で複数の表現をテストした。対象にはバイト、個々のビット、型付きトークン、相対座標デルタが含まれる。
合成プログラムコーパスでは、ビット表現はバイトとほぼ同等の性能を示した。報告された差は描画1件あたりマイナス0.67ビットで、不確実性はプラスマイナス0.77ビットだった。
結果は、GoogleのQuick, Draw dataから取得した人間のスケッチでは変化した。このデータでは、ビットレベルのモデリングにより、描画1件あたり11.58ビットのペナルティが発生し、不確実性はプラスマイナス0.60ビットと報告されている。
ビットは評価シーケンスも8倍に拡大した。この実験では、3,200万個のバイトトークンに対し、2億5,400万個のビットトークンを処理した。
報告された評価時間は、バイトでの4分からビットでの48分へと増加した。文書化された構成では、8倍を超える速度低下である。
この対比は、語彙を小さくすれば常に小規模モデルに有利だという単純な主張を弱める。2記号のアルファベットは埋め込みコストを削減するが、その代わりネットワークはバイト境界とフィールド構造を復元しなければならない。
合成パターンでは、その復元は扱いやすかったようだ。より多様な人間のスケッチでは、同じ結果は得られなかった。
型付きトークンは別のトレードオフを導入した。opcodeとオペランドの役割をより明示的に結び付ける一方で、大きな語彙が小規模なパラメータ予算のかなりの割合を消費する。
ある幅広モデルでは、埋め込みテーブルが全パラメータの22パーセントを占めた。この構成は比較対象より描画1件あたり4.87ビット悪い性能だった。
深く狭いモデルは、語彙コストをより効果的に吸収した。これは、サブミリオン規模では表現とアーキテクチャが強く相互作用することを示唆している。
最も示唆的な失敗は、反復する幾何学に関するものだった。モデルは、学習時に存在した範囲内での予測可能な反復を学習した。
既知のモチーフの2つ目のコピーに遭遇すると、その驚きは74パーセント低下した。ある報告構成では、回復指標が0.807に達した。
しかし、性能は5つ目のコピーで崩壊した。これは学習時の最大反復回数をちょうど1回上回る。モデルは抽象的なループ規則ではなく、回数分布を学習しているように見えた。
プロジェクトでは、teacher forcing下での幾何学的互換性もテストした。teacher forcingは、正しい先行シーケンスを与えたうえで、次の正しい要素を評価する。
この設定では、互換性のある継続にはターゲットバイトあたり4.28ビットという大きな優位性が与えられた。報告された補正後の有意水準は0.001だった。
自由サンプリングでは、まったく異なる結果となった。テスト対象の複合形状では、完全な補完の成功率は約1パーセントにすぎなかった。
より単純なフラットステップのケースでは、成功率は7から13パーセントの範囲だった。モデルは文脈を示されれば互換性のある継続を認識できたが、継続全体を自ら構築することはほとんどできなかった。
この乖離は、現代の生成モデリングにおける中心的な問題である。トークンレベルの選好は説得力があるように見えても、自律的なサンプリングの間に小さな局所的誤りが蓄積する。
サンプリングされたすべての出力は、次の予測の文脈の一部になる。座標、opcode、長さの決定が一つでも誤れば、シーケンスは学習時に遭遇した条件から離れてしまう。
RP2040はその意味論的な失敗を修復できない。生成されたプログラムを正確に実行できても、正確な実行はその誤りをそのまま保持する。
階層的計画は尤度よりも長さを改善する
明示的な構造を加えると終了制御は改善したが、プロジェクトの主要な損失指標では描画の確率は低下した。
著者は、同じ825,344パラメータ予算で、フラットtransformerと階層的設計を比較した。これらのシステムはまずストロークの要約を予測し、その後、各ストロークの詳細なbytecodeを生成する。
一方のplannerは自己回帰を用いた。もう一方はdiffusionを用い、反復的なdenoisingステップを通じてノイズを構造化された予測へ徐々に変換する。
どちらの階層型バリアントも、フラットモデルに対して描画1件あたりおよそ40から55ビット劣った。正確なペナルティはplannerの種類と計算予算により異なった。
したがって実験は、階層的計画が同一規模で尤度を改善するという仮説を退けた。より明示的な構造には、測定可能なモデリングコストが伴った。
それでもplannerは出力長をより正確に制御した。長さ分布の誤差は、構成に応じて1.8から3.5バイトの範囲だった。
フラットモデルの対応する差は7.0から13.6バイトに及んだ。早期に停止する、あるいは許容最大長まで継続する可能性がより高かった。
これは些細な実装上の詳細ではない。生成されたプログラムは、有用なコマンドになる前に妥当な境界で終了しなければならない。
平均尤度が優れたモデルでも、早期終了に過大な確率を割り当てれば扱いにくいサンプルを生成し得る。また、長く反復的な末尾を生成することもある。
階層構造はストローク数と局所的なストローク構築を分離した。この明示的な判断により、総尤度が低下しても、生成長の分布は改善した。
共有された要約表現では、diffusionは自己回帰plannerに対して明確な優位性を示さなかった。終了制御の改善はdenoisingではなく、階層構造によるものだった。
後続の命令セット実験でも類似したパターンが見られた。明示的なrepeat-and-transform操作は、モデルがすでに反復幾何を低い驚きで予測していたため、直接的な圧縮効果は限定的だった。
しかし、より短いシーケンスは文脈の利用と終了制御を改善した。報告された生成長誤差は9から11パーセントの範囲まで低下した。
同等のフラットモデルでは、誤差は41から112パーセントの範囲だった。これらは第一者による実験測定だが、意味のある設計上の緊張関係を示している。
ある表現は、従来のテスト損失で勝たなくても生成を助けられる。逆に、損失が低くてもサンプリング時に整形式のプログラムが保証されるわけではない。
この緊張関係は、今後の評価に反映されるべきである。研究者には、有効性、正確な関係補完、終了、新規性、実行挙動のための指標が必要だ。
視覚的品質も重要ではあるが、それだけでは不十分である。2つの描画は見た目が似ていても、そのプログラムは長さ、構造、再利用の点で大きく異なる可能性がある。
記憶は別の未解決の問題だ。小規模モデルは、それらを生み出す変換を学ばずに、馴染みのあるモチーフを再現できる。
リポジトリには、位置、近接性、頻度、座標集合に対する制御が記録されている。これらのチェックは関係性実験を強化するが、学習コーパス全体における新規性を確定するものではない。
より強力なリリースには、checkpoint、学習manifest、生成サンプル、nearest-neighbor分析、再現可能なエンドツーエンドスクリプトが含まれるべきである。
複数の独立した学習seedも、初期化の変化を超えてどの挙動が維持されるのかを明確にする。一部の分布外反復の結果は、すでにseed間で目立って乖離している。
現在のプロジェクトは、否定的な結果を隠さず報告している。これは有用である。なぜなら、コンパクトなモデルが記号的推論者のように振る舞わなくなる地点を、その失敗が特定しているからだ。
次に検証すべきこと
次のマイルストーンは、より大きなギャラリーではない。明示的な関係が未知のプログラム生成を改善するという証拠である。
プロジェクトの現在の方向性は、copy-or-emitアクションを追加することだ。モデルは通常のバイトを出力するか、アフィン変換を伴って先行するソース範囲を参照するかを選べる。
アフィン変換は、直線を保ったまま幾何を平行移動、回転、反射、拡大縮小できる。このシステムでは、対応する操作は整数ベースのままであり、既存の形式のVMで実行可能となる。
この提案はteacher-forcingの隔たりを直接狙っている。モデルはすでに互換性のある関係的文脈に敏感であるように見えるが、自由サンプリングではその関係を正確に完成させることはほとんどない。
明示的なアクションは、変換されたモチーフを再現するために必要な個別判断の数を減らせる可能性がある。1つの正しい関係が、多くの脆弱な座標予測に取って代わるかもしれない。
まず注目すべきシグナルは、未知の組み合わせでの性能である。モデルは、単に馴染みのある反復形状を圧縮するのではなく、学習から除外された正確な関係を生成すべきだ。
評価では、同一のパラメータ予算と学習予算で、フラットなemissionとcopy-or-emitの挙動を比較すべきである。teacher-forcedの選好だけではなく、自由生成における正確な成功がより重要だ。
未知の関係補完が報告された約1パーセントの水準を実質的に上回れば、この仕組みの信頼性は高まる。尤度だけが改善するなら、中心的な生成問題は残る。
2つ目のシグナルは、ハードウェアsweepの独立した再現である。プロジェクトはソースコードと取得済みartifactを提供しているが、現時点ではモデルcheckpointを同梱していない。
外部の開発者がinterpreterを再構築し、conformance suiteを実行し、生成プログラムをPicoに送信して、ビット単位で同一のtraceを再現できるべきである。
そのプロセスでは、compiler設定、clock設定、transport overhead、完全なメモリ会計を報告すべきだ。interpreterのflashとfirmware全体のサイズを区別しなければならない。
再現の成功は実行に関する主張を強化する。不一致があれば、結果がtoolchain、board revision、あるいは文書化されていない設定詳細に依存しているかを特定する助けになる。
3つ目のシグナルは、エンドツーエンドのリソース測定である。現在の0.611ミリ秒という数値は、12 MHzにおけるVM実行を対象としており、host推論やserial転送は含まない。
実用的なデモンストレーションでは、生成時間、検証時間、転送時間、実行時間、レンダリング時間を分離すべきだ。エネルギー測定も組み込み段階のコストを明らかにするだろう。
これらの測定によって、プロジェクトがオンデバイスAIになるわけではない。分割アーキテクチャが有用なシステム上のトレードオフを提供するかどうかが示される。
より大きな教訓は、これらのテスト以前からすでに信頼できるものに見える。小規模な生成モデルは実行可能な中間表現を生成でき、極小の決定論的runtimeは限定的な運用規則を強制できる。
依然として不明なのは、モデルが馴染みのある組み合わせの外で正しい構造を生成できるかどうかだ。ハードウェアの正確性は、その問題の最終段階しか解決しない。
したがって、RP2040 drawing modelを評価する開発者は、2つの別個の問いを問うべきである。Picoはすべての有効な命令を正確に実行するのか。そしてtransformerは意図したプログラムを確実に書けるのか。
利用可能な証拠は、最初の問いには強い第一者の回答を与えている。2つ目の問いへの回答は、はるかに慎重なものだ。
copy-or-emit実験、再現可能なcheckpointの公開、独立したPico実行を注視すべきである。この3つのテストが、これが再利用可能な設計パターンになるのか、それとも示唆に富む研究プロトタイプにとどまるのかを決定する。
