RTX 5090 ve M4 MacBook Air: Oyun oynamak mümkün mü?

 (scottjg.com)
1 puan yazan GN⁺ 1 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • M4 MacBook Air’a RTX 5090 eGPU bağlanıp Linux VM içinde oyun çalıştırıldı; macOS sürücü eksikliği ve Thunderbolt kısıtları aşılmak zorunda kaldı
  • Uygulama için apple-dma-pci sanal PCI aygıtı, DART eşleme kısıtlarının aşılması, kprobes tabanlı NVIDIA sürücü yaması ve QEMU/HVF değişiklikleri gerekti
  • Cyberpunk 2077, M4 Air + eGPU üzerinde 4K RT Ultra 27fps verdi; DLSS kare üretimiyle 111fps’ye çıkarak oynanabilir hale geldi
  • Aynı RTX 5090 normal bir PCIe PC’ye takıldığında oyuna göre 2–4 kat daha hızlı çalışıyor; FEX·Proton·VM·Thunderbolt ek yükü hâlâ büyük
  • Daha büyük kazanım yapay zeka çıkarımı tarafında görüldü; M4 Air’daki Qwen prefill süresi yaklaşık 100 kat düştü ve tek akış üretim hızı yaklaşık 22 tok/s’den 155 tok/s’ye çıktı

Thunderbolt eGPU ve Apple Silicon Mac kısıtları

  • Thunderbolt eGPU yapısı

    • RTX 5090 gibi masaüstü GPU’lar bir Thunderbolt dock’una takılıyor; dock PCIe’yi Thunderbolt’a çevirip M4 MacBook Air’ın USB-C portuna bağlıyor
    • Thunderbolt, USB-C kablosu üzerinden PCIe tünelleme yaptığı için bilgisayar açısından Thunderbolt aygıtı bir USB aygıtı değil, bir PCIe aygıtı gibi görünüyor
    • Thunderbolt 4, en fazla 40Gbps’lik 4 PCIe lane sunuyor ve tünelleme nedeniyle küçük bir performans kaybı oluyor
    • Genel olarak Linux ve Windows’ta eGPU, biraz daha yavaş bir PCIe aygıtı gibi algılanıyor ve mevcut sürücülerle neredeyse doğrudan çalışıyor
    • İlk engel, Apple Silicon macOS’un yerleşik olarak NVIDIA ya da AMD GPU sürücüleri sunmaması

  • Linux VM ile çözüm

    • Apple Silicon Mac üzerinde Linux çalıştırmak mümkün, ancak mevcut Linux kernel Apple Silicon’da Thunderbolt’u desteklemiyor; yalnızca dahili aygıtlar ve USB3 destekleniyor
    • macOS host üzerinde 64 bit ARM Linux VM çalıştırıldığında, macOS Thunderbolt aygıtını işlerken Linux da NVIDIA GPU’yu işleyebiliyor
    • ARM64 Windows için NVIDIA kart sürücüsü olmadığı için Linux kullanıldı
    • tinygrad’in macOS eGPU sürücüsü yalnızca tinygrad yığını içinde kullanılabildiğinden, yapay zeka çıkarımı ya da oyun çalıştırma için genel amaçlı bir sürücüye uygun değildi

macOS üzerinde PCI passthrough uygulaması

  • PCI BAR ve DMA

    • Bir VM’in PCI device ile iletişim kurabilmesi için PCI BAR(Base Address Registers) ve DMA’in çalışması gerekiyor
    • PCI BAR, PCI device’ın bilgisayarla okuma ve yazma yaptığı bellek alanı; PCI passthrough çalışacaksa bu alanın VM içinde mirror edilmesi gerekiyor
    • DMA(Direct Memory Access), aygıtın CPU kopyalaması olmadan bilgisayar belleğini doğrudan okuyup yazabilmesi anlamına geliyor

  • Hypervisor.framework ve BAR eşleme

    • QEMU, VM’i başlatırken guest bellek düzenini ayarlamak için Hypervisor.framework içindeki hv_vm_map() çağrısını yapıyor
    • Host tarafında PCIDriverKit sürücüsüne bağlanıp IOConnectMapMemory64() ile PCI device belleği sürece eşlendiğinde BAR0 belleği okunabiliyor
    • BAR0[0] okunduğunda, RTX 5090’a işaret eden aygıta özgü sabit 0x1b2000a1 değeri çıkıyor
    • QEMU aygıt belleğini guest’e doğrudan eşlerse guest GPU ile doğrudan konuşabiliyor, ancak başlangıçta VM PCI BAR belleğine dokunduğu anda host kernel çöküyordu
    • Bunun nedeni, QEMU’nun RAM-device/MMIO eşlemelerine de HV_MEMORY_EXEC eklemesi; device/MMIO eşlemelerinde EXEC kaldırılınca host panic önlenebildi
    • Bu yöntem her erişimi trap etmeye göre yaklaşık 30 kat daha hızlı, ancak hv_vm_map() ARM device memory subtype belirleyemediği için BAR yazmaları normal duruma göre yaklaşık 10 kat daha yavaş

