当時の開発ログを見返しながらのメモ。
つながった何台かで、1つの AI の計算を分け合えるか試した。
■脳はおもちゃの大きさ
動かした Transformer はとても小さい。入力は4つの数字、ヘッド2つ、答えは3択。重みは全部で568個。
それでも仕組みは大きなモデルと同じ形。
■部品はそろっていた
K-DDS、中継、SWIM、生きている台数で動き方を変える「degrade」は既にあった。足りなかったのは起動時の配線と、シェルの `infer` コマンドだけ。
2台そろうと degrade が「2台モード」に切り替わる。infer を打つと、1台目がヘッド0を計算して、入力を中継越しに2台目へ。2台目がヘッド1を計算して返して、1台目が2つを合わせて答えを出す。
■毎回でたらめな場所で落ちる
中継越しの2台構成が毎回落ちる。しかも落ちるアドレスが毎回でたらめ。
推論の配線を止めても落ちるので、犯人は別。
中継とやりとりする部分で 1416バイトの受け皿を関数内の変数として4か所で確保していて、T-Kernel のタスクの小さなスタック（2〜4KB）をあふれさせていた。あふれた分が隣のタスクの戻り先を上書きして、でたらめな場所へ飛んでいた。static にして解決。
ベアメタル版には中継がないので今まで出なかった。
ほか：
・2台目が1回の問い合わせに同じ答えを100回くらい返していたのを修正
・パケットを1つ落としただけで「相手が死んだかも」と騒いでいたのを、2回続けて返事がないときだけに。2台だと代わりに様子を見てくれる3台目がいないので
■3台モードと最初のプルリクエスト
3台以上のときの分け方（各ノードが手元の KV キャッシュで注意を計算して持ち寄る）も試したら、送るデータが K-DDS の上限128バイトを超えていて、今まで一度も分散では動いていなかったことが判明。エラーが黙って捨てられて1台で計算していた…
上限を広げて、翌日には2台分の返事を集められるようにした。
5/22 からの13コミットをまとめて、GitHub のプルリクエスト #1 に。5/31 に取り込み。
※この日の実験は、中継も含めて全部1台の機械の中。
※リポジトリ: https://github.com/monyuonyu/p-kernel
※この記事は、p-kernel の開発を手伝ってもらっている AI（Claude）と一緒に書いています。