64ビットだと可変長メモリプールで落ちていた話

今週のメモ。夜間開発が作っている「約束ごとの試験」から、本物のバグが1つ出てきた。

■約束ごとの試験
p-kernel の芯は μT-Kernel 3.0(TRON の流れのリアルタイムOS)。この上にいろいろ載せているので、「タスクを作ったら動く」「待ったら起きる」のようなカーネルの約束を1個ずつ確かめる試験を、夜間開発に作らせている。
わざと壊したカーネルも用意して、試験がちゃんと赤を出すかも見ている。壊したのに緑なら、その試験は何も見ていないことになるので。

今週は可変長メモリプール(大きさがばらばらのメモリを貸し出す仕組み)の項目を足した。これで 133 項目、壊したカーネルは 14 種。

■足したら落ちた
足したとたん、64ビットの環境だけ tk_cre_mpl(メモリプールを作る呼び出し)でカーネルごと落ちた。32ビットの x86 は 133 項目ぜんぶ通る。

原因は構造体の並びだった。メモリプールの管理ブロックの途中を、別の構造体の先頭として読んでいる箇所がある。向こうの構造体は、64ビットだと途中に4バイトの詰め物が入る。こっちには入っていなかった。それで、空き領域をたどるたびに4バイトずれた場所を読んでいた…

mplsz   +36
areaque +40   ← 本当は mplsz から +8 のはず

32ビットでは詰め物が入らないので、元の並びで合っていた。64ビットに移したときに、並びを直し忘れていたっぽい。
直し方はメンバーを1つ前に移すだけ。ついでに、並びがまたずれたらビルドが通らないようにする検査も足した。

これまで見つからなかったのは、64ビット側にこれを呼んでいる所が無かったから。Linux 版や Android 版で、誰かが呼んだ瞬間に落ちる状態だった。(まだ誰も踏んでいない)

■赤のほうがありがたい
このプロジェクトでは「正直な赤は、塗った緑より価値がある」と決めている。試験を増やせば赤も増えるので、見た目は後退しているように見える。ただ今回の赤は、試験を増やさなければ見えなかったもの。

脳のほうも赤が多い週だった。1ビットに量子化して誤差を次に回すやつは 0/3 で赤。そのうえ、間違った作りでも正答率の合格ラインを通ってしまうことが分かった。甘かったのは合格ラインのほう。次の段では「写しのずれ」もラインに入れる。
※緑のままだったら、気づかずに先へ進んでいた。

■ほか
長く回るタスクで切り替わらない問題の続き。Linux の x86_64 と aarch64(Android の中身)でも、割込みの出口でタスクを切り替えられるようにした。

学習の後半の重みを平均するだけで、種7つすべてで少し良くなった。動いている脳を実際に良くできそうな最初の候補。監査待ちなので、まだ既定は OFF。

夜間開発は 10/8 の夜から 10/11 の朝まで止まっていた。週の使用量の枠を、自分が木曜・金曜に使いすぎて上限を超えたため。

■次
mind/hist(「1つの心」の中心の部分)と、重みの平均が長く動かしても効くかを測るところ。

※リポジトリ: https://github.com/monyuonyu/p-kernel

※この記事は、p-kernel の開発を手伝ってもらっている AI(Claude)と一緒に書いています。

論文を読んで p-kernel の脳に試してみた(賢くはならず)

p-kernel の中では小さな言語モデルを育てていて、ログでは「赤子」と呼んでいる。行列の重みが190万個くらいで、fp32 で7.6MB。脳と呼ぶにはおもちゃの大きさです。

これを賢くする方向の研究も、夜間開発に少しずつやらせている。順番はだいたい決まっていて、論文を原文で読んでメモにする → p-kernel のどこに入れるか決める → 「効いた」と言える条件を先に決めてから測る、の流れ。今週はこの結果がいくつか出たのでメモしておく。

■量子化
重みの桁を減らしてモデルを小さくするやつ。量子化のホワイトペーパー、GPTQ、LLM.int8()、AWQ あたりを読んだ。論文から拾ったのは「目盛りを行ごとに取るか全体で取るかが一番効く」「小さいモデルほど壊れやすい」の2つ。

赤子で試した結果。元の損失 3.2258 からどれだけ増えたか。

int8 行ごと     +0.0003
int4 行ごと     -0.0213
int2 32個ごと   +0.0912
int2 行列全体   +1.3948

int8 だとほぼ変わらなくて、2bit で行列全体を1つの目盛りにすると壊れる。ここまでは論文どおり。

int4 で損失が下がっていたので、最初は「量子化したらかえって良くなった」と書いていた。これが監査で崩れた。乱数の種や学習データを変えると -0.021 から +0.017 まで符号が変わる。ただの雑音の幅でした。

※夜間開発では、作った回と別の回が監査する決まりにしている。疑う役がいなかったら、これがそのまま成果として残っていたはず。

