RTX 5090 dan M4 MacBook Air: Bisakah untuk Gaming?

 (scottjg.com)
1 poin oleh GN⁺ 3 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Sebuah RTX 5090 eGPU dipasangkan ke M4 MacBook Air dan game dijalankan di Linux VM, dengan berbagai batasan seperti ketiadaan driver macOS dan keterbatasan Thunderbolt yang harus diakali
  • Implementasinya memerlukan perangkat PCI virtual apple-dma-pci, bypass pemetaan DART, patch driver NVIDIA berbasis kprobes, serta modifikasi QEMU/HVF
  • Cyberpunk 2077 di M4 Air + eGPU mencapai 27fps pada 4K RT Ultra, dan naik hingga 111fps dengan DLSS frame generation sehingga menjadi layak dimainkan
  • RTX 5090 yang sama jika dipasang pada PC PCIe biasa bisa 2–4x lebih cepat tergantung game, dengan overhead besar dari FEX, Proton, VM, dan Thunderbolt yang masih tersisa
  • Peningkatan yang lebih besar justru ada pada inferensi AI: prefill Qwen di M4 Air turun sekitar 100x, dan generasi single-stream naik dari sekitar 22 tok/s ke 155 tok/s

Keterbatasan Thunderbolt eGPU dan Apple Silicon Mac

  • Struktur Thunderbolt eGPU

    • GPU desktop seperti RTX 5090 dipasang ke dock Thunderbolt, lalu dock mengonversi PCIe ke Thunderbolt dan menghubungkannya ke port USB-C pada M4 MacBook Air
    • Thunderbolt melakukan tunneling PCIe melalui kabel USB-C, sehingga dari sudut pandang komputer, perangkat Thunderbolt terlihat sebagai perangkat PCIe, bukan perangkat USB
    • Thunderbolt 4 menyediakan maksimal 4 lane PCIe dengan bandwidth 40Gbps, dengan sedikit penurunan performa akibat tunneling
    • Umumnya di Linux dan Windows, eGPU dikenali seperti perangkat PCIe yang sedikit lebih lambat sehingga hampir bisa langsung bekerja dengan driver yang sudah ada
    • Hambatan pertama adalah macOS di Apple Silicon tidak menyediakan driver NVIDIA maupun AMD GPU secara bawaan

  • Solusi lewat Linux VM

    • Menjalankan Linux di Apple Silicon Mac memang memungkinkan, tetapi kernel Linux saat ini belum mendukung Thunderbolt di Apple Silicon dan baru mendukung perangkat internal serta USB3
    • Dengan menjalankan Linux VM ARM 64-bit di atas host macOS, macOS bisa menangani perangkat Thunderbolt sementara Linux menangani GPU NVIDIA
    • Linux dipilih karena tidak ada driver kartu NVIDIA untuk Windows ARM64
    • Driver macOS eGPU dari tinygrad hanya bisa dipakai di dalam stack tinygrad, sehingga tidak cocok sebagai driver umum untuk inferensi AI atau menjalankan game

Implementasi PCI passthrough di macOS

  • PCI BAR dan DMA

    • Agar VM bisa berkomunikasi dengan PCI device, PCI BAR (Base Address Registers) dan DMA harus berfungsi
    • PCI BAR adalah area memori yang digunakan perangkat PCI untuk membaca dan menulis ke komputer, dan agar PCI passthrough berfungsi area ini harus dimirror ke dalam VM
    • DMA (Direct Memory Access) adalah cara perangkat membaca dan menulis memori komputer secara langsung tanpa penyalinan oleh CPU

  • Hypervisor.framework dan pemetaan BAR

    • Saat memulai VM, QEMU memanggil Hypervisor.framework lewat hv_vm_map() untuk menyiapkan layout memori guest
    • Dengan terhubung ke driver host PCIDriverKit dan memetakan memori perangkat PCI ke proses lewat IOConnectMapMemory64(), memori BAR0 bisa dibaca
    • Saat membaca BAR0[0], keluar 0x1b2000a1, yaitu konstanta spesifik perangkat yang mengarah ke RTX 5090
    • Jika QEMU memetakan memori perangkat langsung ke guest, guest bisa berkomunikasi langsung dengan GPU, tetapi pada awalnya kernel host crash begitu VM menyentuh memori PCI BAR
    • Penyebabnya adalah QEMU menambahkan HV_MEMORY_EXEC juga pada pemetaan RAM-device/MMIO, dan panic host berhasil dihindari dengan workaround berupa menghapus EXEC pada pemetaan device/MMIO
    • Pendekatan ini sekitar 30x lebih cepat daripada melakukan trap pada setiap akses, tetapi karena hv_vm_map() tidak bisa menentukan subtype memori perangkat ARM, penulisan ke BAR menjadi sekitar 10x lebih lambat dari kondisi normal

