RTX 5090 और M4 MacBook Air: क्या इस पर गेमिंग संभव है?

 (scottjg.com)
1 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • M4 MacBook Air पर RTX 5090 eGPU जोड़कर Linux VM में गेम चलाए गए, और macOS में ड्राइवर न होने तथा Thunderbolt की सीमाओं को बायपास करना पड़ा
  • इम्प्लीमेंटेशन के लिए apple-dma-pci virtual PCI device, DART mapping bypass, kprobes-आधारित NVIDIA driver patch, और QEMU/HVF modifications की ज़रूरत पड़ी
  • Cyberpunk 2077, M4 Air + eGPU पर 4K RT Ultra 27fps पर चला, और DLSS frame generation इस्तेमाल करने पर 111fps तक पहुँच गया, जिससे खेलना संभव हो गया
  • वही RTX 5090 अगर सामान्य PCIe PC में लगाया जाए तो गेम के अनुसार 2~4 गुना तेज़ है, और FEX·Proton·VM·Thunderbolt overhead अभी भी काफ़ी बना हुआ है
  • बड़ी उपलब्धि AI inference में रही, जहाँ M4 Air पर Qwen prefill लगभग 100 गुना घट गया और single-stream generation लगभग 22 tok/s से 155 tok/s तक बढ़ गया

Thunderbolt eGPU और Apple Silicon Mac की सीमाएँ

  • Thunderbolt eGPU संरचना

    • RTX 5090 जैसे desktop GPU को Thunderbolt dock में लगाया जाता है, और dock PCIe को Thunderbolt में बदलकर M4 MacBook Air के USB-C port से जोड़ता है
    • Thunderbolt, USB-C cable के ऊपर PCIe tunneling करता है, इसलिए कंप्यूटर की नज़र में Thunderbolt device, USB device नहीं बल्कि PCIe device दिखता है
    • Thunderbolt 4 अधिकतम 40Gbps के 4 PCIe lane देता है, और tunneling की वजह से थोड़ा performance loss होता है
    • आम तौर पर Linux और Windows में eGPU, थोड़ा धीमे PCIe device की तरह दिखता है और मौजूदा drivers के साथ लगभग तुरंत काम करने लगता है
    • पहली बड़ी रुकावट यह थी कि Apple Silicon macOS NVIDIA या AMD GPU drivers डिफ़ॉल्ट रूप से उपलब्ध नहीं कराता

  • Linux VM के ज़रिए बायपास

    • Apple Silicon Mac पर Linux चलाना संभव है, लेकिन फिलहाल Linux kernel, Apple Silicon पर Thunderbolt को सपोर्ट नहीं करता और केवल internal devices तथा USB3 को सपोर्ट करता है
    • macOS host के ऊपर 64-bit ARM Linux VM चलाने पर ऐसा setup संभव हुआ जहाँ macOS Thunderbolt device संभाले और Linux NVIDIA GPU संभाले
    • ARM64 Windows के लिए NVIDIA card driver उपलब्ध न होने से Linux का उपयोग किया गया
    • tinygrad का macOS eGPU driver केवल tinygrad stack के भीतर ही इस्तेमाल हो सकता है, इसलिए AI inference या गेम चलाने के लिए यह general-purpose driver नहीं था

macOS में PCI passthrough इम्प्लीमेंट करना

  • PCI BAR और DMA

    • VM को PCI device से बात करने के लिए PCI BAR(Base Address Registers) और DMA का काम करना ज़रूरी है
    • PCI BAR वह memory area है जिसे PCI device कंप्यूटर के साथ पढ़ने-लिखने के लिए इस्तेमाल करता है, और PCI passthrough के लिए इस area को VM के भीतर mirror करना पड़ता है
    • DMA(Direct Memory Access) वह तरीका है जिसमें device CPU copy के बिना सीधे computer memory को पढ़ता-लिखता है

  • Hypervisor.framework और BAR mapping

    • QEMU, VM शुरू करते समय Hypervisor.framework के hv_vm_map() को call करके guest memory layout सेट करता है
    • host PCIDriverKit driver से कनेक्ट होकर IOConnectMapMemory64() के ज़रिए PCI device memory को process में map करने पर BAR0 memory पढ़ी जा सकती है
    • BAR0[0] पढ़ने पर RTX 5090 को इंगित करने वाला device-specific constant 0x1b2000a1 मिलता है
    • अगर QEMU device memory को सीधे guest में map कर दे तो guest सीधे GPU से बात कर सकता है, लेकिन शुरुआत में VM जैसे ही PCI BAR memory को छूता था, host kernel crash हो जाता था
    • कारण यह था कि QEMU, RAM-device/MMIO mapping पर भी HV_MEMORY_EXEC जोड़ देता है, और device/MMIO mapping में EXEC हटाने वाले workaround से host panic से बचा गया
    • यह तरीका हर access को trap करने की तुलना में लगभग 30 गुना तेज़ है, लेकिन hv_vm_map() ARM device memory subtype निर्धारित नहीं कर सकता, इसलिए BAR writes सामान्य स्थिति की तुलना में लगभग 10 गुना धीमे हैं