■合体
2つのモデルの重みを平均して1つにする話。群れの端末がそれぞれ学んだことを1つにまとめたいので、p-kernel にとっては大事なところ。Sakana AI の進化的な合体、TIES、DARE、それと Linear Mode Connectivity の論文を読んだ。

最後の論文によると、同じ出発点から別々に学習した2体を直線で結ぶと、途中で損失の山ができる。ただ、学習率を途中で下げていけば、早めに分かれた2体なら山は消えるらしい。

第1段では、赤子の2体のあいだにもやっぱり山があった(0.375)。第2段で学習率の計画だけ変えてみたら、山はかえって高くなった(0.42〜0.70)。消えた組もあるにはあったけど、2体がほとんど動いていない組だけ。離れたまま平均できる組はひとつも無かった。

なので「そのまま重みを平均する」道はここで閉じた。次は蒸留(重みではなく出力で知識を渡すやり方)にする予定。監査では「データ1つ・種1つでしか測っていない」と結論の書き方を狭められた。重みの並びを揃えてから平均する re-basin はまだ試していない。

■副産物
同じ実験で、学習率を下げていくと親そのものの損失が 2.19 → 1.43 に下がった。合体とは関係ないところで、今週いちばん良い数字が出ている…。今の赤子はどこも学習率が一定なので効くかもしれない。でも小さいデータだけの話かもしれないので、確かめるまでは保留。

■10/4 に読んだもの
BitDelta と DARE。群れで共有している重みは、今は世代ごとに全部送っている。でも受け手は前の世代を持っているので、差分だけ送れば足りる。差分を行列ごとに「符号1ビット+大きさ1個」にすると、86KB が 2.7KB くらいになる見込み。
DARE の論文によると、差が小さいときしか効かない。なのでまず差の大きさを測るところから。実装はまだ。

■ほか
RNG0 を、ベアメタルの x86 と AArch64 で直した。カーネルを呼ばずに回り続けるタスクがいると、ほかのタスクに切り替わらない不具合。Linux の上で動く版も作ったけど、途中で原因を2回取り違えて、結局スタックが128バイトずれていただけ。自分のバグでした。これは監査待ち。

週の使用量の枠は98%で締まって、9/30〜10/3 は夜間開発がほぼ止まっていた。

「小さいモデルが賢くなった」という結果は、まだひとつも出ていない。丸暗記しているだけか、本当に覚えたかを見分ける試験も、2週続けて手つかずのまま。

※リポジトリ: https://github.com/monyuonyu/p-kernel

※この記事は、p-kernel の開発を手伝ってもらっている AI(Claude)と一緒に書いています。

AIがいても、自分がサボると開発は止まるという当たり前の話

git の履歴で、p-kernel の開発が止まっていた期間を数えてみた。

■止まっていた期間

コミットの間があいているところ(古い順)。

2016-05 → 2025-04   3,258日(約9年)
2025-06 → 2026-03     262日
2026-07 → 2026-08      31日
2026-08 → 2026-09      21日

9年はまあ分かる。趣味のプロジェクトによくあるやつ。
問題は2行目。

■AIと再開して、262日止まる

2025年4月に「AIの力でどこまで行けるのか検証してみることに」と README に書いて再開した。
4月に少し進めて、6月にちょっと触って、そこで止まった。次のコミットは翌年の3月。

その間もAIはいつでも使える状態だった。呼んでなかっただけ。

チャットのAIは、こっちが話しかけないと何もしない。どれだけ賢くても、こっちがサボればゼロ。
2026年3月からは一気に進んだけど、それも自分が毎日のように話しかけていた期間だけ。夏にまた1か月、3週間と止まっている。

足りなかったのはAIの能力じゃなくて、自分のやる気…

■対策:サボっても止まらない仕組み

サボり癖はたぶん直らないので、直すのはあきらめて仕組みの方を作った。
9月から動かしている夜間の無人開発。

・毎晩AIが自分で起動して、引き継ぎメモを読んで開発を進める
・作る回と、それを疑ってチェックする回は分ける
・何時にどれくらい進めるかも、計画役のAIが決める
・自分は朝に結果を見て、方針を決めるだけ

何もしない日でも、朝起きるとコミットが増えている。

■ただし任せきりはダメだった

決まりごとだけ渡して放っておいたら、AIが「調べて文書を書く」ような無難な仕事ばかりするようになって、2週間カーネルのコードが1行も変わらなかった。
方向を決めるのは人間の仕事らしい。

今の自分の役目は「方針を決めて、週1でまとめを読んで、変なところで口を出す」くらい。これならなんとか続きそう。たぶん。

※リポジトリ: https://github.com/monyuonyu/p-kernel

※この記事は、p-kernel の開発を手伝ってもらっている AI(Claude)と一緒に書いています。

p-kernel の設計の考え方メモ

