29 GB RAM और 0.50 tok/s पर Kimi K3 चलाएँ

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

एक नया open-source engine दावा करता है कि वह SSD से अधिकांश weights स्ट्रीम करके लगभग 29 GB RAM के साथ laptop पर पूरा 2.78T-पैरामीटर Kimi K3 मॉडल स्थानीय रूप से चला सकता है, और लगभग 0.5 tokens per second की गति हासिल करता है। टिप्पणीकार इसकी गति और ऊर्जा लागत पर इसकी व्यावहारिकता को लेकर बँटे हुए हैं, लेकिन इसे स्थानीय, high-end LLM inference के लिए तकनीकी रूप से क्या संभव है, इसका एक दिलचस्प proof मानते हैं। बहस का बड़ा हिस्सा AI-generated code और documentation के भारी उपयोग, “pure” models की तुलना में quantization trade-offs, और क्या ऐसे प्रोजेक्ट craftsmanship, clarity, और long-term usability को प्राथमिकता देते हैं, इस पर केंद्रित है.

प्रोजेक्ट की अवधारणा और प्रदर्शन

  • यह टूल अधिकांश वज़न SSD से स्ट्रीम करके कमोडिटी हार्डवेयर पर पूरा 2.78T-पैरामीटर Kimi K3 चलाता है, और 4k context के लिए केवल लगभग 29 GB RAM उपयोग करता है।
  • थ्रूपुट लगभग 0.5 tokens/second है; कुछ लोग इसे आज के लिए व्यावहारिक समाधान से ज़्यादा एक proof-of-concept मानते हैं।
  • macOS पर, इस प्रोजेक्ट के लिए ARM NEON को reportedly Metal से तेज़ पाया गया।

0.5 tok/s वाले K3 के व्यावहारिक उपयोग

  • कई लोगों के अनुसार 0.5 tok/s इंटरैक्टिव काम के लिए, यहाँ तक कि email-level workflows के लिए भी, उपयोगी नहीं है।
  • कुछ लोग रात भर या कई घंटों के batch tasks सुझाते हैं: code review, project analysis, meetings या हफ्तों के काम के summaries।
  • इस गति पर मॉडल कितना “thinking” कर सकता है, इस पर बहस है; एक टिप्पणीकार नोट करता है कि मॉडल छोटे उत्तर बनाने के लिए tens of thousands internal tokens उपयोग कर सकते हैं।

Storage, memory, और system design

  • चर्चा custom streaming engine की तुलना mmap-based approaches जैसे llama.cpp से करती है।
  • कुछ का दावा है कि manual prefetching और caching generic OS paging की तुलना में काफ़ी बेहतर प्रदर्शन कर सकते हैं।
  • swap को लेकर चिंता: कई लोग SSD wear और खराब performance से बचने के लिए swap पूरी तरह disable करने की बात करते हैं; दूसरे स्पष्ट करते हैं कि weights का read-only mmap SSD endurance को नुकसान नहीं पहुँचाता।

Quantization और model fidelity

  • यह engine “pure” K3 नहीं, बल्कि re-quantized 3‑bit residual variant उपयोग करता है।
  • एक और प्रोजेक्ट (deltafin) का हवाला दिया गया है जो unaltered K3 चलाता है, लेकिन प्रति-token bandwidth अधिक लेता है (≈25.8 GB बनाम ≈17 GB)।
  • एक टिप्पणीकार README को confusing या self-contradictory कहता है, कि मॉडल सच में “native precision” पर है या नहीं; कुल मिलाकर precision और quality impact स्पष्ट नहीं माने गए हैं।

लागत और ऊर्जा दक्षता

  • मोटा लागत अनुमान: 42W और $0.20/kWh पर लगभग $5 प्रति million tokens।
  • कुछ लोग इसकी तुलना आधुनिक GPU clusters से कम अनुकूल रूप में करते हैं (प्रति Wh tokens के हिसाब से कई order of magnitude अधिक), लेकिन यह भी नोट करते हैं कि GPUs की upfront cost बहुत अधिक होती है।
  • Solar/PV चर्चा इस बात पर केंद्रित है कि क्या self-consumed energy को भी वास्तविक opportunity cost माना जाना चाहिए।

Documentation की गुणवत्ता और LLM authorship

  • एक बड़ा subthread LLM-generated README की आलोचना करता है: यह लंबा, अस्पष्ट, और internal-focused है।
  • दूसरे लोग LLM-assisted docs का बचाव करते हैं, कहते हैं कि वे बिना docs से बेहतर हैं, लेकिन स्पष्टता के लिए उन्हें संपादित किया जाना चाहिए।
  • LLMs का code, commits, और docs में उपयोग करने पर व्यापक बहस: कुछ इसे “lazy slop” मानते हैं, जबकि अन्य इसे कुशल सहयोग मानते हैं, बशर्ते code की समीक्षा हो।

Licensing, branding, और trust

  • कुछ लोग कंपनी पर पहले के non-open-source licenses और SQLite से नाम-भ्रम की धारणा के कारण भरोसा नहीं करते।
  • कंपनी जवाब देती है कि उसके पास नाम के अधिकार हैं और यह प्रोजेक्ट permissively licensed ही रहेगा।

संबंधित प्रयास और आगे की दिशा

  • थ्रेड में लगभग एक साथ हुए कई Kimi K3 self-hosting प्रयासों का उल्लेख है: CPU-only streaming, consumer GPUs, और compressed GGUF variants।
  • कई लोग इस प्रोजेक्ट को अंततः व्यवहार्य local execution की ओर एक शुरुआती, अभी-न-व्यावहारिक कदम मानते हैं, जहाँ बहुत बड़े models समय के साथ locally चल सकें।