29GB RAM पर Kimi K3 को 0.50 tok/s पर चलाना

 (github.com/sqliteai)
1 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • WASTE एक C-आधारित inference engine है जो 2.78 ट्रिलियन पैरामीटर वाले पूरे Kimi K3 open-weight मॉडल को बिना छोटा किए 982GiB कंटेनर में बदलकर consumer laptops पर चलाता है
  • यह मॉडल के resident trunk को ही memory में रखता है और हर token पर सक्रिय होने वाले लगभग 4% expert weights को NVMe से पढ़ता है, जबकि बची हुई RAM को size-limited expert cache के रूप में इस्तेमाल करता है
  • Kimi K3 को 4K context में न्यूनतम 29.05GB RAM के साथ खोला जा सकता है, लेकिन व्यावहारिक configuration 64GB MacBook Pro पर 46GB budget है, जहाँ यह 0.45~0.62 tok/s देता है
  • expert reads और computation को overlap करके लगभग 1.6 गुना सुधार मिलता है, और अगले layer के router को एक residual पहले चलाकर cache hit rate को 14% से 38% तक बढ़ाया जाता है, बिना total read volume या logits बदले
  • इंटरनेट कनेक्शन, per-token cost, या external data transfer के बिना इतने बड़े मॉडल को लोकल में चलाया जा सकता है, लेकिन इसके लिए internal NVMe और लगभग 1TB storage space चाहिए, और यदि RAM budget 52GB से ऊपर हो तो OS paging के कारण यह उल्टा बहुत धीमा हो सकता है

WASTE का लक्ष्य और implementation

  • WASTE(Weight-Aware Streaming Tensor Engine) एक embeddable C inference engine है जिसमें runtime बाहरी dependencies नहीं हैं
    • इसमें सिर्फ libwaste.a और waste executable का उपयोग होता है, और libc व pthreads के अलावा BLAS, CUDA, ONNX, Python की जरूरत नहीं होती
    • Python का उपयोग केवल model conversion और PyTorch reference validation के लिए होता है, inference path में नहीं
    • public API में 26 functions हैं, जो model open करना, RAM limit सेट करना, generation, session save करना, और shutdown को support करते हैं
  • अभी validation का मुख्य target Kimi K3 2.78T पूरा मॉडल है
    • public source 1.42TB है और conversion के बाद कंटेनर 982GiB का हो जाता है
    • यह distilled, pruned, या downsized version नहीं है
    • Kimi-Linear 48B भी इसी engine और format पर 19GiB container, न्यूनतम 1.87GB RAM, और 10.7 tok/s देता है
  • प्रोजेक्ट का नाम उस स्थिति को कम करने के लक्ष्य से आया है जिसमें डेस्क पर रखे जा सकने वाले हार्डवेयर पर चल सकने वाले मॉडल cloud datacenter में चलाए जाते हैं और साथ में token cost व बिजली दोनों खर्च करते हैं

डिस्क streaming architecture

  • MoE (Mixture of Experts) architecture वाले K3 में हर token पर मॉडल का केवल लगभग 4% ही सक्रिय होता है, इसलिए inactive weights को RAM में resident रखने की जरूरत नहीं होती; उन्हें जरूरत के समय उपलब्ध रहने लायक रखा जाता है
  • .waste container में JSON manifest, resident trunk, और layer-wise expert banks होते हैं
    • हर expert record 4KiB alignment पर रखा जाता है
    • gate, up, down matrices को पास-पास रखा जाता है ताकि एक expert को ठीक एक pread से पढ़ा जा सके
    • page cache को macOS में F_NOCACHE, Linux में O_DIRECT, और Windows में FILE_FLAG_NO_BUFFERING से bypass किया जाता है
  • अगर page cache bypass न किया जाए, तो RAM से छोटे test containers OS cache में आ सकते हैं और 982GiB मॉडल में दोहराए न जा सकने वाले hit rates दिखा सकते हैं
  • record पढ़ते समय magic, expert ID, और offset range हमेशा verify किए जाते हैं ताकि कटा हुआ या गलत जोड़ा गया bank गलत weights के साथ जवाब न दे
    • payload की crc32 जांच --verify से enable होती है
    • validation cost Kimi-Linear में लगभग 5% और K3 में लगभग 1% है, इसलिए default में बंद है
    • copy/download किए गए या untrusted disk पर रखे containers को एक बार verify करने की सलाह दी जाती है
    • trunk और codebooks पर checksum नहीं है

