なぜLocalLLaMAが反応したのか

r/LocalLLaMAのthreadが取り上げたのは巨大model releaseではなく、かなり小さな実験である。やっていることは明快だ。4-bitのQwen 3.5 0.8BをMacBook Airで動かし、coding taskを解かせ、testを回し、失敗したらinput、expected output、actual outputをそのまま返して再挑戦させる。さらに複数のcandidateを同時に試すevolutionary search風のloopを加え、壊れた解答と修正済み解答のpairをLoRA training dataにする。teacher modelもcloud APIも使わず、automatic verificationだけでself-improvementを回そうとする点がこのcommunityに刺さった。

noveltyで終わらなかった理由は、postとtinyforge READMEが具体的な数字を出しているからだ。fresh holdout sliceではsingle-passが16/50から28/50へ改善し、使ったrepair pairは13個だけ、training時間は約3分とされる。別のholdout sliceではfeedback loop付きで42/58から47/58へ伸びたという。READMEは6GB RAM級をうたい、Reddit投稿ではtraining時peakがおよそ10GBだったと補足している。多少の差はあっても、local LLM界隈では十分に現実的なhardware条件だ。

本当に面白いのはどこか

投稿者自身が一番驚いたと書くのは、training後にcold coding能力が劇的に伸びたことではない。むしろ、failure feedbackを受け取った後の修正の仕方が良くなったという点だ。つまり小さなmodelは答えを丸ごと覚えるより、何が間違っていたかを聞いたあとにどう直すかという手続きを学びやすいかもしれない。この読みが正しければ、codeだけでなくSQL、数学、data transformのように自動検証できる仕事にも同じloopを広げられる。

training signalはhuman labelではなくself-generated repair pairから来る。
一番大きい改善はone-shot generationよりfeedback-aware repairにある。
まだ小規模実験なので広いreplicationが必要である。

だからこのpostは単なるlaptop demoでは終わらなかった。小さなlocal modelでも、周囲のverification loopをうまく設計すれば役に立つ学習が起こりうることを示しているからだ。

#local-training

r/LocalLLaMAが注目したtinyforge、0.8Bモデルのローカルself-improvement