antirez/ds4 - Metal के लिए DeepSeek V4 Flash लोकल inference इंजन

 (github.com/antirez)
1 पॉइंट द्वारा GN⁺ 8 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Apple Metal GPU के लिए ऑप्टिमाइज़ किया गया DeepSeek V4 Flash-विशेष लोकल inference इंजन, जो किसी जनरल-परपज़ GGUF runner के बजाय एक ही मॉडल पर केंद्रित native C implementation है
  • DeepSeek V4 Flash में active parameters कम हैं, इसलिए यह तेज़ स्पीड देता है, और thinking mode में अन्य मॉडलों की तुलना में लगभग 1/5 जितना छोटा reasoning segment बनाता है
  • 10 लाख token context window और बेहद compressed KV cache की मदद से लोकल environment में भी long-context inference संभव है, साथ ही disk KV cache persistence सपोर्ट भी है
  • OpenAI और Anthropic-compatible HTTP API server built-in है, इसलिए Claude Code, opencode, Pi जैसे कई coding agents के साथ तुरंत integration संभव है
  • यह llama.cpp और GGML ecosystem की नींव पर बनाया गया है, और GPT 5.5 की मजबूत coding सहायता के साथ विकसित किया गया प्रोजेक्ट है

प्रोजेक्ट अवलोकन और design philosophy

  • ds4.c एक छोटा native inference इंजन है जो सिर्फ DeepSeek V4 Flash के लिए बना है; यह कोई generic GGUF runner या किसी दूसरे runtime का wrapper नहीं है
  • इसका core path DeepSeek V4 Flash के लिए विशेष रूप से तैयार किया गया Metal graph executor है, जिसमें DS4-specific loading, prompt rendering, KV state और server API glue code शामिल हैं
  • लोकल inference क्षेत्र में कई बेहतरीन प्रोजेक्ट हैं, लेकिन नए मॉडल लगातार आने से ध्यान बिखरने की समस्या रहती है
    • यह प्रोजेक्ट जानबूझकर एक समय में एक मॉडल पर फोकस करता है, और official vector verification (logits), long-context tests तथा agent integration तक करता है
  • लोकल inference की vision: A) HTTP API सहित inference इंजन + B) किसी खास इंजन के लिए ऑप्टिमाइज़ किया गया GGUF + C) coding agent implementations के माध्यम से testing और validation — ये तीनों साथ काम करें
  • यह सिर्फ Metal के लिए है; भविष्य में CUDA सपोर्ट की संभावना है, लेकिन तय नहीं है
    • CPU path केवल correctness verification के लिए मौजूद है, और वर्तमान macOS version के virtual memory implementation bug के कारण CPU code चलाने पर kernel crash होता है
  • इसे GPT 5.5 के मजबूत समर्थन से विकसित किया गया, जबकि इंसानों ने ideas, testing और debugging को lead किया

DeepSeek V4 Flash के लिए अलग इंजन क्यों बनाया गया

  • Active parameters कम होने के कारण ज़्यादा तेज़ inference speed मिलती है
  • Thinking mode में यह दूसरे मॉडलों की तुलना में लगभग 1/5 जितना छोटा reasoning segment बनाता है, और reasoning segment की लंबाई समस्या की जटिलता के अनुपात में होती है
    • जिन स्थितियों में दूसरे मॉडल thinking mode में practically usable नहीं रहते, वहाँ DeepSeek V4 Flash उपयोगी रहता है
  • 10 लाख token context window सपोर्ट करता है
  • 284B parameters के स्केल पर यह 27B, 35B मॉडलों की तुलना में knowledge boundary पर अधिक जानकारी रखता है
    • इतालवी TV कार्यक्रमों, राजनीति-संबंधित सवालों आदि में यह अंतर देखा जा सकता है
  • अंग्रेज़ी और इतालवी writing quality लगभग frontier मॉडल-स्तर की है
  • KV cache बहुत अधिक compressed है, इसलिए लोकल कंप्यूटर पर long-context inference संभव है, और disk KV cache persistence सपोर्ट भी है
  • खास तरीके से quantization करने पर यह 2-bit quantization पर भी अच्छी तरह काम करता है, इसलिए 128GB RAM वाले MacBook पर चल सकता है
  • आगे चलकर DeepSeek की ओर से V4 Flash का updated version आने की संभावना है

