DeepSeek công nghệ mới chuyển sang chip Apple! Mô hình lớn cục bộ trên Mac tăng tốc 60%.

DSpark刚开源一周，就被搬进了苹果电脑。 DSpark vừa mới mã nguồn mở một tuần, đã được chuyển sang máy tính Apple.

移植版本叫mlx-dspark，跑的是Gemma-4 12B和Qwen3-4B这两个模型。 Phiên bản port được gọi là mlx-dspark, chạy hai mô hình Gemma-4 12B và Qwen3-4B.

装上之后，这两个模型在Mac上的生成速度分别提了1.6倍和1.4倍。 Sau khi cài đặt, tốc độ sinh của hai mô hình này trên Mac lần lượt tăng gấp 1,6 lần và 1,4 lần.

更难的是，它做到了大多数移植版本做不到的一件事——输出和原模型逐字节相同，一个字都不差。 Khó hơn là, nó đã làm được một điều mà hầu hết các phiên bản port không làm được — đầu ra giống hệt từng byte với mô hình gốc, không sai một chữ nào.

也就是说，速度换来了，质量一点没丢。 Nghĩa là, tốc độ đã đổi được, chất lượng không hề mất đi.

动手的人是Abdur Rahim，业余时间捣鼓开源项目的一个工程师，DSpark开源以来的第一个Mac原生版本，都是他一个人做出来的。 Người thực hiện là Abdur Rahim, một kỹ sư làm dự án mã nguồn mở trong thời gian rảnh, phiên bản Mac nguyên bản đầu tiên kể từ khi DSpark mã nguồn mở, đều do một mình anh ấy làm ra.

苹果电脑跑大模型，提速60%

针对DeepSeek在6月27日开源的DSpark，官方给出的数字是服务端场景下能提速60%到85%。 Đối với DSpark mà DeepSeek mã nguồn mở vào ngày 27 tháng 6, con số chính thức đưa ra là có thể tăng tốc từ 60% đến 85% trong kịch bản máy chủ.

不过这套技术当时只有数据中心GPU上的实现，没有适配苹果芯片的版本。 Tuy nhiên, công nghệ này lúc đó chỉ có triển khai trên GPU trung tâm dữ liệu, không có phiên bản thích ứng cho chip Apple.

mlx-dspark是这套技术的第一个苹果芯片原生版本。 mlx-dspark là phiên bản nguyên bản chip Apple đầu tiên của công nghệ này.

DSpark的思路是配一个更小的模型给目标模型打下手，小模型先一口气蹦出几个候选词，目标模型再一次性核对，对的收下，错的打回去重猜。 Ý tưởng của DSpark là ghép một mô hình nhỏ hơn hỗ trợ mô hình mục tiêu, mô hình nhỏ trước tiên nhảy ra vài từ ứng cử, mô hình mục tiêu sau đó kiểm tra một lần, đúng thì nhận, sai thì đẩy về đoán lại.

这一步的成本，在数据中心和苹果电脑上不一样。 Chi phí của bước này, khác nhau giữa trung tâm dữ liệu và máy tính Apple.

在数据中心的GPU上，核对一批候选词更像包车，坐几个人都是一口价，解码本来就是内存瓶颈，多核对几个词几乎不多花时间。 Trên GPU trung tâm dữ liệu, kiểm tra một lô từ ứng cử giống như thuê xe, ngồi bao nhiêu người cũng một giá, giải mã vốn là nút thắt bộ nhớ, kiểm tra thêm vài từ gần như không mất thêm thời gian.

苹果芯片更像打表的出租车，核对的候选词越多，表跳得越多。 Chip Apple giống như taxi tính tiền, từ ứng cử được kiểm tra càng nhiều, đồng hồ nhảy càng nhiều.