DMA ve DART kısıtlarını aşmak

  • Apple Silicon’daki DART sınırları

    • Apple Silicon’da IOMMU benzeri DART adlı bir donanım birimi var ve aygıtların rastgele host belleğine erişmesini engelleyen bir güvenlik sınırı olarak da çalışıyor
    • Thunderbolt aygıtını PCIDriverKit üzerinden kullanırken üç kısıt özellikle büyüktü
      • Yaklaşık 1.5GB eşleme sınırı, CUDA ve modern oyunların ihtiyaç duyduğu 8–16GB düzeyindeki bellek eşlemelerinin olduğu gibi bırakılamaması anlamına geliyor
      • Yaklaşık 64k eşleme sınırı, çok sayıda küçük DMA buffer olduğunda eşleme tablosunun dolmasına yol açıyor
      • Adres ve hizalama doğrudan seçilemediği için guest’in DMA adresini belirlediği sanal IOMMU yaklaşımı uymuyor
    • restricted-dma-pool ile DMA’i önceden ayrılmış bir bölgeye zorlamak basit aygıtlarda işe yaradı, ancak GPU sürücüsüyle uyumlu olmadı

  • apple-dma-pci sanal PCI aygıtı

    • QEMU’ya apple-dma-pci adlı bir sanal PCI aygıtı eklendi ve passthrough yapılan GPU ile birlikte VM’e takıldı
    • Guest kernel sürücüsü, NVIDIA sürücüsünün DMA eşleme çağrılarını yakalıyor; her DMA isteği için talep üzerine eşleme oluşturuyor ve buffer serbest bırakılınca eşlemeyi de kaldırıyor
    • Bu yapıda guest RAM’in tamamının değil, o anda canlı DMA buffer çalışma kümesinin 1.5GB sınırının içinde kalması yeterli oluyor
    • Guest sürücüsü, NVIDIA sürücüsü GPU’yu kullanmadan önce özel DMA işlemleriyle değiştiriliyor; map_page, unmap_page, map_sg, unmap_sg, alloc, free ince wrapper’larla ele alınıyor
    • Host tarafındaki QEMU istekleri PCIDriverKit sürücüsüne iletiyor; bu sürücü gerçek DART eşlemesini yapıp DMA adresini yeniden guest belleğine yazıyor

  • NVIDIA hizalama sorunu ve kprobes yaması

    • CUDA iş yükü çalışırken NV_ERR_INVALID_OFFSET ve RM_PAGE_SIZE_HUGE hizalamasıyla ilgili kernel log’ları görüldü
    • Sorunlu allocation, UVM_RM_MEM_TYPE_SYS tipinde 16MB allocation idi ve NVIDIA sürücüsünün 2MB page size kullanması hizalama kısıtlarıyla çakışıyordu
    • Sürücüde NV_ERR_NO_MEMORY hatasında varsayılan page size ile yeniden deneme yapan bir workaround vardı, ancak NV_ERR_INVALID_OFFSET için bir işlem yoktu
    • Linux kernel’in kprobes özelliği kullanılarak nvUvmInterfaceMemoryAllocSys() çağrısında pageSize, UVM_PAGE_SIZE_DEFAULT olacak şekilde zorlandı
    • NVIDIA sürücüsünü doğrudan değiştirmeden daha küçük page size istenmesi sağlandı ve basit iş yükleri çalışabildi

  • Mapping coalescing ile 64k sınırını aşmak

    • Oyun ayarları yükseltilince çok sayıda tiny mapping oluşuyor ve yaklaşık 64k eşleme sayısı sınırı aşılıyordu
    • Eşleme log’unda, eşlemelerin %90’dan fazlasının 4kB olduğu ve bitişik olmasalar da kümeler halinde göründüğü izlendi
    • Guest belleği 256kB gibi sabit boyutlu bölgelere ayrıldı; 4kB buffer eşlenirken ilgili kümenin tamamı eşlenerek daha sonra aynı kümedeki allocation’ların mevcut eşlemeyi yeniden kullanması sağlandı
    • Bu yöntem gerçek canlı buffer miktarından biraz daha fazla bellek eşliyor, ancak test iş yüklerinde yaklaşık 1.5GB eşleme tavanının altında kalındı
    • Canlı eşleme sayısı yaklaşık 4 kat azaldı ve zorlayıcı oyunları en yüksek ayarlarda çalıştırmak için ek alan oluştu

