1 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • TurboFieldfare पूरा 14.3GB मॉडल मेमोरी में लोड किए बिना Gemma 4 26B-A4B को लगभग 2GB मेमोरी में चलाता है, जिससे 8GB Apple Silicon Mac पर भी लोकल inference संभव होता है
  • MoE expert weights में से हर token के लिए ज़रूरी weights को SSD से stream किया जाता है, जबकि 1.35GB shared core और FP16 KV cache ही resident रहते हैं; 16-slot LFU cache और parallel pread से I/O सीमित रखा जाता है
  • Gemma 4 26B-A4B हर token पर लगभग 3.88B parameters activate करता है, और मापी गई decoding speed 8GB M2 MacBook Air पर 5.1~6.3 tok/s तथा 24GB M5 Pro पर 31~35 tok/s है
  • यह Swift 6.2 और Metal 4 में बना समर्पित runtime है, जो native Mac app, CLI, installer और experimental OpenAI-compatible server को एक ही .gturbo model directory पर उपलब्ध कराता है
  • अभी इसका दायरा macOS 26 या उससे ऊपर और कम से कम 8GB RAM वाले Apple Silicon Mac पर सिर्फ text inference तक सीमित है; image, audio, video, remote server authentication और TLS समर्थित नहीं हैं

मेमोरी घटाने वाली execution संरचना

  • TurboFieldfare instruction-tuned Gemma 4 26B-A4B को पूरी तरह मेमोरी में लोड नहीं करता
    • 1.35GB shared core और FP16 KV cache मेमोरी में बनाए रखे जाते हैं
    • हर token के लिए ज़रूरी routed expert ही SSD से उस buffer में पढ़े जाते हैं जिसे Metal देख सकता है
    • इंस्टॉल किया गया text-only model लगभग 14.3GB का है, लेकिन weights और 4K KV cache द्वारा इस्तेमाल की जाने वाली मेमोरी लगभग 2GB है
  • मॉडल कुल 26B parameters में से हर token पर लगभग 3.88B parameters activate करता है
  • Weights में group 64 आधारित MLX affine 4-bit का उपयोग होता है; router 8-bit है, और shared तथा routed expert 4-bit हैं
  • यह MLX या llama.cpp को wrap करने वाला सेटअप नहीं, बल्कि Gemma 4 26B-A4B के लिए बनाया गया Swift·Metal dedicated runtime है

Token generation प्रक्रिया

  • हर Transformer layer में Metal resident weights के साथ attention और router की गणना करता है
  • CPU router द्वारा चुने गए top 8 expert ID को layer-वार 16-slot LFU cache से मिलाता है
    • Cache miss को सीमित संख्या में parallel pread calls से भरा जाता है
    • SSD read चलने के दौरान Metal resident shared-expert branch की गणना करता है
    • Read पूरा होने पर shared output और routed output को जोड़ा जाता है
  • Prompt prefill में अधिकतम 128-token chunks का उपयोग होता है, ताकि एक बार लाया गया expert कई rows को प्रोसेस कर सके
  • Generation चरण में routed layer loop token-दर-token दोहराया जाता है
  • KV cache, 25 sliding-window layers के लिए सीमित circular storage और 5 full-attention layers के लिए linear storage का उपयोग करता है
  • Decoding attention, normalized K और V paths को अलग करने वाली exact split-K/V विधि का उपयोग करता है

इंस्टॉलेशन और model format

  • पहली बार चलाने पर Download चुनने से fixed Hugging Face revision से लगभग 15GB range requests के जरिए डाउनलोड होता है
  • Installer मूल checkpoint को अस्थायी फ़ाइल या मेमोरी में पूरी तरह नहीं बनाता
    • ज़रूरी byte ranges लेकर उन्हें सीधे .gturbo layout में repack करता है
    • पूरे shard या tensor को अलग से तैयार नहीं किया जाता, इसलिए अस्थायी मेमोरी उपयोग सीमित रहता है
    • तैयार इंस्टॉल तभी उपयोग किया जा सकता है जब वह manifest और file hash verification पास करे
  • इंस्टॉलेशन पूरा होने के बाद model लगभग 14.3GB storage लेता है, और इंस्टॉलेशन प्रक्रिया खुद model को मेमोरी में लोड नहीं करती
  • Runtime केवल final manifest.json वाले पूर्ण .gturbo directory को स्वीकार करता है
  • Interrupted download resume, partial download state deletion, और model लोड किए बिना installation verification समर्थित हैं