Mengakali keterbatasan DMA dan DART

  • Batasan DART di Apple Silicon

    • Apple Silicon memiliki unit hardware DART yang mirip IOMMU, dan juga berfungsi sebagai batas keamanan agar perangkat tidak bisa mengakses memori host sembarangan
    • Dalam penggunaan perangkat Thunderbolt melalui PCIDriverKit, ada tiga keterbatasan utama
      • Batas pemetaan sekitar 1,5GB membuat pemetaan memori besar 8–16GB yang dibutuhkan CUDA dan game modern tidak bisa dibiarkan apa adanya
      • Batas sekitar 64k mapping membuat tabel pemetaan cepat penuh bila ada banyak buffer DMA kecil
      • Alamat dan alignment tidak bisa dipilih sendiri, sehingga model virtual IOMMU tempat guest menentukan alamat DMA menjadi tidak cocok
    • Pendekatan memaksa DMA ke region yang sudah dialokasikan sebelumnya dengan restricted-dma-pool berhasil untuk perangkat sederhana, tetapi tidak cocok untuk driver GPU

  • Perangkat PCI virtual apple-dma-pci

    • QEMU ditambah perangkat PCI virtual bernama apple-dma-pci dan disisipkan ke VM bersama GPU passthrough
    • Driver kernel guest mencegat pemanggilan DMA mapping dari driver NVIDIA, membuat pemetaan secara on-demand untuk setiap request DMA, lalu melepas mapping saat buffer dibebaskan
    • Dengan struktur ini, yang perlu muat di dalam batas 1,5GB bukan seluruh RAM guest, melainkan hanya working set buffer DMA yang aktif saat itu
    • Driver guest mengganti driver NVIDIA ke custom DMA ops sebelum GPU dipakai, lalu menangani map_page, unmap_page, map_sg, unmap_sg, alloc, dan free lewat wrapper tipis
    • Di sisi host, QEMU meneruskan request ke driver PCIDriverKit, yang melakukan pemetaan DART sebenarnya lalu menuliskan kembali alamat DMA ke memori guest

  • Masalah alignment NVIDIA dan patch kprobes

    • Saat menjalankan workload CUDA, muncul log kernel NV_ERR_INVALID_OFFSET dan masalah alignment terkait RM_PAGE_SIZE_HUGE
    • Alokasi bermasalah adalah alokasi 16MB bertipe UVM_RM_MEM_TYPE_SYS, dan penggunaan page size 2MB oleh driver NVIDIA bertabrakan dengan batasan alignment
    • Driver sebenarnya punya workaround untuk mencoba lagi dengan page size default jika gagal dengan NV_ERR_NO_MEMORY, tetapi tidak menangani NV_ERR_INVALID_OFFSET
    • Dengan kprobes di kernel Linux, pemanggilan nvUvmInterfaceMemoryAllocSys() dipaksa memakai UVM_PAGE_SIZE_DEFAULT pada pageSize
    • Tanpa memodifikasi driver NVIDIA itu sendiri, cara ini memaksa permintaan page size yang lebih kecil sehingga workload sederhana bisa berjalan

  • Menghindari batas 64k dengan mapping coalescing

    • Saat pengaturan game dinaikkan, muncul sangat banyak mapping kecil hingga melewati batas jumlah mapping sekitar 64k
    • Dari log mapping terlihat lebih dari 90% mapping berukuran 4kB, dan meski tidak kontigu, pola kemunculannya berbentuk cluster
    • Memori guest dibagi ke region berukuran tetap seperti 256kB, lalu saat buffer 4kB dipetakan, seluruh cluster terkait ikut dipetakan agar alokasi berikutnya di cluster yang sama bisa memakai mapping yang sudah ada
    • Cara ini memang memetakan sedikit lebih banyak memori daripada buffer aktif sebenarnya, tetapi pada workload yang diuji tetap berada di bawah plafon pemetaan sekitar 1,5GB
    • Jumlah mapping aktif turun kira-kira 4x, sehingga tersedia headroom untuk menjalankan game berat pada setting tertinggi