llama.cpp और GGML के प्रति आभार

  • ds4.c, GGML से link नहीं करता, लेकिन यह llama.cpp प्रोजेक्ट द्वारा बनाई गई राह पर खड़ा है
  • llama.cpp के kernels, quantization formats, GGUF ecosystem, और hard-won engineering knowledge इस काम के लिए आवश्यक reference रहे
  • कुछ source-level code MIT license के तहत रखा गया या अपनाया गया है: GGUF quant layouts और tables, CPU quant/dot logic, कुछ Metal kernels आदि
  • LICENSE फ़ाइल में GGML authors के copyright notices बनाए रखे गए हैं

मॉडल weights

  • यह सिर्फ इस प्रोजेक्ट के लिए प्रकाशित DeepSeek V4 Flash GGUF के साथ काम करता है; कोई भी मनमाना DeepSeek/GGUF फ़ाइल compatible नहीं है
  • 2-bit quantization में asymmetric quantization तरीका अपनाया गया है
    • केवल MoE experts को quantize किया जाता है: up/gate के लिए IQ2_XXS, down के लिए Q2_K
    • Shared experts, projections, routing और बाकी components को quantize नहीं किया जाता, ताकि quality बनी रहे
  • ./download_model.sh q2 से 128GB RAM मशीन के लिए, और ./download_model.sh q4 से 256GB या अधिक RAM मशीन के लिए मॉडल डाउनलोड करें
    • डाउनलोड Hugging Face (antirez/deepseek-v4-gguf) से होता है, और curl -C - के जरिए partial download resume सपोर्ट मिलता है
  • ./download_model.sh mtp से optional speculative decoding सपोर्ट वाला GGUF डाउनलोड किया जा सकता है
    • MTP/speculative decoding path अभी experimental है और फिलहाल केवल हल्का speedup देता है

स्पीड benchmark

  • --ctx 32768, --nothink, greedy decoding, -n 256 सेटिंग पर single-run Metal CLI आंकड़े
  • MacBook Pro M3 Max, 128GB (q2)
    • Short prompt: prefill 58.52 t/s, generation 26.68 t/s
    • 11709-token prompt: prefill 250.11 t/s, generation 21.47 t/s
    • q4 memory की कमी के कारण N/A
  • Mac Studio M3 Ultra, 512GB (q2)
    • Short prompt: prefill 84.43 t/s, generation 36.86 t/s
    • 11709-token prompt: prefill 468.03 t/s, generation 27.39 t/s
  • Mac Studio M3 Ultra, 512GB (q4)
    • Short prompt: prefill 78.95 t/s, generation 35.50 t/s
    • 12018-token prompt: prefill 448.82 t/s, generation 26.62 t/s

CLI उपयोग

  • -p option से one-shot prompt चलाया जाता है; -p के बिना चलाने पर interactive multi-turn chat mode शुरू होता है
  • Interactive CLI rendered chat transcript और live Metal KV checkpoints बनाए रखता है, ताकि हर turn पिछली बातचीत का विस्तार बने
  • उपयोगी commands: /help, /think, /think-max, /nothink, /ctx N, /read FILE, /quit
    • Ctrl+C से मौजूदा generation रोककर prompt पर वापस लौटा जा सकता है
  • Default रूप से thinking mode चालू रहता है; /nothink या --nothink से direct-response mode में जाया जा सकता है
  • --mtp MTP.gguf --mtp-draft 2 से optional MTP speculative path enable किया जा सकता है
    • यह सिर्फ greedy decoding में उपयोगी है, और slow acceptances से बचने के लिए confidence gate (--mtp-margin) का उपयोग करता है

