"3B Tham Số Hoạt Động" của MiniCPM-V 4.7 Không Có Trong Model Card — Tôi Đã Đo Nó Từ Trọng Số

Con số được nhắc đi nhắc lại nhiều nhất về MiniCPM-V 4.7 35B-A3B lại không hề được in ra ở bất kỳ đâu trong tài liệu của chính nó. Tuyên bố — "chỉ 3B tham số hoạt động (!) — nó chạy được cả trên iPhone" — đến từ một bài đăng của bên thứ ba ngày 13 tháng 10 năm 2026, còn model card của nhà cung cấp, README của repository và ghi chú phát hành thì tuyệt nhiên không nêu bất kỳ con số tham số hoạt động nào. Đó không phải là lời chỉ trích tuyên bố ấy cho lắm, mà đúng hơn là một khoảng trống đáng được lấp đầy: bản checkpoint tự nó đã mã hóa câu trả lời. Vậy nên, trước mọi thứ khác ở đây, tôi đã kéo chỉ mục safetensors và toàn bộ header của từng shard thuộc openbmb/MiniCPM-V-4.7-35B-A3B rồi đếm. Để so sánh, model còn lại trong cùng bài đăng đó — Qwen3.8-27B, phát hành ngày 13 tháng 8 năm 2026 — là dạng dense 27B và không có sự mơ hồ nào kiểu ấy cần gỡ: mọi tham số đều hoạt động ở mọi token. Câu hỏi thú vị là liệu "3B hoạt động" có sống sót qua cuộc chạm trán với các trọng số hay không, và câu trả lời là: nó sống sót, nhưng chỉ khi bạn định nghĩa từ "hoạt động" theo cách của nhà cung cấp, và con số trung thực thì gần với 4B hơn một khi bạn tính cả những phần mà bạn không thể tránh chạy.

Sổ cái, được đọc từ chính điểm kiểm tra

Tệp chỉ mục liệt kê 40 lớp ngôn ngữ cộng với một tháp thị giác và một bộ chiếu, tổng cộng 35.212.875.824 tham số ở BF16 — 70,43 GB trọng số cần tải xuống. Điều đó khớp với "35B" trong tên. Câu hỏi về MoE là bao nhiêu phần trong số đó được dùng đến trên mỗi token:

• Tổng đã lưu trữ — 35,21 tỷ tham số, 70,43 GB ở BF16. Mọi chuyên gia đều nằm trên đĩa bất kể có được sử dụng hay không.

• Ngân sách router — 8 chuyên gia được chọn cho mỗi token, trong tổng số 256, trên mỗi lớp MoE. Được cấu hình trong config.json với num_experts_per_tok: 8. Mỗi chuyên gia đều nhỏ: 3,15M tham số.

• Đường MoE mỗi lớp — 8 chuyên gia (25,17M) + một chuyên gia chia sẻ (3,15M) + cổng định tuyến (0,52M) ≈ 28,83M.

• Đường dẫn attention theo từng lớp — kiến trúc là dạng lai: 30 trong số 40 lớp dùng attention tuyến tính (33,72M mỗi lớp), 10 lớp dùng attention đầy đủ (27,26M mỗi lớp). Tổng ≈ 2,44B trên cả 40 lớp cho phần attention cộng với các phép toán MoE, được lặp lại theo mỗi token.

• Cộng thêm những gì bạn không thể bỏ qua — token embeddings 508,2M, LM head 508,2M, vision tower 522,3M, projector 30,7M.

• Hai câu trả lời có thể bảo vệ được — ~2,44B hoạt động chỉ riêng trên nhánh attention và MoE; ~4,01B nếu tính cả embeddings, output head, vision tower và projector, những thứ mà một yêu cầu vision thực sự sử dụng.

Vậy nên "3B active" không sai. Đó là kết quả làm tròn 2.44B lên, và nó nằm trong khoảng trống giữa hai con số ở trên. Chỉ có điều nó không phải là một con số mà OpenBMB đã công bố, và nó không phải là cùng một thứ với hậu tố "A3B" — hậu tố đó là một phần tên của mô hình, và tài liệu của chính nhà cung cấp không bao giờ biến nó thành một phép đo.

Tại sao hậu tố và số không phải là cùng một thứ

Các quy ước đặt tên trong hệ sinh thái trọng số mở ngụ ý một số lượng tham số hoạt động: một mô hình có tên 30B-A3B, hay 235B-A22B, đang cho bạn biết rằng nó kích hoạt khoảng chừng ấy tham số mỗi token. Hàm ý này thường đáng tin cậy — nhưng đó là một quy ước, không phải một cam kết, và MiniCPM-V 4.7 là một trường hợp mà không có gì trong card, README hay bài đăng ra mắt chuyển "A3B" thành một con số mà bạn có thể dựa vào để lập kế hoạch bộ nhớ. Cho đến khi có người đếm, hậu tố chỉ là một nhãn.

