RTX 5090 กับ MacBook Air M4: เล่นเกมได้ไหม?

 (scottjg.com)
1 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • มีการต่อ RTX 5090 eGPU เข้ากับ MacBook Air M4 แล้วรันเกมใน Linux VM โดยต้องเลี่ยงทั้งการไม่มีไดรเวอร์บน macOS และข้อจำกัดของ Thunderbolt
  • การติดตั้งต้องใช้การแก้ไข apple-dma-pci อุปกรณ์ PCI เสมือน, การเลี่ยง DART mapping, การแพตช์ไดรเวอร์ NVIDIA ด้วย kprobes และการแก้ไข QEMU/HVF
  • Cyberpunk 2077 บน M4 Air + eGPU ทำได้ 4K RT Ultra 27fps และขึ้นไปถึง 111fps เมื่อใช้ DLSS frame generation จนเล่นได้จริง
  • เมื่อนำ RTX 5090 ตัวเดียวกันไปเสียบกับพีซี PCIe ปกติ จะเร็วกว่า 2–4 เท่า แล้วแต่เกม โดยยังมีโอเวอร์เฮดจาก FEX, Proton, VM และ Thunderbolt อยู่มาก
  • ความก้าวหน้าที่ใหญ่กว่าคือ AI inference โดย Qwen prefill บน M4 Air ลดเวลาลงราว 100 เท่า และการสร้างแบบ single stream เพิ่มจากราว 22 tok/s เป็น 155 tok/s

ข้อจำกัดของ Thunderbolt eGPU และ Apple Silicon Mac

  • โครงสร้าง Thunderbolt eGPU

    • เป็นการนำ GPU เดสก์ท็อปอย่าง RTX 5090 ไปใส่ใน Thunderbolt dock แล้วให้ dock แปลง PCIe เป็น Thunderbolt ก่อนเชื่อมต่อเข้าพอร์ต USB-C ของ MacBook Air M4
    • Thunderbolt ทำ PCIe tunneling ผ่านสาย USB-C ดังนั้นจากมุมมองของคอมพิวเตอร์ อุปกรณ์ Thunderbolt จะมองเห็นเป็นอุปกรณ์ PCIe ไม่ใช่อุปกรณ์ USB
    • Thunderbolt 4 ให้ PCIe lane ได้สูงสุด 4 เส้นที่ 40Gbps และมีการสูญเสียประสิทธิภาพเล็กน้อยจากการ tunneling
    • โดยทั่วไปบน Linux และ Windows ระบบจะมอง eGPU เป็นอุปกรณ์ PCIe ที่ช้าลงเล็กน้อย จึงมักใช้ไดรเวอร์เดิมได้แทบจะทันที
    • อุปสรรคแรกคือ macOS บน Apple Silicon ไม่มีไดรเวอร์ NVIDIA หรือ AMD GPU มาให้โดยปริยาย

  • เลี่ยงด้วย Linux VM

    • สามารถรัน Linux บน Apple Silicon Mac ได้ แต่ Linux kernel ปัจจุบันยังไม่รองรับ Thunderbolt บน Apple Silicon และรองรับแค่อุปกรณ์ภายในกับ USB3
    • หากรัน Linux VM แบบ ARM 64 บิตบน macOS host จะได้โครงสร้างที่ macOS จัดการอุปกรณ์ Thunderbolt ส่วน Linux จัดการ NVIDIA GPU
    • เลือกใช้ Linux เพราะไม่มีไดรเวอร์การ์ด NVIDIA สำหรับ Windows ARM64
    • ไดรเวอร์ macOS eGPU ของ tinygrad ใช้ได้เฉพาะภายในสแตก tinygrad จึงไม่เหมาะเป็นไดรเวอร์ทั่วไปสำหรับ AI inference หรือการรันเกม