read-ahead और router prediction

  • जब किसी layer का router 16 expert IDs तय करता है, तो हर read को अलग thread के रूप में request किया जाता है, और computation आने वाले data से शुरू हो जाती है
    • reads और computation का overlap K3 में लगभग 1.6x सुधार देता है
    • feature enable करने से पहले और बाद में work done और cache stats समान रहते हैं
  • अगले layer का actual hidden state बनने से पहले resident अगला router वर्तमान hidden state पर चलाया जाता है ताकि 6 experts को पहले से fetch किया जा सके
    • एक residual पहले की prediction की accuracy rank 1 पर 92% और top 6 में 81% है
    • actual router ही final experts तय करता है, इसलिए output पूरी तरह सटीक रहता है
    • demand hit rate 14% से 38% तक बढ़ती है और कुल पढ़े गए bytes नहीं बदलते
    • इसे WASTE_LOOKAHEAD=0 से बंद किया जा सकता है
  • prefill पर यही तकनीक लागू करने वाला implementation हटा दिया गया
    • decode layer 16 cache slots लेता है, लेकिन chunk layer लगभग 550 slots लेता है
    • पहले से पढ़े गए records इस्तेमाल होने से पहले ही evict हो जाते थे, जिससे read volume 6.9% बढ़ी और समय कम नहीं हुआ

quantization और accuracy

  • expert weights को 8-dimensional vectors के लिए 256-entry codebook वाली 3-stage residual vector quantization में store किया जाता है, और हर weight पर 3.00 bits उपयोग होते हैं
    • पूरा matrix reconstruct किए बिना partial inner-product tables बनाए जाते हैं, फिर हर row को 3 table lookups और 2 additions से process किया जाता है
  • trunk 4-bit और 8-bit पर रखा जाता है
    • क्योंकि model को केवल experts के लिए quantization-aware training मिली थी, 3-bit trunk पर output collapse हो जाता है
    • cache prediction सही थी, लेकिन throughput नहीं सुधरा, इसलिए इसे हटा दिया गया
  • सभी layers की तुलना PyTorch reference implementation से की गई
    • final logits difference 3.6e-06
    • vision tower के लिए अपने reference के साथ 2.3e-06
    • latent KV cache transformation 1.2e-05 स्तर पर समान logits बनाए रखती है

RAM budget और संकीर्ण performance window

  • K3, 92 layers में हर layer पर 16 experts का उपयोग करके, हर token पर 17.0GB का working set बनाता है
    • यदि cache इस आकार से छोटी हो, तो एक token में store किए गए experts अगले token से पहले evict हो जाते हैं और hit rate 0% हो जाती है
  • 64GB system पर मापा गया कि अधिक RAM देने से हमेशा speed नहीं बढ़ती
    • 32GB budget · 3.32GB cache: hit rate 0%, 0.50 tok/s
    • 46GB budget · 17.32GB cache: legacy hit rate 17%, 0.53~0.55 tok/s
    • 52GB budget · 23.32GB cache: 0.04~0.15 tok/s, परिणाम reproducible नहीं
    • 58GB budget · 29.32GB cache: 0.02~0.03 tok/s
  • router lookahead 46GB पर hit rate को लगभग 14% से 38% तक बढ़ाता है, लेकिन 52GB से ऊपर की गिरावट cache miss नहीं बल्कि OS paging के कारण है
    • 58GB पर hit rate और ऊँची होने पर भी यह 46GB से लगभग 20 गुना धीमा है
    • बड़े budget से system को paging state में धकेलने के बाद 46GB measurement भी 0.02 tok/s तक गिर सकती है
  • default budget physical RAM के 7/8 से नीचे, token working set इकाई के आधार पर नीचे की ओर चुनकर सेट किया जाता है
    • 64GB MacBook Pro पर 46.24GB उपयोग होते हैं और 17.56GB expert cache को दिए जाते हैं
    • यदि दिया गया budget minimum से छोटा हो, तो swapping के साथ चलने के बजाय startup ही reject कर दिया जाता है
    • 128GB system पर trunk और working set के 3x के बराबर पूरा recommended budget इस्तेमाल किया जा सकता है