DMA और DART सीमाओं को बायपास करना

  • Apple Silicon में DART की सीमा

    • Apple Silicon में IOMMU जैसा DART hardware unit होता है, जो device को मनमानी host memory तक पहुँचने से रोकने वाली security boundary की तरह भी काम करता है
    • PCIDriverKit के माध्यम से Thunderbolt device इस्तेमाल करते समय तीन बड़ी सीमाएँ सामने आईं
      • लगभग 1.5GB mapping limit की वजह से CUDA और modern games के लिए ज़रूरी 8–16GB स्तर की memory mapping को वैसे का वैसा नहीं रखा जा सकता
      • लगभग 64k mapping cap की वजह से अगर छोटे DMA buffer बहुत अधिक हों तो mapping table भर जाती है
      • address और alignment सीधे चुनने की सुविधा नहीं होने से वह virtual IOMMU तरीका फिट नहीं बैठता जिसमें guest DMA address तय करता है
    • restricted-dma-pool से DMA को pre-allocated region में मजबूर करने वाला तरीका simple devices पर काम कर गया, लेकिन GPU driver के लिए उपयुक्त नहीं था

  • apple-dma-pci virtual PCI device

    • QEMU में apple-dma-pci नाम का virtual PCI device जोड़ा गया और passed-through GPU के साथ VM में insert किया गया
    • guest kernel driver, NVIDIA driver की DMA mapping calls को intercept करता है, हर DMA request पर on-demand mapping बनाता है, और buffer मुक्त होने पर mapping भी हटा देता है
    • इस संरचना में पूरी guest RAM नहीं, बल्कि उस समय का live DMA buffer working set ही 1.5GB limit के भीतर होना चाहिए
    • guest driver, NVIDIA driver द्वारा GPU इस्तेमाल करने से पहले custom DMA ops से replace हो जाता है, और map_page, unmap_page, map_sg, unmap_sg, alloc, free को thin wrapper की तरह संभालता है
    • host side का QEMU request को PCIDriverKit driver तक भेजता है, और यह driver वास्तविक DART mapping करके DMA address को वापस guest memory में लिख देता है

  • NVIDIA alignment समस्या और kprobes patch

    • CUDA workload चलाते समय NV_ERR_INVALID_OFFSET और RM_PAGE_SIZE_HUGE alignment से जुड़ी kernel log दिखाई दी
    • समस्या वाली allocation UVM_RM_MEM_TYPE_SYS प्रकार की 16MB allocation थी, और NVIDIA driver का 2MB page size इस्तेमाल alignment constraints से टकरा रहा था
    • driver में NV_ERR_NO_MEMORY failure पर default page size के साथ retry करने वाला workaround था, लेकिन NV_ERR_INVALID_OFFSET को handle नहीं किया गया था
    • Linux kernel के kprobes का इस्तेमाल करके nvUvmInterfaceMemoryAllocSys() call में pageSize को UVM_PAGE_SIZE_DEFAULT पर force किया गया
    • NVIDIA driver को सीधे modify किए बिना ही छोटे page size की request करवाई गई, जिससे simple workload चलने लगे

  • Mapping coalescing से 64k cap से बचाव

    • गेम settings बढ़ाने पर बहुत सारे tiny mappings बनते थे और लगभग 64k mapping count limit पार हो जाती थी
    • mapping log में 90% से अधिक mappings 4kB की थीं, और वे contiguous नहीं थीं लेकिन cluster के रूप में दिखती थीं
    • guest memory को 256kB जैसे fixed-size regions में बाँटा गया, और जब 4kB buffer map होता था तो उसके पूरे cluster को map किया जाता था ताकि बाद की allocations उसी cluster में पुरानी mapping reuse कर सकें
    • इस तरीके में वास्तविक live buffer से थोड़ा अधिक memory map होती है, लेकिन test workload में यह लगभग 1.5GB mapping ceiling के नीचे रही
    • live mappings की संख्या लगभग 4 गुना कम हो गई, जिससे demanding games को highest settings पर चलाने की headroom मिली