การทำ PCI passthrough บน macOS

  • PCI BAR และ DMA

    • ถ้า VM จะสื่อสารกับ PCI device ได้ ต้องให้ PCI BAR(Base Address Registers) และ DMA ใช้งานได้
    • PCI BAR คือพื้นที่หน่วยความจำที่อุปกรณ์ PCI ใช้สำหรับอ่านและเขียนกับคอมพิวเตอร์ และถ้า PCI passthrough จะทำงานได้ พื้นที่นี้ต้องถูก mirror เข้าไปใน VM
    • DMA(Direct Memory Access) คือวิธีที่อุปกรณ์อ่านและเขียนหน่วยความจำของคอมพิวเตอร์ได้โดยตรงโดยไม่ต้องผ่านการคัดลอกโดย CPU

  • Hypervisor.framework และการแมป BAR

    • ตอนเริ่ม VM นั้น QEMU จะเรียก Hypervisor.framework ผ่าน hv_vm_map() เพื่อตั้งค่า guest memory layout
    • หากเชื่อมกับไดรเวอร์ PCIDriverKit บน host และแมปหน่วยความจำของอุปกรณ์ PCI เข้าสู่โปรเซสด้วย IOConnectMapMemory64() ก็จะอ่าน BAR0 memory ได้
    • เมื่ออ่าน BAR0[0] จะได้ค่า 0x1b2000a1 ซึ่งเป็นค่าคงที่เฉพาะอุปกรณ์ที่ชี้ว่าเป็น RTX 5090
    • ถ้า QEMU แมปหน่วยความจำของอุปกรณ์เข้า guest โดยตรง guest ก็จะคุยกับ GPU ได้โดยตรง แต่ในช่วงแรกเพียงแค่ VM แตะ PCI BAR memory ก็ทำให้ host kernel crash
    • สาเหตุคือ QEMU ใส่ HV_MEMORY_EXEC ให้กับ RAM-device/MMIO mapping ด้วย และการเอา EXEC ออกจาก device/MMIO mapping ก็ช่วยหลีกเลี่ยง host panic ได้
    • วิธีนี้เร็วกว่าแบบ trapping every access ราว 30 เท่า แต่เพราะ hv_vm_map() ระบุ ARM device memory subtype ไม่ได้ การเขียน BAR จึงช้ากว่าปกติราว 10 เท่า

การเลี่ยงข้อจำกัดของ DMA และ DART

  • ขีดจำกัดของ DART บน Apple Silicon

    • Apple Silicon มีฮาร์ดแวร์ DART ซึ่งคล้าย IOMMU และยังทำหน้าที่เป็นขอบเขตความปลอดภัยเพื่อกันไม่ให้อุปกรณ์เข้าถึง host memory แบบตามใจได้
    • เมื่อใช้อุปกรณ์ Thunderbolt ผ่าน PCIDriverKit มีข้อจำกัดสำคัญ 3 อย่าง
      • มี ขีดจำกัดการแมปราว 1.5GB จึงไม่สามารถปล่อยให้การแมปหน่วยความจำขนาด 8–16GB ที่ CUDA และเกมสมัยใหม่ต้องใช้ค้างไว้ตรง ๆ ได้
      • มี เพดานการแมปราว 64k รายการ ทำให้ถ้ามี DMA buffer เล็กจำนวนมาก ตาราง mapping จะเต็ม
      • ไม่สามารถเลือก address และ alignment เองได้ จึงไม่เข้ากับแนวทาง virtual IOMMU ที่ guest เป็นผู้กำหนด DMA address
    • แนวทางบังคับ DMA ไปยัง region ที่ pre-allocate ด้วย restricted-dma-pool ใช้ได้กับอุปกรณ์ง่าย ๆ แต่ไม่เหมาะกับไดรเวอร์ GPU

  • อุปกรณ์ PCI เสมือน apple-dma-pci

    • มีการเพิ่มอุปกรณ์ PCI เสมือนชื่อ apple-dma-pci เข้าไปใน QEMU แล้วใส่เข้า VM ไปพร้อมกับ GPU ที่ทำ passthrough
    • guest kernel driver จะดักจับ DMA mapping call ของไดรเวอร์ NVIDIA สร้าง on-demand mapping ให้ทุก DMA request และยกเลิก mapping เมื่อตัว buffer ถูกปล่อย
    • โครงสร้างนี้ไม่จำเป็นต้องให้ guest RAM ทั้งหมดอยู่ในเพดาน 1.5GB แต่ให้เพียง working set ของ live DMA buffer ในขณะนั้นอยู่ภายในขีดจำกัดก็พอ
    • guest driver จะถูกสลับเป็น custom DMA ops ก่อนที่ไดรเวอร์ NVIDIA จะเริ่มใช้ GPU และจัดการ map_page, unmap_page, map_sg, unmap_sg, alloc, free ด้วย wrapper แบบบาง
    • ฝั่ง QEMU บน host จะส่ง request ไปยังไดรเวอร์ PCIDriverKit ซึ่งจะทำ DART mapping จริง แล้วเขียน DMA address กลับเข้าไปใน guest memory

  • ปัญหา alignment ของ NVIDIA และแพตช์ kprobes

    • ระหว่างรัน CUDA workload มี kernel log แจ้ง NV_ERR_INVALID_OFFSET และข้อความเกี่ยวกับ alignment ของ RM_PAGE_SIZE_HUGE
    • allocation ที่มีปัญหาเป็น 16MB allocation ประเภท UVM_RM_MEM_TYPE_SYS และไดรเวอร์ NVIDIA ใช้ขนาดเพจ 2MB ซึ่งชนกับข้อจำกัดด้าน alignment
    • ในไดรเวอร์มี workaround ที่จะลองใหม่ด้วย page size ปริยายเมื่อเจอ NV_ERR_NO_MEMORY แต่ไม่ได้จัดการกรณี NV_ERR_INVALID_OFFSET
    • จึงใช้ kprobes ของ Linux kernel เพื่อบังคับให้ pageSize ในการเรียก nvUvmInterfaceMemoryAllocSys() เป็น UVM_PAGE_SIZE_DEFAULT
    • ทำให้ไดรเวอร์ NVIDIA ขอเพจขนาดเล็กลงได้โดยไม่ต้องแก้ไดรเวอร์โดยตรง และช่วยให้ workload แบบง่ายทำงานได้

  • ใช้ mapping coalescing เพื่อเลี่ยงเพดาน 64k

    • เมื่อปรับกราฟิกเกมสูงขึ้น จะเกิด tiny mapping จำนวนมากจนเกิน ขีดจำกัดจำนวน mapping 64k
    • จาก log ของ mapping พบว่า มากกว่า 90% เป็น mapping ขนาด 4kB และแม้ไม่ contiguous แต่มีลักษณะเป็นคลัสเตอร์
    • จึงแบ่ง guest memory เป็น region ขนาดคงที่ เช่น 256kB และเมื่อมีการแมป buffer 4kB ก็จะแมปทั้งคลัสเตอร์นั้น เพื่อให้ allocation ถัดไปในคลัสเตอร์เดียวกัน reuse mapping เดิมได้
    • วิธีนี้แมปหน่วยความจำมากกว่า live buffer จริงเล็กน้อย แต่ใน workload ที่ทดสอบยังต่ำกว่าเพดานการแมป 1.5GB
    • จำนวน live mapping ลดลงราว 4 เท่า ทำให้มี headroom พอสำหรับรันเกมหนัก ๆ ที่การตั้งค่าสูงสุด