Rahim实测过，Gemma-4 12B每多核对一个token，要多花约14毫秒。他把这套账算成了一个成本模型，得出的结论是，苹果芯片上的速度天花板在2.2倍左右。 Rahim đã thử nghiệm, Gemma-4 12B mỗi khi kiểm tra thêm một token, mất thêm khoảng 14 mili giây. Anh ấy tính toán bộ sổ sách này thành một mô hình chi phí, kết luận được là trần tốc độ trên chip Apple khoảng 2,2 lần.

总之，Rahim把这个打下手的小模型从HuggingFace的checkpoint里搬了过来，分别配给Gemma-4 12B和Qwen3-4B这两个目标模型使用。 Tóm lại, Rahim đã chuyển mô hình nhỏ hỗ trợ này từ checkpoint của HuggingFace sang, ghép lần lượt cho hai mô hình mục tiêu Gemma-4 12B và Qwen3-4B sử dụng.

他还把核对流程在MLX框架里重新搭了一遍，权重量化成4-bit。 Anh ấy còn xây dựng lại quy trình kiểm tra trong khung MLX, lượng tử hóa trọng số thành 4-bit.

结果，在M4 Pro上，对比苹果官方的MLX工具，Gemma-4 12B的生成速度从18.4tok/s涨到约30tok/s，是原来的约1.6倍；Qwen3-4B从52.9tok/s涨到约73tok/s，是原来的约1.4倍。 Kết quả, trên M4 Pro, so với công cụ MLX chính thức của Apple, tốc độ sinh của Gemma-4 12B từ 18,4 tok/s tăng lên khoảng 30 tok/s, gấp khoảng 1,6 lần; Qwen3-4B từ 52,9 tok/s tăng lên khoảng 73 tok/s, gấp khoảng 1,4 lần.

另外，在mlx-dspark里，Rahim还做了一件大多数移植工作没做的事。 Ngoài ra, trong mlx-dspark, Rahim còn làm một việc mà hầu hết các công việc port không làm.

移植版本，也能高精度还原

多数把大模型搬到本地的版本，只支持贪婪解码，也就是每一步都挑概率最高的那个词。 Hầu hết các phiên bản chuyển mô hình lớn sang local, chỉ hỗ trợ giải mã tham lam, tức là mỗi bước chọn từ có xác suất cao nhất.

Rahim在mlx-dspark里，把DSpark论文里原本描述的温度采样方法也实现了出来，草稿模型给出候选词，接受概率是min(1, p/q)，没通过的部分从残差重新采样。 Rahim trong mlx-dspark, đã triển khai phương pháp lấy mẫu nhiệt độ được mô tả trong bài báo DSpark, mô hình nháp đưa ra từ ứng cử, xác suất chấp nhận là min(1, p/q), phần không được thông qua lấy mẫu lại từ phần dư.

他自己核对过，这套流程跑出来的输出，严格等于目标模型在同样温度下会给出的那个精确分布，不是打了折扣的近似版本。 Anh ấy tự kiểm tra, đầu ra của quy trình này chạy ra, nghiêm ngặt bằng với phân phối chính xác mà mô hình mục tiêu sẽ đưa ra ở cùng nhiệt độ, không phải phiên bản xấp xỉ bị giảm chất lượng.

多数投机解码只做贪婪版本，是因为验证贪婪模式的正确性很简单，逐字比对就行。 Hầu hết giải mã đầu cơ chỉ làm phiên bản tham lam, vì kiểm tra tính đúng đắn của chế độ tham lam rất đơn giản, chỉ cần so sánh từng chữ.

Rahim多做的这一步，是自己把采样模式下跑出来的输出分布核对了一遍，确认没有走样。 Bước mà Rahim làm thêm, là tự mình kiểm tra phân phối đầu ra chạy dưới chế độ lấy mẫu, xác nhận không bị méo.

负责核对的目标模型该配哪个精度，是他自己试出来的一个坑。 Mô hình mục tiêu chịu trách nhiệm kiểm tra nên ghép độ chính xác nào, là một cái hố do anh ấy tự thử ra.