सर्वर

  • OpenAI/Anthropic-compatible लोकल HTTP server चलाया जा सकता है
  • यह Metal-only है और memory में एक mutable graph/KV checkpoint बनाए रखता है
    • अगर stateless client उसी prompt का लंबा version दोबारा भेजता है, तो shared prefix reuse किया जा सकता है
  • Request parsing और sockets client thread में चलते हैं, लेकिन inference खुद एक single Metal worker के जरिए serialized होता है
    • अभी सर्वर कई independent requests को batch नहीं करता; concurrent requests क्रम से wait करती हैं

  • समर्थित endpoints

    • GET /v1/models, GET /v1/models/deepseek-v4-flash
    • POST /v1/chat/completions, POST /v1/completions, POST /v1/messages

  • /v1/chat/completions (OpenAI-compatible)

    • messages, max_tokens/max_completion_tokens, temperature, top_p, top_k, min_p, seed, stream, stream_options.include_usage, tools, tool_choice सपोर्ट करता है
    • Tool schema को DeepSeek के DSML tool format में render किया जाता है, और generated DSML tool calls को वापस OpenAI tool calls में बदला जाता है

  • /v1/messages (Anthropic-compatible)

    • Claude Code-style clients के लिए endpoint
    • system, messages, tools, tool_choice, max_tokens, temperature, top_p, top_k, stream, stop_sequences, thinking control सपोर्ट
    • Tool use Anthropic tool_use block के रूप में लौटाया जाता है
  • दोनों APIs SSE streaming सपोर्ट करती हैं, और thinking mode में reasoning process native API format में stream होता है

agent client integration

  • ds4-server को OpenAI-compatible chat completions इस्तेमाल करने वाले लोकल coding agents के साथ जोड़ा जा सकता है
  • 128GB RAM पर 2-bit quant (81GB) चलाते समय 100k~300k token context window उपयुक्त मानी जाती है
    • पूरा 1M token context लगभग 26GB memory लेता है, जिसमें केवल compressed indexer ही लगभग 22GB लेता है
  • 384000 output limit सेट करके token cap से बचा जा सकता है (मॉडल अधिकतम 384k tokens तक generate कर सकता है)

  • opencode integration

    • ~/.config/opencode/opencode.json में provider और agent entries जोड़कर configure करें
    • baseURL को http://127.0.0.1:8000/v1 पर सेट करें

  • Pi integration

    • ~/.pi/agent/models.json में provider config जोड़ें
    • DeepSeek thinking format, reasoning effort support, streaming usage support जैसी compatibility options शामिल हैं
    • ~/.pi/agent/settings.json में इसे default model के रूप में सेट किया जा सकता है

  • Claude Code integration

    • Anthropic-compatible endpoint का उपयोग करें, और ~/bin/claude-ds4 wrapper script से environment variables सेट करें
    • ANTHROPIC_BASE_URL को लोकल server पर सेट करें और सभी model variables को deepseek-v4-flash रखें
    • Claude Code शुरुआत में लगभग 25k tokens का बड़ा prompt भेजता है, इसलिए --kv-disk-dir enable करना ज़रूरी है
      • पहले expensive prefill के बाद disk KV cache saved prefixes को reuse करती है, इसलिए बाद की sessions में पूरा prompt दोबारा process नहीं करना पड़ता

Thinking mode

  • DeepSeek V4 Flash तीन modes सपोर्ट करता है: non-thinking, thinking, और Think Max
  • Server default रूप से thinking mode में चलता है
  • reasoning_effort=max से Think Max माँगा जा सकता है, लेकिन यह तभी लागू होता है जब context size मॉडल कार्ड की recommendations के अनुसार पर्याप्त बड़ा हो
    • छोटे context में यह सामान्य thinking पर fallback कर जाता है
  • OpenAI reasoning_effort=xhigh को सामान्य thinking पर map किया जाता है; यह Think Max नहीं है
  • यदि direct response चाहिए तो thinking: {"type":"disabled"}, think:false, या deepseek-chat जैसे non-thinking model alias का उपयोग करें