การปรับปรุงประสิทธิภาพ VM

  • การจัดตาราง vCPU

    • มีปัญหาที่คะแนน benchmark แกว่งแบบสุ่มอย่างมาก และบางครั้งช้าลงถึง 50%
    • ดูเหมือนว่า QEMU ไม่ได้ตั้ง priority ให้กับ vCPU thread ทำให้ scheduler ไม่ยอมให้เวลา CPU กับ VM มากพอ
    • จึงแพตช์เส้นทางเริ่ม vCPU ของ QEMU ให้เรียก pthread_set_qos_class_self_np(QOS_CLASS_USER_INTERACTIVE, 0) และ pthread_setschedparam(..., SCHED_RR, ...) เพื่อเพิ่ม priority

  • Total Store Ordering และ FEX-Emu

    • แม้ VM จะเป็น Linux arm64 แต่เกมที่วางขายส่วนใหญ่ยังเป็นไบนารี Windows x86-64 จึงต้องใช้ Proton) ร่วมกับ FEX-Emu
    • x86 ใช้ Total Store Ordering(TSO) ซึ่งทำให้ store ถูกมองเห็นบนคอร์อื่นตามลำดับของโปรแกรม ขณะที่ ARM ใช้โมเดล memory ordering ที่อ่อนกว่า
    • Apple Silicon มี TSO mode ระดับฮาร์ดแวร์แบบต่อเธรด และ Hypervisor.framework ของ macOS 15+ ก็เปิดให้ใช้งานได้
    • มีการนำแพตช์จาก UTM มาใช้เพื่อเปิด bit 1 ของ ACTLR_EL1 บน vCPU และปิด software TSO emulation ของ FEX-Emu
    • หากปิด software TSO emulation โดยไม่มี hardware bit นี้ Geekbench 6 จะ crash กลางทาง
    • ประสิทธิภาพของ guest เมื่อใช้ FEX และ CPU TSO ยังต่ำกว่า native host ราว 50%