VM performans iyileştirmeleri

  • vCPU zamanlaması

    • Benchmark skorlarının rastgele büyük dalgalanma göstermesi ve bazen %50 daha yavaş çıkması sorunu vardı
    • Görünüşe göre QEMU vCPU thread’lerine öncelik vermediği için scheduler VM’e yeterli çalışma süresi tanımıyordu
    • QEMU vCPU başlangıç yoluna pthread_set_qos_class_self_np(QOS_CLASS_USER_INTERACTIVE, 0) ve pthread_setschedparam(..., SCHED_RR, ...) yamaları eklenerek yüksek öncelik verildi

  • Total Store Ordering ve FEX-Emu

    • VM arm64 Linux çalıştırıyor, ancak piyasadaki oyunların çoğu x86-64 Windows ikilisi olduğu için Proton) ve FEX-Emu birlikte kullanılıyor
    • x86, store işlemlerinin diğer çekirdekler tarafından program sırasına göre görüldüğü Total Store Ordering(TSO) kullanırken ARM daha zayıf bir bellek sıralama modeli kullanıyor
    • Apple Silicon’da thread başına donanımsal TSO mode bulunuyor ve macOS 15+ içindeki Hypervisor.framework bunu dışa açıyor
    • UTM yaması alınarak vCPU üzerinde ACTLR_EL1 bit 1 açıldı ve FEX-Emu’nun yazılımsal TSO emülasyonu kapatıldı
    • Donanımsal bit olmadan yazılımsal TSO emülasyonu kapatıldığında Geekbench 6 test ortasında çöküyor
    • FEX ve CPU TSO ile guest performansı, native host performansından yaklaşık %50 daha düşük