如果小模型配的是没经过指令微调的基础版目标模型，蹦出的候选词只有47%能通过核对；换成对应的指令微调版本，这个比例涨到82%。 Nếu mô hình nhỏ ghép với mô hình mục tiêu phiên bản cơ bản chưa qua tinh chỉnh lệnh, thì từ ứng cử nhảy ra chỉ có 47% vượt qua kiểm tra; đổi sang phiên bản tinh chỉnh lệnh tương ứng, tỷ lệ này tăng lên 82%.

他还测过把目标模型换成bf16精度，核对成本涨得比通过率涨得多，反而更慢，所以目标模型默认留在8-bit上最划算。 Anh ấy còn thử đổi mô hình mục tiêu sang độ chính xác bf16, chi phí kiểm tra tăng nhiều hơn tỷ lệ thông qua tăng, ngược lại còn chậm hơn, nên mô hình mục tiêu mặc định để ở 8-bit là tiết kiệm nhất.

负责打前站蹦候选词的小模型，用的是另一套精度。 Mô hình nhỏ chịu trách nhiệm nhảy từ ứng cử trước, dùng một bộ độ chính xác khác.

草稿模型本身被他做了压缩，4-bit量化之后只有1.8GB，装进内存毫无压力，跑起来还是无损。 Bản thân mô hình nháp đã được anh ấy nén, sau khi lượng tử hóa 4-bit chỉ còn 1,8GB, nạp vào bộ nhớ không áp lực, chạy vẫn không mất mát.

结果就是，DSpark不仅实现了加速，也确实把论文里提到的16%到18%接受率提升，在设备端复现了出来。 Kết quả là, DSpark không chỉ thực hiện tăng tốc, mà còn thực sự tái hiện được mức tăng 16% đến 18% tỷ lệ chấp nhận được đề cập trong bài báo, ở phía thiết bị.

DFlash也接了进来，代码任务更快

推文发出后，评论区来了一条留言，DFlash论文的作者之一Jian Chen问，能不能试试他们团队的模型。 Sau khi tweet được đăng, trong phần bình luận có một tin nhắn, một trong các tác giả của bài báo DFlash Jian Chen hỏi, có thể thử mô hình của nhóm họ không.

DFlash是z-lab今年5月发的论文里提出的另一种投机解码方案，作者团队带头人Zhijian Liu，UCSD助理教授，同时是NVIDIA的研究科学家。 DFlash là một giải pháp giải mã đầu cơ khác được đề xuất trong bài báo của z-lab phát hành tháng 5 năm nay, trưởng nhóm tác giả Zhijian Liu, trợ lý giáo sư UCSD, đồng thời là nhà khoa học nghiên cứu của NVIDIA.

DFlash的思路和DSpark不太一样，它用一次并行的「块扩散」去噪一整块16个token，而不是像DSpark那样一步步带着依赖关系去猜。 Ý tưởng của DFlash và DSpark không giống nhau, nó dùng một lần "khuếch tán khối" song song để khử nhiễu cả một khối 16 token, thay vì đoán từng bước với sự phụ thuộc như DSpark.

Rahim迅速动手。 Rahim nhanh chóng bắt tay vào việc.

他用Jian自己写的移植脚本，把z-lab发布的gemma4-12B-it-DFlash接到mlx-vlm的Gemma-4目标模型上，在同一台Mac上，跟自己刚测完的DSpark又跑了一轮头对头对比。 Anh ấy dùng script port do Jian tự viết, kết nối gemma4-12B-it-DFlash của z-lab phát hành vào mô hình mục tiêu Gemma-4 của mlx-vlm, trên cùng một Mac, chạy một vòng so sánh đối đầu với DSpark vừa mới thử xong của mình.

代码和数学任务上，DFlash整块解码的接受长度能到5.95到6.20，速度约36tok/s，达到约2.1倍，跑赢了DSpark。 Trên các tác vụ mã và toán học, độ dài chấp nhận của giải mã cả khối của DFlash đạt 5,95 đến 6,20, tốc độ khoảng 36 tok/s, đạt khoảng 2,1 lần, chạy thắng DSpark.

