Flash-MoE - Chạy mô hình 397 tỷ tham số trên laptop

 (github.com/danveloper)
5 điểm bởi GN⁺ 2026-03-23 | 1 bình luận | Chia sẻ qua WhatsApp
  • Engine suy luận nền tảng C/Metal chạy mô hình Mixture-of-Experts 397B tham số trên MacBook Pro (48GB RAM) với tốc độ hơn 4,4 token/giây
  • Toàn bộ mô hình 209GB được stream từ SSD, triển khai chỉ bằng C và shader Metal, không cần Python hay framework
  • Tối đa hóa hiệu quả song song giữa GPU·SSD·CPU bằng SSD Expert Streaming, kernel tối ưu FMA, Deferred GPU Compute
  • Cấu hình lượng tử hóa 4-bit cân bằng giữa chất lượng và tốc độ, tạo đầu ra ở mức production bao gồm khả năng gọi công cụ
  • Một ví dụ về tối ưu hóa và tinh gọn giúp suy luận thời gian thực các mô hình MoE siêu lớn ngay cả trên môi trường laptop

Kết quả hiệu năng

  • Ở cấu hình chuyên gia 4-bit (kernel FMA) đạt 4,36 tok/s, chất lượng tốt, dùng toàn bộ 209GB trên đĩa
  • Cấu hình cơ bản 4-bit đạt 3,90 tok/s, là bước trước khi tối ưu FMA
  • Cấu hình chuyên gia 2-bit (trust OS) đạt 5,74 tok/s, nhanh hơn nhưng lỗi xuất JSON nên không thể gọi công cụ
  • Đỉnh đơn token 2-bit đạt tới 7,05 tok/s nhưng không phù hợp cho sử dụng thực tế
  • Lượng tử hóa 4-bit là cấu hình phù hợp cho vận hành thực tế

Môi trường phần cứng

  • MacBook Pro (Apple M3 Max), CPU 16 lõi (12P+4E), GPU 40 lõi, ANE 16 lõi
  • 48GB bộ nhớ hợp nhất, băng thông khoảng 400GB/s
  • SSD là Apple Fabric 1TB, tốc độ đọc tuần tự 17,5GB/s
  • Môi trường macOS 26.2 (Darwin 25.2.0)

Kiến trúc mô hình

  • Tổng cộng 60 lớp transformer: 45 lớp GatedDeltaNet (linear attention) + 15 lớp full attention
  • Mỗi lớp có 512 chuyên gia, trong đó K=4 được kích hoạt cho mỗi token (bao gồm 1 chuyên gia dùng chung)
  • Chiều ẩn 4096

  • Công nghệ cốt lõi

    • SSD Expert Streaming

      • Trọng số chuyên gia (209GB theo chuẩn 4-bit) được tải khi cần bằng pread() song song từ NVMe SSD
      • Mỗi lớp chỉ tải 4 chuyên gia đang hoạt động (mỗi chuyên gia khoảng 6,75MB)
      • Page cache của OS tự động quản lý việc cache, không cần cache riêng
      • Kiến trúc lấy cảm hứng từ bài báo “LLM in a Flash” của Apple

    • Kernel dequant tối ưu FMA

      • Phép toán (nibble * scale + bias) * x được sắp xếp lại thành dạng fma(nibble, scale*x, bias*x)
      • scale*x và bias*x được tính trước để đơn vị FMA của GPU thực hiện chỉ với một lệnh
      • Nhanh hơn 12% so với triển khai đơn giản

    • Metal Compute Shaders

      • Các kernel Metal viết tay hiện thực nhân ma trận-vectơ dequant 4-bit/2-bit, kích hoạt SwiGLU, chuẩn hóa RMS, attention trên GPU (Q@Kᵀ, softmax, scores@V), RoPE, kết hợp MoE + residual + gate

    • Deferred GPU Expert Compute

      • Lệnh CMD3 (forward của chuyên gia) được gửi bất đồng bộ để CPU chuẩn bị lớp tiếp theo trong khi GPU đang chạy
      • Các phép kết hợp + chuẩn hóa + residual cũng được thực hiện trên GPU và truyền trực tiếp sang lớp kế tiếp

    • Tận dụng Accelerate BLAS

      • Dùng cblas_sscal, cblas_sgemv, cblas_sger cho tính toán hồi quy của GatedDeltaNet
      • Nhanh hơn 64% so với mã scalar

    • Trust the OS

      • Loại bỏ cache tùy chỉnh, để page cache của OS (dựa trên LRU, khoảng 35GB) đảm nhiệm việc cache dữ liệu chuyên gia
      • Đều chậm hơn so với page cache của OS khi dùng Metal LRU tự triển khai, cache malloc, hay cache nén LZ4
      • Đạt tỷ lệ cache hit tự nhiên 71%

  • Ràng buộc của bộ nhớ hợp nhất

    • Trên Apple Silicon, SSD DMA và tính toán GPU dùng chung cùng bộ điều khiển bộ nhớ
    • Khi chạy song song, băng thông GPU bị bão hòa khiến độ trễ tăng vọt
    • Pipeline tuần tự GPU → SSD → GPU là dạng tối ưu theo phần cứng