K3 performance और hardware requirements

  • measurement system 64GB MacBook Pro M5 Pro और internal SSD था
    • 4K context minimum RAM: 29.05GB
    • 32K: 30.54GB, 128K: 35.63GB, 1M: 83.21GB
    • resident trunk: 27.28GB
    • model load: 20 सेकंड
    • decode: default budget पर 0.45~0.62 tok/s
    • prefill: chunked 0.47 tok/s, sequential 0.29 tok/s
  • मॉडल को न्यूनतम 29.05GB पर खोला जा सकता है, लेकिन 32GB system में भारी paging हो सकती है, इसलिए 64GB वास्तविक recommended spec है
  • cold state में हर token पर 17.0GB experts पढ़े जाते हैं, और lookahead के 38% hit rate पर 10.5GB पढ़े जाते हैं
  • internal SSD 12.78GB/s और external USB enclosure 0.94GB/s मापा गया
    • क्योंकि एक token के लिए 17GB experts पढ़ने पड़ते हैं, external storage पर वही processing लगभग 13 सेकंड लेगी
    • original download external disk पर रखा जा सकता है, लेकिन converted container internal NVMe पर होना चाहिए
  • converted container के लिए 982GiB और original shard staging के लिए 1.42TB चाहिए; staging space conversion के बाद खाली की जा सकती है

Attention और multimodal processing

  • K3 attention, Kimi Delta Attention और gated multi-head latent attention को 3:1 अनुपात में जोड़ता है
    • KDA बढ़ते हुए KV cache के बजाय fixed-size recurrent state रखता है
    • MLA head-wise key/value को फैलाने के बजाय width 512 का latent cache करता है
  • kv_b_proj को query और output में absorb करके 4K context cache को 11.25GB से 0.21GB तक घटाया जाता है
    • यह पहले की तुलना में 53x कमी है
    • 128K पर expanded layout को 360GB और latent layout को 7.2GB चाहिए
  • multimodal path 401M parameters, 27 layers, और patch 14 वाले ViT को support करता है
    • 1024 patch image encoding में 15.7 सेकंड लगते हैं
    • 896×896 image default settings पर 256 sequence positions लेती है
    • image embeddings भी 92 MoE layers से गुजरती हैं, इसलिए अधिकांश cost vision tower नहीं बल्कि text prefill जैसी होती है
    • vision.json में max_patches आधा करने पर prompt positions भी आधी हो जाती हैं
  • PNG, JPEG, GIF, BMP, TGA, PSD supported हैं और run, chat, eval में images का उपयोग किया जा सकता है
    • बातचीत के दौरान encoded image positions attention state में रहती हैं और अगले turn में दोबारा encode नहीं करनी पड़ती
    • vision tower केवल image होने पर load होती है और 434MB weights व 1.12GB total reserved memory का उपयोग करती है

conversion, execution और server

  • build के लिए केवल C11 compiler और make चाहिए
    • make check बिना असली model के synthetic containers से 23 checks pass करता है और 11 skip करता है
    • दो real containers होने पर full test count 36 है
  • K3 conversion, public moonshotai/Kimi-K3 के 96 safetensors shards को ज्यों का त्यों उपयोग करता है
    • M5 Pro पर 3 processes के साथ लगभग 4.7 घंटे लगते हैं
    • pure PyTorch encoder को 23.7 घंटे लगते हैं
    • layer unit पर resume किया जा सकता है, इसलिए interruption होने पर केवल चल रही layer फिर से process करनी होती है
    • downloader partial file resume, exponential backoff और jitter, Content-Length verification, और completed shard status recording को support करता है
  • CLI run, chat, eval, plan आदि देता है, और --json के साथ eval, tokenize, plan, info, bench के results machine-readable रूप में निकालता है
  • serve/ public C API को ctypes से कॉल करने वाला OpenAI-compatible HTTP server है
    • यह /v1/chat/completions, /v1/completions, /v1/models, /health देता है
    • streaming, tool definitions/results, typed call arguments, JSON response schema, tool_choice, think channel, thinking_effort, और images को handle करता है
    • prompt renderer, K3 release के encoding_k3.py का port है, और यदि weights directory मौजूद हो तो 38 conversations को segment स्तर पर compare करता है

