nesformer คอมไพล์ CPU ของ NES ลงในน้ำหนักโมเดลโครงสร้าง Qwen3.5 — เล่น Super Mario Bros. ได้ แต่ช้ากว่าเครื่องจริง 150–290 เท่า

Drew Breunig ปล่อย nesformer บน GitHub เมื่อ 30 ต.ค. 2026 เป็น checkpoint สถาปัตยกรรม Qwen3_5ForCausalLM ที่ไม่มีใครเทรนเลยสักน้ำหนัก คอมไพเลอร์คำนวณทุกค่าให้กลายเป็น CPU 6502 ของเครื่อง NES เมื่อสั่ง generate โมเดลจะ “ทำนาย” execution log ของ CPU ทีละ token และเกมก็เดินไปตามนั้น Super Mario Bros. จึงเล่นได้จริง แม้จะช้ามาก

งานนี้ต่อยอดจาก Qwenputer ของ Divyansh Agrawal (22 ต.ค.) ซึ่งใส่ RISC-V CPU ลงใน Qwen3.5-4B ตัวจริง สองโปรเจกต์รวมกันชี้ว่าน้ำหนักโมเดลเป็นที่เก็บโปรแกรมแบบกำหนดผลได้แน่นอน ไม่ใช่แค่ค่าสถิติจากการเทรน

RAM อยู่ใน Gated DeltaNet

Qwen3.5 ใช้ Gated DeltaNet ซึ่งเป็น linear RNN ใน 3 จาก 4 ชั้น attention แต่ละ head เก็บ state matrix ไว้ Agrawal พบว่าถ้าตั้ง gate เป็น 1, ตั้ง write strength เป็น 1 และใช้ key แบบ one-hot การเขียนแต่ละครั้งจะทับแถวเดียวพอดี และ query แบบ one-hot จะอ่านค่ากลับมาได้ตรงทุกบิต แถวของ state จึงทำหน้าที่เป็นเซลล์หน่วยความจำ

ส่วน nesformer แบ่งงานแบบนี้:

• อยู่ในโมเดล: แกน 6502 ครบ 151 official opcodes, RAM 2KB และ PRG-ROM 32KB
• อยู่ในโปรแกรม host: PPU ที่วาดภาพ, คอนโทรลเลอร์ และจังหวะ vblank ไม่มีเสียง

ขนาดโมเดลคือ 466.6 ล้านพารามิเตอร์ใน bf16 หรือ 933MB แต่มีค่าไม่เป็นศูนย์เพียง 9.3 ล้านตัว ไฟล์จึง zip เหลือ 3.3MB

ตรวจสอบละเอียด แต่ช้ามาก

ผู้สร้างทดสอบแบบปล่อยโมเดลรันเองโดยไม่มีตัวแก้ระหว่างทาง ได้ trace ตรงกับ CPU อ้างอิงทุกตำแหน่ง ทั้ง nestest และเกมทดสอบ โดยเกม Full Game รันไป 2,645,885 tokens และ frame ที่บันทึกไว้ทั้ง 210 ภาพตรงกันหมด

เครื่อง NES จริงต้องการราว 700,000 tokens ต่อวินาที แต่ engine ที่เร็วที่สุด (numba) ทำได้ราว 1,650 tokens ต่อวินาทีบน CPU คอร์เดียว ส่วน transformers ปกติได้เพียงราว 10 แม้จะมีทริกข้าม idle loop แล้ว ภาพรวมก็ยังช้ากว่าเครื่องจริง 150–290 เท่า 600 frames หรือ 10 วินาทีของเกมใช้เวลาราว 25 นาที

ข้อจำกัดสำคัญคือรองรับเฉพาะตลับ NROM (mapper 0) เพราะ ROM อยู่ในตารางตายตัว 32KB จึงยังสลับ bank ไม่ได้ ผู้เล่นต้องหา ROM เอง ตัวโปรเจกต์แจกเฉพาะเกมทดสอบ 3 เกมที่ใบอนุญาตเปิด

ต่างจาก Qwenputer อย่างไร

ระวังคำว่า “stock Qwen3.5” เพราะ nesformer ใช้แค่สถาปัตยกรรมและรูปร่าง head ของ Qwen มีเพียง 7 ชั้นวงจร และไม่มีความสามารถทางภาษาเลย ส่วน Qwenputer เก็บน้ำหนักเดิมของ Qwen ไว้ครบ แล้วเพิ่ม CPU อีก 11 ชั้นเข้าไป โมเดลจึงยังคุยได้และเรียก CPU ในตัวเองผ่านรูปแบบ tool call โดยไม่มีการเรียกเครื่องมือภายนอก

ผู้สร้างรายงานว่า Qwenputer ยกคะแนนเลขจำนวนเต็มยาวชุด NUPA จาก 48.6% เป็น 100% และการกระจายของข้อความปกติแทบไม่ต่างจาก Qwen เดิม แลกกับไฟล์ขนาด 18.8GB หรือราวสองเท่าของ base

ที่น่าสนใจอีกอย่างคือวิธีสร้าง nesformer ตามที่ Simon Willison สรุปไว้ ผู้สร้างเปิดเผยใน Hacker News ว่าใช้ Opus 5.5 กับพรอมต์สั้น ๆ ให้อ่านบทความ Qwenputer แล้วประเมินความเป็นไปได้ ก่อนสั่งให้ลงมือทำ และโมเดลไปหาชุดทดสอบ CPU ของ NES ที่มีมาราว 15 ปีมาใช้ตรวจงานเอง

มุมมอง AI Curator

นี่ไม่ใช่วิธีเล่นเกมที่ดีขึ้น ความหมายจริงอยู่ที่อีกชั้นหนึ่ง คือเรากำลังเห็นน้ำหนักโมเดลทำตัวเหมือนไฟล์โปรแกรม ทั้งที่เครื่องมือตรวจสอบส่วนใหญ่ยังมองมันเป็นข้อมูลล้วน การสแกนว่า checkpoint ปลอดภัยด้วยการดูว่าไม่มี pickle หรือไม่มีโค้ดแนบมาด้วยจึงไม่ครอบคลุมพฤติกรรมที่ฝังอยู่ในตัวเลขแล้ว ประเด็นนี้ไม่ใช่ข้อสรุปจากการโจมตีจริง แต่ Agrawal ก็เขียนบทความต่อเรื่องโมเดลแบบ hybrid ที่อาจซ่อนการคิดไว้ใน RNN state เพื่อหลบการตรวจ CoT และเรื่องกลับด้านอย่าง monitor ที่ฝังในน้ำหนักจนโมเดลปิดเองไม่ได้ เทคนิคเดียวกันจึงใช้ได้ทั้งสองฝั่ง

สำหรับนักพัฒนาไทย งานนี้เป็นโจทย์เรียนรู้ที่ดีมาก โค้ดอ่านได้ มีตาราง layer plan ชัด และใช้แค่ CPU ส่วนมุมมองระยะยาว ควรจับตาทางที่ Agrawal วางไว้ คือให้ Qwen เขียน Python แล้วรันบน MicroPython ในน้ำหนักของตัวเอง ถ้าทำได้ดี โมเดลบนอุปกรณ์จะคำนวณแม่นยำโดยไม่ต้องมี sandbox ภายนอก ซึ่งมีประโยชน์จริงกว่าการรัน Mario

แหล่งข่าว

• nesformer — GitHub
• Divyansh Agrawal — Qwenputer: a fully functioning, deterministic RISC-V CPU inside Qwen3.5
• Simon Willison — dbreunig/nesformer