VM performance में सुधार

  • vCPU scheduling

    • benchmark score बेतरतीब ढंग से बहुत उतार-चढ़ाव दिखा रहे थे और कभी-कभी 50% धीमे निकलते थे
    • ऐसा लगा कि QEMU vCPU thread पर priority सेट नहीं कर रहा था, इसलिए scheduler VM को पर्याप्त execution time नहीं दे रहा था
    • pthread_set_qos_class_self_np(QOS_CLASS_USER_INTERACTIVE, 0) और pthread_setschedparam(..., SCHED_RR, ...) को QEMU vCPU start path में patch करके ऊँची priority दी गई

  • Total Store Ordering और FEX-Emu

    • VM arm64 Linux है, लेकिन अधिकतर shipping games x86-64 Windows binaries हैं, इसलिए Proton) और FEX-Emu दोनों का उपयोग किया गया
    • x86 में store, program order के अनुसार दूसरे core को दिखाई देते हैं, जिसे Total Store Ordering(TSO) कहा जाता है, जबकि ARM का memory ordering model इससे कमज़ोर है
    • Apple Silicon में per-thread hardware TSO mode मौजूद है, और macOS 15+ के Hypervisor.framework में यह expose किया गया है
    • UTM का patch लेकर vCPU में ACTLR_EL1 bit 1 चालू किया गया, और FEX-Emu का software TSO emulation बंद किया गया
    • hardware bit के बिना software TSO emulation बंद करने पर Geekbench 6 बीच में crash हो जाता है
    • FEX और CPU TSO के साथ guest performance, native host performance से लगभग 50% कम रही

गेम performance

  • Cyberpunk 2077

    • Cyberpunk 2077 को M4 Air native macOS, M4 Air + eGPU, 2020 Intel MacBook Pro + eGPU, M5 Max native macOS, M5 Max + eGPU, और i5-12600K gaming PC + RTX 5090 पर test किया गया
    • + Framegen का अर्थ eGPU/native PCIe configuration में DLSS 4x और native macOS configuration में FSR 2x का उपयोग है
    • 720p Low पर GPU load कम था, इसलिए CPU और emulation/virtualization overhead हावी रहा, और M4 Air native 61fps, M4 Air + eGPU के 49fps से तेज़ था
    • 1080p High पर M5 Max native macOS, 131fps के साथ M5 Max + eGPU के 68fps से तेज़ था, यानी जहाँ integrated GPU पर्याप्त है वहाँ overhead का असर और बड़ा दिखता है
    • M4 Air native macOS, 1080p RT Ultra पर केवल 7fps दे पाया, लेकिन M4 Air + eGPU ने 30fps हासिल किए, और frame generation के साथ 119fps तक पहुँच गया
    • 4K पर bottleneck मुख्यतः GPU बन गया, और M4 Air + eGPU ने RT Ultra में 27fps तथा DLSS frame generation के साथ 111fps दिए, जिससे यह खेलने लायक स्तर तक पहुँच गया
    • native PCIe gaming PC, 4K RT Ultra में 100fps और DLSS frame generation के साथ 282fps पर सबसे तेज़ था
    • M5 Max + eGPU ने 4K RT Ultra में 47fps और frame generation के साथ 145fps दिए, जो M4 Air + eGPU से लगभग 30~70% तेज़ था

  • दूसरे गेम और benchmarks

    • GravityMark में वही GPU अगर PCIe slot की जगह Thunderbolt से जोड़ा जाए तो performance लगभग 20% घट गई, और M4 Air + eGPU native PCIe connection से लगभग 31% धीमा था
    • Shadow of the Tomb Raider में eGPU ने M4 Air को 4K native 8fps से 40fps तक पहुँचाया, और 1080p भी native 26fps से eGPU पर 42fps हो गया
    • Shadow of the Tomb Raider में eGPU performance 1080p और 4K पर लगभग समान थी, जिससे पता चला कि bottleneck GPU नहीं बल्कि FEX के नीचे CPU है
    • Horizon Zero Dawn Remastered सबसे कम 720p setting पर भी एक बार में 1.5GB से अधिक DMA memory mapping मांगता था, इसलिए benchmark शुरू ही नहीं हो सका
    • Doom (2016) eGPU configuration में चला, performance overlay के अनुसार 49fps मिला, और यह हमेशा 30fps से ऊपर रहा
    • Crysis Remastered gaming PC की तुलना में अधिकतम लगभग 4 गुना धीमा था, लेकिन M4 MacBook Air पर भी playable framerate के साथ चला