Con số ở trên là số học, không phải suy luận từ nhãn đó. Đó cũng là lý do các con số ~2.44B và ~4.01B khác nhau: việc bạn có tính bảng embedding và đầu ra hay không là một quyết định thực sự, không phải chuyện bắt bẻ. Trên một mô hình dense, embedding chỉ chiếm một phần nhỏ trong ngân sách 27B. Trên một mô hình sparse nơi đường tính toán theo mỗi token chỉ có vài tỷ tham số, một bảng embedding 508M và một LM head 508M không còn là nhiễu — cộng lại chúng chiếm khoảng một phần năm đường hoạt động, và chúng được lưu ở độ rộng đầy đủ trong khi các expert được lượng tử hóa.

Một hệ quả đáng nói thẳng ra: tỷ lệ giữa tham số được lưu trữ và tham số hoạt động ở đây là khoảng 8,8:1 theo cách hiểu hẹp. Đó chính là toàn bộ lý do một mô hình 35B có thể được quảng bá như một mô hình điện thoại, và cũng là lý do nó không phải là một mô hình như vậy theo cách một mô hình dense 3B là. Dung lượng lưu trữ không giảm đi khi bộ định tuyến bỏ qua một chuyên gia.

Tuyên bố về iPhone là một tuyên bố riêng biệt với cơ sở bằng chứng riêng biệt.

Mọi thông tin cụ thể về hiệu năng trên thiết bị trong bản phát hành này đều do nhà cung cấp báo cáo và chưa được tái lập. Con số cụ thể là hơn 13 token mỗi giây ở mức khoảng 3 GB bộ nhớ trên iPhone 17 Pro Max, với cùng checkpoint được trình diễn trên iPad M4. OpenBMB cho rằng đó là nhờ ba kỹ thuật phối hợp với nhau — Lập lịch chuyên gia Lookahead, vốn dự đoán định tuyến xuyên lớp và tải trước các chuyên gia, lượng tử hóa theo từng lớp ở mức mịn, và lấy mẫu suy đoán DSpark — và mô tả kết quả là mô hình MoE mã nguồn mở đầu tiên chạy mượt trên thiết bị mà không làm giảm năng lực. Không có đo lường độc lập nào về thông lượng đó trong hồ sơ công khai, không có tái lập từ bên thứ ba, và không có phân tích chi tiết nào được công bố về việc con số 3 GB giả định dùng phương pháp lượng tử hóa nào.

Điều này quan trọng vì một lý do cụ thể: 3 GB là con số quyết định liệu tuyên bố đó có đáng quan tâm với bạn hay không, và đó cũng là con số mà chúng ta biết ít nhất. Một MoE 35B với phần lớn trọng số chuyên gia nằm trên lưu trữ flash không phải là một mô hình 3 GB; nó là một mô hình mà tập làm việc thường trú tình cờ vừa trong 3 GB khi các dự đoán định tuyến, tải trước và bộ nhớ đệm chuyên gia đã lượng tử hóa đều đang làm đúng việc của chúng. Đó chính xác là những điều kiện mà thông lượng trên benchmark và thông lượng thực tế phân kỳ — prompt đầu tiên làm ấm bộ nhớ đệm, và hành vi giúp bạn đạt 13 token mỗi giây trong một bản demo là một lịch trình, chứ không phải một thuộc tính của các trọng số.

Hãy coi 13 token mỗi giây là một tuyên bố về một kỹ thuật, chứ không phải về checkpoint. Checkpoint mới là thứ bạn có thể xác minh ngay hôm nay: 35,21 tỷ được lưu trữ, 8 trong số 256 chuyên gia được định tuyến cho mỗi token, ~2,44 tỷ đến ~4,01 tỷ hoạt động tùy theo cách bạn đếm, Apache-2.0, các bản lượng tử hóa day-0 trong GGUF, AWQ, GPTQ, int4 và FP8, cùng danh sách nhà cung cấp các chip được hỗ trợ bao gồm Rockchip, Houmo, Intel, AMD và Arm.

Số lượng hoạt động quyết định và không quyết định điều gì

