MacBook Pro पर 1 टोकन/सेकंड पर Kimi K3 (2.8T), चार SSDs से स्ट्रीम किया गया

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

एक developer ने MacBook Pro पर Kimi K3, एक 2.8‑trillion-parameter Mixture-of-Experts model, को लगभग 1.45 TB expert weights को चार SSDs से stream करके चलाया है, और लगभग 1 token प्रति second की गति हासिल की है, लेकिन 512-token prompt पर पहले token तक पहुँचने में 6 मिनट लगते हैं। यह project disk bandwidth, read scheduling, और Thunderbolt constraints के performance पर प्रभाव को गहराई से देखता है, और यह दर्ज करता है कि कौन-से optimizations मददगार रहे और कौन-से नुकसानदेह (जैसे RAID-0 striping और RAM caching)। Commenters ऐसी धीमी, storage-bound setup की practical value बनाम इसे frontier-scale models को स्थानीय और पूरी तरह offline चलाने के proof of concept के रूप में इसकी अहमियत पर बहस करते हैं।

मॉडल और प्रदर्शन

  • 2.78T-पैरामीटर MoE (Kimi K3) जिसमें लगभग 1.45 TB expert weights हैं, को 4 SSDs वाले MacBook Pro M5 Max (128 GB) पर चलाया गया।
  • Experts को disk से stream किया जाता है; attention “trunk” (~50 GB) int8 precision पर unified memory में resident रहता है।
  • रिपोर्टेड decode: 512 tokens पर ~1 token/s, 128 tokens पर ~1.13 tok/s, और tests के बीच consistent behavior।
  • 512-token prompt पर time-to-first-token ~6.3 minutes है, भारी prefill I/O के कारण।

I/O आर्किटेक्चर और स्केलिंग

  • प्रति (layer, expert) एक 17.5 MB file; हर layer प्रति token 16 experts पढ़ती है, और सबसे धीमी read का इंतज़ार करना पड़ता है।
  • Thunderbolt 5 enclosures के माध्यम से चार SSDs; केवल internal SSD, 4-drive decode rate का लगभग आधा देता है।
  • अनुभवजन्य “drive ladder”: 1/2/3/4 drives ≈ 4-drive speed के 52% / 73–78% / 90–92% / 100%; अधिक drives के साथ returns घटते जाते हैं।
  • RAID0/striping और कुछ caching strategies को मापा गया और performance के लिए हानिकारक पाया गया, मुख्यतः क्योंकि barrier सबसे धीमे device द्वारा तय होते हैं।

Prefill, Context, और Workload Fit

  • Prefill मुख्य bottleneck है: current scheduling experts को कई बार re-read करती है, जिससे 1.4 TB model के लिए ~9 TB reads हो जाते हैं।
  • इससे “single-token classifier” workloads (लंबा prompt, 1 token आउट) अभी सबसे खराब case बनते हैं, सबसे अच्छा नहीं।
  • KV cache प्रति token लगभग 2.8 MiB बढ़ता है; 128 GB RAM और अन्य reservations के साथ, इस setup पर context लगभग 4.4k tokens तक सीमित है।
  • प्रस्तावित “expert-major” prefill (प्रति layer हर expert को एक बार पढ़ना, फिर सभी routed rows process करना) amplification को 6.2x से लगभग ~1x तक घटा सकता है।

Use Cases और “Why Bother?” बहस

  • Skeptics का तर्क है कि multi-minute prefill के साथ 1 tok/s interactive use के लिए अव्यावहारिक और महंगा है।
  • Supporters इसमें मूल्य देखते हैं:
    • Scheduled, unattended local jobs (reports, reconciliations) जहाँ latency मायने नहीं रखती।
    • यह proof-of-concept कि frontier-like models स्थानीय रूप से भी चल सकते हैं।
    • “Because it’s hard” hacker experimentation और अधिक efficient designs की ओर एक stepping stone।

Tooling, Methodology, और Documentation

  • Custom instrumentation (per-device read monitor, barrier tracing, config assertions) ने non-obvious bottlenecks उजागर किए; इन्हें ठीक करने से कई >8–14% gains मिले।
  • caching, striping, trunk streaming, विभिन्न APIs सहित negative results का बड़ा catalog cautionary data के रूप में दिया गया है।
  • कुछ commenters को README dense और “LLM-ish” लगता है, वे short TL;DR को prefer करते हैं; लंबे, LLM-authored documentation के प्रति resentment भी नोट किया गया है।

Hardware Futures और Model Design Ideas

  • चर्चा SSD bandwidth limits (Thunderbolt/PCIe), संभावित desktop या GPU-based setups, और ASIC-style inference chips तक जाती है।
  • इस पर बहस कि future models अधिक modular होने चाहिए या expert routing में “sticky” ताकि केवल weights का छोटा subset ही memory-resident रखना पड़े; current MoE approaches को मुख्यतः compute बचाने वाला, memory नहीं, माना गया है।