Bài viết liên quan

1 bình luận

 
GN⁺ 2026-03-23
Ý kiến trên Hacker News

  • Có một cách khác để chạy Qwen 3.5 397B ngay cả trên thiết bị tiêu dùng
    Có bản lượng tử hóa 2.5 BPW (quant) nên hoàn toàn khả thi cả trên thiết bị có 128GB bộ nhớ
    Tôi đã chạy ổn trên M1 Ultra với tốc độ khoảng 20 tok/s, đồng thời giữ ngữ cảnh 256k
    Kết quả lm-evaluation-harness vào khoảng mmlu 87.86%, gpqa diamond 82.32%, gsm8k 86.43%, ifeval 75.90%
    Tôi đã tổng hợp trải nghiệm chi tiết trong thảo luận Hugging Face link 1 và link 2
    Đây là một mô hình rất tốt cho suy luận ngoại tuyến

    • Cách trong bài cũng đã dùng 2-bit quantization rồi
      Số chuyên gia trên mỗi token bị giảm từ 10 xuống 4 nên chất lượng giảm thêm
      Với prompt ngắn thì ổn, nhưng trong các phiên dài thì không còn hữu dụng
      Còn có vấn đề tạo ra "name" thành \name\, khiến tool calling không ổn định
    • Tôi tò mò không biết dạo này tốc độ tok/s là bao nhiêu
      Muốn biết liệu nó có chạy tốt cả với ngữ cảnh dài không
      Và thật vui khi lại thấy nickname của bạn — người tạo ra Neovim, đúng là một thành công đáng kinh ngạc
      Tôi cũng dùng nó mỗi ngày
    • Tôi tò mò về mức tiêu thụ điện
      Có thể ước lượng bằng CoconutBattery
    • Không rõ là chỉ chạy trên một M1 Ultra duy nhất hay không
    • Tôi đã tiêu quá nhiều credit cho tự động hóa cá nhân, nên thông tin này cực kỳ hữu ích

  • Nhìn vào chi tiết thì có vẻ họ đạt khoảng 5 tok/s bằng cách dùng lượng tử hóa 2-bit và giảm số chuyên gia từ 10 xuống 4
    Đây là một proof of concept thú vị, nhưng khá xa so với chất lượng của mô hình 397B gốc
    Kiểu tối ưu hóa cực đoan này dẫn đến mất mát năng lực suy luận của mô hình
    Nó còn có vấn đề tạo ra "name" thành \name\ trong đầu ra JSON nên không phù hợp để sử dụng thực tế
    Tôi công nhận đây là một thử nghiệm cho thấy về mặt kỹ thuật điều đó là khả thi, nhưng chưa đạt đến mức thực sự dùng được
    Dạo này có quá nhiều bài báo do AI viết kiểu này khiến tôi thấy mệt mỏi

    • Khi thấy vấn đề đầu ra JSON, tôi đã nghĩ liệu có thể giới hạn sampling chỉ vào các token JSON hợp lệ hay không
      Nhưng thực tế tôi nghe nói ngay cả các LLM thương mại cũng có độ chính xác tool calling thấp
      Có lẽ việc này hoặc khó triển khai, hoặc có phần nào đó là bất khả thi về mặt cấu trúc

  • Cũng có thảo luận liên quan trên r/LocalLLaMA

  • Theo trang GitHub, cách mmap đơn giản gặp nghẽn do overhead ở cấp trang nhớ
    Tôi tò mò liệu việc cấu hình huge page trên macOS hoặc prefetch bằng posix_fadvise có thể cải thiện hay không

  • Suy giảm chất lượng ở lượng tử hóa 2-bit thực sự là một vấn đề nghiêm trọng
    Theo kinh nghiệm của tôi trong công việc thực tế, một mô hình 30B 4-bit được tinh chỉnh tốt còn tốt hơn loại 70B+ 2-bit
    Khi giảm số chuyên gia thì về cơ bản nó đã trở thành một mô hình khác
    Dù vậy, việc thử nghiệm giới hạn của phần cứng tiêu dùng vẫn rất thú vị

  • Tôi thấy mệt với kiểu tiêu đề “chạy trên laptop” mà lần nào cũng ám chỉ MacBook giá $3000
    Kỹ thuật nén thì rất ấn tượng, nhưng không phải lựa chọn thực tế với người dùng phổ thông

    • Tôi dùng một chiếc laptop khá ổn (không phải Mac), nên thấy những thử nghiệm như vậy rất thú vị
      Nhưng nhìn tiêu đề tôi cũng không kỳ vọng nó sẽ chạy trên bất kỳ laptop nào
      Tôi thích tận hưởng những thử nghiệm như vậy hơn là quá cay nghiệt
    • Có thể kiếm mẫu M1 Max 64GB cũ với giá dưới $2000
      Cũng có nhiều người vốn đã sở hữu MacBook hiệu năng cao như vậy để làm dựng video
      Điểm hay là có thể thử nghiệm ngay trên laptop đang có mà không cần thiết bị riêng
    • Thực ra cũng có thể làm điều đó với laptop Strix Halo giá $3000~4000
    • Có lẽ tiêu đề kiểu “,on a laptop!” sẽ chính xác hơn
    • Tôi đã chạy toàn bộ mô hình bằng một cụm gồm hai laptop $3000 (128GB zbook)
      Tốc độ khoảng 20 tok/s, và tôi nghĩ mức này vẫn đủ dễ tiếp cận với cá nhân
      Với công việc thì khoản đầu tư đó cũng đáng giá

  • “No Python. No frameworks. Just C, Objective-C, and hand-tuned Metal shaders.”
    Đọc câu này là tôi lập tức đoán ra token đến từ đâu

  • Họ nói là “Hand-written Metal kernels”, nhưng liệu có phải do GPT tự viết không? 😉

    • Thực tế tác giả có nói rõ đó là mã do AI viết

  • Kết quả thực sự rất ấn tượng
    Tôi tò mò liệu trên Linux có thể làm cách tương tự bằng truy cập dựa trên bộ nhớ hệ thống thay vì SSD hay không
    Hoặc ý tưởng lưu trọng số ở dạng ROM cũng khá thú vị

    • Cách tiếp cận tương tự cũng khả thi trên Linux
      Chỉ là dự án này dùng Metal nên bị giới hạn ở macOS
    • Hầu hết các engine (ví dụ: llama.cpp, vllm, sglang) đều hỗ trợ tính năng này
      Nhưng mô hình MoE vẫn bị ràng buộc mạnh bởi băng thông
    • Tính năng nạp chuyên gia vào bộ nhớ hệ thống đã được hầu hết framework AI cục bộ hỗ trợ
      Tuy nhiên ở giai đoạn decode, overhead truyền CPU còn lớn hơn GPU nên lợi ích không nhiều
      Dùng GPU chỉ để tăng tốc phần dùng chung sẽ hiệu quả hơn
    • Cũng có thể chạy một số layer không vừa bộ nhớ GPU trên CPU
      Nhưng khi mô hình tràn sang RAM hệ thống hoặc đĩa thì hiệu năng giảm rất mạnh
    • Nếu cách này hiệu quả thì chỉ với hai chiếc 3090 và đủ RAM cũng có thể làm suy luận lớn ở mức phòng lab cá nhân

  • Có giải thích rằng SSD là nút thắt, nhưng tác giả nói đạt 15GB/s
    Trong khi theo tôi biết, băng thông tối đa chỉ khoảng 8GB/s. Tôi đã bỏ sót điều gì?

    • Trong kiến trúc này, IO mang tính burst rất cao
      Khi có kết quả từ router, chuyên gia sẽ được nạp từ SSD, và chính lúc đó SSD bị bão hòa
      IO trung bình chỉ khoảng 2970MB/s, thấp hơn khá nhiều so với giới hạn SSD
      Nếu song song hóa một số tensor bằng đọc bất đồng bộ thì có thể còn tốt hơn
      Khi tôi thử trên Linux với io_uring, khoảng 20% số lần đọc hoàn thành song song trong lúc đang tính toán
    • Ở thế hệ PCIe 5, băng thông tăng gấp đôi nên SSD đời mới nhanh hơn
    • SSD trên MacBook Pro M5 Pro/Max đạt cỡ đó