Peningkatan performa VM

  • Penjadwalan vCPU

    • Ada masalah skor benchmark yang berfluktuasi besar secara acak dan sering kali keluar 50% lebih lambat
    • QEMU tampaknya tidak mengatur prioritas thread vCPU, sehingga scheduler tidak memberi cukup jatah waktu eksekusi ke VM
    • Jalur start vCPU di QEMU dipatch dengan pthread_set_qos_class_self_np(QOS_CLASS_USER_INTERACTIVE, 0) dan pthread_setschedparam(..., SCHED_RR, ...) untuk memberi prioritas tinggi

  • Total Store Ordering dan FEX-Emu

    • VM ini memakai Linux arm64, tetapi kebanyakan game yang tersedia adalah binary Windows x86-64, sehingga digunakan Proton) bersama FEX-Emu
    • x86 menggunakan Total Store Ordering (TSO), yaitu model di mana store terlihat oleh core lain sesuai urutan program, sedangkan ARM memakai model pengurutan memori yang lebih lemah
    • Apple Silicon memiliki mode TSO hardware per-thread, dan fitur ini diekspos oleh Hypervisor.framework di macOS 15+
    • Patch dari UTM diambil untuk menyalakan bit 1 ACTLR_EL1 pada vCPU dan mematikan emulasi TSO software milik FEX-Emu
    • Jika emulasi TSO software dimatikan tanpa bit hardware tersebut, Geekbench 6 akan crash di tengah jalan
    • Performa guest dengan FEX dan CPU TSO sekitar 50% lebih rendah daripada performa host native

Performa gaming

  • Cyberpunk 2077

    • Cyberpunk 2077 diuji pada M4 Air native macOS, M4 Air + eGPU, MacBook Pro Intel 2020 + eGPU, M5 Max native macOS, M5 Max + eGPU, serta PC gaming i5-12600K + RTX 5090
    • + Framegen berarti memakai DLSS 4x pada konfigurasi eGPU/PCIe native, dan FSR 2x pada konfigurasi native macOS
    • Pada 720p Low, beban GPU kecil sehingga CPU dan overhead emulasi/virtualisasi menjadi faktor dominan, dan M4 Air native 61fps lebih cepat daripada M4 Air + eGPU 49fps
    • Pada 1080p High, M5 Max native macOS mencatat 131fps, lebih tinggi daripada M5 Max + eGPU 68fps, menunjukkan bahwa bila iGPU sudah cukup maka overhead menjadi lebih terasa
    • M4 Air native macOS hanya mencapai 7fps pada 1080p RT Ultra, tetapi M4 Air + eGPU mencapai 30fps, dan 119fps saat frame generation diaktifkan
    • Pada 4K, bottleneck beralih ke GPU, dan M4 Air + eGPU mencatat 27fps pada RT Ultra serta 111fps dengan DLSS frame generation, sehingga naik ke level yang layak dimainkan
    • PC gaming dengan PCIe native adalah yang tercepat, dengan 100fps pada 4K RT Ultra dan 282fps dengan DLSS frame generation
    • M5 Max + eGPU mencatat 47fps pada 4K RT Ultra dan 145fps dengan frame generation, sekitar 30–70% lebih cepat daripada M4 Air + eGPU

  • Game dan benchmark lain

    • Di GravityMark, menghubungkan GPU yang sama lewat Thunderbolt alih-alih slot PCIe menurunkan performa sekitar 20%, dan M4 Air + eGPU sekitar 31% lebih lambat daripada koneksi PCIe native
    • Di Shadow of the Tomb Raider, eGPU meningkatkan M4 Air dari 8fps native 4K menjadi 40fps, dan pada 1080p juga naik dari 26fps native menjadi 42fps dengan eGPU
    • Performa eGPU di Shadow of the Tomb Raider hampir sama pada 1080p dan 4K, menunjukkan bottleneck-nya bukan GPU melainkan CPU di bawah FEX
    • Horizon Zero Dawn Remastered membutuhkan pemetaan memori DMA lebih dari 1,5GB sekaligus bahkan pada setting 720p terendah, sehingga benchmark tidak bisa dimulai
    • Doom (2016) bisa berjalan pada konfigurasi eGPU, dengan 49fps menurut overlay performa dan selalu bertahan di atas 30fps
    • Crysis Remastered hingga sekitar 4x lebih lambat daripada PC gaming, tetapi tetap berjalan pada framerate yang bisa dimainkan di M4 MacBook Air

