Show HN: लगभग 1GB Qwen weights में एक काम करने वाला Nintendo

मूल लेख ↗ Hacker News चर्चा ↗

एक नया प्रोजेक्ट पूरे Nintendo Entertainment System—CPU, RAM, और ROM—को लगभग 1 GB large language model weights में compile करता है, जिससे Super Mario Bros. केवल transformer architecture के भीतर चल सकती है। टिप्पणीकार इसे एक चतुर proof-of-concept मानते हैं जो deterministic systems का अनुकरण करने के लिए LLMs के उपयोग की flexibility और extreme inefficiency—दोनों को उजागर करता है, और इसकी तुलना पारंपरिक emulators तथा सामान्य code से करते हैं। यह प्रयोग LLM determinism, future software architectures, और तेज़ी से बेहतर होते AI tools engineering work और team sizes को कैसे बदल सकते हैं, इन व्यापक विचारों को भी जन्म देता है.

नामकरण और नॉस्टैल्जिया

  • कई टिप्पणियाँ इस पर बहस करती हैं कि इसे “NES” के बजाय “Nintendo” कहना चाहिए या नहीं।
  • बड़े उम्र के टिप्पणीकार “Nintendo” को क्लासिक Mario-युग के हार्डवेयर से जोड़ते हैं; अन्य लोग बताते हैं कि यह शब्द सभी गेम कंसोल्स के लिए सामान्य-सा हो गया, जिससे ट्रेडमार्क संबंधी चिंताएँ भी पैदा हुईं।
  • कुछ लोगों को शीर्षक प्यारे “grandma tech” वाले अंदाज़ का लगता है (हर कंसोल एक Nintendo है, कंट्रोलर “remotes” हैं)।

प्रोजेक्ट वास्तव में क्या करता है

  • मॉडल एक transformer के weights के अंदर NES CPU और RAM का अनुकरण करता है, और मशीन मेमोरी के रूप में “Gated DeltaNet” state का उपयोग करता है।
  • CPU, ROM, और RAM मॉडल के भीतर ही रहते हैं; runtime पर केवल controller events इनपुट होते हैं।
  • यह पिछले “Qwenputer” काम पर आधारित है, जिसने अन्य CPUs को Qwen models में compile किया था।

निर्धार्यता, परीक्षण, और “काम करने” का अर्थ

  • चर्चा की एक पंक्ति यह है कि हर संभव input का परीक्षण किए बिना वे कैसे जानते हैं कि यह “काम करता है”।
  • जवाब: ठीक वैसे ही जैसे real CPUs validate किए जाते हैं—व्यापक conformance test suites से, न कि exhaustive state-space coverage से।
  • emulation समुदाय के test ROMs, जिनमें हजारों golden instructions थे, इस्तेमाल किए गए; फिर भी टिप्पणीकार नोट करते हैं कि दुर्लभ timing या edge-case bugs बने रह सकते हैं।

दक्षता बनाम सामान्य प्रोग्राम

  • कई लोग भारी inefficiency पर ज़ोर देते हैं: nesformer एक real NES से लगभग 150–290× धीमा है, जबकि यह एक सरल fixed-function system को दोहराता है।
  • इसे इस बात के ठोस उदाहरण के रूप में लिया जाता है कि LLM-based execution को सामान्य code की तुलना में कितनी अधिक compute चाहिए, और क्यों “हर frame पर LLM as OS” जैसे विचार बेहद महंगे होंगे।
  • कुछ लोगों का तर्क है कि यह मूलतः Minecraft में Minecraft बनाना या CSS में CPU बनाना जितना ही सूचनात्मक है—तकनीकी रूप से प्रभावशाली, लेकिन व्यावहारिक रूप से बेकार।
  • दूसरे जवाब देते हैं कि “anything can run anything” अपने-आप में एक दिलचस्प proof-of-concept है और builders के लिए प्रेरणा भी।

व्यापक निहितार्थ और विचार

  • छोटे VMs, shells, या interpreters को सीधे LLM weights में compile करने की अटकलें, जिससे internal tool use और debugger की तरह reasoning को step-by-step देखा जा सके।
  • यह सवाल कि क्या LLMs एक “universal computing medium” बन सकते हैं, हालांकि कई लोग ध्यान दिलाते हैं कि यह code सीधे चलाने की तुलना में बहुत कम efficient होगा।

AI tooling, productivity, और jobs

  • एक अलग लेकिन सक्रिय बहस: AI coding tools में तेज़ सुधार, कम लोगों के साथ अधिक throughput, और engineering teams के सिकुड़ने तथा job loss की आशंकाएँ।
  • अन्य लोग AI का उपयोग उसी headcount के साथ अधिक काम करने के लिए करने पर ज़ोर देते हैं, हालांकि यह कैसे घटित होगा इस पर shareholder-driven organizations में मतभेद है।