runtime environment और performance

  • आवश्यक environment है Apple Silicon Mac, macOS 26, Metal 4, Xcode 26, Swift 6.2 या उससे ऊपर
  • Package arm64-only है और पुराने macOS व Metal versions को support नहीं करता
  • सत्यापन 8GB M2 MacBook Air पर किया गया है, और model installation के लिए खाली storage space तथा पहली डाउनलोड के लिए internet connection चाहिए
  • मापी गई decoding performance इस प्रकार है
    • 8GB M2 MacBook Air: 5.1~6.3 tok/s
    • 24GB M5 Pro: 31~35 tok/s
  • Throughput prompt length, generation length, page cache state और hardware के अनुसार बदलता है, इसलिए ये माप performance ceiling नहीं बल्कि baseline हैं
  • Model चलाने से पहले ज़्यादा मेमोरी लेने वाले apps बंद करने चाहिए और memory_pressure -Q से उपलब्ध मेमोरी जांचनी चाहिए
  • App, decode service, CLI, server, tests या अन्य local model process में से एक समय पर केवल एक ही चलाना चाहिए

उपलब्ध products और उपयोग का तरीका

  • Swift package छह products उपलब्ध कराता है
    • TurboFieldfare: runtime और Metal kernels वाली Swift library
    • TurboFieldfareMac: installation और generation के लिए native Mac app
    • TurboFieldfareDecodeService: Mac app द्वारा इस्तेमाल किया जाने वाला one-shot local model·Metal ownership process
    • TurboFieldfareCLI: command-line instruction chat और raw completion
    • TurboFieldfareServer: loopback OpenAI-compatible Chat Completions server
    • TurboFieldfareRepack: streaming installation और installation verification tool
  • Mac app में model डाउनलोड करने के बाद Load Model चुनें और prompt दर्ज करके generation करें
    • Status bar में progress, decoding speed और memory usage देखा जा सकता है
    • Sampling, context length, expert-cache slots और runtime options को समायोजित किया जा सकता है
  • CLI का instruction chat JSON message array लेता है और उसे Mac app के समान format में बदलता है
    • Response limit --max-new का default 1,024 tokens है
    • Mac app चुनी गई context window भरने तक generation कर सकता है
  • --prompt का उपयोग chat format लागू किए बिना raw completion और reproducible comparison के लिए किया जाता है
  • Generated text standard output पर जाता है, time statistics standard error पर, और --quiet से statistics output बंद किया जा सकता है

Prompt और supported scope

  • Mac app input को instruction के रूप में प्रोसेस करता है और Gemma का chat format अपने आप लागू करता है
  • Default sampling settings हैं temperature 0.2, Top-K 64, Top-P 0.95
    • Temperature को 0 पर सेट करने से deterministic greedy output उपयोग होता है
    • Model दोहराव कर सकता है या गलत जवाब दे सकता है, इसलिए महत्वपूर्ण परिणामों की पुष्टि करनी चाहिए
  • App और CLI user·model messages तथा optional system guidance को support करते हैं, लेकिन tools को expose या execute नहीं करते
  • अभी model input/output केवल text-only है; image, audio और video समर्थित नहीं हैं
  • CLI --max-context, --temperature, --top-k, --top-p, --repetition-penalty, --seed, और repeatable --stop strings उपलब्ध कराता है

OpenAI-compatible local server

  • Experimental server 127.0.0.1:8080/v1 पर चलता है और Chat Completions, streaming, function tool declaration, तथा single prefix prompt reuse को support करता है
  • Server model द्वारा बनाए गए tool calls लौटाता है, लेकिन सभी tool call approval और execution की ज़िम्मेदारी client की होती है
  • Remote authentication और TLS नहीं होने के कारण server को सिर्फ loopback पर ही रखना चाहिए
  • Mac app, CLI और server एक ही .gturbo directory का उपयोग करते हैं, लेकिन model का ownership रखने वाला product एक समय पर केवल एक ही चलना चाहिए