Performa inferensi AI

  • Qwen 3.6

    • Model Qwen 35B MoE diuji dalam kuantisasi 4-bit, dengan 3B parameter aktif
    • Di GPU NVIDIA digunakan vLLM dan versi NVFP4, sedangkan di Apple Silicon digunakan vllm-mlx dan model kuantisasi MLX 4-bit
    • Benchmark dijalankan dengan llama-benchy
    • Thunderbolt eGPU kehilangan sekitar 9% performa dibanding PCIe, tetapi karena sebagian besar pemrosesan terjadi di kartu, hasilnya tetap cukup mirip dengan PCIe
    • RTX 5090 6,5x lebih cepat dari M4 Air, 2,1x lebih cepat dari M4 Max Mac Studio, dan 1,2x lebih cepat dari M5 Max MacBook Pro dalam generasi single-stream
    • Pada prompt 4K token, M4 MacBook Air butuh 17 detik untuk prefill, tetapi M4 Air yang sama dengan eGPU turun menjadi 150ms, atau sekitar 120x lebih cepat
    • Saat jumlah request paralel dinaikkan dari 1 menjadi 4, total throughput konfigurasi RTX 5090 naik sekitar 3x, sementara Apple Silicon Mac menunjukkan skalabilitas yang lebih rendah

  • Gemma 4

    • Gemma 4 31B adalah model dense 31B, bukan sparse MoE, sehingga setiap token harus melewati seluruh parameter
    • iGPU M4 Air tidak mampu melewati 2–3 token per detik saat pengujian, sehingga dianggap tidak lagi berguna secara praktis
    • Semua konfigurasi RTX 5090 berbasis vLLM berkumpul di sekitar 50 t/s dalam selisih beberapa persen, sedangkan M4 Max Mac Studio mencatat sekitar 22 t/s dan M5 Max MacBook Pro sekitar 27 t/s
    • Pada prefill, RTX 5090 selalu berada di bawah 400ms, tetapi M4 Max memerlukan hingga 21 detik untuk parsing prompt 4K token, sedangkan M5 Max sekitar 7,5 detik
    • Konfigurasi vLLM mencatat throughput sekitar 3,5x pada 4 request paralel, sementara backend MLX di Mac hampir tidak bertambah lagi pada 4 request