但是，DFlash一次要蹦出一整块16个token，而但目标模型未必全部认可，实际能通过核对的只是其中一部分，业内管这个叫“接受长度”，不是每次都能把16个全填满。 Tuy nhiên, DFlash một lần phải nhảy ra cả một khối 16 token, nhưng mô hình mục tiêu chưa chắc chấp nhận tất cả, thực tế chỉ có một phần vượt qua kiểm tra, trong ngành gọi là "độ dài chấp nhận", không phải lần nào cũng lấp đầy cả 16.

所以在开放聊天这种内容不好预测的场景里，接受长度上不去，块填不满，DFlash的优势发挥不出来。 Vì vậy trong các kịch bản như trò chuyện mở, nội dung khó dự đoán, độ dài chấp nhận không lên, khối không lấp đầy, ưu thế của DFlash không phát huy được.

DSpark的Markov头正是为了对付同一个毛病存在的，并行蹦出一整块词，越往后的位置是各自独立算出来的，容易互相不搭调，Markov头给这些位置之间加了一层依赖关系，专门纠正这个问题。 Đầu Markov của DSpark chính là tồn tại để đối phó với cùng một vấn đề, nhảy ra song song cả một khối từ, vị trí càng về sau là tính toán độc lập, dễ không ăn khớp với nhau, đầu Markov thêm một lớp phụ thuộc giữa các vị trí này, chuyên để sửa vấn đề này.

结果就是，在聊天场景里，DSpark反而比DFlash更快。 Kết quả là, trong kịch bản trò chuyện, DSpark ngược lại nhanh hơn DFlash.

而后更新的mlx-dspark v0.0.3，正式把z-lab原版DFlash接入了包里，还加了一个参数，可以手动把DFlash的有效块长度调短，聊天场景用短块，代码和数学场景仍然用满16的整块。 Sau đó, bản cập nhật mlx-dspark v0.0.3, chính thức đưa DFlash gốc của z-lab vào gói, còn thêm một tham số, có thể thủ công điều chỉnh độ dài khối hiệu dụng của DFlash ngắn lại, kịch bản trò chuyện dùng khối ngắn, kịch bản mã và toán học vẫn dùng cả khối 16.

这之后，同一台Mac、同一个包，就能同时完成聊天和代码、数学类的任务，不用再在DSpark和DFlash两个项目之间来回搬了。 Sau đó, cùng một Mac, cùng một gói, có thể hoàn thành đồng thời các tác vụ trò chuyện, mã và toán học, không cần phải di chuyển qua lại giữa hai dự án DSpark và DFlash.

Rahim在推文里说，同样的方法，用在更大的Qwen3-8B和14B草稿模型上应该也能跑通。 Rahim trong tweet nói, phương pháp tương tự, dùng trên các mô hình nháp Qwen3-8B và 14B lớn hơn cũng nên chạy được.

来源：量子位 Nguồn: Lượng Tử Vị

风险提示及免责条款 Cảnh báo rủi ro và điều khoản miễn trách nhiệm

        市场有风险，投资需谨慎。本文不构成个人投资建议，也未考虑到个别用户特殊的投资目标、财务状况或需要。用户应考虑本文中的任何意见、观点或结论是否符合其特定状况。据此投资，责任自负。

Thị trường có rủi ro, đầu tư cần thận trọng. Bài viết này không cấu thành lời khuyên đầu tư cá nhân, cũng không xem xét đến mục tiêu đầu tư, tình hình tài chính hoặc nhu cầu đặc biệt của từng người dùng. Người dùng nên cân nhắc xem bất kỳ ý kiến, quan điểm hoặc kết luận nào trong bài viết này có phù hợp với tình hình cụ thể của họ hay không. Đầu tư dựa theo đó, tự chịu trách nhiệm.