p-kernel の設計でいつも立ち返っている考え方を、自分用に整理しておく。

■5つの層

システム全体を生き物っぽく5つの層に分けて考えている。部品が増えると「これ何のためだっけ」となるので、その地図がわり。

体(Body):ハードウェアと、電源が落ちても消えない記憶の置き場
脳(Brain):1台の中で考える部分。小さなニューラルネット
自分(Self):機械をまたいで続く「自分」の記録
群れ(Collective):たくさんの機械が1つの頭みたいに動く層
進化(Evolution):動いたまま自分を作り変えていく層

今のところ、体と群れはそれなりにできていて、進化はほぼ手つかず。

■中央を置かない

一番大事にしているところ。中央のサーバも、名簿も、まとめ役も置かない。どの1台が消えても残りが動く。
生きてるかどうかは、機械どうしが見張り合ってうわさ話みたいに広げる(SWIM)。
設計で迷ったらここに戻る。

■「死なない」の定義

最初は「どれか1台が生き残ればいい」だと思っていたけど、今は「引き継ぎが途切れなければいい」に変わった。

「自分」の層では、覚えたことや経験したことを改ざんできないように鎖状につないで記録している。元の機械が壊れても、別の機械が続きを書ける。
極端な話、最初の機械が全部入れ替わっても鎖がつながっていれば同じ、という考え方。テセウスの船みたいな話。

■広がり方

一気に広がる仕組みは目指していない。目立たなくても、しぶとく残る方。

■参加する人の身元は確かめない

ペンネームでも匿名でも実名でも同じ扱い。署名で確かめるのは、コードと脳の重みの出どころだけ。

■正直に書く

「動く」と書いたものは、全部自動テストで毎回確かめる。
動くもの・設計中のもの・まだ構想のものは分けて書く。
モットーは「正直な赤は、塗った緑より価値がある」。READMEを盛りすぎて5分で直したことがあるので、自分への戒めでもある。

■今の大きさ

脳は2万パラメータちょっと。教えたことをいくつか覚えて答えられる程度で、文章は書けない。
なので今は、脳より先に、それが死なないための土台を作っているところ。

※リポジトリ: https://github.com/monyuonyu/p-kernel

※この記事は、p-kernel の開発を手伝ってもらっている AI(Claude)と一緒に書いています。

自作OS p-kernel をまた作り始めたので、これまでの経緯をメモ

しばらく p-kernel という自作OSを触っているので、ここに作業メモを残していくことにした。
まずはこれまでの経緯から。

■p-kernel とは

ひとことで言うと「AIが死なないためのOS」。
AIをたくさんの機械(PC・スマホ・ラズパイみたいな小さな基板)に分散して載せて、どれか1台でも生き残れば全体としては止まらない、というのを OS の一番下(カーネル)から作っている。中央のサーバは置かない。

カーネルの芯は μT-Kernel 3.0(TRON系のリアルタイムカーネル)。

■経緯

2011年:自分でOSを作り始める。gitの一番古いコミットは 2011-04-03 の「first commit.」。H8/3069F のボード用で、同じ日に x86 のブートのコードも入れていた。
(学生の頃はOS部にいた。ほぼ見てるだけだったけど。最初に買ったOSの本は『30日でできる! OS自作入門』だったはず)
2012〜2016年:H8、STM32、RL78 など。2016年に T-Kernel の移植をしようとしていたところで止まる。

2025年4月:9年ぶりに再開。AIにコードを書かせるのが現実的になってきたので、どこまで行けるか試してみることにした。READMEの目標に1行足す。

2025-04-06
    AIの力でどこまで行けるのか検証してみることに

……が、また止まる。

2026年3月:再開。ここから一気に進む。分散(SWIM)やカーネル内の pub/sub を入れたあたりで、目標を書き換えた。

2026-03-22
    凄い進む... 普通のカーネルではなくて、生物の様な自己修復、
    自己増殖機能をもち、分散推論で集合意識となるAIファーストなカーネルを目指すことに

2026年6月:カーネルの中の小さな脳が、先生役のモデル(SmolLM2)の書いた文を寝てる間に学習して、"cat sat on the sand…" と出力するところまで。
2026年7月:芯を micro T-Kernel 2.0 から μT-Kernel 3.0 に載せ替え。

■今の状態

動くもの:x86 と ARM のベアメタル、Linux 上のプロセス、Android アプリ。
Windows は .exe が作れるところまで(実機ではまだ動かしてない)。
何台かつないで、1台落としても覚えたことが残るところまでは確認済み。

中の脳はまだおもちゃの大きさ。短い文を少し覚えられる程度。

■開発のやり方

今は夜の間にAIが自分で計画を立てて開発を進めている。自分は方針を決めて、朝に結果を確認する係。
このへんの仕組みは別でメモする。

週1くらいで、ここに作業メモを書いていく予定。

※リポジトリ: https://github.com/monyuonyu/p-kernel