Kelayakan penggunaan langsung dan stabilitas

  • Distribusi dan syarat build

    • Dalam kondisi sekarang, ini belum sampai tahap “unduh lalu langsung jalan”, dan masih memerlukan entitlement khusus dari Apple
    • Entitlement sudah diminta, tetapi belum ada balasan dan waktu tunggunya bisa beberapa bulan
    • Sambil menunggu, driver masih bisa dibuild sendiri, dengan syarat Mac tersebut harus termasuk dalam akun sertifikat penandatanganan
    • Tidak perlu menonaktifkan SIP atau memakai reduced security mode
    • Kodenya tersedia di qemu-vfio-apple
    • Launcher yang disertakan akan otomatis mengunduh image Ubuntu prabuild yang sudah dipasangi driver khusus apple_dma

  • Stabilitas

    • Stabilitasnya masih belum baik
    • Saat ini FEX memiliki bug yang membuat Steam sering crash dalam loop, dan masalah ini tampak lebih parah pada konfigurasi ini
    • Memulai game tertentu bisa memakan waktu beberapa menit
    • Karena batas DMA mapping, mapping bisa terfragmentasi seiring waktu dan akhirnya tidak menyisakan ruang untuk menjalankan game baru
    • Jika itu terjadi, Linux VM harus dimatikan lalu GPU dicabut dan dipasang kembali untuk menghapus semua DMA mapping sebelum mencoba lagi
    • Beban kerja yang paling stabil adalah AI, dan untuk penggunaan ini performanya sangat baik
    • Integrasi patch dengan QEMU upstream sedang berlangsung, dan target idealnya adalah masuk ke distribusi QEMU arus utama seperti UTM agar bisa langsung digunakan

Bacaan terkait