Oyun performansı

  • Cyberpunk 2077

    • Cyberpunk 2077; M4 Air yerel macOS, M4 Air + eGPU, 2020 Intel MacBook Pro + eGPU, M5 Max yerel macOS, M5 Max + eGPU ve i5-12600K gaming PC + RTX 5090 üzerinde test edildi
    • + Framegen, eGPU/yerel PCIe yapılandırmalarında DLSS 4x; yerel macOS yapılandırmalarında ise FSR 2x kullanıyor
    • 720p Low’da GPU yükü düşük olduğu için CPU ile emülasyon/sanallaştırma ek yükü baskın hale geldi ve M4 Air yerel 61fps, M4 Air + eGPU’nun 49fps sonucundan daha hızlı oldu
    • 1080p High’da M5 Max yerel macOS 131fps ile M5 Max + eGPU’nun 68fps sonucunu geçti; birleşik GPU’nun yeterli olduğu koşullarda ek yük daha belirgin etkili oldu
    • M4 Air yerel macOS, 1080p RT Ultra’da yalnızca 7fps verirken M4 Air + eGPU 30fps, kare üretimi açıkken 119fps gördü
    • 4K’da darboğaz ağırlıklı olarak GPU tarafına kayıyor; M4 Air + eGPU, RT Ultra’da 27fps, DLSS kare üretimiyle 111fps vererek oynanabilir düzeye ulaşıyor
    • Yerel PCIe gaming PC, 4K RT Ultra’da 100fps, DLSS kare üretimiyle 282fps ile en hızlı sistem oldu
    • M5 Max + eGPU, 4K RT Ultra’da 47fps, kare üretimiyle 145fps verdi ve M4 Air + eGPU’dan yaklaşık %30–70 daha hızlıydı

  • Diğer oyunlar ve benchmark’lar

    • GravityMark’ta aynı GPU PCIe yuvası yerine Thunderbolt üzerinden bağlandığında performans yaklaşık %20 düştü; M4 Air + eGPU ise yerel PCIe bağlantıdan yaklaşık %31 daha yavaştı
    • Shadow of the Tomb Raider’da eGPU, M4 Air’ı 4K yereldeki 8fps seviyesinden 40fps’ye çıkardı; 1080p de yerel 26fps’den eGPU ile 42fps’ye yükseldi
    • Shadow of the Tomb Raider’da eGPU performansının 1080p ve 4K’da neredeyse aynı olması, darboğazın GPU değil FEX altındaki CPU olduğunu gösterdi
    • Horizon Zero Dawn Remastered, en düşük 720p ayarında bile tek seferde 1.5GB’den fazla DMA bellek eşlemesi istediği için benchmark başlatılamadı
    • Doom (2016), eGPU yapılandırmasında çalıştı ve performans kaplamasına göre 49fps verdi; her zaman 30fps üstünde kaldı
    • Crysis Remastered, gaming PC’ye kıyasla en fazla yaklaşık 4 kat daha yavaştı, ancak M4 MacBook Air’da yine de oynanabilir kare hızlarında çalıştı

Yapay zeka çıkarım performansı

  • Qwen 3.6

    • Qwen 35B MoE modeli 4 bit kuantize edilerek test edildi; etkin parametre sayısı 3B
    • NVIDIA GPU üzerinde vLLM ve NVFP4 sürümü, Apple Silicon’da ise vllm-mlx ve 4 bit MLX kuantize model kullanıldı
    • Benchmark llama-benchy ile çalıştırıldı
    • Thunderbolt eGPU, PCIe’ye göre yaklaşık %9 performans kaybetti, ancak işlemlerin çoğu kart üzerinde gerçekleştiği için PCIe’ye oldukça yakın kaldı
    • RTX 5090, tek akış üretiminde M4 Air’dan 6.5 kat, M4 Max Mac Studio’dan 2.1 kat, M5 Max MacBook Pro’dan 1.2 kat daha hızlıydı
    • 4K token prompt’ta M4 MacBook Air’ın prefill süresi 17 saniye iken aynı M4 Air’a eGPU bağlandığında 150ms’ye düşerek 120 kat hızlandı
    • Eşzamanlı istek sayısı 1’den 4’e çıktığında RTX 5090 yapılandırmasının toplam throughput’u yaklaşık 3 kat arttı; Apple Silicon Mac’ler daha düşük ölçeklenebilirlik gösterdi

  • Gemma 4

    • Gemma 4 31B, seyrek MoE değil yoğun 31B model olduğu için her token tüm parametrelerden geçmek zorunda
    • M4 Air birleşik GPU’su test sırasında saniyede 2–3 token seviyesini aşamadı ve pratik kullanım sınırının dışında kabul edildi
    • vLLM tabanlı RTX 5090 yapılandırmalarının tümü yaklaşık 50 t/s civarında, birkaç yüzde puanlık farkla kümelendi; M4 Max Mac Studio yaklaşık 22 t/s, M5 Max MacBook Pro ise yaklaşık 27 t/s verdi
    • Prefill tarafında da RTX 5090 her zaman 400ms altındaydı, buna karşılık M4 Max 4K token prompt ayrıştırmada en fazla 21 saniye, M5 Max ise yaklaşık 7.5 saniye sürdü
    • vLLM yapılandırmaları 4 eşzamanlı istekte yaklaşık 3.5 kat throughput elde ederken, Mac’in MLX backend’i 4 istekte neredeyse hiç ek artış göstermedi