AI inference performance

  • Qwen 3.6

    • Qwen 35B MoE model को 4-bit quantization के साथ test किया गया, और active parameters 3B थे
    • NVIDIA GPU पर vLLM और NVFP4 version का उपयोग हुआ, जबकि Apple Silicon पर vllm-mlx और 4-bit MLX quantized model इस्तेमाल हुआ
    • benchmark llama-benchy से चलाया गया
    • Thunderbolt eGPU ने PCIe की तुलना में लगभग 9% performance खोई, लेकिन अधिकांश processing card पर होने से यह PCIe के काफ़ी करीब रहा
    • RTX 5090 single-stream generation में M4 Air से 6.5 गुना, M4 Max Mac Studio से 2.1 गुना, और M5 Max MacBook Pro से 1.2 गुना तेज़ था
    • 4K token prompt पर M4 MacBook Air को prefill में 17 सेकंड लगे, लेकिन उसी M4 Air में eGPU जोड़ने पर यह 150ms रह गया, यानी 120 गुना तेज़
    • concurrent requests को 1 से 4 करने पर RTX 5090 configuration का कुल throughput लगभग 3 गुना बढ़ा, जबकि Apple Silicon Mac की scaling इससे कम रही

  • Gemma 4

    • Gemma 4 31B sparse MoE नहीं बल्कि dense 31B model है, इसलिए हर token को पूरे parameters से होकर गुजरना पड़ता है
    • M4 Air का integrated GPU test के दौरान 2~3 tokens प्रति second से ऊपर नहीं जा सका, इसलिए इसे उपयोगी सीमा से बाहर माना गया
    • vLLM-आधारित RTX 5090 configurations सभी लगभग 50 t/s के आसपास, कुछ ही प्रतिशत के भीतर रहे, जबकि M4 Max Mac Studio ने लगभग 22 t/s और M5 Max MacBook Pro ने लगभग 27 t/s दर्ज किए
    • prefill में भी RTX 5090 हमेशा 400ms से कम रहा, लेकिन M4 Max को 4K token prompt parsing में अधिकतम 21 सेकंड और M5 Max को लगभग 7.5 सेकंड लगे
    • vLLM configurations ने 4 concurrent requests पर लगभग 3.5 गुना throughput दिया, जबकि Mac का MLX backend 4 requests पर लगभग और नहीं बढ़ा