1 komentar

 
GN⁺ 3 jam lalu
Komentar Hacker News

  • Sudah bertahun-tahun meminta VM GPU passthrough ke tim VM. Pernah mengerjakan Apple Silicon Mac Pro, dan rasanya akan jauh lebih masuk akal kalau GPU yang terpasang di dalam casing bisa di-passthrough ke Linux VM
    Sayangnya permintaan itu tidak diterima, tetapi keren melihat orang lain berhasil membuatnya berjalan

    • Bagian passthrough di sini, menurut saya, tampaknya diimplementasikan dengan antarmuka DriverKit standar. Artinya PCIe BAR pada dasarnya sudah bisa dipetakan ke user space tanpa perlu modifikasi tambahan pada macOS
      Pada akhirnya ini tampak seperti persoalan agar monitor mesin virtual seperti QEMU mengadopsi antarmuka itu selain pendekatan seperti Linux VFIO. Jika yang dimaksud adalah Virtualization.framework, itu sendiri sudah cukup mirip dengan monitor mesin virtual, jadi saya penasaran apa tepatnya yang dianggap masih kurang di macOS
    • Ada dua hal yang agak menarik terkait ini. Pertama, Virtualization.framework tampaknya mendukung sesuatu yang mirip passthrough GPU host. Bukan untuk eGPU, melainkan GPU bawaan, dan kegunaan utamanya tampaknya agar guest macOS bisa berbagi waktu GPU dengan host sambil tetap mendapatkan akselerasi
      Baru-baru ini bahkan masuk patch ke QEMU mainline yang memakai virtio-gpu bersama "venus server" untuk mendukung fungsi serupa pada guest Linux di bawah Hypervisor.framework. Kedua, tampaknya ada dukungan PCI passthrough untuk Virtualization.framework di internal Apple. Kode framework-nya sendiri didistribusikan ke pelanggan, tetapi tampaknya bergantung pada kext atau komponen kernel yang tidak disertakan dalam macOS biasa. Saya tidak tahu apakah ini memang diniatkan untuk dibuka ke pelanggan, tetapi jelas seseorang di Apple pernah memikirkan fitur ini
    • Seberapa besar kemungkinan Mac Pro akan hadir lagi ke depannya? Apakah Apple suatu hari bisa membuat komputer yang memuaskan Siracusa, dan saya juga penasaran apakah dia punya kaus "Believe"
    • Setengah dari masalah di tulisan ini tampaknya membahas masalah akses memori yang ditimbulkan oleh batas antara QEMU dan VM. Mungkin ada sesuatu yang bodoh yang saya lewatkan, tetapi kalau menjalankan Ubuntu di Docker, bukankah driver NVIDIA seharusnya tetap bisa dimuat? Kalau begitu memorinya tetap dimiliki OSX, jadi seharusnya tidak perlu berhadapan dengan manajemen memori Apple
    • Saya masih menganggap tidak adanya dukungan NVIDIA GPU di Mac Pro akan tetap menjadi salah satu peluang terbesar yang terlewat di industri teknologi
      Bagaimanapun juga, Mac Pro sekarang sudah jadi produk mati. Penjualan ke profesional audio dan video saja ada batasnya

  • Tulisan yang luar biasa. Benchmark game-nya menyenangkan, tetapi secara praktis bagian yang benar-benar menarik adalah peningkatan performa LLM
    Platform Apple adalah lingkungan yang mudah diakses untuk menjalankan model lokal karena RAM-nya besar, tetapi kecepatan pemrosesan prompt yang relatif lambat sering diabaikan. Seperti kutipan di artikel, dengan prompt 4K token, M4 MacBook Air memerlukan 17 detik untuk parsing sebelum mulai menghasilkan respons, sedangkan dengan eGPU cukup 150ms, jadi 120 kali lebih cepat. Saat hanya mengutak-atik LLM dengan percakapan kecil, masalah prefill memang tidak terlalu terlihat, tetapi begitu mulai dipakai untuk tugas yang lebih besar, batas komputasi menjadi bottleneck. Grafik time to first token (TTFT) juga awalnya tidak tampak buruk, tetapi maknanya berubah ketika diketahui bahwa platform Mac terlalu lambat dibanding total komputasi GPU sampai grafiknya harus digambar dalam skala log

    • Saya bukan ahli, jadi penasaran apakah ada yang tahu kenapa TTFT di Mac bisa jauh lebih buruk. Di artikel hanya dibilang tahap ini terikat komputasi, tetapi saya penasaran apakah memang sesederhana itu atau ada juga optimisasi di sisi MLX yang masih kurang
    • Ini mungkin terdengar sepele, tetapi sebenarnya 113 kali lebih cepat
      Kalau penulis menyajikan hasil dengan cara seperti itu, bisa memberi kesan seolah ada bias, meskipun saya percaya sebenarnya tidak begitu
    • Tinggal pakai oMLX. Di Qwen3.6 saya mendapat pemrosesan prompt 300 token/detik dan generasi token 30 token/detik

  • Bagian bahwa OpenGL tidak lagi didukung dengan baik di macOS sehingga game tidak sepenuhnya bisa dimainkan bahkan lewat CrossOver tampaknya benar
    Namun Doom tampaknya mendukung Vulkan, dan mungkin cukup dengan menambahkan VK_NV_glsl_shader ke MoltenVK. Itu sepertinya jauh lebih sedikit pekerjaan dibanding memasang RTX 5090 ke M4, tetapi tetap saja salut untuk Scott. Kecepatan inferensi AI lokalnya juga cukup keren, benar-benar proyek gila

  • Cukup mengesankan. Kesan saya selama ini adalah bahwa eGPU di Apple Silicon memang tidak bisa
    Apple juga mengambil posisi yang sama. “Untuk menggunakan eGPU, Anda memerlukan Mac dengan prosesor Intel.” Selain itu, eGPU yang didukung resmi semuanya AMD, bukan NVIDIA. https://support.apple.com/en-us/102363

    • Ini bukan memakai eGPU di macOS. Misalnya, Chrome di macOS tidak bisa berjalan dengan akselerasi dari eGPU ini
      Strukturnya di sini adalah menyalurkan eGPU itu ke Linux VM

  • Awalnya saya kira ini akan jadi artikel tentang menjalankan VM dengan driver tinygrad yang lambat, tetapi ternyata pendekatannya jauh lebih baik
    Sayang sekali kalau Apple tidak mendukung lebih baik dan melonggarkan batas jendela 1.5GB, karena itu akan membuat semuanya jauh lebih mudah. Arm memang punya banyak kekhasan terkait perangkat PCIe secara umum, tetapi setidaknya di Linux, sebagian besar driver modern memperlakukan arm64 sebagai warga kelas satu sehingga jauh lebih mudah

    • Saya tidak yakin sepenuhnya, tetapi alasan sisi tinygrad lambat tampaknya bukan karena driver host macOS itu sendiri. Strukturnya terlihat sangat mirip dengan yang saya lakukan, yaitu memetakan PCI BAR ke user space lalu menggerakkan GPU lewat kode Python
      Dugaan saya, alasan besar tinygrad lambat adalah karena mesin inferensi tinygrad sendiri belum banyak dioptimalkan untuk model LLM publik seperti ini. Kemungkinan besar sebagian besar pekerjaan masuk ke optimisasi stack untuk perusahaan perangkat keras kendaraan otonom milik George. Karena kernel CUDA yang sudah ada tidak bisa langsung dijalankan begitu saja di mesin itu, tingkat kesulitan rekayasanya jadi jauh lebih tinggi. Saya juga penasaran apakah proyek saya bisa berbagi driver host macOS dengan mereka. Mungkin perlu beberapa perubahan, tetapi tampaknya ada cukup banyak bagian yang tumpang tindih

  • Bagian “langkah pertama sebagian besar proyek akhir-akhir ini, meski enggan diakui, adalah bertanya ke AI” kemungkinan lebih berarti AI akan memberi tahu hal-hal yang bahkan tidak diketahuinya sendiri
    Ini mengingatkan saya pada saat kemarin berdebat dengan ChatGPT apakah 5070TI benar-benar kartu grafis yang ada. ChatGPT terus mencoba mengoreksi saya dengan mengatakan bahwa kartu 5070TI tidak ada, jadi pasti yang saya maksud 4070ti

    • Bahkan setelah mengakui kesalahan, kadang masih terus mengulang kesalahan yang sama
      Saya pernah meminta Claude membuat halaman HTML tentang PowerShell 7, dan dia menulis bahwa 7.4 adalah rilis LTS terbaru. Saya lalu memberinya tautan bahwa 7.6 dirilis pada bulan Maret dan memintanya membuat ulang dengan informasi terbaru, tetapi dia membuat halaman yang hampir sama sambil mengulangi klaim yang sama bahwa 7.4 adalah rilis terbaru
    • LLM pada umumnya memang kurang berada pada posisi yang tepat untuk memberi penilaian kuat tentang kelayakan topik paling mutakhir
      Meski begitu, jawaban ChatGPT terhadap tulisan aslinya justru tepat sekali. Ringkasan seperti “sangat mendalam”, “hampir tidak praktis”, dan “dari sudut pandang riset” menjelaskan artikel ini dengan sempurna
    • Melihat seluruh ekonomi negara adidaya dan hampir seluruh budaya onlinenya tergila-gila pada Furby adalah salah satu hal paling aneh yang pernah saya lihat sampai sekarang
    • Karena itu saya memakai Grok expert mode. Dia agresif mencari informasi di web, jadi jauh lebih baik daripada bergantung pada data yang sudah berumur setahun
    • Saya pernah berdebat dengan GPT-OSS 120B bahwa komponen CPU workstation Cascade Lake Xeon tidak punya GPU. Model itu dengan yakin justru mengklaim kebalikannya

  • Ini benar-benar luar biasa. Saya punya 5090 cadangan dan sedang menjalankan claw-like di M4 Mini, jadi kalau dipasang ke semacam rangka hasil 3D print demi stabilitas lalu dihubungkan ke port TB, ini bisa jadi alat yang lumayan berguna untuk inferensi lokal
    Memang perlu perangkat yang bisa menjamin hal-hal seperti catu daya dengan rapi. Masalahnya adalah max-num-seqs dan max-model-len saling berbenturan, dan kalau bukan mode murni single-client, maka perlu beberapa slot, bisa dibilang begitu

  • Ini tampak cukup berguna untuk inferensi AI kalau saja bisa lolos persetujuan Apple. Saya memang ingin memakai NVIDIA GPU di Mac Mini, dan dengan cara ini CUDA bisa dijalankan langsung. Benar-benar keren