Doğrudan çalıştırılabilirlik ve kararlılık

  • Dağıtım ve derleme koşulları

    • Mevcut durum henüz “indirip hemen çalıştır” seviyesinde değil ve Apple’ın özel entitlement izni gerekiyor
    • Bu izin talep edildi, ancak henüz yanıt gelmedi; bekleme süresi ayları bulabilir
    • O zamana kadar sürücü elle derlenebiliyor, ancak ilgili Mac’in imzalama sertifikası hesabına eklenmiş olması gerekiyor
    • SIP’i kapatmak veya reduced security mode kullanmak gerekmiyor
    • Kod qemu-vfio-apple adresinden alınabiliyor
    • Paket içindeki başlatıcı, özel apple_dma sürücüsü kurulmuş önceden derlenmiş Ubuntu imajını otomatik indiriyor

  • Kararlılık

    • Kararlılık henüz iyi değil
    • FEX tarafında şu anda Steam’in döngü halinde sık çökmesine yol açan bir hata var ve bu yapılandırmada sorun daha da belirgin görünüyor
    • Bazı oyunların başlaması birkaç dakika sürebiliyor
    • DMA eşleme sınırı nedeniyle zamanla eşlemeler parçalanabiliyor ve yeni oyun başlatacak alan kalmayabiliyor
    • Bu durumda Linux VM’i durdurup GPU’yu çıkarıp yeniden takarak tüm DMA eşlemelerini temizlemek ve yeniden denemek gerekiyor
    • En kararlı kullanım alanı yapay zeka ve bu amaçta oldukça iyi çalışıyor
    • Upstream QEMU ile yama entegrasyonu sürüyor; ideal hedef bunun UTM gibi ana akım QEMU dağıtımlarına eklenip doğrudan çalışması

İlgili okumalar