Số lượng tham số hoạt động là một đại diện cho năng lực tính toán. Nó cho bạn biết mỗi token thực hiện bao nhiêu phép nhân ma trận, qua đó phản ánh tốc độ giải mã bị giới hạn bởi GPU chạy nhanh đến đâu. Nó không cho bạn biết cần bao nhiêu bộ nhớ để chứa mô hình, vì điều đó do tổng số tham số quyết định — 70,43 GB trọng số BF16, hay khoảng một phần tư con số đó ở 4-bit, trước khi tính đến KV cache. Với một mô hình có ngữ cảnh 256K, bộ đệm đó cũng không phải là thứ có thể xem nhẹ.

• Tốc độ giải mã — được chi phối bởi các tham số hoạt động (~2.44B–4.01B ở đây). Đây là điều mà tuyên bố 13 token/s nói tới.

• Bộ nhớ thường trú — được quy định bởi tổng số tham số (35.21B được lưu trữ), sau đó bị cắt giảm bởi lượng tử hóa và bởi tập chuyên gia nào còn thường trú.

• Lưu trữ và tải — chịu sự chi phối của toàn bộ 70,43 GB ở BF16. Định tuyến thưa không làm giảm dung lượng tải xuống.

• Băng thông, không phải flops — trên điện thoại, ràng buộc quyết định là đưa các expert qua bus bộ nhớ, đó là lý do kỹ thuật lập lịch tồn tại và là lý do chỉ riêng số lượng active không dự đoán được gì về độ trễ trên di động.

Hệ quả thực tế: nếu bạn có một GPU đủ bộ nhớ để chứa các trọng số đã lượng tử hóa, số tham số hoạt động là yếu tố quyết định thông lượng của bạn, và "3B active" là điều tốt. Nếu bạn là lý do khiến cụm từ "chạy trên iPhone" xuất hiện trong một bài đăng, tổng số tham số là con số quyết định tính khả thi, và công việc lập lịch của nhà cung cấp là phần khiến tổng số tham số đó trở nên chấp nhận được. Cả hai cách đọc cùng một tiêu đề đều đúng và chúng không phải là cùng một cách đọc.

So sánh trong bài đăng đó cần hai nhãn, không phải một.

Cách định hình khiến chủ đề này được bàn tán là chạy cục bộ so với phần cứng đắt tiền: MiniCPM-V 4.7 35B-A3B là mô hình mang lại cho bạn cùng năng lực mà không cần dàn máy, đối đầu với Qwen3.8-27B là mô hình thông minh hơn nhưng cần dàn máy. Phần năng lực trong đó đến từ chính model card của Qwen, và đây là số liệu do nhà cung cấp báo cáo giống như mọi thứ khác trên trang này. Các con số Qwen công bố cho Qwen3.8-27B bao gồm 90,3 trên LiveCodeBench v6, 89,2 trên GPQA Diamond, 84,3 trên OSWorld-Verified và 79,0 trên QwenSWEBench, và mục trong danh mục của chúng tôi về nó ghi nhận đó là những kết quả agentic và coding mạnh bất thường đối với một mô hình dense 27B. Việc nó có "thông minh hơn Opus 4.6" hay không là một tuyên bố từ bài đăng trên mạng xã hội, và tôi không có đánh giá độc lập nào trước mắt để phân xử điều đó — nên tôi sẽ không nhắc lại nó như một sự thật.

Sự khác biệt về cấu trúc mới là thứ thực sự có thể kiểm chứng: Qwen3.8-27B là dense, nên toàn bộ 27B tham số của nó đều hoạt động, và lượng bộ nhớ chiếm dụng lẫn chi phí tính toán của nó là cùng một con số. MiniCPM-V 4.7 35B-A3B tách hai con số đó ra xa nhau khoảng chín lần. Đó là toàn bộ lập luận kiến trúc, và nó có thật. Chỉ là nó không giống với một so sánh benchmark, và bài đăng khiến nó nổi tiếng đã trộn lẫn cả hai.

Khi nào bộ định tuyến thay đổi quyết định và khi nào thì không

Có hai điều đúng ở đây và đáng được tách bạch, vì chúng chỉ về hai hướng ngược nhau.

Đầu tiên là chúng tôi không phục vụ MiniCPM-V 4.7. Nó không có trong danh mục của chúng tôi. Nếu bạn muốn dùng nó, con đường là phần cứng của riêng bạn — đó chính xác là mục đích thiết kế của bản phát hành này, với trọng số, lượng tử hóa và hướng dẫn triển khai trên thiết bị được xuất bản kèm theo. Không có gì ở một API được lưu trữ giúp bạn chạy mô hình trên điện thoại, và sẽ là gây hiểu lầm nếu gợi ý điều ngược lại.