platforms और मौजूदा सीमाएँ

  • macOS arm64, Linux arm64, Linux x86_64 ने समान model-independent tests में 23 pass·11 skip रिकॉर्ड किए और sanitizer व 400 fuzz runs भी pass किए
  • Windows x86_64 को MinGW-w64 से cross-compile करके synthetic containers, CLI, और forward pass validate किए गए, लेकिन real model containers पर नहीं चलाया गया
    • MSVC और Windows ARM64 supported नहीं हैं
    • Windows में page-cache bypass केवल CI filesystem पर verify हुआ है; RAM से बड़े real containers के load पर validate नहीं हुआ
  • x86 SIMD, CPUID के आधार पर AVX-512 या AVX2 चुनता है, लेकिन AVX-512 path अभी तक वास्तविक supported CPU पर नहीं चलाया गया
  • Metal backend सटीक है, लेकिन छोटी dependent matvec operations सैकड़ों बार होने वाले workload के कारण CPU से 22% धीमा है, इसलिए default में disabled है
  • API अभी स्थिर नहीं है, और chat format auto-conversion फिलहाल केवल K3 को support करती है
    • Kimi-Linear template guess नहीं करता और raw mode में चलता है
  • expert-wise non-uniform bit allocation लाने की योजना नहीं है
    • तीसरे bit की value, एक layer के experts के बीच अधिकतम 1.15x और layers के बीच 1.01x ही बदलती है, इसलिए optimal allocation का लाभ नहीं मिला
    • routing frequency आधारित allocation storage घटा सकता है, लेकिन bottleneck I/O को लगभग कम नहीं करता
  • license Apache 2.0 है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 3 시간 전