disk KV cache

  • Chat/completion API stateless है, इसलिए agent clients हर request पर पूरी बातचीत दोबारा भेजते हैं
  • ds4-server rendered token stream की तुलना cached token prefix से करके processing करता है
    • Live in-memory checkpoint current session को संभालता है
    • Disk KV cache वह mechanism है जो session switching और server restart के बाद भी उपयोगी prefixes को बनाए रखता है
  • अभी memory में केवल एक live KV cache रहता है; यदि कोई नया unrelated session इसे replace कर दे, तो पुराना checkpoint तभी बिना reprocessing resume हो सकता है जब वह disk KV cache में लिखा गया हो
  • --kv-disk-dir और --kv-disk-space-mb से इसे enable किया जाता है

  • cache key और file structure

    • Cache key सटीक token IDs का SHA1 hash होता है, raw text नहीं
    • हर token ID को little-endian 32-bit integer के रूप में hash किया जाता है, और filename <sha1>.kv होता है
    • Writing सामान्य read/write I/O से होती है; mmap का उपयोग नहीं किया जाता (ताकि पहले से model map कर रही process में अतिरिक्त VM mappings न जुड़ें)

  • disk cache file layout

    • KVC fixed header 48 bytes: magic("KVC"), version, routed expert quant bits, save reason, cached token count, hit count, context size, creation/last-use Unix time, DS4 session payload byte count
    • Rendered text: cached token prefix का tokenizer-decoded text (observation के लिए, key के रूप में नहीं)
    • DS4 session payload: 13 little-endian u32 fields से शुरू होता है, जिनमें magic("DSV4"), payload version, context size, prefill chunk size, KV ring capacity आदि शामिल हैं
      • Checkpoint token IDs, अगले token के लिए float32 logits, हर layer की compressed attention row count, live raw sliding-window KV rows, compressed layers की KV rows और compressor frontier tensors आदि store किए जाते हैं

  • checkpoint कब save होते हैं

    • cold: लंबा initial prompt stable prefix तक पहुँचने के बाद, generation से पहले
    • continued: जब prefill या generation configured interval तक आगे बढ़ जाए
    • evict: किसी unrelated request द्वारा live in-memory session replace किए जाने से पहले
    • shutdown: server के clean exit पर
  • Cold saves में छोटे token suffix को trim करके prefill chunk boundary पर align किया जाता है, ताकि future requests में BPE-boundary retokenization mismatches से बचा जा सके
    • Default: minimum 512-token prefix, cold save maximum 30000 tokens, tail 32-token trimming, 2048-token chunk alignment
  • Default रूप से 2-bit और 4-bit routed-expert variants के बीच यदि token prefix समान हो तो checkpoints reuse किए जा सकते हैं
    • --kv-cache-reject-different-quant से केवल same-quantization reuse enforce किया जा सकता है

backend

  • Default backend Metal है (--metal)
  • CPU reference/debug path भी मौजूद है (--cpu), लेकिन यह production target नहीं है
    • Server Metal-only है, और optimized implementation Metal graph path में मौजूद है
  • MIT license, C/Objective-C/Metal implementation

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

