Thành thật mà nói, tôi đã rất bất ngờ. Khi tôi kết nối hai đơn vị DGX Spark thành một cụm và chạy DeepSeek-V4-Flash, kết quả là nhanh hơn 1.78x về tổng thời gian sinh (thời gian thực tế trên đồng hồ) so với Mac Studio M3 Ultra—có nghĩa là nó hoàn thành tác vụ trong khoảng một nửa thời gian. Và điều này đạt được khi DGX Spark chạy mô hình FP8 chính thức mà không cần thêm bất kỳ lượng tử hóa nào.
Trong khi thực hiện các điểm chuẩn này, tôi cảm thấy rằng quan điểm tôi đã nhiều lần đưa ra một lần nữa được chứng minh bằng những con số. Cụ thể là:
Hiệu suất LLM không thể chỉ được đo bằng tốc độ giải mã (token trên giây, TPS) dựa trên băng thông bộ nhớ.
Sức mạnh tính toán GPU, giao tiếp giữa các nút, phân cấp bộ nhớ, chất lượng lượng tử hóa, độ dài ngữ cảnh, xử lý song song, v.v.—"sự cân bằng" của tất cả các yếu tố này quyết định trải nghiệm người dùng thực tế. Và DGX Spark đơn giản là có sự cân bằng tốt hơn.
Điểm Chuẩn Được Sử Dụng: Điểm Chuẩn Mã hóa của shi3z
Để đo lường, tôi đã sử dụng điểm chuẩn mã hóa từ Điểm chuẩn LLM tiếng Nhật của shi3z. Nhiệm vụ là "hoàn thành một ứng dụng chat chạy trên React trong một lần sinh duy nhất." Mã được tạo ra thực sự được khởi chạy trong Docker và tự động kiểm tra bằng Playwright cho các chức năng đăng nhập, bạn bè, tin nhắn riêng tư (DM) và cập nhật thời gian thực, với điểm chức năng tối đa là 80 điểm.
Kết quả chạy DeepSeek-V4-Flash Q4 (lượng tử hóa 4-bit) trên Mac Studio M3 Ultra thông qua công cụ suy luận ds4 của antirez được liệt kê trong kho lưu trữ của shi3z. Bảng dưới đây so sánh các kết quả đó với kết quả của lần này từ cụm 2 đơn vị DGX Spark + FP8 chính thức.
Kết Quả Điểm Chuẩn
Tại Sao Nó "Thua về tok/s nhưng Thắng về Thời Gian Thực Tế"
Nếu bạn nhìn vào bảng và nghĩ, "Khoan đã, Mac nhanh hơn về tok/s," thì bạn đúng. Chỉ nhìn vào tốc độ tức thời của việc nhả ra một token (TPS giải mã), Mac Studio M3 Ultra nhanh hơn 1.58x. Điều này là do băng thông bộ nhớ khổng lồ của Apple Silicon.
Tuy nhiên, có một cái bẫy ở đây. Để hoàn thành cùng một ứng dụng chat "80/80 điểm tuyệt đối", Mac đã viết 8.036 token, trong khi DGX Spark chỉ viết 2.866 token. Đó là sự khác biệt khoảng 2.8 lần.
Cả hai đều sử dụng DeepSeek-V4-Flash mà không có sự suy giảm chất lượng chính thức, nhưng thật tự nhiên khi giải thích rằng phía Mac, được lượng tử hóa xuống Q4, đã trở nên dư thừa, trong khi phía Spark, chạy ở chất lượng đầy đủ FP8, giữ cho nó ngắn gọn. Đó là một hiện tượng phổ biến nơi tác động của lượng tử hóa lên phân phối đầu ra không hiện ra trong tốc độ giải mã nhưng lại âm thầm ảnh hưởng đến chiến lược sinh.
Kết quả là, phép tính trông như thế này:
Thời Gian Thực Tế Trên Đồng Hồ = (Token Đầu Ra) ÷ (tok/s)
Mac: 8.036 ÷ 26,2 = 307 giây Chúng tôi: 2.866 ÷ 16,6 = 172 giây
Thua về tok/s nhưng thắng về thời gian thực tế có nghĩa là "đạt được cùng một câu trả lời đúng trong ít bước hơn." Trong sử dụng thực tế, những gì con người trải nghiệm là "thời gian cho đến khi nhiệm vụ hoàn thành," chứ không phải tok/s tức thời.
Cấu Hình Đã Sử Dụng
- Phần cứng: DGX Spark × 2 (NVIDIA GB10, dựa trên Blackwell, mỗi đơn vị 128 GB bộ nhớ hợp nhất)
- Kết nối giữa các nút: Kết nối trực tiếp qua ConnectX-7 200 Gbps RoCE (Tensor Parallel = 2, backend phân tán PyTorch)
- Công cụ suy luận: Công thức của Aiden, tích hợp b12x (một bộ kernel CuTe DSL dành riêng cho GB10) vào vLLM 0.21.1dev
- Mô hình: DeepSeek-V4-Flash FP8 chính thức (154 GB, FP8 attention, MXFP4 MoE—đây là định dạng chính thức do DeepSeek phát hành)
- Ngữ cảnh: 524.288 token (512K), util 0,82, KV cache 19,85 GiB, đồng thời 3,89×
- Dự đoán đa token (MTP): Giải mã suy diễn với tỷ lệ chấp nhận khoảng 62% (tăng tốc mà không hy sinh chất lượng đầu ra)
Nhìn Kỹ Hơn Về Hiệu Suất
Ngoài các con số trong điểm chuẩn này, tôi đã đo riêng tốc độ giải mã thuần túy và prefill:
- Tốc độ giải mã thuần túy (Văn bản ngắn, không bao gồm TTFT): Ổn định ở khoảng 39 tok/s
- Tốc độ Prefill (Ngữ cảnh lớn): 1.277 tok/s (Điều này nhanh hơn khoảng 6.5x so với 196 tok/s của cấu hình cũ không có kernel b12x)
- Giải mã với ngữ cảnh dài: Ngay cả khi tôi tăng nó từ 8K → 64K → 128K → 256K → 512K → 768K, tốc độ giải mã không giảm mạnh; trên thực tế, nó còn tăng tốc (106 tok/s ở 768K). Điều này là do Sparse Attention (DSA) của DeepSeek được triển khai nguyên bản trong các kernel b12x, làm cho các tính toán attention hầu như không phụ thuộc vào độ dài ngữ cảnh.
Đây Là Kết Quả Với "Không Lượng Tử Hóa, Chất Lượng Đầy Đủ"
Một điểm khác tôi muốn nhấn mạnh là phía DGX Spark không sử dụng bất kỳ lượng tử hóa bổ sung nào trên mô hình. Chúng tôi đã tải 154 GB chính thức được phân phối trên HuggingFace nguyên trạng và chạy nó ở định dạng lượng tử hóa chính thức do DeepSeek thiết kế: FP8 attention + MXFP4 MoE.
Trong thế giới của các LLM cục bộ, việc nén các mô hình khổng lồ xuống IQ2 (2-bit) hoặc Q4 để chạy đã trở thành lẽ thường, nhưng những điều này chắc chắn làm giảm chất lượng. Trên thực tế, trước đây tôi đã thử phiên bản IQ2XXS (2-bit) của DeepSeek-V4-Flash và thấy kết quả 55/80 cộng với sự sụp đổ hành vi của agent trên cùng một điểm chuẩn. Lượng tử hóa không phải là một bữa trưa miễn phí.
Một cấu hình có thể đảm bảo 256 GB bộ nhớ hợp nhất với hai DGX Spark lần đầu tiên biến tùy chọn "chạy các mô hình khổng lồ ở chất lượng đầy đủ" thành hiện thực. Tôi nghĩ đây là một bước tiến có ý nghĩa hơn những gì các con số gợi ý.
Tại Sao "Sự Cân Bằng" Của Spark Hoạt Động
Phân tích các yếu tố kỹ thuật đã hỗ trợ kết quả này:
- Bộ Kernel b12x: Bốn loại kernel (NVFP4 fused MoE GEMM, NVFP4 dense GEMM, FP8 paged attention và sparse MLA attention) được viết riêng cho GB10 / SM12.x bằng CuTe DSL. Không giống như đường dẫn MARLIN trong vLLM thông thường, các kernel này tính toán trực tiếp ở chế độ fused mà không cần giải lượng tử hóa.
- Kết nối trực tiếp 200 Gbps RoCE: Mặc dù TP=2 all-reduce giữa các nút xảy ra hai lần mỗi lớp, kết nối trực tiếp 200 Gbps giữ cho độ trễ hiệu quả thấp, do đó nó không trở thành nút thắt cổ chai cho việc giải mã.
- 128 GB Bộ Nhớ Hợp Nhất × 2: Một lợi thế của Grace Blackwell, vốn không tách biệt HBM và DDR. Nó cho phép mô hình FP8 chính thức 154 GB được chia trên hai đơn vị nguyên trạng, với đủ dung lượng cho KV cache 19,85 GiB cho ngữ cảnh 512K.
- Triển khai nguyên bản DeepSeek Sparse Attention (DSA): Các kernel b12x xử lý chính xác thiết kế nơi độ phức tạp của attention không phụ thuộc vào độ dài ngữ cảnh bằng cách sử dụng các hoạt động sparse nguyên bản của GB10. Điều này đã dẫn đến kết quả là tốc độ giải mã không giảm mạnh theo độ dài ngữ cảnh.
Nói cách khác, nếu chỉ một trong những yếu tố này—băng thông bộ nhớ, sức mạnh tính toán, giao tiếp nút, tối ưu hóa ngữ cảnh dài hoặc chất lượng lượng tử hóa—nổi bật, thì kết quả này đã không xảy ra. Spark cung cấp tất cả các yếu tố này ở mức cao hơn bất kỳ cấu hình máy đơn nào trong cùng tầm giá. Đây là bản chất thực sự của "sự cân bằng" của nó.
Điều Gì Thay Đổi Trong Sử Dụng Thực Tế?
Để vượt ra ngoài lý thuyết trừu tượng, đây là một số lợi ích cụ thể:
- Việc tóm tắt và phân tích mã của các tài liệu khổng lồ trở nên khả thi: Với ngữ cảnh 512K và tốc độ prefill 1.277 tok/s, bạn có thể tải và tóm tắt toàn bộ một cuốn sách (~300.000 token) trong khoảng 4 phút.
- Các vòng lặp agent không bị kẹt: Với độ đồng thời 3,89×, bạn có thể chạy chat và tóm tắt văn bản dài đồng thời (ví dụ: với Hermes Agent) mà không bị sụp đổ giải mã.
- Không có vấn đề "Agent chỉ nói suông" do lỗi lượng tử hóa: Đây là cái bẫy tôi đã mắc phải nhiều lần với các mô hình dòng IQ2; với chất lượng đầy đủ, điều đó đơn giản là không xảy ra.
- Cạnh tranh với Mac về mức tiêu thụ điện năng: Tổng mức tiêu thụ điện năng của hai GB10 trong quá trình suy luận là khoảng 100W–140W, gần với Mac Studio M3 Ultra ở chế độ tăng tốc tối đa. Xem xét hiệu suất 1.78x, hiệu quả năng lượng cũng không tệ.
Kết Luận: Kỷ Nguyên Đánh Giá Hiệu Suất LLM Bằng TPS Đơn Thuần Đã Qua
Tốc độ tức thời của việc nhả ra một token—decode TPS—chắc chắn là một số liệu quan trọng. Tuy nhiên, nó giống như "tốc độ tối đa của một cuộc chạy nước rút 100m." Điều cần thiết trong thực tế là "thời gian để đạt được cùng một câu trả lời đúng," "chất lượng của câu trả lời," "có thể chạy bao nhiêu đồng thời," "có thể xử lý ngữ cảnh dài bao nhiêu," và "liệu các vòng lặp agent có hoạt động không." Đây là những điểm số tổng thể.
Điều mà kết quả này cho thấy là DGX Spark đang bắt đầu vượt lên trong điểm số tổng thể này. Chúng ta đã bước vào một kỷ nguyên nơi bạn có thể chạy một mô hình khổng lồ ở chất lượng chính thức, với ngữ cảnh dài, trong khi vẫn duy trì khả năng tương thích agent, với tốc độ thực tế nhanh hơn 1.78x so với Mac Studio, chỉ bằng cách kết nối hai đơn vị trong một cụm.
Trong vài năm qua, mọi người đã nói "LLMs hoàn toàn là về băng thông bộ nhớ" và "decode TPS là tất cả," nhưng sau khi thực sự chạy Spark, tôi cảm thấy tuyên bố của mình rằng "sự cân bằng là hiệu suất thực tế" cuối cùng đã được chứng minh bằng những con số.
RTX Spark cũng đã được công bố, và có cảm giác mọi thứ đang trở nên nóng hơn dự kiến (mặc dù bầu không khí có thể hạ nhiệt khi giá được công bố...). Tôi có kỳ vọng cao rằng cộng đồng sẽ phát triển và nhiều tối ưu hóa cũng như bí quyết sẽ được tích lũy!
Jensen thực sự tuyệt vời... Liệu triều đại của ông ấy có tiếp tục kéo dài trong thời gian tới không?
**
**
**
**
**
Phần Thưởng
Bạn đọc tinh ý có thể có lời phê bình này:
"Vậy thì sẽ không phải là một so sánh công bằng nếu bạn cũng chạy FP8 chính thức thô trên Mac Studio sao?"
"Chẳng phải sự so sánh này không công bằng sao? Mac Studio chỉ trở nên dư thừa vì nó được lượng tử hóa xuống Q4. Nếu bạn chạy FP8 chính thức thô trên Mac Studio, chẳng phải nó sẽ ở cùng một sân chơi về chất lượng sao?" Đây là một câu hỏi hợp lý.
Để đi thẳng vào vấn đề: Hiện tại, không có cách nào để chạy 'FP8 chính thức thô + MXFP4 MoE' trên Mac Studio ở tốc độ thực tế.
- Trước hết, không có công cụ suy luận tương thích.
Dường như không có công cụ nào hỗ trợ đầy đủ định dạng chính thức của DeepSeek-V4-Flash (FP8 attention + MXFP4 MoE + Lightning Indexer + DSA Sparse Attention) trên Apple Silicon (theo tìm kiếm của Claude Code).
- MLX (Khung LLM Apple Silicon chính thức của Apple): Không có triển khai nguyên bản của MXFP4 MoE fused GEMM, không có FP8 paged attention và không có triển khai MLX của DeepSeek's DSA Sparse Attention. Nếu bạn cố gắng chạy nó, bạn có thể sẽ phải upcast lên bf16.
- llama.cpp: Không thể tải MXFP4 trực tiếp, do đó yêu cầu lượng tử hóa lại thành GGUF = cuối cùng nó sẽ được chuyển đổi thành Q4 / Q5 / IQ2, v.v., và không còn là phiên bản "chính thức thô" nữa.
- vLLM: Hỗ trợ Apple Silicon vốn đã hạn chế và các kernel dành riêng cho GB10 như b12x sẽ không chạy trên Mac.
- antirez/ds4: Đây là một công cụ chuyên dụng được viết dựa trên MLX dành riêng cho DeepSeek V4 Flash với giả định Q4. Nó là giải pháp tối ưu hiện tại để chạy nó trên Mac Studio, nhưng nó không được xây dựng để xử lý "FP8 thô."
Việc antirez đã viết một công cụ chuyên dụng cho DeepSeek V4 Flash dành riêng cho Q4 cho thấy thực tế là hiện tại không có con đường thực tế nào để chạy chất lượng chính thức nguyên trạng trên Apple Silicon.
- Ngay cả khi nó được chạy với bf16 upcast, băng thông gần như sẽ bị tiêu thụ hoàn toàn.
Vì mục đích tranh luận, giả sử ai đó đã tạo ra một triển khai MLX upcast các trọng số chính thức lên bf16. Bạn có thể ước tính điều gì sẽ xảy ra với một tính toán băng thông thô:
- DeepSeek-V4-Flash có cấu hình MoE với khoảng 30B tham số hoạt động.
- Ở Q4 (4-bit), các tham số hoạt động chiếm khoảng 15 GB và ds4 đạt 26,2 tok/s (đã đo).
- Nếu cùng một mô hình được giữ ở FP8 (8-bit), các tham số hoạt động chiếm khoảng 30 GB = yêu cầu băng thông gấp 2 lần = về mặt lý thuyết ~13 tok/s trên cùng một công cụ.
- Hơn nữa, upcast lên bf16 trong MLX mất khoảng 60 GB cho các tham số hoạt động = yêu cầu băng thông gấp 4 lần = về mặt lý thuyết ~6,5 tok/s.
- Vì băng thông bộ nhớ hiệu quả của Mac Studio M3 Ultra là khoảng 800 GB/s, việc đọc 60 GB cho mỗi token sẽ chạm đến giới hạn băng thông.
Nói cách khác, lựa chọn "có chất lượng thô" trên Apple Silicon hiện tại phải trả giá bằng "hy sinh tốc độ hơn gấp đôi." Chạy ở 26,2 tok/s với ds4 + Q4 là một lựa chọn thực tế hơn là chỉ đạt 6 tok/s với bf16 chất lượng đầy đủ.
- Đây là nơi lợi thế cấu trúc của Spark phát huy tác dụng.
Mặt khác, cấu hình DGX Spark này chạy "FP8 chính thức thô + MXFP4 MoE nguyên bản." Điều này được hỗ trợ bởi:
- Bộ kernel b12x dành riêng cho GB10, có các triển khai để chạy NVFP4 fused MoE GEMM và FP8 paged attention "mà không cần giải lượng tử hóa."
- Điều này chưa được viết cho Apple Silicon.
- Kết quả là, Spark hiện là giải pháp thực tế duy nhất để chạy "chất lượng chính thức nguyên trạng" và "ở tốc độ thực tế."
Tóm lại, nếu bạn chỉ nhìn vào băng thông phần cứng, giá trị tuyệt đối của Mac Studio cho một đơn vị đơn lẻ ở mức tương tự, nhưng sự hiện diện hay vắng mặt của "các triển khai kernel chạy các định dạng lượng tử hóa chính thức một cách nguyên bản" tạo ra một sự khác biệt quyết định. Lợi thế của Spark không chỉ đến từ chip, mà còn từ toàn bộ sự kết hợp với ngăn xếp phần mềm chuyên dụng cho GB10 như b12x.
Nếu ai đó viết MXFP4 fused MoE GEMM, FP8 paged attention và DSA Sparse Attention cho Apple Silicon trong MLX trong tương lai, tiền đề này sẽ sụp đổ. Cục diện sẽ thay đổi tùy thuộc vào các triển khai của cộng đồng. Tại thời điểm này, sự thật là Spark đang đi trước một bước trong việc đạt được sự kết hợp giữa "chất lượng chính thức × tốc độ thực tế."
Đây là kết quả của phân tích được cung cấp bởi Claude Code.