ประสิทธิภาพด้านเกม

  • Cyberpunk 2077

    • มีการทดสอบ Cyberpunk 2077 บน M4 Air macOS แบบ native, M4 Air + eGPU, 2020 Intel MacBook Pro + eGPU, M5 Max macOS แบบ native, M5 Max + eGPU และพีซีเกมมิง i5-12600K + RTX 5090
    • + Framegen หมายถึงการใช้ DLSS 4x ในชุด eGPU/PCIe native และใช้ FSR 2x ในชุด native macOS
    • ที่ 720p Low ภาระ GPU ต่ำ ทำให้ CPU และโอเวอร์เฮดจาก emulation/virtualization กลายเป็นตัวคุมหลัก โดย M4 Air native ทำได้ 61fps เร็วกว่า M4 Air + eGPU ที่ 49fps
    • ที่ 1080p High นั้น M5 Max native macOS ได้ 131fps เร็วกว่า M5 Max + eGPU ที่ 68fps แสดงว่าเมื่อ integrated GPU เพียงพอ โอเวอร์เฮดจะยิ่งเห็นชัด
    • M4 Air native macOS ทำได้เพียง 7fps ที่ 1080p RT Ultra แต่ M4 Air + eGPU ได้ 30fps และขึ้นเป็น 119fps เมื่อใช้ frame generation
    • ที่ 4K คอขวดจะอยู่ที่ GPU เป็นหลัก โดย M4 Air + eGPU ทำได้ 27fps ที่ RT Ultra และ 111fps เมื่อใช้ DLSS frame generation ซึ่งอยู่ในระดับเล่นได้
    • พีซีเกมมิงที่ใช้ PCIe แบบ native เร็วที่สุดที่ 100fps ใน 4K RT Ultra และ 282fps เมื่อใช้ DLSS frame generation
    • M5 Max + eGPU ทำได้ 47fps ที่ 4K RT Ultra และ 145fps เมื่อเปิด frame generation เร็วกว่า M4 Air + eGPU ราว 30~70%

  • เกมและเบนช์มาร์กอื่น ๆ

    • ใน GravityMark หากเชื่อม GPU ตัวเดียวกันผ่าน Thunderbolt แทน PCIe slot ประสิทธิภาพจะลดลงราว 20% และ M4 Air + eGPU ช้ากว่าการเชื่อมต่อ PCIe แบบ native ราว 31%
    • ใน Shadow of the Tomb Raider นั้น eGPU ยกระดับ M4 Air จาก 8fps แบบ native ที่ 4K เป็น 40fps และที่ 1080p ก็เพิ่มจาก 26fps แบบ native เป็น 42fps บน eGPU
    • ประสิทธิภาพ eGPU ของ Shadow of the Tomb Raider แทบไม่ต่างกันระหว่าง 1080p และ 4K ซึ่งบ่งชี้ว่าคอขวดไม่ได้อยู่ที่ GPU แต่อยู่ที่ CPU ภายใต้ FEX
    • Horizon Zero Dawn Remastered ต้องการ DMA memory mapping มากกว่า 1.5GB ในคราวเดียว แม้จะตั้งค่าต่ำสุดที่ 720p จึงเริ่ม benchmark ไม่ได้
    • Doom (2016) ทำงานได้บนชุด eGPU และตาม performance overlay ทำได้ 49fps โดยรักษาระดับ 30fps ขึ้นไปตลอด
    • Crysis Remastered ช้ากว่าพีซีเกมมิงได้มากสุดราว 4 เท่า แต่ก็ยังรันได้ที่เฟรมเรตระดับเล่นได้บน M4 MacBook Air

ประสิทธิภาพ AI inference

  • Qwen 3.6

    • ทดสอบโมเดล Qwen 35B MoE ที่ควอนไทซ์เป็น 4 บิต โดยมีพารามิเตอร์ที่ active จริง 3B
    • ฝั่ง NVIDIA GPU ใช้ vLLM และเวอร์ชัน NVFP4 ส่วน Apple Silicon ใช้ vllm-mlx และโมเดล MLX quantization 4 บิต
    • รัน benchmark ด้วย llama-benchy
    • Thunderbolt eGPU สูญเสียประสิทธิภาพจาก PCIe ไปราว 9% แต่เพราะงานส่วนใหญ่เกิดบนการ์ด จึงใกล้เคียงกับ PCIe มาก
    • RTX 5090 เร็วกว่า M4 Air ในการสร้างแบบ single stream 6.5 เท่า, เร็วกว่า M4 Max Mac Studio 2.1 เท่า และเร็วกว่า M5 Max MacBook Pro 1.2 เท่า
    • สำหรับพรอมป์ต์ 4K tokens นั้น M4 MacBook Air ใช้เวลา 17 วินาที ในช่วง prefill แต่เมื่อเพิ่ม eGPU ให้ M4 Air ตัวเดิม เวลาลดเหลือ 150ms หรือเร็วขึ้น 120 เท่า
    • เมื่อเพิ่มคำขอพร้อมกันจาก 1 เป็น 4 รายการ throughput รวมของชุด RTX 5090 เพิ่มขึ้นราว 3 เท่า ขณะที่ Apple Silicon Mac ขยายตัวได้น้อยกว่า

  • Gemma 4

    • Gemma 4 31B เป็น dense 31B model ไม่ใช่ sparse MoE ดังนั้นทุกโทเคนต้องผ่านพารามิเตอร์ทั้งหมด
    • integrated GPU ของ M4 Air ทำได้ไม่เกิน 2~3 tokens ต่อวินาที ระหว่างทดสอบ จึงถือว่าอยู่นอกช่วงที่ใช้งานได้จริง
    • ทุกชุด RTX 5090 ที่ใช้ vLLM รวมตัวอยู่ที่ ประมาณ 50 t/s ต่างกันเพียงไม่กี่เปอร์เซ็นต์ ขณะที่ M4 Max Mac Studio อยู่ที่ราว 22 t/s และ M5 Max MacBook Pro อยู่ที่ราว 27 t/s
    • ในช่วง prefill เช่นกัน RTX 5090 ทำได้ต่ำกว่า 400ms ตลอด แต่ M4 Max ใช้เวลาสูงสุด 21 วินาที เพื่อ parse พรอมป์ต์ 4K tokens และ M5 Max ใช้เวลาราว 7.5 วินาที
    • ชุด vLLM ทำ throughput ได้ราว 3.5 เท่า เมื่อมีคำขอพร้อมกัน 4 รายการ ส่วน MLX backend บน Mac แทบไม่เพิ่มขึ้นเมื่อไปถึง 4 คำขอ