1 टिप्पणियां

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

  • इसे मौजूदा codebase में Claude Code के साथ इस्तेमाल करके देखा, और 2-bit quantized model होने के बावजूद यह अपना काम करता हुआ लगा
    prompt processing में कुछ मिनट लगते हैं, लेकिन असली editing 20 tokens/sec से ज़्यादा की speed पर काफ़ी तेज़ है
    छोटे कामों में इसने code exploration, बदलाव लागू करना, और test लिखना तक सफलतापूर्वक किया, लेकिन एक मामूली issue ठीक नहीं कर पाया
    इससे भी बुरा यह था कि किसी दूसरे issue पर काम करते समय इसने साथ-साथ हुई “The Duck” वाली बातचीत को hallucinate करके खींच लिया। शायद यह Claude Code के शुरुआती prompt examples में से एक है

  • मैंने पहले Qwen3 model के लिए बहुत मिलती-जुलती चीज़ बनाई थी। वह सिर्फ Qwen3 चलाती है, कुछ ही quantization support करती है, GGUF से load करती है, और Claude द्वारा बार-बार optimize किया गया inference इस्तेमाल करती है
    पूरा project कुछ files जितना छोटा और समझने में आसान था, इसलिए इसे इस तरह बनाया था कि छात्र decoding strategies जोड़कर या abliteration जैसी चीज़ों के साथ experiment करते हुए सीख सकें। मशहूर frameworks बड़े और जटिल होते हैं, इसलिए hack करना मुश्किल होता है, और educational projects अक्सर GPT-2 जैसी पुरानी चीज़ों पर अटके रहते हैं
    यह educational project के रूप में शुरू हुआ था, लेकिन तब से एक idea दिमाग़ में बना हुआ है। अगर किसी खास GPU+model combination के लिए ultra-optimized inference engine बनाया जाए तो? GPU महंगे हैं और उन्हें पाना भी दिन-ब-दिन मुश्किल हो रहा है, इसलिए अगर abstraction को काफ़ी हद तक हटाकर सीधे exact hardware/model के लिए tune किया जाए तो शायद काफ़ी optimization मिल सके
    लेकिन दिक्कत यह है कि model पुराना पड़ते ही सब कुछ फिर से शुरुआत से करना पड़ेगा

    • पहले से इस्तेमाल में मौजूद inference engines में अलग-अलग hardware के लिए optimized backend components शामिल हैं
      कम लोकप्रिय platforms पर अभी भी कुछ performance gains आसानी से मिल सकते हैं, लेकिन किसी खास GPU family के लिए ultra-optimized model runner बनाकर बहुत ज़्यादा बेहतर performance निकालने की जगह ज़्यादा नहीं है। मुख्य computation पहले ही हर GPU के लिए highly optimized kernels द्वारा संभाला जा रहा है
      CPU architectures पर बेहतर चलने के लिए optimize किए गए llama.cpp forks भी हैं, लेकिन maintainers के बीच कोई असहमति न हो तो ऐसे improvements को upstream merge कराना, किसी खास model+GPU runner को अलग से बनाने की तुलना में समय का बेहतर उपयोग है
    • इससे मशहूर FizzBuzz high-performance code golf जवाब याद आता है। अगर वैसी optimization inference पर लागू की जा सके, तो शायद speed 10x से भी ज़्यादा बढ़ाई जा सकती है
      https://codegolf.stackexchange.com/questions/215216/high-thr...
    • इसके आगे, अगर chip को ही model के हिसाब से design किया जाए तो? अगर digital से analog की तरफ़ जाएँ और vectors को bits की जगह voltages के रूप में व्यक्त करें तो क्या होगा?
      क्या भारी computation वाले matrix multiplication को operational amplifiers से संभाला जा सकता है? और क्या यह analog approach bit representation की सीमाओं से कहीं ज़्यादा efficient हो सकती है?
    • लगता है Mojo का लक्ष्य भी ऐसा ही ultra-optimized hardware-specific engine है, लेकिन यहाँ इसका लगभग ज़िक्र ही नहीं होता
    • मैंने भी ऐसा कुछ बनाने की कोशिश की थी। एक समस्या यह है कि LLM अच्छे shader लिखने में सचमुच बहुत ख़राब होते हैं। उन्हें कम बुरा output देने लायक बनाने में बहुत समय लगा

  • अब जब आधुनिक AI kernel optimization तक कर सकता है, तो मुझे लगता है कि ज़्यादा लोगों को अपने hardware के लिए बेहतर inference खुद बनाकर देखना चाहिए
    मेरे पास पुराना W7900(RDNA3) है, और 48GB VRAM के अलावा 123 FP16 TFLOPS/INT8 TOPS, 864GB/s memory bandwidth जैसे metrics भी काफ़ी अच्छे हैं। लेकिन AMD का ROCm support भी, और llama.cpp support भी, बदनाम रूप से ख़राब रहे हैं
    हाल में मैंने इस card को एक dedicated agent/coding endpoint की तरह इस्तेमाल करने के लिए W8A8-INT8 models tune करना शुरू किया। कई दिनों तक लगभग 800 automated iterations चलाए, कई frontier/SOTA models आज़माए, और हैरानी की बात यह रही कि Kimi K2.6 ने काफ़ी अच्छा किया। नतीजतन, Qwen3.6 MoE के आधार पर सबसे अच्छे llama.cpp numbers की तुलना में prefill 20% और decode 50% तेज़ हो गया
    अभी मैं MTP और DFlash optimization को और गहराई से देख रहा हूँ, और नतीजे काफ़ी संतोषजनक हैं; अगला target शायद Gemma 4 होगा

    • 7900xtx के साथ मेरी भी लगभग यही स्थिति है। 24GB VRAM है और कागज़ पर performance ठीक दिखती है, लेकिन असल में ज़्यादातर चीज़ें ठीक से नहीं चलतीं
      फिर भी llama.cpp, भले ही absolute best performance न दे, ज़्यादातर models को लगातार चला देता है। लगता है MTP की कमी है और hybrid models में cache invalidation की समस्या भी है, लेकिन कम से कम यह तो पता रहता है कि क्या चलेगा
      Python-आधारित inference tools में uv/venv, मेरा venv, system environment, Python और libraries सब इतने उलझ जाते हैं कि असल में क्या चल रहा है यह समझने के लिए भी agent चाहिए। मुझे पता है यह skill issue या user error है, लेकिन उस पर देने के लिए समय नहीं बचता
      अगर GitHub या Hugging Face पर डाल दिया जाए, चाहे वह perfect न भी हो, तो दूसरे agents शून्य से शुरू करने के बजाय वहीं से आगे बढ़ सकते हैं। मैंने Ling-2.6-flash(107B-A7B4 MoE) के साथ ऐसा किया था, और local LLM के लिए मेरे दूसरे hardware M2 Max पर व्यावहारिक रूप से चल सकने वाला यह सबसे बड़ा LLM है
      भले ही MTP ठीक से काम न करे, फिर भी यह वर्तमान llama.cpp के Ling-2.6-flash को बिल्कुल न चला पाने से बेहतर है। संबंधित चर्चा https://huggingface.co/inclusionAI/Ling-2.6-flash/discussion... पर है, 4-bit quantization https://huggingface.co/ljupco/Ling-2.6-flash-GGUF पर है, और branch https://github.com/ljubomirj/llama.cpp/tree/LJ-Ling-2.6-flas... पर है
    • अच्छा होगा अगर आप अपना ज्ञान और नतीजे साझा करें
      मुझे लगता है llama.cpp PC support बहुत बेहतर कर सकता था। कुछ हद तक वजह vendor support की ख़राबी होगी, लेकिन इतने users होने के बावजूद standard PC पर ज़्यादा optimized inference का न दिखना हैरान करता है

  • यह सचमुच शानदार है। मैं देखना चाहूँगा कि अगर किसी एक open source model पर कई महीनों तक केंद्रित होकर optimization किया जाए, तो नतीजा क्या निकलता है
    सिर्फ inference serving नहीं, बल्कि harness optimization और custom workflows समेत, frontier models inference और derivation कर सकते हैं, लेकिन open source models size या training limitations की वजह से मूल रूप से पीछे रह जाते हैं—यह gap कितना कम किया जा सकता है, यह देखना दिलचस्प होगा

    • frontier models और open source models के बीच हमेशा बड़ा gap रहेगा। अगर आप बहुत अमीर नहीं हैं तो और भी ज़्यादा, और पूरा यह उद्योग unit economics को नज़रअंदाज़ कर रहा है, जो बेतुका है
      Kimi 2.6 को ठीक-ठाक tokens/sec speed पर चलाने में महीने के $20,000 लगते हैं, और अगर उन tokens को मुनाफ़े के साथ बेचना है तो hardware cost महीने के $1,000 से कम होनी चाहिए
      अगर आप इस उम्मीद पर अपनी क्षमता दाँव पर लगा रहे हैं कि अरबपति लोग लागत के 1/10 से 1/20 पर tokens बेचते रहेंगे, या यह कल्पना कर रहे हैं कि सक्षम open source models consumer hardware में आ जाएँगे, तो फिर खेल पहले ही खत्म है

  • इसमें एक मज़ेदार, दिलचस्प और बहुत कुछ बताने वाला data point है। मेरा MacBook M3 Max, जब DS4 अधिकतम speed पर tokens generate करता है, तब power usage 50W तक चला जाता है

    • इंटरनेट अभी शायद इस data point को स्वीकार करने के लिए तैयार नहीं है कि “LLM datacenters, economies of scale की वजह से, self-hosted LLMs की तुलना में प्रति user तकनीकी रूप से अधिक energy efficient हैं”
    • यह सोचना दिलचस्प है कि ऐसी मशीनों को “सोचने” में कितनी बिजली लगती है। धुँधले तौर पर लगता था कि “बहुत” लगती होगी, लेकिन numbers में देखना अच्छा है
      अगर DS4 Flash 50W पर peak करता है और उसमें 280B parameters हैं, तो 1.6T parameters वाला DS4 Pro लगभग 300W होगा? नवीनतम GPT 5 और Opus भी कुछ 500W जैसे महसूस होते हैं
      जब मैं Claude Code इस्तेमाल करता हूँ और model अपने-आप लंबा चलता रहता है, तो क्या यह मानना ठीक है कि कहीं कोई datacenter 500W जला रहा है?
    • शायद सब लोग इसे notice न करें, लेकिन यह वाकई शानदार और प्रभावशाली नतीजा है। मेरे M4 Max पर ज़्यादातर models 150W consume करते हैं
    • मुझे जानना है कि यह आँकड़ा सच में सही है या नहीं। और जो लोग hardware से परिचित नहीं हैं, वे ऐसी चीज़ें मापें कैसे—यह भी जानना है
    • यह लगभग 2-3 मानव मस्तिष्कों की power usage के बराबर है। कमाल का काम है

  • Mac Studio में 96GB RAM से बड़ा option order ही नहीं किया जा सकता। M3 Ultra या M4 Max, दोनों में यही हाल है। पता नहीं यह सिर्फ ऑस्ट्रेलिया तक सीमित है या नहीं
    दूसरी तरफ़ MacBook Pro में M5 Mac के साथ 128GB चुना जा सकता है
    https://www.apple.com/au/shop/buy-mac/mac-studio

    • यह मानना मुश्किल है कि यह memory unobtanium से बनी है
      हो सकता है Apple ने ज़्यादा कीमत वसूलने के विवाद या stock shortage पर backlash झेलने के बजाय उसे बेचने के लिए price ही न लगाने का रास्ता चुना हो
    • यह सिर्फ ऑस्ट्रेलिया की बात नहीं है: https://9to5mac.com/2026/05/05/apples-most-powerful-mac-stud...
      96GB से ऊपर की सभी Mac Studio configurations और base Mac mini हटा दिए गए हैं। ऐसी अफ़वाह भी है कि Neo base configuration को भी market से हटाने पर विचार हो रहा है
      शायद fab capacity और RAM supply constraints को ऐसे संभाला जा रहा है
    • Studio अब काफ़ी पुराना product है। जब कभी नया model आएगा, तो उसमें ज़्यादा memory options होने की संभावना है। फिर भी 128GB M5 Max MBP शानदार है

  • पता नहीं क्या कोई आसान motivational benchmark या लक्ष्य छूट गया है
    अंदाज़ा तो लगाया जा सकता है कि यह सामान्य toolchain से तेज़ है, या इससे बड़े और ज़्यादा स्मार्ट models चलाए जा सकते हैं, लेकिन baseline की तुलना में पहले से हुए या अपेक्षित improvement का दायरा साफ़-साफ़ लिखा नहीं दिखता
    अगर संबंधित comparison values पता हों तो दिए गए numbers से उसे निकाला जा सकता है, लेकिन फिर भी

  • बहुत प्रभावशाली। लेकिन बड़े inputs पर response शुरू होने में लगभग 4 मिनट लगना अजीब लगता है
    मैं Mac hardware पर LLM इस्तेमाल नहीं करता, इसलिए यह काफ़ी चौंकाने वाला है, और असली उपयोग में बड़ी रुकावट जैसा लगता है
    हालांकि सामान्य उपयोग में caching वाली व्याख्या देखकर बात कहीं ज़्यादा समझ में आती है। Claude Code अक्सर किसी उपयोगी काम की शुरुआत से पहले लगभग 25k tokens का बड़ा initial prompt भेज सकता है, और अगर --kv-disk-dir चालू हो, तो पहले महंगे prefill के बाद disk KV cache saved prefix को दोबारा इस्तेमाल कर सकता है, जिससे पूरे prompt को फिर से process नहीं करना पड़ता

    • coding agents जब बहुत बड़े system prompts भेजते हैं, तब ऐसा होता है। बाद में tool calls बड़े files या diff डालें, तब भी यही होता है
      लेकिन M3 Ultra पर prefill speed लगभग 500 tokens/sec है, इसलिए यह काफ़ी practical है। M3 Max पर थोड़ा ज़्यादा धैर्य चाहिए, लेकिन यह ठीक काम करता है, और अगर आप pi agent इस्तेमाल करें तो वह thought process output करता है, इसलिए इंतज़ार करने के बजाय आप uncensored chain of thought पढ़ते रहते हैं
      मैंने कल X पर M3 Max के साथ इसका video डाला था, और यह काफ़ी ठीक speed पर tokens उगलता है
    • M5 पर prefill तेज़ है, और पिछली generations थोड़ी कमज़ोर हैं

  • MacBook पर बड़े LLMs में token generation speed तो स्वीकार्य होती है, लेकिन असली समस्या context reading है
    chat session की तरह KV cache के साथ incremental reading नहीं, बल्कि बड़े input पढ़ने की बात है, जैसे कोई बड़ी file paste करना। उसमें कई मिनट लग सकते हैं

    • DS4 prompt tokens को 460 प्रति सेकंड की दर से process कर सकता है। यह असाधारण नहीं है, लेकिन इतना धीमा भी नहीं। यह M3 Max पर है; README के benchmarks देखे जा सकते हैं
    • क्या कोई आसान तरीके से समझा सकता है कि local inference इतना धीमा क्यों है, जबकि hosted models इतने तेज़ लगते हैं?
    • अगर मैं गलत नहीं समझ रहा, तो यह repository 2-bit quantization पर चलाने की बात कर रही है
      संभव है कि यह cloud providers द्वारा दी जाने वाली मूल intelligence से काफ़ी दूर हो
      फिर भी, यह agent-style workflows में local LLM की संभावनाएँ बेहतर ढंग से दिखाता है
    • ऐसा क्यों होता है?
      क्या ऐसी architectures हैं जो पूरी बातचीत का इतिहास फिर से feed करने पर निर्भर न हों? जैसे recurrent LLM वगैरह?