- 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 को एक ही
.gturbomodel 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
preadcalls से भरा जाता है - SSD read चलने के दौरान Metal resident shared-expert branch की गणना करता है
- Read पूरा होने पर shared output और routed output को जोड़ा जाता है
- Cache miss को सीमित संख्या में parallel
- 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 लेकर उन्हें सीधे
.gturbolayout में repack करता है - पूरे shard या tensor को अलग से तैयार नहीं किया जाता, इसलिए अस्थायी मेमोरी उपयोग सीमित रहता है
- तैयार इंस्टॉल तभी उपयोग किया जा सकता है जब वह manifest और file hash verification पास करे
- ज़रूरी byte ranges लेकर उन्हें सीधे
- इंस्टॉलेशन पूरा होने के बाद model लगभग 14.3GB storage लेता है, और इंस्टॉलेशन प्रक्रिया खुद model को मेमोरी में लोड नहीं करती
- Runtime केवल final
manifest.jsonवाले पूर्ण.gturbodirectory को स्वीकार करता है - 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 libraryTurboFieldfareMac: installation और generation के लिए native Mac appTurboFieldfareDecodeService: Mac app द्वारा इस्तेमाल किया जाने वाला one-shot local model·Metal ownership processTurboFieldfareCLI: command-line instruction chat और raw completionTurboFieldfareServer: loopback OpenAI-compatible Chat Completions serverTurboFieldfareRepack: 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 कर सकता है
- Response limit
--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-K64, Top-P0.95- Temperature को
0पर सेट करने से deterministic greedy output उपयोग होता है - Model दोहराव कर सकता है या गलत जवाब दे सकता है, इसलिए महत्वपूर्ण परिणामों की पुष्टि करनी चाहिए
- Temperature को
- 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--stopstrings उपलब्ध कराता है
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 एक ही
.gturbodirectory का उपयोग करते हैं, लेकिन 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 टिप्पणियां
Hacker News की राय
मुझे हमेशा यह सवाल रहा है कि हर बार Charles राजा कौन है, यह जानने तक के लिए पूरा मॉडल मेमरी में क्यों ठूंसना पड़ता है। बड़ी फाइलों को छोटे टुकड़ों में बांटकर कम मेमरी में कुशलता से पढ़ने की तकनीक पहले से स्थापित है
अत्याधुनिक AI इंडस्ट्री में मॉडल बनाने में तो महारत दिखती है, लेकिन स्केलिंग और व्यावहारिकता को इन्फ्रास्ट्रक्चर टीमों पर छोड़ देने की प्रवृत्ति दिखती है। अगर वास्तव में इस्तेमाल होने वाला ज्ञान 10% से कम है, तो fine-tuning और optimization से लागत काफी घटाई जा सकती है
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_0comments के मुताबिक attention 11.24x तेज़ होने से prefill 2.4x accelerate होने वाला फायदा छूट जाएगा, लेकिन 8-core GPU M1 Air पर 5–6 tokens per second मिलते हैं
2.4x prefill improvement केवल apple10 GPU family पर काम करता है, और याद पड़ता है M1 apple7 है
जानना चाहूंगा कि यह प्रोजेक्ट साधारण
mmapसे कैसे compare करता है। llama.cpp में भीmmapenable और repacking बंद करने पर चाहें तो 26B model को 2GB RAM में चला सकते हैंमुख्य फर्क यह लगता है कि SSD reads को inference work के साथ synchronize करके latency घटाई गई है, जबकि operating system ऐसा execution context ध्यान में नहीं रखता
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 से कम में चल तो सकता है, लेकिन शायद धीमा होगा“measurement results are a baseline, not a ceiling” वाला वाक्य Claude जैसी विशिष्ट अभिव्यक्ति लगता है
अगर लेखक ने LLM से सिर्फ sentences polish करवाए हैं और फालतू सामग्री नहीं जोड़ी, तो कोई बात नहीं। अगर लेख खुद ही बेकार generated output है, तो बस उसे कम score दे दें
तेज़ SSD वाले M1 Max Mac Studio पर 12 tokens per second और लगभग तुरंत response मिलना impressive है। यह बड़े models को memory के बजाय सीधे SSD से चलाने की संभावना दिखाता है
आजकल 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 से ही इसे ध्यान में रख सकते हैं
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 करने लायक हालत में नहीं है
इस पर आपके विचार जानना चाहूंगा
यह जानने की उत्सुकता है कि 8GB M2 MacBook Air के प्रति सेकंड 5–6 टोकन और M5 MacBook Pro के 31–35 टोकन के बीच इतना बड़ा अंतर क्यों है। SSD performance में इतना बड़ा फर्क होने की संभावना नहीं लगती, लेकिन इस तरीके में SSD के प्रमुख bottleneck होने की उम्मीद थी
https://www.tomshardware.com/laptops/macbooks/m5-macbook-pro...
अगर operating system cache सहित कुल केवल 2GB ही इस्तेमाल किए जा सकते हों, तो inference speed और कम हो सकती है
preadपर काफी निर्भर करता है। process 2GB से नीचे होने पर भी M5 Mac कुछ हिस्सा cache कर सकता है, और hardware खुद भी कहीं ज्यादा तेज़ हैप्रति token read M2 पर 83ms और M5 Pro पर 12ms था, जबकि कुल समय क्रमशः 163ms और 30ms था। यह read और GPU processing दोनों के तेज़ होने का नतीजा है
उम्मीद है कि आगे 30–60GB memory और बेहद तेज़ SSD वाले systems पर इस तरह की techniques से बहुत बड़े models भी चलाए जा सकेंगे
https://github.com/danveloper/flash-moe
https://github.com/JustVugg/colibri
https://github.com/antirez/ds4 या खुद बनाए गए https://github.com/steadfastgaze/MoEspresso का इस्तेमाल किया जा सकता है। अगले token के लिए जो experts memory में नहीं हैं उन्हें SSD से पढ़ना पड़ता है, इसलिए speed SSD read से सीमित होती है, और memory जितनी बड़ी होगी inference उतना तेज़ होगा