Hacker News की राय

  • वाकई शानदार। यह ऐसा प्रोजेक्ट नहीं है जो अभी तुरंत cloud providers से ज़्यादा व्यावहारिक बनने की कोशिश कर रहा हो, बल्कि संभावना की सीमा दिखाने वाला प्रोजेक्ट है
    अगर model efficiency में सुधार और local hardware performance में बढ़ोतरी साथ-साथ होती रही, तो किसी दिन high-quality local models को आर्थिक रूप से चलाना भी संभव हो सकता है

  • 0.5 tokens per second लंबे कामों के लिए भी बेकार लगते हैं। मैं तो इसके बजाय पैसे लगाकर 16GB 4060 Ti की 2 cards लेकर tensor parallelism लगाऊंगा
    20 साल बाद यह शायद solar-powered, cyberpunk-style धीमे robots के लिए ठीक लगे, जो lawn काटते हों या footpath साफ करते हों, या बगीचे में bonsai की growth speed के साथ मुश्किल से तालमेल बिठाते हुए pruning करते हों

    • अभी यह लगभग इस्तेमाल लायक नहीं है, लेकिन ऐसे projects का लगातार बेहतर होना ज़रूरी है ताकि आखिरकार व्यावहारिक version तक पहुंचा जा सके, इसलिए अच्छा लग रहा है

  • token cost देने और inference provider के बिजली बिल भरने को waste बताया जा रहा है, लेकिन खीरा खरीदने पर किसान पानी और fertilizer का खर्च उठाता है, उससे यह अलग कैसे है समझ नहीं आता। उम्मीद है LLM ने बाद में बस तर्क फिट किया होगा
    idea अपने-आप में दिलचस्प है और मैं इसे छोटे models पर आज़माना चाहूंगा। अगर यह 0.5 tokens per second generate करते हुए SSD से हर second कई GB पढ़ता है, तो आम consumer laptop के लिए यह अब भी बहुत बड़ा है, लेकिन 250–500GiB models के लिए शायद उल्टा practical हो सकता है

    • खुद टमाटर उगाएं तो मुफ्त टमाटर मिलते हैं। BLT बनाने के लिए काफी न हों, फिर भी supermarket वाले नहीं हैं, तो आपने दुनिया को थोड़ा बचा लिया /s

  • अगर मानें कि यह लगातार 42W इस्तेमाल करता है और बिजली की दर 20 cents प्रति kWh है, तो 10 लाख tokens पर लगभग 5 डॉलर पड़ते हैं, hardware और बाकी खर्च छोड़कर

    • एक महीने में करीब 26 लाख seconds होते हैं, और 0.5 tokens per second पर महीने में 13 लाख tokens generate होंगे। ancillary costs मिलाकर देखें तो महीने का equipment operating cost ही 10 लाख tokens की cost मान लेना मोटे तौर पर सही रहेगा
    • अगर solar power हो तो calculation कैसे बदलती है, यह जानने की उत्सुकता है

  • standard llama.cpp भी GGUF को mmap कर सकता है, जिससे memory में न समाने वाले हिस्से disk पर रहते हैं, और kernel page cache अक्सर इस्तेमाल होने वाले हिस्से यानी resident trunk को बनाए रखता है। इसे खुद implement करने का फायदा क्या है, यह जानना चाहूंगा

    • कुछ दिन पहले एक similar project में भी यही सवाल आया था; उन्होंने कहा था कि पहले mmap आज़माया, फिर खुद implement किया और यह 10x तेज़ हो गया
      यह वही वजह है कि database engines अपना cache खुद implement करते हैं। kernel paging general-purpose और demand-based होती है, लेकिन अगर actual access pattern पता हो तो ज़रूरी data पहले से read करके pipeline किया जा सकता है
    • इस scale पर SSD को swap space की तरह इस्तेमाल करने पर सिर्फ कुछ महीनों में cumulative write endurance खत्म होना आसान है। short-term test से ज्यादा चलाने पर SMART की cumulative writes और wear statistics देखना चाहूंगा
      अगर model पूरा RAM में फिट होता हो, तो llama-server को --no-mmap के साथ चलाना बेहतर था। बेशक पूरे Kimi K3 और 10 लाख token context को लोड करने के लिए 2TB server चाहिए

  • README से LLM-written होने का एहसास बहुत मजबूत आता है; जानना चाहूंगा कि codebase भी LLM ने लिखा है या नहीं

    • मैं सतही तौर पर नीचा नहीं दिखाना चाहता, लेकिन docs खुद से ही contradict करते हैं कि model वाकई original precision में चल रहा है या नहीं। दावा किया गया 3-bit quantization दिलचस्प हो सकता है, लेकिन K3 के original precision dense parameters ही लगभग 115GB हैं, token प्रति active sparse experts लगभग 25GB हैं, और KV cache अलग से जुड़ता है, इसलिए 29GB RAM में 2 seconds per token वाला दावा समझना मुश्किल है
    • मैंने software का बड़ा हिस्सा खुद लिखा है और programming language भी बनाई है: https://github.com/marcobambini/gravity
      अब मैं LLMs और agents को coordinate करने में अपनी skills इस्तेमाल करता हूं ताकि बहुत तेजी से बेहतर code लिख सकूं। developers को नई technology के साथ adapt करना होगा या पीछे छूटना होगा
    • काश authors ने कम-से-कम LLM-generated README को खुद पढ़कर देखा होता। LLM में reader perspective की समझ कम होती है और वह मान लेता है कि बाहरी reader भी project का पूरा context और decision process जानता है
      users के लिए अहम, लेकिन finished product देखने वाले readers के लिए irrelevant internal decisions और Claude-style की उलझाऊ terminology वैसे ही आ जाती है। मैं मानता हूं कि LLMs का खूब इस्तेमाल करता हूं और वे complex code लिखने में बहुत उपयोगी हैं, लेकिन writing draft की quality बेहद खराब होती है
    • contributors list में claude है, इसलिए अनुमान लगाने की ज़रूरत ही नहीं। अगर Claude से commits तक करवाए जा रहे हैं, तो code को खुद review किया गया होने की संभावना भी कम लगती है
    • README में Claude की खास writing style सबसे ज्यादा महसूस होती है। जैसे हम अलग-अलग लोगों की writing पहचानते हैं, वैसे ही अब Claude द्वारा default में generate की जाने वाली छोटी, टूटी-फूटी और सिर्फ लय में जरूरत से ज्यादा सजी हुई style भी दिमाग में एक अलग category की तरह बैठती जा रही है

  • अगर technology इतनी आगे बढ़ जाए कि task के हिसाब से सही model ठीक-ठीक चुना जा सके, तो इसकी value बढ़ सकती है। मैं ऐसे future की कल्पना कर सकता हूं जहां automatic exploration process में दिन में सिर्फ 30 minutes बड़ा model चलाया जाए और बाकी समय छोटे models इस्तेमाल हों

    • ऐसा future शायद नहीं आएगा। backlog item का समय भी उसे पूरा करने के बाद ही पता चलता है; असल में काम किए बिना task complexity पहले से जानने का कोई तरीका नहीं है