implementation scope और experiment log

  • Custom Metal kernels quantized GEMV, attention, MoE, normalization, RoPE, sampling और production fusion को संभालते हैं
  • Runtime SSD-आधारित routed-expert streaming, सीमित expert cache, chunk-based single-prompt prefill, और token-based generation लागू करता है
  • Kernels, caching, I/O, prefill और decode में फैले 103 measured results को experiment log के रूप में रखा गया है
  • Experiment documents में असरदार optimizations, विफल ideas, और वे शुरुआती results शामिल हैं जो बाद में अधिक सख्त validation के बाद पलट गए
  • आगे के काम में iPhone·iPad app development, mobile inference speed·memory measurement, और 16GB M4 Mac mini व अन्य 8GB Apple Silicon Mac के benchmarks शामिल हैं

License और model terms

  • Source code और documents Apache License 2.0 के तहत वितरित किए जाते हैं
  • Model weights repository में शामिल नहीं हैं; installer उन्हें fixed Hugging Face checkpoint से अलग से डाउनलोड करता है
  • Weights पर मूल वितरण शर्तें लागू रहती हैं
  • TurboFieldfare, Google से संबद्ध या Google द्वारा प्रायोजित/स्वीकृत परियोजना नहीं, बल्कि एक independent research project है

1 टिप्पणियां

 
GN⁺ 3 시간 전
Hacker News की राय
  • मुझे हमेशा यह सवाल रहा है कि हर बार Charles राजा कौन है, यह जानने तक के लिए पूरा मॉडल मेमरी में क्यों ठूंसना पड़ता है। बड़ी फाइलों को छोटे टुकड़ों में बांटकर कम मेमरी में कुशलता से पढ़ने की तकनीक पहले से स्थापित है
    अत्याधुनिक AI इंडस्ट्री में मॉडल बनाने में तो महारत दिखती है, लेकिन स्केलिंग और व्यावहारिकता को इन्फ्रास्ट्रक्चर टीमों पर छोड़ देने की प्रवृत्ति दिखती है। अगर वास्तव में इस्तेमाल होने वाला ज्ञान 10% से कम है, तो fine-tuning और optimization से लागत काफी घटाई जा सकती है

    • पूरा मॉडल मेमरी में रखना डिस्क से swap करने की तुलना में कहीं तेज़ है
    • असल में यह Mixture of Experts (MoE) संरचना का ही वर्णन है। अगर expert layers पर्याप्त छोटी हों और SSD तेज़ हो, तो उन्हें जरूरत पड़ने पर ही लोड किया जा सकता है
      Dense LLM आम तौर पर बेहतर प्रदर्शन देते हैं, लेकिन layers को external storage में भेजने पर वे MoE की तुलना में बहुत ज्यादा धीमे हो जाते हैं
  • आजकल अज्ञात स्रोत वाले प्रोजेक्ट डाउनलोड करते समय ऐसी security review खुद चलानी पड़ती है। repository के agent instructions और Markdown files को अनदेखा कर Swift/Metal source, build scripts, CI config और dependencies की जांच करवाई; malicious code, backdoor, credential theft या hidden network endpoints तो नहीं मिले, लेकिन compile, supply-chain और runtime risks अब भी बचे हुए बताए गए
    अगर किसी के पास बेहतर prompt हो तो साझा कर सकते हैं; Cursor के Composer 2.5 से चलाने की लागत 0.20 डॉलर से कम थी

  • अगर M1 MacBook Air पर macOS 15 इस्तेमाल कर रहे हैं, तो ये दो lines हटाने या if #available(macOS 26.0, *) से wrap करने पर compile हो जाता है: opts.languageVersion = .version4_0
    comments के मुताबिक attention 11.24x तेज़ होने से prefill 2.4x accelerate होने वाला फायदा छूट जाएगा, लेकिन 8-core GPU M1 Air पर 5–6 tokens per second मिलते हैं

    • उपयोगी जानकारी है। बाद में minimum supported version घटाने की कोशिश की जा सकती है
      2.4x prefill improvement केवल apple10 GPU family पर काम करता है, और याद पड़ता है M1 apple7 है
  • जानना चाहूंगा कि यह प्रोजेक्ट साधारण mmap से कैसे compare करता है। llama.cpp में भी mmap enable और repacking बंद करने पर चाहें तो 26B model को 2GB RAM में चला सकते हैं
    मुख्य फर्क यह लगता है कि SSD reads को inference work के साथ synchronize करके latency घटाई गई है, जबकि operating system ऐसा execution context ध्यान में नहीं रखता

    • पहले version में mmap इस्तेमाल हुआ था। 8GB M2 पर cold state में 3.36MB expert पढ़ने में mmap को 10ms लगे, जबकि pread को 2.8ms; पूरी simulation में क्रमशः 0.50 tokens/sec और 4 tokens/sec मिले
      mmap में जब model pages को touch करता है, तब operating system reactive तरीके से पढ़ता है, इसलिए उसे पता नहीं होता कि कौन सा expert चुना गया है या GPU work और read को कब overlap किया जा सकता है। common weights simplicity के लिए अब भी mmap इस्तेमाल करते हैं, और llama.cpp भी 2GB से कम में चल तो सकता है, लेकिन शायद धीमा होगा
    • असली speed जानने के लिए llama.cpp के SSD offloading से सीधे compare करना चाहूंगा
  • “measurement results are a baseline, not a ceiling” वाला वाक्य Claude जैसी विशिष्ट अभिव्यक्ति लगता है

    • ऐसी expressions इतनी फैल गई हैं कि Claude-style लिखावट बार-बार पढ़ते-पढ़ते कहीं मैं भी वही आदत न सीख लूं, इसकी चिंता होने लगी है
    • “100 से ज्यादा experiments किए, ज्यादातर fail हुए लेकिन कुछ ने यहां तक पहुंचाया” भी वैसा ही संकेत लगता है
    • संभव है कि मूल रूप से यह ChatGPT-style expression रहा हो, लेकिन इसलिए मैं किसी पश्चिमी कंपनी को distill करने का आरोप नहीं लगाऊंगा। 2022 के बाद के recipe blogs शायद 4.6–4.8 के आसपास training data में चले गए हों
    • अब ऐसे पहचानने-छांटने का समय खत्म होना चाहिए। यह नई तरह की grammar policing से अलग नहीं है और ज्यादा value भी नहीं जोड़ता
      अगर लेखक ने LLM से सिर्फ sentences polish करवाए हैं और फालतू सामग्री नहीं जोड़ी, तो कोई बात नहीं। अगर लेख खुद ही बेकार generated output है, तो बस उसे कम score दे दें
  • तेज़ SSD वाले M1 Max Mac Studio पर 12 tokens per second और लगभग तुरंत response मिलना impressive है। यह बड़े models को memory के बजाय सीधे SSD से चलाने की संभावना दिखाता है

    • अफसोस कि यहां SSD read speed सबसे बड़ा bottleneck है
  • आजकल SSD streaming engines तो कई हैं, लेकिन कठिन features तक जाने की कोशिश कम ही दिखती है। मुख्य model में speculative decoding के लिए MTP head होता है, इसलिए इसे SSD के expert weights को पहले से read करने में इस्तेमाल किया जा सकता है
    GPU को जरूरत पड़ने से पहले weights तैयार कर दिए जाएं, तो VRAM cache miss की cost काफी घट सकती है; अगर यह असरदार साबित हुआ, तो भविष्य के models experts को पहले से लोड करने के dedicated heads रखकर training stage से ही इसे ध्यान में रख सकते हैं

    • SSD streaming में GPU सही expert लाए जाने तक लगभग हमेशा SSD का इंतजार करता है, इसलिए SSD side पर पहले से read करने की गुंजाइश practically नहीं होती। गलत predict किए गए expert को पढ़ना उल्टा नुकसान है, और इसी वजह से सामान्य non-large-batch environment में मौजूदा MTP भी खास मददगार नहीं है
    • असल में यह उम्मीद से ज्यादा कठिन है। हर layer में experts का set अलग होता है, और छोटा router नीचे की layer के experts की output state देखकर तय करता है कि कौन सा expert इस्तेमाल होगा
      MTP के बनाए draft token से पहली layer के experts तक predict किए जा सकते हैं, लेकिन 10वीं layer जानने के लिए 1–9वीं layers चलानी होंगी और उन experts को पहले पढ़ना होगा। इसलिए next-token generator के बजाय सभी layers के expert activations को एक साथ predict करने के लिए trained device चाहिए
  • DiffusionGemma चलाने वाला project भी लगभग तैयार है और दोनों projects को जोड़ना अच्छा fit हो सकता है। 36GB M3 पर लगभग 20 tokens per second मिलते हैं और एक-दूसरे से तेज़ kernels लेने की संभावना भी काफी है
    मौजूदा code https://github.com/mmastrac/diffgemma पर है, लेकिन अभी release करने लायक हालत में नहीं है

    • हाल में देखा था, लेकिन diffusion model को local चलाने में कम practical benefit लगा: https://eamag.me/2026/why-parallel-diffusion-llms-are-slow-o...
      इस पर आपके विचार जानना चाहूंगा
    • Diffusion Gemma project के बीच में आया था, इसलिए switch करने पर गंभीरता से विचार किया, लेकिन मौजूदा दिशा में ही पूरा करने का फैसला किया। दोनों projects बहुत अच्छी तरह fit होंगे लगता है, और जरूरत का code freely इस्तेमाल कर सकते हैं या README के अंत में दिए LinkedIn से संपर्क कर सकते हैं
  • यह जानने की उत्सुकता है कि 8GB M2 MacBook Air के प्रति सेकंड 5–6 टोकन और M5 MacBook Pro के 31–35 टोकन के बीच इतना बड़ा अंतर क्यों है। SSD performance में इतना बड़ा फर्क होने की संभावना नहीं लगती, लेकिन इस तरीके में SSD के प्रमुख bottleneck होने की उम्मीद थी

    • M5 SSD की performance improvement पिछली पीढ़ी की तुलना में भी काफी बड़ी है। Blackmagic Disk Speed Test में M5 MacBook Pro ने अधिकतम 6,323MB/s, जबकि M4 MacBook Pro ने 2,031MB/s दर्ज किया, यानी 3 गुना से भी ज्यादा अंतर था
      https://www.tomshardware.com/laptops/macbooks/m5-macbook-pro...
    • संभावना ज्यादा है कि M5 में memory अधिक होने के कारण operating system ने फ़ाइल का अधिकांश हिस्सा पहले ही cache कर रखा है। M2 में memory pressure अधिक होगा, इसलिए वह SSD read results को कम cache करेगा
      अगर operating system cache सहित कुल केवल 2GB ही इस्तेमाल किए जा सकते हों, तो inference speed और कम हो सकती है
    • यह system cache और pread पर काफी निर्भर करता है। process 2GB से नीचे होने पर भी M5 Mac कुछ हिस्सा cache कर सकता है, और hardware खुद भी कहीं ज्यादा तेज़ है
      प्रति token read M2 पर 83ms और M5 Pro पर 12ms था, जबकि कुल समय क्रमशः 163ms और 30ms था। यह read और GPU processing दोनों के तेज़ होने का नतीजा है
    • पीढ़ी पुरानी होने के कारण Pro-to-Pro तुलना में भी SSD काफी धीमा है, और समान पीढ़ी में भी Air के SSD और memory bandwidth के Pro से कम होने की संभावना है
    • M5 MacBook Pro में 24GB RAM है, इसलिए यह अधिक context को memory में रख भी सकता है
  • उम्मीद है कि आगे 30–60GB memory और बेहद तेज़ SSD वाले systems पर इस तरह की techniques से बहुत बड़े models भी चलाए जा सकेंगे

    • Colibri और Flash-MoE पहले से इसे आज़मा रहे हैं
      https://github.com/danveloper/flash-moe
      https://github.com/JustVugg/colibri
    • 64GB unified memory हो तो DeepSeek V4 Flash quantized model को प्रति सेकंड 7–10 टोकन पर चलाया जा सकता है
      https://github.com/antirez/ds4 या खुद बनाए गए https://github.com/steadfastgaze/MoEspresso का इस्तेमाल किया जा सकता है। अगले token के लिए जो experts memory में नहीं हैं उन्हें SSD से पढ़ना पड़ता है, इसलिए speed SSD read से सीमित होती है, और memory जितनी बड़ी होगी inference उतना तेज़ होगा