1 yorum

 
GN⁺ 1 시간 전
Hacker News yorumları

  • Yıllardır VM ekibinden VM GPU passthrough istiyordum. Apple Silicon Mac Pro üzerinde çalıştım; kasanın içine giren bir GPU’yu Linux VM’e passthrough yapabilseydik çok daha anlamlı olurdu
    Ne yazık ki talep kabul edilmedi ama başkalarının bunu çalıştırmış olması harika

    • Buradaki passthrough kısmı bana göre standart DriverKit arayüzü ile uygulanmış gibi görünüyor. Yani PCIe BAR, macOS’ta ek değişiklik yapmadan zaten kullanıcı alanına eşlenebiliyor
      Sonuçta mesele, QEMU gibi bir sanal makine monitörünün Linux VFIO benzeri bir yaklaşıma ek olarak bu arayüzü benimsemesi gibi görünüyor. Virtualization.framework’ü kastediyorsanız, o zaten başlı başına bir tür sanal makine monitörüne yakın; macOS’ta tam olarak neyin eksik olduğunu düşündüğünüzü merak ediyorum
    • Bununla ilgili yarı ilginç iki nokta var. Birincisi, Virtualization.framework ana makinenin GPU’suna passthrough benzeri bir özelliği destekliyor gibi görünüyor. Bu bir eGPU değil, dahili GPU için ve ana kullanım amacı da macOS guest’in host ile GPU zamanını paylaşarak hızlandırma alması gibi duruyor
      Yakın zamanda QEMU mainline’a da Hypervisor.framework altında Linux guest’lerde benzer bir özelliği desteklemek için virtio-gpu ile birlikte bir "venus server" kullanan yamalar girdi. İkincisi, Apple içinde Virtualization.framework için PCI passthrough desteği var gibi görünüyor. Framework kodunun kendisi müşterilere dağıtılıyor ama normal macOS’ta yer almayan kext’lere ya da kernel bileşenlerine bağımlı gibi. Bunu müşterilere açma niyetleri var mı bilmiyorum ama Apple içinde birilerinin bu özelliği düşündüğü açık
    • İleride yine bir Mac Pro çıkma ihtimali ne kadar? Apple bir gün Siracusa’yı tatmin edecek bir bilgisayar yapabilir mi, bir de "Believe" tişörtü var mı merak ediyorum
    • Bu yazıda sorunun yarısı, QEMU ve VM sınırının yarattığı bellek erişim sorunlarını ele alıyor gibi görünüyor. Aptalca gözden kaçırdığım bir şey olabilir ama Docker’da Ubuntu çalıştırınca NVIDIA sürücüsü yine de yüklenmez mi? O zaman bellek yine OSX’in mülkiyetinde kalır, dolayısıyla Apple’ın bellek yönetimiyle uğraşmak gerekmez gibi geliyor
    • Mac Pro’da NVIDIA GPU desteğinin olmaması bence teknoloji sektöründeki en büyük kaçırılmış fırsatlardan biri olarak kalacak
      Her hâlükârda Mac Pro artık ölü bir ürün. Sadece ses ve video profesyonellerine satışla bir yere kadar gidilir

  • Harika bir yazı. Oyun benchmark’ları eğlenceli ama pratik açıdan asıl ilginç kısım LLM performansındaki iyileşme
    Apple platformu, yüksek RAM sayesinde yerel modeller çalıştırmak için erişilebilir bir ortam; ancak nispeten yavaş prompt işleme hızı sık sık gözden kaçıyor. Yazıdaki alıntıda belirtildiği gibi, 4K token’lık bir prompt’ta M4 MacBook Air yanıt üretmeye başlamadan önce ayrıştırma için 17 saniye harcıyor; eGPU takılınca bu süre 150ms’ye düşüyor, yani 120 kat daha hızlı. Küçük sohbetlerde LLM kullanırken prefill sorunu pek görünmüyor ama daha büyük işlerde kullanmaya başlayınca hesaplama sınırları darboğaz oluyor. İlk token’a kadar geçen süre (TTFT) grafiği de ilk bakışta fena görünmüyor ama Mac platformu toplam GPU hesaplamasında o kadar yavaş kalmış ki grafiği log ölçeğinde çizmek gerekmiş; bunu görünce anlamı değişiyor

    • Uzman değilim, sadece merak ediyorum: Mac’te TTFT neden bu kadar daha kötü? Yazıda bu aşamanın hesaplamaya bağlı olduğu söyleniyor ama gerçekten bu kadar basit mi, yoksa MLX tarafında optimizasyon eksikliği de olabilir mi?
    • Küçük bir detay gibi gelebilir ama gerçekte 113 kat daha hızlı
      Yazar sonucu bu şekilde sununca biraz taraflıymış gibi bir izlenim verebilir ama gerçekten öyle olduğunu sanmıyorum
    • oMLX kullanın. Qwen3.6’da prompt işleme 300 token/sn, token üretimi 30 token/sn veriyor

  • OpenGL artık macOS’ta düzgün desteklenmediği için oyunun CrossOver ile bile tamamen oynanamaz olması kısmı doğru gibi görünüyor
    Yine de Doom’un Vulkan desteği var gibi ve MoltenVK’ye VK_NV_glsl_shader eklenirse bu mümkün olabilir. M4’e RTX 5090 bağlamaktan çok daha az iş gibi duruyor ama yine de Scott’ı alkışlamak lazım. Yerel yapay zeka çıkarım hızı da oldukça etkileyici; gerçekten çılgın bir proje

  • Oldukça etkileyici. Benim izlenimim Apple Silicon’da eGPU’nun hiç çalışmadığı yönündeydi
    Apple da aynı şeyi söylüyor: “eGPU kullanmak için Intel işlemcili bir Mac gerekir.” Üstelik resmî desteklenen eGPU’ların hepsi de NVIDIA değil AMD idi. https://support.apple.com/en-us/102363

    • Bu, macOS’ta eGPU kullanmak değil. Örneğin macOS’teki Chrome’un bu eGPU hızlandırmasıyla çalışması mümkün değil
      Buradaki yapı, bu eGPU’yu Linux VM’e tünellemek

  • İlk başta bunun yavaş tinygrad sürücüsüyle VM çalıştırma üzerine bir yazı olacağını sanmıştım ama aslında yaklaşım çok daha iyiydi
    Apple daha iyi destek verse ve 1.5GB pencere sınırını gevşetse işler çok daha kolay olurdu. Arm tarafında genel olarak PCIe aygıtlarıyla ilgili tuhaflıklar var ama en azından Linux’ta çoğu modern sürücü artık arm64’ü birinci sınıf vatandaş gibi gördüğü için işler çok daha kolaylaştı

    • Kesin konuşamam ama tinygrad tarafının yavaş olmasının nedeni macOS host sürücüsünün kendisi olmayabilir. Görünüşe göre benim yaptığım şeye çok benzer biçimde PCI BAR’ı kullanıcı alanına eşleyip ardından Python koduyla GPU’yu çalıştırıyor
      Tahminimce tinygrad’in yavaş olmasının büyük nedeni, tinygrad çıkarım motorunun bu açık LLM modelleri için henüz çok optimize edilmemiş olması. Muhtemelen işin çoğu George’un otonom sürüş donanım şirketine yönelik stack optimizasyonuna gitmiştir. Mevcut CUDA kernel’lerini o motorda doğrudan çalıştıramadığınız için mühendislik zorluğu çok daha artıyor. Benim projemin onlarla macOS host sürücüsünü paylaşıp paylaşamayacağını da merak ediyorum. Bazı değişiklikler gerekir ama epey örtüşen kısım var gibi

  • “Bugünlerde çoğu projede ilk adım, kabul etmek istemesek de AI’ye sormak” sözü büyük ihtimalle AI’nin kendinin de bilmediği şeyleri anlatacağı anlamına geliyor
    Dün ChatGPT ile 5070TI’ın gerçekten var olan bir ekran kartı olup olmadığını tartıştığım anı hatırlattı. ChatGPT, böyle bir 5070TI kartı olmadığını, benim aslında 4070ti demek istediğimi söyleyip beni sürekli düzeltmeye çalıştı

    • Hatasını kabul ettikten sonra bile aynı hatayı tekrar tekrar yapabiliyor
      Claude’dan PowerShell 7 hakkında bir HTML sayfası yapmasını istemiştim; 7.4’ün en güncel LTS sürümü olduğunu yazdı. Mart ayında 7.6’nın çıktığını gösteren bağlantıyı verip güncel bilgiyle yeniden oluşturmasını istedim, o da neredeyse aynı sayfayı hazırlayıp yine 7.4’ün en güncel sürüm olduğunu tekrarladı
    • LLM’ler genel olarak en güncel konularda akla yatkınlık konusunda güçlü hüküm vermek için pek iyi bir konumda değil
      Yine de ChatGPT’nin asıl yazıya verdiği cevap tamamen isabetliydi. “Çok derin”, “pratikte neredeyse kullanılamaz”, “araştırma açısından” özeti bu yazıyı kusursuz anlatıyor
    • Bir süper gücün tüm ekonomisinin ve çevrimiçi kültürünün neredeyse tamamının Furby hayranlığına kapılmasını izlemek, şimdiye kadar gördüğüm en tuhaf şeylerden biriydi
    • Bu yüzden ben Grok expert mode kullanıyorum. Web’de agresif şekilde bilgi aradığı için bir yıllık veriye dayanmasından çok daha iyi
    • GPT-OSS 120B ile Cascade Lake Xeon workstation CPU parçalarında GPU olmadığı konusunda tartışmıştım. Model tam tersini çok güçlü biçimde savunuyordu

  • Bu gerçekten etkileyici. Elimde boşta bir 5090 var ve M4 Mini’de claw-like çalıştırıyorum; bunu bir 3D baskı çerçeve gibi bir şeye takıp TB portuna bağlayarak yerel çıkarım için gayet kullanışlı bir araç hâline getirmek mümkün olabilir
    Tabii güç beslemesi gibi şeyleri temiz biçimde garanti edecek bir düzeneğe ihtiyaç var. Sorun, max-num-seqs ile max-model-len değerlerinin birbiriyle çakışması; saf tek istemcili mod dışında, tabiri caizse birden fazla slot gerekiyor

  • Apple onayından geçebilirse yapay zeka çıkarımı için oldukça faydalı görünüyor. Mac Mini’de NVIDIA GPU kullanmak istiyordum; bu yöntemle CUDA’yı doğrudan çalıştırmak mümkün oluyor. Gerçekten harika