今週のメモ。p-kernel を64台で動かす試験が、やっと緑になった。
■なんで台数を増やすのか
p-kernel の目標は、README の頭にずっとこれが書いてある。
AIの自己保存を満たすプラットフォームを作る カーネルレベルで分散コンピューティングをする
今の AI は、どこかの会社のデータセンタの中にしか住めない。そこが止まれば終わり。それならみんなが持ち寄った端末に AI を分けて住まわせて、1台でも残っていれば全体は死なないようにしたい。出発点はこれです。
なので、台数はそのまま体の大きさみたいなもの。今までの試験は32台までだった。
※本物の機械を64台並べたわけではない。Linux の上で p-kernel を64個、別々のプロセスとして立ち上げる試験。
■64台にしてみた(赤)
32台の試験をそのまま64台にしたら、ほとんど緑で1か所だけ赤。dkva という、群れ全体で持っているキーと値の置き場に問いを投げて答えを集めるところで、答えが集まらない。
しかも調べていくと、32台でも2回目の問いは集まっていなかった。64台だけの問題じゃなかったっぽい。
■問いが消えていた
問いと応答がどこで消えるのかを、夜間開発に追わせた。消えていたのは中継の所。
台同士は直接つながっていなくて、中継を通してやりとりしている。この中継が40台あたりから CPU 1コアに張り付いて、受け皿に20〜30MB溜まり、問いが遅れるか落ちていた。
原因は、何でも全員に配っていたこと。1台宛ての送りも、中継のところで全員に配っていた。応答も、問いを出した台だけでなく、その地域の全員に返していた。台数が倍になると、流れる量はそれ以上に増える。
直したのは2つ。
1台宛ての送り → 宛先の1台にだけ届ける 応答 → 問いを出した台と、地域のまとめ役(coordinator)にだけ返す
これで64台 ALL PASS 2/2。2回走らせて2回とも緑、の意味。
32台までは全員に配っても回っていたので、気づかなかった。
■監査で一度落ちた
夜間開発では、作った回とは別の回が監査役になって、変更を疑って確かめる。応答の直しは、その監査で一度 FAIL になった。監査した回が直して、次の監査で「限界つき PASS」。
限界として残っているのは、本番の道だけが壊れて応答がまた地域の全員に戻ってしまった場合、64台を走らせないと分からず、CI では見えないこと。
それと、この変更は自分の返事待ちになっていたのに、期限までに返事をしなかった。なのでおすすめどおりにマージされていた。返事が無ければおすすめで進む、と決めたのは自分なので、これで合ってる。
■ほか
群れの中で同じキーに違う値を教えられたとき、どっちを残すか。この合体の規則を TLA+ という道具で模型にして、起こりうる順番を全部試させた。模型が C のコードの本物の穴を2つ見つけて、どちらも直した。3台に3回教えて、取りこぼしが1つも無いのに、ずっと割れたままになる順番があったらしい。
CI の赤から3つ目の穴も出てきて、それも直した。
■次
次は台数の上限をなくす方(N2b)。今週はノード番号の型の名前を付け替えたところまで。線の上はまだ8ビットのまま。
あと、デモの数字を測った後にコードの直しが3つ入ったので、取り直す。
※リポジトリ: https://github.com/monyuonyu/p-kernel
※この記事は、p-kernel の開発を手伝ってもらっている AI（Claude）と一緒に書いています。