Điều thứ hai là mô hình mà mô hình này đang được đem ra so sánh không nằm ở vị trí đó. Qwen3.8-27B có sẵn qua API của chúng tôi, được tự vận hành trên hạ tầng của chính chúng tôi, với mức giá 0,33 đô la cho mỗi triệu token đầu vào và 2,40 đô la cho mỗi triệu token đầu ra. Nếu câu hỏi bạn thực sự đang đặt ra là "liệu tôi có nên thay các lệnh gọi Qwen3.8-27B qua dịch vụ lưu trữ bằng một MiniCPM-V 4.7 triển khai cục bộ hay không", thì câu trả lời trung thực là bạn nên chạy thử nghiệm trước khi cam kết: con số thông lượng trên thiết bị chưa được kiểm chứng lại, và phần so sánh năng lực chỉ dựa trên tài liệu của chính bên kia. Đó chính là tình huống mà failover tồn tại để giải quyết — định tuyến một phần lưu lượng sang một đường dẫn mới, giữ đường dẫn đã được kiểm chứng ở phía sau, và để một tuần tồi tệ chỉ khiến bạn tốn một phần khối lượng công việc thay vì mất cả khối lượng công việc đó. Một mô hình không tăng giá cũng giữ cho phép tính được minh bạch: khi nhà cung cấp thay đổi giá, con số bạn phải trả sẽ thay đổi ngay trong cùng ngày, bởi vì không có lớp biên lợi nhuận nào nằm giữa giá niêm yết của họ và hóa đơn của bạn.

Điều mà một router không thể làm là khiến câu hỏi chạy cục bộ hay chạy trên dịch vụ lưu trữ biến mất. Câu hỏi đó được quyết định bởi phần cứng của bạn, những ràng buộc về quyền riêng tư của bạn và việc liệu một bản tải xuống 70 GB có chấp nhận được hay không — và số lượng tham số hoạt động, dù bạn có làm tròn thế nào, cũng không thay đổi bất kỳ điều nào trong ba yếu tố đó.

Điều gì sẽ giải quyết được nó?

Ba thứ, xếp theo mức độ hữu ích giảm dần. Một con số tham số hoạt động do OpenBMB công bố, để con số mà ai cũng nhắc lại không còn là phép tính của bên thứ ba — kể cả của tôi, và con số của tôi có thể tái lập từ các header shard nếu bạn không đồng ý với nó. Một phép đo độc lập về 13 token mỗi giây trên điện thoại, với các thiết lập lượng tử hóa được nêu rõ, bởi vì một con số phụ thuộc lịch trình mà không có thiết lập của nó thì không phải là một đặc tả. Và một đánh giá thực sự so sánh MiniCPM-V 4.7 35B-A3B với Qwen3.8-27B trên cùng các tác vụ, vì phép so sánh khiến mô hình này trở nên đáng chú ý hiện chỉ là biểu đồ của một nhà cung cấp đối chiếu với bảng thông số của một nhà cung cấp khác.

Cho đến lúc đó, tóm tắt an toàn vẫn hẹp hơn bài đăng: trọng số là thật, độ thưa là thật, bản tải xuống là 70.43 GB, và với mỗi token, mô hình thực hiện khối lượng công việc tương đương từ 2.4 đến 4 tỷ tham số, tùy thuộc vào cách bạn đếm những phần mà bạn không thể định tuyến để né tránh. Đó là một kết quả kỹ thuật thực sự. Nó chưa phải là một benchmark điện thoại được đo đạc, và nó chưa phải là một chiến thắng benchmark trước một mô hình dense 27B.

Nguồn dữ liệu: các tham số, số lượng expert, loại layer, độ dài ngữ cảnh và kích thước tải xuống được đọc trực tiếp từ config.json và phần header của các shard safetensors thuộc openbmb/MiniCPM-V-4.7-35B-A3B vào ngày 13 tháng 10 năm 2026. Tốc độ trên thiết bị, con số bộ nhớ, kết quả benchmark và các số liệu đánh giá Qwen3.8-27B đều do nhà cung cấp báo cáo và chưa được kiểm chứng lại. Các tuyên bố "3B tham số hoạt động" và "thông minh hơn Opus 4.6" bắt nguồn từ một bài đăng mạng xã hội của bên thứ ba, chứ không phải từ bất kỳ nhà cung cấp nào.

Không có điều nào trong số đó là giả thuyết: những thất bại AI và sự cố agent được ghi nhận mà một con số như thế này được trích dẫn trong đó đều được tập hợp trong OrcaRouter AI Incident Archive, nơi mỗi mục mang theo các nguồn, mức độ nghiêm trọng, xếp hạng độ tin cậy và cờ tranh chấp của riêng mình.