सीधे चलाने की स्थिति और स्थिरता

  • डिप्लॉयमेंट और build शर्तें

    • मौजूदा स्थिति अभी “download करके तुरंत चलाने” लायक नहीं है, और Apple की special entitlement की ज़रूरत है
    • entitlement के लिए अनुरोध किया गया है, लेकिन अभी जवाब नहीं मिला, और प्रतीक्षा कई महीनों की हो सकती है
    • तब तक driver को manually build किया जा सकता है, और signing certificate account में संबंधित Mac शामिल होना चाहिए
    • SIP disable करने या reduced security mode उपयोग करने की आवश्यकता नहीं है
    • code qemu-vfio-apple से लिया जा सकता है
    • शामिल launcher, special apple_dma driver वाले pre-built Ubuntu image को अपने आप download करता है

  • स्थिरता

    • स्थिरता अभी अच्छी नहीं है
    • FEX में फिलहाल Steam के loop की तरह बार-बार crash होने वाला bug है, और इस configuration में यह समस्या और गंभीर दिखती है
    • कुछ games शुरू होने में कई मिनट लग सकते हैं
    • DMA mapping limit की वजह से समय के साथ mappings fragmented हो सकती हैं, और नए game के लिए जगह कम पड़ सकती है
    • ऐसे में Linux VM बंद करनी पड़ती है, GPU निकालकर फिर लगाना पड़ता है ताकि सभी DMA mappings साफ़ हो जाएँ, और फिर दोबारा कोशिश करनी होती है
    • सबसे स्थिर workload AI है, और इस उपयोग में यह बहुत अच्छा काम करता है
    • upstream QEMU के साथ patches को merge करने का काम जारी है, और आदर्श लक्ष्य यह है कि यह UTM जैसे mainstream QEMU distributions में शामिल होकर सीधे काम करे

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