ความพร้อมในการใช้งานจริงและเสถียรภาพ

  • การแจกจ่ายและเงื่อนไขการบิลด์

    • สถานะปัจจุบันยังไม่ถึงระดับ “ดาวน์โหลดแล้วรันได้ทันที” และต้องใช้ entitlement พิเศษ จาก Apple
    • มีการยื่นขอ entitlement แล้วแต่ยังไม่ได้รับคำตอบ และอาจต้องรอหลายเดือน
    • ระหว่างนี้ยังสามารถบิลด์ไดรเวอร์เองได้ แต่บัญชีใบรับรองสำหรับการเซ็นต้องมี Mac เครื่องนั้นรวมอยู่ด้วย
    • ไม่จำเป็นต้องปิด SIP หรือใช้ reduced security mode
    • โค้ดสามารถรับได้จาก qemu-vfio-apple
    • ตัว launcher ที่มีมาให้จะดาวน์โหลดอิมเมจ Ubuntu ที่พรีบิลด์และติดตั้งไดรเวอร์ apple_dma แบบพิเศษไว้แล้วโดยอัตโนมัติ

  • เสถียรภาพ

    • เสถียรภาพยังไม่ดีนัก
    • ตอนนี้ FEX มี บั๊กที่ทำให้ Steam crash บ่อยในลักษณะวนลูป และดูเหมือนว่าปัญหาในชุดนี้จะยิ่งหนักขึ้น
    • การเริ่มเกมบางเกมอาจใช้เวลาหลายนาที
    • เพราะข้อจำกัดของ DMA mapping ทำให้ mapping อาจ fragment มากขึ้นเรื่อย ๆ เมื่อใช้งานไปนาน ๆ และอาจไม่มีพื้นที่พอสำหรับเปิดเกมใหม่
    • หากเกิดกรณีนี้ ต้องปิด Linux VM แล้วถอด GPU ออกเสียบใหม่เพื่อล้าง DMA mapping ทั้งหมด จากนั้นค่อยลองใหม่
    • งานที่เสถียรที่สุดคือ AI และสำหรับการใช้งานนี้ระบบทำงานได้ดีมาก
    • กำลังดำเนินการรวมแพตช์เข้ากับ upstream QEMU โดยเป้าหมายในอุดมคติคือให้ถูกรวมอยู่ในดิสทริบิวชัน QEMU กระแสหลักอย่าง UTM และใช้งานได้ทันที

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 3 시간 전
ความเห็นจาก Hacker News

  • ขอ VM GPU passthrough จากทีม VM มาหลายปีแล้ว เคยทำงานกับ Apple Silicon Mac Pro และถ้าสามารถ passthrough GPU ที่อยู่ในเครื่องเข้าไปยัง Linux VM ได้ ก็คงสมเหตุสมผลกว่านี้มาก
    น่าเสียดายที่คำขอนั้นไม่ถูกรับไว้ แต่ก็เจ๋งดีที่มีคนอื่นทำให้มันใช้การได้

    • ตรงส่วน passthrough ตรงนี้ เท่าที่ผมดูน่าจะถูกทำผ่าน อินเทอร์เฟซ DriverKit มาตรฐาน หมายความว่า PCIe BAR สามารถถูกแมปเข้า user space ได้อยู่แล้วโดยไม่ต้องแก้ macOS เพิ่มเติม
      สุดท้ายก็ดูเหมือนเป็นเรื่องของการที่ virtual machine monitor อย่าง QEMU ต้องรองรับอินเทอร์เฟซนี้เพิ่มเติม ควบคู่ไปกับแนวทางแบบ Linux VFIO ถ้าหมายถึง Virtualization.framework มันเองก็ใกล้เคียงกับการเป็น virtual machine monitor แบบหนึ่งอยู่แล้ว เลยสงสัยว่าในมุมมองนั้นคิดว่า macOS ยังขาดอะไรอยู่กันแน่
    • มีประเด็นที่น่าสนใจแบบครึ่ง ๆ อยู่สองอย่าง อย่างแรกคือ Virtualization.framework ดูเหมือนจะรองรับฟีเจอร์คล้ายการ passthrough GPU ของโฮสต์ ไม่ใช่ eGPU แต่เป็น GPU ในตัว และดูเหมือนกรณีใช้งานหลักคือให้ macOS guest แชร์เวลา GPU กับโฮสต์เพื่อรับการเร่งความเร็ว
      ไม่นานมานี้ใน QEMU mainline ก็มีแพตช์ที่ใช้ "venus server" ร่วมกับ virtio-gpu เพื่อรองรับความสามารถคล้ายกันบน Linux guest ภายใต้ Hypervisor.framework อย่างที่สองคือ ภายใน Apple เองดูเหมือนจะมีการรองรับ PCI passthrough สำหรับ Virtualization.framework อยู่ โค้ดฝั่ง framework เองถูกส่งให้ลูกค้า แต่ดูเหมือนจะพึ่งพา kext หรือคอมโพเนนต์เคอร์เนลที่ไม่ได้รวมอยู่ใน macOS ปกติ ไม่รู้ว่าตั้งใจจะเปิดให้ลูกค้าใช้หรือไม่ แต่ชัดเจนว่ามีใครบางคนใน Apple เคยคิดเรื่องฟีเจอร์นี้มาแล้ว
    • ต่อจากนี้ Mac Pro จะยังมีโอกาสออกมาอีกมากแค่ไหน? Apple จะสร้างคอมพิวเตอร์ที่ทำให้ Siracusa พอใจได้สักวันไหม แล้วเขามีเสื้อ "Believe" อยู่หรือเปล่าก็สงสัย
    • ดูเหมือนว่าครึ่งหนึ่งของปัญหาในบทความนี้เป็นเรื่อง ปัญหาการเข้าถึงหน่วยความจำ ที่เกิดจากขอบเขตระหว่าง QEMU กับ VM อาจมีอะไรโง่ ๆ ที่ผมพลาดไป แต่ถ้ารัน Ubuntu ใน Docker ไดรเวอร์ NVIDIA ก็น่าจะยังโหลดได้ไม่ใช่หรือ? แบบนั้นหน่วยความจำก็ยังเป็นของ OSX ต่อไป และคงไม่ต้องไปสู้กับระบบจัดการหน่วยความจำของ Apple
    • ผมยังมองว่าการ ขาดการรองรับ NVIDIA GPU บน Mac Pro จะยังเป็นหนึ่งในโอกาสที่พลาดครั้งใหญ่ที่สุดของวงการเทคโนโลยี
      ยังไงก็ตาม ตอนนี้ Mac Pro ก็เหมือนเป็นผลิตภัณฑ์ที่ตายไปแล้ว การขายให้มืออาชีพสายออดิโอและวิดีโออย่างเดียวมีเพดานอยู่

  • บทความยอดเยี่ยมมาก เบนช์มาร์กเกมก็น่าสนุก แต่ในทางปฏิบัติ ส่วนที่น่าสนใจจริง ๆ คือ การเพิ่มประสิทธิภาพของ LLM
    แพลตฟอร์ม Apple เป็นสภาพแวดล้อมที่เข้าถึงง่ายสำหรับรันโมเดลแบบโลคัลเพราะมี RAM เยอะ แต่ความเร็วการประมวลผลพรอมป์ต์ที่ค่อนข้างช้ากลับมักถูกมองข้าม ตามที่บทความอ้างไว้ สำหรับพรอมป์ต์ 4K token นั้น M4 MacBook Air ใช้เวลา 17 วินาทีกว่าจะ parse เสร็จก่อนเริ่มสร้างคำตอบ แต่ถ้าต่อ eGPU จะใช้เพียง 150ms เท่านั้น เร็วขึ้น 120 เท่า เวลาลองเล่น LLM ด้วยแชตสั้น ๆ ปัญหา prefill อาจไม่ค่อยชัด แต่พอเริ่มใช้กับงานใหญ่ขึ้น ข้อจำกัดด้านคอมพิวต์จะกลายเป็นคอขวด แม้กราฟเวลาไปยังโทเค็นแรก (TTFT) จะดูไม่ได้แย่มาก แต่พอรู้ว่าต้องวาดเป็นสเกลลอการิทึมเพราะแพลตฟอร์ม Mac ช้ากว่าคอมพิวต์ GPU โดยรวมมากเกินไป ความหมายก็เปลี่ยนเลย

    • ไม่ใช่ผู้เชี่ยวชาญนะ แต่อยากรู้ว่าทำไม TTFT บน Mac ถึงแย่กว่ามากขนาดนั้น บทความบอกแค่ว่าขั้นตอนนี้ผูกกับคอมพิวต์ แต่สงสัยว่ามันง่ายแค่นั้นจริงหรือเปล่า หรือว่าเป็นเพราะฝั่ง MLX ยัง optimize ไม่พอด้วย
    • ฟังดูเหมือนเรื่องเล็กน้อย แต่จริง ๆ แล้วมันคือ เร็วขึ้น 113 เท่า
      ถ้าผู้เขียนนำเสนอผลลัพธ์แบบนี้ อาจทำให้รู้สึกว่ามีอคติอยู่บ้าง แต่ผมเชื่อว่าคงไม่ได้ตั้งใจให้เป็นแบบนั้น
    • ใช้ oMLX ก็ได้ กับ Qwen3.6 ผมได้ความเร็วประมวลผลพรอมป์ต์ 300 token/วินาที และสร้างโทเค็น 30 token/วินาที

  • ส่วนที่บอกว่า OpenGL บน macOS ไม่ได้รับการรองรับที่ดีอีกแล้ว จนทำให้เกมเล่นไม่ได้จริงแม้ผ่าน CrossOver ก็ดูจะถูกต้อง
    แต่ Doom น่าจะรองรับ Vulkan และอาจแค่ต้องเพิ่ม VK_NV_glsl_shader ให้ MoltenVK ซึ่งน่าจะงานน้อยกว่าการเอา RTX 5090 ไปแขวนกับ M4 มาก ถึงอย่างนั้นก็ขอปรบมือให้ Scott ความเร็ว local AI inference ก็เจ๋งมากด้วย เป็นโปรเจกต์ที่บ้าดีจริง ๆ

  • ค่อนข้างน่าประทับใจ ความเข้าใจของผมคือบน Apple Silicon นั้น eGPU ใช้ไม่ได้อยู่แล้ว
    Apple เองก็พูดแบบนั้น “หากต้องการใช้ eGPU คุณต้องมี Mac ที่ใช้โปรเซสเซอร์ Intel” แถม eGPU ที่รองรับอย่างเป็นทางการก็ไม่มีตัวไหนเป็น NVIDIA เลย มีแต่ AMD https://support.apple.com/en-us/102363

    • อันนี้ไม่ใช่การใช้ eGPU บน macOS เช่นจะให้ Chrome บน macOS ใช้การเร่งจาก eGPU ตัวนี้ อะไรแบบนั้นทำไม่ได้
      โครงสร้างตรงนี้คือ tunnel eGPU เข้าไปใน Linux VM

  • ตอนแรกนึกว่าจะเป็นบทความเกี่ยวกับการรัน VM ด้วยไดรเวอร์ tinygrad ที่ช้า ๆ แต่จริง ๆ แล้วเป็นแนวทางที่ดีกว่านั้นมาก
    น่าเสียดายที่ Apple ไม่รองรับให้ดีกว่านี้และไม่ผ่อนคลาย ข้อจำกัดหน้าต่าง 1.5GB เพราะคงทำให้ทุกอย่างง่ายขึ้นมาก โดยรวมแล้ว Arm มีความแปลกเฉพาะตัวเรื่องอุปกรณ์ PCIe อยู่บ้าง แต่ใน Linux อย่างน้อยไดรเวอร์สมัยใหม่ส่วนใหญ่ก็ปฏิบัติกับ arm64 ในฐานะพลเมืองชั้นหนึ่ง ทำให้ทุกอย่างง่ายขึ้นมาก

    • ไม่แน่ใจแบบฟันธง แต่ผมคิดว่าสาเหตุที่ฝั่ง tinygrad ช้า ไม่น่าใช่เพราะไดรเวอร์โฮสต์บน macOS เอง ดูเหมือนมันทำแบบคล้ายกับที่ผมทำมาก คือแมป PCI BAR เข้า user space แล้วขับ GPU ด้วยโค้ด Python
      เดาเอาว่าเหตุผลใหญ่ที่ tinygrad ช้าคือเอนจิน inference ของ tinygrad ยังไม่ได้ optimize มากนักสำหรับโมเดล LLM แบบเปิดเหล่านี้ งานส่วนใหญ่น่าจะไปลงกับการ optimize สแตกสำหรับบริษัทฮาร์ดแวร์ขับขี่อัตโนมัติของ George มากกว่า เพราะคุณไม่สามารถเอาเคอร์เนล CUDA เดิมมารันบนเอนจินนั้นได้ตรง ๆ ทำให้ความยากด้านวิศวกรรมสูงขึ้นมาก ผมเองก็สงสัยว่าโปรเจกต์ของผมจะใช้ไดรเวอร์โฮสต์บน macOS ร่วมกับพวกเขาได้หรือเปล่า อาจต้องมีการปรับบางส่วน แต่ดูเหมือนมีส่วนที่ทับซ้อนกันอยู่พอสมควร

  • ประโยคที่ว่า “ทุกวันนี้ก้าวแรกของโปรเจกต์ส่วนใหญ่คือการไปถาม AI ทั้งที่ไม่อยากยอมรับ” นั้น ที่จริงแล้วน่าจะแปลว่า AI จะบอก สิ่งที่มันเองก็ไม่รู้ ให้คุณมากกว่า
    ทำให้นึกถึงตอนเมื่อวานที่ผมเถียงกับ ChatGPT ว่า 5070TI เป็นการ์ดจอจริงหรือไม่ ChatGPT พยายามแก้ผมอยู่เรื่อยว่าการ์ดชื่อ 5070TI ไม่มีอยู่จริง ผมน่าจะหมายถึง 4070ti มากกว่า

    • ต่อให้มันยอมรับว่าพลาดแล้ว มันก็ยังอาจทำ ผิดซ้ำแบบเดิม ต่อไป
      ผมให้ Claude ทำหน้า HTML เกี่ยวกับ PowerShell 7 แล้วมันเขียนว่า 7.4 คือ LTS ล่าสุด ผมส่งลิงก์ให้ว่ารุ่น 7.6 ออกไปแล้วในเดือนมีนาคม แล้วขอให้ทำใหม่ด้วยข้อมูลล่าสุด แต่มันก็ทำหน้าเดิมแทบจะเหมือนเดิมพร้อมย้ำอีกครั้งว่า 7.4 คือรุ่นล่าสุด
    • โดยทั่วไปแล้ว LLM ไม่ได้อยู่ในตำแหน่งที่ดีนักสำหรับการตัดสินอย่างหนักแน่นเรื่อง ความน่าเป็นไปได้ของหัวข้อแนวหน้าสุด
      ถึงอย่างนั้นคำตอบของ ChatGPT ต่อบทความต้นทางก็ถูกต้องมาก สรุปว่า “ลึกมาก”, “แทบใช้งานจริงไม่ได้เลย” และ “ในเชิงงานวิจัย” ซึ่งอธิบายบทความนี้ได้สมบูรณ์แบบ
    • การได้เห็นทั้งเศรษฐกิจของมหาอำนาจและวัฒนธรรมออนไลน์แทบทั้งหมดคลั่งไคล้ Furby เป็นหนึ่งในสิ่งที่ประหลาดที่สุดเท่าที่ผมเคยเห็นมา
    • เพราะงั้นผมเลยใช้ Grok expert mode มันค้นข้อมูลบนเว็บแบบดุดันกว่า ซึ่งดีกว่าการพึ่งข้อมูลที่เก่าเป็นปีมาก
    • ผมเคยเถียงกับ GPT-OSS 120B และชิ้นส่วน CPU เวิร์กสเตชัน Cascade Lake Xeon ว่าไม่มี GPU อยู่ด้วย โมเดลกลับยืนยันอย่างหนักแน่นในทางตรงกันข้าม

  • นี่สุดยอดจริง ๆ ผมมี 5090 เหลืออยู่ตัวหนึ่ง และกำลังรัน claw-like บน M4 Mini ถ้าเสียบมันเข้ากับอะไรอย่างเฟรมพิมพ์ 3 มิติแล้วต่อเข้าพอร์ต TB เพื่อความเสถียร มันอาจกลายเป็นเครื่องมือสำหรับ local inference ที่ใช้ได้ดีพอสมควร
    แน่นอนว่าต้องมีอุปกรณ์บางอย่างมาช่วยให้เรื่องจ่ายไฟเรียบร้อย ปัญหาคือ max-num-seqs กับ max-model-len มันชนกัน และถ้าไม่ใช่โหมด single-client ล้วน ๆ คุณก็ต้องมีหลายสล็อตอยู่ดี

  • ถ้าผ่านการอนุมัติจาก Apple ได้ มันก็ดูน่าจะมีประโยชน์มากสำหรับ AI inference ผมอยากใช้ NVIDIA GPU กับ Mac Mini อยู่แล้ว และวิธีนี้ทำให้รัน CUDA ได้โดยตรง เท่มาก