1 टिप्पणियां

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

  • मैं कई सालों से VM टीम से VM GPU passthrough की मांग करता आ रहा हूँ। मैंने Apple Silicon Mac Pro पर काम किया था, और अगर केस के अंदर जाने वाले GPU को Linux VM में passthrough किया जा सकता, तो यह बहुत ज़्यादा समझदारी भरा होता
    अफसोस कि यह अनुरोध स्वीकार नहीं किया गया, लेकिन यह शानदार है कि किसी और ने इसे चलाकर दिखा दिया

    • जहाँ तक मैं समझता हूँ, यहाँ passthrough वाला हिस्सा एक मानक DriverKit interface से implement किया गया लगता है। यानी PCIe BAR को बिना macOS में अतिरिक्त बदलाव किए पहले से ही user space में map किया जा सकता है
      आखिरकार यह ऐसा मामला लगता है जहाँ QEMU जैसे virtual machine monitor को Linux VFIO जैसी चीज़ के साथ इस interface को अपना लेना होगा। अगर बात Virtualization.framework की हो रही है, तो वह खुद ही एक तरह के virtual machine monitor के काफ़ी करीब है, इसलिए मैं जानना चाहूँगा कि macOS में ठीक-ठीक क्या कमी मानी जा रही है
    • इससे जुड़ी दो आधी-रोचक बातें हैं। पहली, Virtualization.framework होस्ट GPU passthrough जैसी किसी चीज़ को support करता हुआ लगता है। यह eGPU नहीं है बल्कि built-in GPU के लिए है, और इसका मुख्य उपयोग शायद यह है कि macOS guest होस्ट के साथ GPU समय साझा करते हुए acceleration पा सके
      हाल ही में QEMU mainline में भी ऐसे patch आए हैं जो Hypervisor.framework के तहत Linux guest में इसी तरह की सुविधा के लिए virtio-gpu के साथ "venus server" का उपयोग करते हैं। दूसरी बात, Apple के अंदर शायद Virtualization.framework के लिए PCI passthrough support मौजूद है। framework code खुद ग्राहकों तक पहुँचाया जाता है, लेकिन लगता है कि यह ऐसे kext या kernel components पर निर्भर करता है जो सामान्य macOS में शामिल नहीं होते। पता नहीं इसे ग्राहकों के लिए सार्वजनिक करने का इरादा है या नहीं, लेकिन इतना साफ़ है कि Apple के अंदर किसी ने इस feature के बारे में सोचा ज़रूर है
    • आगे चलकर Mac Pro के फिर आने की संभावना कितनी है? क्या Apple कभी ऐसा कंप्यूटर बना पाएगा जो Siracusa को संतुष्ट करे, और क्या उसके पास अभी भी "Believe" शर्ट है, यह जानने की जिज्ञासा है
    • इस लेख में आधी समस्या QEMU और VM boundary से पैदा होने वाली memory access problem से निपटने की लगती है। हो सकता है मैं कुछ बहुत साधारण बात चूक रहा हूँ, लेकिन अगर Docker में Ubuntu चलाया जाए, तो क्या NVIDIA driver फिर भी load नहीं होगा? तब memory का मालिकाना OSX के पास ही रहेगा, इसलिए Apple के memory management से लड़ना नहीं पड़ेगा, ऐसा लगता है
    • मेरा अभी भी मानना है कि Mac Pro में NVIDIA GPU support की कमी tech industry के सबसे बड़े missed opportunities में से एक रहेगी
      वैसे भी अब Mac Pro एक dead product है। सिर्फ audio-video professionals को बेचकर इसकी सीमा है

  • शानदार लेख है। गेम benchmark मज़ेदार हैं, लेकिन व्यावहारिक तौर पर LLM performance improvement वाला हिस्सा सच में सबसे दिलचस्प है
    Apple platform में RAM ज़्यादा होने की वजह से local models चलाना आसान और सुलभ है, लेकिन तुलनात्मक रूप से धीमी prompt processing speed को अक्सर नज़रअंदाज़ कर दिया जाता है। लेख के उद्धरण के अनुसार 4K token prompt पर M4 MacBook Air को response generate शुरू करने से पहले parsing में 17 सेकंड लगते हैं, जबकि eGPU जोड़ने पर वही काम 150ms में हो जाता है, यानी 120 गुना तेज़। छोटे chat में LLM इस्तेमाल करते समय prefill समस्या ज़्यादा दिखती नहीं, लेकिन जैसे ही बड़े काम शुरू होते हैं, compute limit bottleneck बन जाती है। time to first token (TTFT) का chart पहली नज़र में इतना बुरा नहीं लगता, लेकिन जब पता चलता है कि Mac platform कुल GPU compute की तुलना में इतना धीमा था कि उसे log scale पर दिखाना पड़ा, तब उसका मतलब बदल जाता है

    • मैं expert नहीं हूँ, लेकिन यह जानने की जिज्ञासा है कि Mac पर TTFT इतना ज़्यादा खराब क्यों है। लेख कहता है कि यह चरण compute-bound है, पर क्या बात सच में इतनी ही सीधी है, या MLX की तरफ optimization भी कम है?
    • यह मामूली लग सकता है, लेकिन असल में यह 113 गुना तेज़ है
      अगर लेखक नतीजों को इस तरह पेश करता है, तो यह biased लग सकता है, हालांकि मुझे नहीं लगता कि वास्तव में ऐसा है
    • बस oMLX इस्तेमाल कीजिए। Qwen3.6 पर prompt processing 300 tokens/sec और token generation 30 tokens/sec मिलते हैं

  • यह बात सही लगती है कि macOS पर OpenGL अब ठीक से support नहीं होता, इसलिए गेम CrossOver के ज़रिए भी पूरी तरह playable नहीं है
    लेकिन Doom शायद Vulkan support करता है, और संभव है कि MoltenVK में VK_NV_glsl_shader जोड़ देना काफ़ी हो। M4 में RTX 5090 टाँगने की तुलना में यह बहुत कम मेहनत होगी, फिर भी Scott के लिए तालियाँ। local AI inference speed भी काफ़ी शानदार है, और यह सच में एक पागलपन भरा project है

  • काफ़ी प्रभावशाली है। मेरी समझ यह थी कि Apple Silicon पर eGPU बस काम ही नहीं करता
    Apple भी यही कहता है। “eGPU का उपयोग करने के लिए Intel processor वाला Mac चाहिए।” और ऊपर से officially supported eGPU भी सभी NVIDIA नहीं बल्कि AMD थे। https://support.apple.com/en-us/102363

    • यह macOS पर eGPU इस्तेमाल करने की बात नहीं है। उदाहरण के लिए, macOS का Chrome इस eGPU की acceleration लेकर चल नहीं सकता
      यहाँ संरचना यह है कि उस eGPU को Linux VM में tunnel किया जा रहा है

  • पहले मुझे लगा था कि यह धीमे tinygrad driver के साथ VM चलाने पर लेख होगा, लेकिन असल में यह उससे कहीं बेहतर approach निकली
    काश Apple इसे बेहतर support देता और 1.5GB window limit को ढीला करता, तो चीज़ें बहुत आसान हो जातीं। Arm में सामान्य तौर पर PCIe devices से जुड़ी कुछ विचित्रताएँ हैं, लेकिन कम से कम Linux में ज़्यादातर modern drivers अब arm64 को first-class citizen की तरह लेते हैं, इसलिए चीज़ें बहुत आसान हो गई हैं

    • पक्का नहीं कह सकता, लेकिन tinygrad की धीमी रफ़्तार का कारण शायद macOS host driver खुद नहीं है। यह मेरे काम से काफ़ी मिलता-जुलता लगता है, जहाँ PCI BAR को user space में map करके Python code से GPU चलाया जाता है
      मेरा अनुमान है कि tinygrad के धीमे होने का बड़ा कारण यह है कि tinygrad inference engine अभी ऐसे public LLM models के लिए ज़्यादा optimize नहीं है। शायद ज़्यादातर काम George की autonomous driving hardware company के लिए stack optimization में गया होगा। मौजूदा CUDA kernels को उस engine में सीधे चलाया नहीं जा सकता, इसलिए engineering difficulty बहुत बढ़ जाती है। मैं यह भी सोच रहा हूँ कि क्या मेरा project और उनका project macOS host driver साझा कर सकते हैं। कुछ बदलाव तो लगेंगे, लेकिन overlap काफ़ी दिखता है

  • “आजकल ज़्यादातर projects का पहला step, चाहे मानना न चाहें, AI से पूछना है” — इसका ज़्यादा संभावित मतलब यह है कि AI आपको वह भी बता देगा जो उसे खुद नहीं पता
    इससे मुझे कल की वह बहस याद आ गई जब मैं ChatGPT से 5070TI के सचमुच मौजूद graphics card होने पर बहस कर रहा था। ChatGPT बार-बार मुझे सुधारने की कोशिश कर रहा था कि ऐसा कोई 5070TI card है ही नहीं, तुम शायद 4070ti कहना चाहते हो

    • गलती मान लेने के बाद भी यह उसी गलती को दोहराता रहता है
      मैंने Claude से PowerShell 7 के बारे में एक HTML page बनाने को कहा, तो उसने लिखा कि 7.4 latest LTS release है। मैंने उसे वह link दिया जिसमें 7.6 के मार्च में release होने की जानकारी थी और कहा कि नई जानकारी के साथ फिर बनाओ, लेकिन उसने लगभग वही page बनाया और वही दावा दोहराया कि 7.4 latest release है
    • LLM आम तौर पर cutting-edge topics की plausibility पर बहुत मज़बूत फैसला सुनाने की अच्छी स्थिति में नहीं होते
      फिर भी मूल लेख पर ChatGPT का जवाब ठीक ही था। “बहुत deep”, “लगभग practical use के लायक नहीं”, और “research perspective से” — यह summary इस लेख को लगभग पूरी तरह बयान कर देती है
    • किसी महाशक्ति की पूरी economy और लगभग पूरी online culture को Furby के पीछे दीवाना होते देखना अब तक देखी गई सबसे अजीब चीज़ों में से एक था
    • इसलिए मैं Grok expert mode इस्तेमाल करता हूँ। यह web पर बहुत आक्रामक तरीके से जानकारी खोजता है, इसलिए 1 साल पुराने data पर निर्भर रहने से कहीं बेहतर है
    • मैंने GPT-OSS 120B से यह बहस की थी कि Cascade Lake Xeon workstation CPU parts में GPU नहीं होता। model पूरे आत्मविश्वास से इसका उल्टा कह रहा था

  • यह सच में कमाल है। मेरे पास एक spare 5090 है और मैं M4 Mini पर claw-like चला रहा हूँ; अगर इसे stability के लिए किसी 3D-printed frame जैसी चीज़ में लगाकर TB port से जोड़ दिया जाए, तो यह local inference के लिए काफ़ी उपयोगी tool बन सकता है
    हालाँकि power supply जैसी चीज़ को साफ़-सुथरे तरीके से सुनिश्चित करने वाला कोई setup चाहिए होगा। समस्या यह है कि max-num-seqs और max-model-len आपस में टकराते हैं, और अगर यह शुद्ध single-client mode नहीं है, तो कहें कि कई slots चाहिए होंगे

  • अगर Apple की approval process पार की जा सके, तो यह AI inference के लिए काफ़ी उपयोगी दिखता है। मैं Mac Mini पर NVIDIA GPU इस्तेमाल करना चाहता था, और इस तरीके से सीधे CUDA चलाना संभव हो जाता है। सच में शानदार