Chuyển tới nội dung chính

Chuyên gia hạt mịn và chuyên gia chia sẻ

Mười ô sửa đượcNgân sách đứng yênSố tổ hợp 246 chữ số

Chuyên gia hạt mịn và chuyên gia chia sẻ

Hai ý tưởng luôn đi cùng nhau trong họ DeepSeek. Cắt chuyên gia ra thật nhỏ, rồi tách riêng vài chuyên gia luôn chạy cho mọi token. Cả hai đều là bài toán kế toán, và cả hai đều tính được chính xác tới từng tham số.

Ở bài định tuyến và tham số hoạt động bạn đã thấy ý tưởng gốc của trộn chuyên gia: một lớp có rất nhiều khối feed-forward, nhưng mỗi token chỉ chạy qua vài khối, nên tham số tổngtham số hoạt động tách hẳn ra làm hai con số. Ở bài mất cân bằng tải bạn đã thấy chuyện gì xảy ra khi bộ định tuyến dồn hết token vào vài chuyên gia quen.

Bài này trả lời câu hỏi tiếp theo, và là câu hỏi mà DeepSeek trả lời khác hẳn Mixtral: chuyên gia nên to hay nhỏ, và có nên để dành vài chuyên gia luôn chạy hay không. Hai lựa chọn đó nghe như hai chuyện riêng, nhưng chúng bù nhau, và cái hay là bạn không cần tin lời ai: mở bảng tính bên dưới, sửa số, rồi tự nhìn.

Chuyên gia hạt mịn và chuyên gia chia sẻ · kế toán tham số
Hoạt động 396,36 triệu mỗi lớp · thưa 96,50%
DeepSeek-V3 (671B)số của mô hình có thật
Chuyên gia MoE chỉ rộng 2048 trong khi lớp dày rộng 18432, tức mỗi chuyên gia nhỏ hơn một FFN thường đúng 9 lần. Ba lớp đầu vẫn là FFN dày, 58 lớp còn lại mới là MoE.
Hai preset mang tên mô hình lấy số từ tệp config.json phát hành kèm mô hình, đọc ngày 27/07/2026: DeepSeek-V3 với n_routed_experts 256, n_shared_experts 1, num_experts_per_tok 8, moe_intermediate_size 2048, intermediate_size 18432, hidden_size 7168, num_hidden_layers 61, first_k_dense_replace 3, vocab_size 129280; Mixtral-8x7B-v0.1 với num_local_experts 8, num_experts_per_tok 2, intermediate_size 14336, hidden_size 4096, num_hidden_layers 32. Lĩnh vực này đổi rất nhanh nên hãy coi đây là ảnh chụp một thời điểm: số có thể đã lạc hậu. Mọi tham số dưới đây sửa được, có số mới hơn thì gõ vào là tính lại ngay. Cấu hình thứ ba cố tình không mang tên mô hình nào.
1 · Một chuyên gia nhỏ hơn một FFN thường bao nhiêu lần
KhốiBề rộng trongCông thứcTham số
Một chuyên gia MoE2.0483 × 7168 × 204844.040.19244,04 triệu
Một FFN thường (lớp dày)18.4323 × 7168 × 18432396.361.728396,36 triệu
Tỉ lệ18432 / 2048×9,000
Một chuyên gia ở đây nhỏ hơn một FFN thường 9,000 lần. Con số này chính là độ mịn: càng lớn thì kho chuyên gia càng gồm nhiều mảnh nhỏ. Ba ma trận trong công thức là gate, updown của một khối SwiGLU, cả ba đều cỡ d_model × chiều trong.
2 · Tổng tham số so với tham số hoạt động
KhoảnCách tínhMỗi lớp MoECả 58 lớp MoE
Kho định tuyến, 256 chuyên gia256 × 44.040.19211.274.289.152653,91 tỉ
Chuyên gia chia sẻ, 1 cái1 × 44.040.19244.040.1922,55 tỉ
Bộ định tuyến7168 × 2561.835.008106,43 triệu
Tổng chuyên gia, 257 cái(256 + 1) × 44.040.19211.318.329.344656,46 tỉ
Hoạt động cho một token, 9 chuyên gia(8 + 1) × 44.040.192396.361.72822,99 tỉ
Lớp dày ở đầu: 3 × 396.361.7281.189.085.184
Cả tầng feed-forward của mô hình657.758.617.600 657,76 tỉ
Phần chạy cho một token24.284.495.872 24,28 tỉ
Nhúng vào và ra: 2 × 129.280 × 71681.853.358.080
Chặn dưới cho tổng tham số mô hình659,61 tỉ
Tỉ lệ thưa của kho chuyên gia: 96,4981% nằm im, chỉ 3,5019% chạy cho mỗi token
Tính trên cả tầng feed-forward thì phần chạy là 3,6920%, cao hơn một chút vì lớp dày và bộ định tuyến luôn chạy. Với kho 256 chuyên gia định tuyến và k = 8, số tập chuyên gia mà một token có thể được đưa tới là 409.663.695.276.000, tức 15 chữ số.
3 · Chia mỗi chuyên gia thành m phần và chọn nhiều gấp m lần
mChuyên giaChọn kBề rộngTổng tham sốTham số hoạt độngSố tổ hợp C(n, k)số chữ số
×1gốc256+ 1 chia sẻ82.04811.318.329.344396.361.728409.663.695.276.00015
×2512+ 2 chia sẻ161.02411.318.329.344396.361.7288,411 × 10^2930
×41.024+ 4 chia sẻ3251211.318.329.344396.361.7284,975 × 10^6061
×82.048+ 8 chia sẻ6425611.318.329.344396.361.7282,453 × 10^122123
×164.096+ 16 chia sẻ12812811.318.329.344396.361.7288,414 × 10^245246
Đây là điểm chính của cả bài. Hai cột giữa không nhúc nhích một đơn vị nào khi m đổi: chia mỗi chuyên gia thành m phần rồi tăng k lên m lần thì k × m × 3 × d_model × (w / m) rút gọn lại đúng bằng k × 3 × d_model × w. Cùng ngân sách tính, cùng ngân sách bộ nhớ, nhưng cột số tổ hợp thì nhảy từ 15 chữ số lên 246 chữ số.
Cách hiển thị đã đổi giữa chừng, tôi nói rõ chứ không giấu. Số tổ hợp vượt qua 9.007.199.254.740.991, tức mốc mà một số dấu phẩy động 64 bit còn gọi tên được từng số nguyên. Từ mốc đó trở lên tôi tính bằng số nguyên lớn rồi in ra dạng khoa học, lấy bốn chữ số đầu và cắt bỏ phần sau chứ không làm tròn. Cột cuối là số chữ số thập phân của giá trị chính xác, nên nó vẫn so sánh được.
4 · Ba cách cắt cùng một ngân sách tham số hoạt động
Thiết kếKhoChọnBề rộngTổng tham sốTham số hoạt độngTỉ lệ thưaSố tổ hợpLần nạpBộ định tuyến
Thô · ít chuyên gia to32116.38411.274.289.152352.321.53696,875%321mỗi lần 352,32 triệu229.376
Mịn · nhiều chuyên gia nhỏ25682.04811.274.289.152352.321.53696,875%409.663.695.276.0008mỗi lần 44,04 triệu1.835.008
Mịn + chia sẻ255+ 1 chia sẻ72.04811.274.289.152352.321.53696,875%12.801.990.477.3758mỗi lần 44,04 triệu1.827.840
Đọc bảng này cẩn thận. Cả ba dòng được chuẩn hoá về cùng một ngân sách, nên dòng thứ ba phải trả cho chuyên gia chia sẻ bằng đúng bấy nhiêu suất định tuyến: nó có 255 chuyên gia định tuyến và chọn 7, chứ không phải cấu hình bạn đặt ở trên, nơi chuyên gia chia sẻ là suất cộng thêm. Đổi lại, nó là dòng duy nhất có chỗ chứa kiến thức phổ thông mà mọi token đều dùng. Cái giá đo được ngay trong bảng: số tổ hợp của dòng ba nhỏ hơn dòng hai, vì kho định tuyến đã bị lấy bớt.
5 · Cái giá của hạt mịn mà sim này đo được
Số lần nạp trọng số chuyên gia cho một token, mỗi lớp MoE9
Cả 58 lớp MoE522
Kích thước mỗi lần nạp44.040.192 44,04 triệu
Số chuyên gia bộ định tuyến phải xếp hạng, mỗi lớp256
Cả một token đi hết mô hình14.848
Tổng số byte trọng số phải kéo về cho một token không đổi khi chia nhỏ, nhưng nó bị xé thành nhiều lần nạp nhỏ hơn: ở bảng mục 3, m tăng gấp đôi thì số lần nạp gấp đôi còn mỗi lần nạp nhỏ đi một nửa. Phần cứng thích ít lần nạp to hơn là nhiều lần nạp bé, nên đây là chỗ hạt mịn phải trả tiền. Cột bộ định tuyến trong bảng mục 4 là cái giá thứ hai: ma trận cổng cỡ d_model × n nên nó lớn lên đúng m lần khi kho chuyên gia mịn ra, và bộ định tuyến cũng phải xếp hạng gấp m lần số mục.
Sim này không đo được cái gì. Phép đếm tham số ở đây chính xác từng đơn vị, và số tổ hợp C(n, k) cũng là con số đúng chứ không phải ước lượng. Nhưng số tổ hợp lớn không có nghĩa mô hình dùng hết chúng: bộ định tuyến được huấn luyện thường dồn về một số tổ hợp quen thuộc, và số tổ hợp thực sự xuất hiện trong một lần chạy nhiều nhất cũng chỉ bằng số token bạn đưa vào. Con số C(n, k) kích thước không gian chọn, không phải bằng chứng về chất lượng.
Câu hỏi thật sự thì sim không trả lời được: chia nhỏ chuyên gia có làm mô hình chuyên môn hoá tốt hơn hay không, và tách riêng chuyên gia chia sẻ có bớt trùng lặp thật hay không. Cả hai đều là câu hỏi phải huấn luyện mới biết: ta phải luyện hai mô hình cùng ngân sách rồi so điểm, chứ không có phép nhân chia nào ở đây kết luận thay được. Lý do người ta tin vào hai ý tưởng này nằm trong các báo cáo thực nghiệm, không nằm trong bảng trên. Ngoài ra, phép đếm ở đây bỏ qua mọi thứ ngoài tầng feed-forward: chú ý, chuẩn hoá, độ lệch định tuyến, nên dòng chặn dưới đúng nghĩa là chặn dưới, thấp hơn con số tổng tham số mà nhà phát hành công bố, và khoảng cách đó chính là phần sim không mô hình hoá. Ô nhúng cũng là một ước lượng thô: tôi đếm hai ma trận, vào và ra, nên nếu một mô hình dùng chung trọng số cho hai đường đó thì con số này đang cao hơn thực tế đúng một ma trận.

Chuyên gia của DeepSeek nhỏ tới mức nào

Mở trang ra là cấu hình DeepSeek-V3. Nhìn bảng mục 1 trước, vì nó là chỗ dễ bị bỏ qua nhất.

Một chuyên gia MoE của V3 có chiều trong là 2048. Cũng mô hình đó, ở ba lớp đầu chưa dùng MoE, một khối feed-forward thường có chiều trong là 18432. Cả hai con số đều đọc thẳng từ tệp config.json, trường moe_intermediate_size và trường intermediate_size. Chia ra là đúng 9 lần. Đổi sang tham số, một chuyên gia là 3 × 7168 × 2048 bằng 44.040.192, còn một khối dày là 3 × 7168 × 18432 bằng 396.361.728, vẫn đúng tỉ lệ 9. Số 3 ở đây là ba ma trận gate, updown của một khối SwiGLU.

Đó chính là hạt mịn. Mixtral thì ngược lại: chọn preset Mixtral ở thanh trên và nhìn lại đúng ô đó, tỉ lệ tụt về 1, vì intermediate_size của Mixtral là 14336 và chuyên gia của nó cũng rộng đúng 14336. Một chuyên gia Mixtral một khối feed-forward đầy đủ. Một chuyên gia DeepSeek chỉ là một mảnh bằng một phần chín.

Có một con số vui ở bảng mục 2 mà bạn nên tự kiểm: 8 chuyên gia định tuyến cộng 1 chuyên gia chia sẻ là 9, và 9 × 2048 bằng 18432, đúng bằng chiều trong của lớp dày. Nghĩa là mỗi token đi qua một lớp MoE của V3 kích hoạt đúng bằng một khối feed-forward thường, không hơn. Tôi không biết đây có phải chủ ý của nhóm thiết kế hay không, và bài này không đoán chuyện đó, nhưng phép tính thì đúng và nó nói cho bạn biết ngân sách tính toán mỗi lớp được giữ ở mức nào.

Điểm chính: chia nhỏ mà ngân sách không đổi

Bảng mục 3 là trái tim của bài. Nó làm một việc rất đơn giản: cắt mỗi chuyên gia thành m phần rồi cho mỗi token chọn nhiều gấp m lần.

Lý do ngân sách không đổi chỉ là một phép rút gọn. Trước khi cắt, phần hoạt động là k chuyên gia rộng w, tức k × 3 × d_model × w tham số. Sau khi cắt, ta có k × m chuyên gia rộng w / m, tức k × m × 3 × d_model × w / m. Hai chữ m triệt tiêu nhau. Không phải xấp xỉ, không phải gần bằng, mà là bằng đúng tới từng đơn vị.

Nhìn hai cột giữa của bảng khi bạn đổi m: cột tổng tham số đứng im ở 11.318.329.344 và cột tham số hoạt động đứng im ở 396.361.728, dù số chuyên gia đi từ 256 lên 4096 và bề rộng đi từ 2048 xuống 128. Cổng kiểm số của bài khẳng định đúng điều này trên 972 cấu hình khác nhau, và một đột biến chỉ cần làm sai một đơn vị là cổng đỏ ngay.

Còn cột cuối thì không đứng im chút nào:

mChuyên gia định tuyếnChọn kSố tổ hợp C(n, k)Số chữ số
12568409.663.695.276.00015
2512168,411 × 10^2930
41024324,975 × 10^6061
82048642,453 × 10^122123
1640961288,414 × 10^245246

Cùng một ngân sách tính toán, cùng một ngân sách bộ nhớ, mà số cách chọn tập chuyên gia đi từ mười lăm chữ số lên hai trăm bốn mươi sáu chữ số. Đó là toàn bộ lý lẽ của hạt mịn: cùng số tham số chạy, nhưng số cách phối hợp chúng nhiều hơn hẳn, nên mô hình có nhiều đường hơn để chuyên môn hoá.

Chú ý một chi tiết kỹ thuật mà tôi cố ý không giấu: từ dòng m bằng 2 trở đi, bảng đổi cách hiển thị. Số tổ hợp vượt qua 9.007.199.254.740.991, tức mốc mà một số dấu phẩy động 64 bit còn gọi tên được từng số nguyên, nên tính bằng kiểu số thường từ đó trở đi là sai âm thầm. Sim tính bằng số nguyên lớn rồi in ra dạng khoa học, lấy bốn chữ số đầu và cắt bỏ phần sau chứ không làm tròn. Cột số chữ số thì luôn đếm trên giá trị chính xác. Nếu một ngày bạn thấy một bảng tính nào đó in ra Infinity ở chỗ này thì bạn đã biết nó hỏng ở đâu.

Hạt mịn không miễn phí

Sim đo được hai cái giá, và cả hai đều nằm trong bảng.

Trọng số bị xé nhỏ. Tổng số byte trọng số phải kéo về cho một token không đổi, nhưng số lần nạp thì nhân lên. Ở m bằng 1, mỗi token nạp 9 lần, mỗi lần 44.040.192 tham số. Ở m bằng 16, nó nạp 144 lần, mỗi lần 2.752.512. Phần cứng thích ít lần nạp to hơn nhiều lần nạp bé, nên đây là chỗ hạt mịn trả tiền bằng thông lượng thật.

Bộ định tuyến phình ra. Ma trận cổng có cỡ d_model × n, nên nó lớn lên đúng m lần: từ 1.835.008 ở m bằng 1 lên 29.360.128 ở m bằng 16. Và mỗi token, mỗi lớp, bộ định tuyến phải cho điểm rồi xếp hạng gấp m lần số mục. Ở cấu hình mặc định thì đó đã là 14.848 lượt xếp hạng cho một token đi hết mô hình.

Chuyên gia chia sẻ, và cái giá của nó ở ngân sách cố định

Ý tưởng thứ hai đơn giản tới mức dễ bị coi thường: để dành một hoặc vài chuyên gia luôn chạy cho mọi token, không qua định tuyến.

Lý do là chuyện trùng lặp. Có những thứ mọi token đều cần: cấu trúc câu, quy tắc chính tả, kiến thức phổ thông. Nếu tất cả chuyên gia đều đi qua đường định tuyến thì chuyên gia nào cũng phải học lại phần chung ấy, và ngân sách tham số bị tiêu vào việc lặp đi lặp lại cùng một kiến thức. Tách phần chung ra một chỗ luôn bật thì các chuyên gia còn lại rảnh tay để chuyên biệt hoá.

Bảng mục 4 đo cái giá của việc đó, và nó là bảng dễ đọc sai nhất trên trang nên tôi nói trước cách đọc. Cả ba dòng được chuẩn hoá về cùng một ngân sách: tổng 11.274.289.152 tham số và hoạt động 352.321.536 tham số, giống hệt nhau ở cả ba. Vì ngân sách cố định nên dòng thứ ba phải trả cho chuyên gia chia sẻ bằng đúng một suất định tuyến: nó có 255 chuyên gia định tuyến và chọn 7, chứ không phải cấu hình V3 bạn đang đặt ở trên, nơi chuyên gia chia sẻ là suất cộng thêm.

Thiết kếKhoChọnBề rộngSố tổ hợp
Thô3211638432
Mịn25682048409.663.695.276.000
Mịn cộng chia sẻ255 định tuyến, 1 chia sẻ7204812.801.990.477.375

Đọc dòng cuối: dành ra một chuyên gia chia sẻ làm số tổ hợp nhỏ đi đúng 32 lần. Con số 32 không phải ngẫu nhiên, nó là 256 / 8, vì C(n, k) chia cho C(n-1, k-1) luôn bằng n / k. Đó là cái giá đo được: bạn đổi một phần không gian phối hợp lấy một chỗ chứa kiến thức chung không bị nhân bản. Còn nó có đáng hay không thì bảng này không trả lời, và tôi sẽ nói rõ ở mục dưới.

Con số toàn cục, và một phép đối chiếu tự làm được

Kéo xuống khối tổng ở mục 2. Với DeepSeek-V3, cả tầng feed-forward là 657.758.617.600 tham số, trong đó phần chạy cho một token là 24.284.495.872. Tức là 96,31% kho chuyên gia nằm im ở mỗi bước sinh, tính theo THAM SỐ: 1 − 24.284.495.872 / 657.758.617.600. Đếm theo ĐẦU CHUYÊN GIA thì ra một số khác, 1 − 9/257 bằng 96,50%, vì các chuyên gia không bằng nhau về kích thước. Hai con số này trả lời hai câu hỏi khác nhau và không được trộn vào nhau. Đó là ý nghĩa thật của chữ "thưa" trong trộn chuyên gia, và nó là lý do một mô hình 671 tỉ tham số vẫn sinh chữ được với giá của một mô hình nhỏ hơn nhiều.

Cộng thêm ước lượng nhúng vào và ra, 2 × 129280 × 7168 bằng 1.853.358.080, ta được 659.611.975.680, tức khoảng 659,61 tỉ. Con số công bố của V3 là 671 tỉ. Khoảng cách chừng 11,39 tỉ chính là phần sim này không mô hình hoá: toàn bộ khối chú ý, các lớp chuẩn hoá, độ lệch của bộ định tuyến và những phần phụ khác. Nên hãy đọc dòng đó đúng như tên của nó, một chặn dưới. Nếu bạn tính ra một con số lớn hơn số công bố thì chắc chắn có chỗ sai, còn nhỏ hơn một chút thì hợp lý.

Làm y hệt với Mixtral: chặn dưới 45,36 tỉ so với con số công bố 46,7 tỉ, và tỉ lệ thưa là đúng 75%, vì nó chọn 2 trong 8. Số tổ hợp của Mixtral là C(8, 2) bằng 28. Hai mươi tám. So với bốn trăm nghìn tỉ của V3. Cùng một cơ chế, hai triết lý khác nhau, và bây giờ bạn có thể đặt chúng cạnh nhau bằng số chứ không bằng cảm giác.

Sim này không nói được gì

Đây là phần quan trọng nhất của bài, nên đọc kỹ.

Phép đếm ở đây chính xác, nhưng nó chỉ là phép đếm. Số tham số đúng tới từng đơn vị, số tổ hợp C(n, k) là giá trị đúng chứ không phải ước lượng. Nhưng số tổ hợp lớn không có nghĩa mô hình dùng hết chúng. Bộ định tuyến sau khi huấn luyện thường dồn về một số tổ hợp quen thuộc, và dù nó có phân bố đều đi nữa thì số tổ hợp thực sự xuất hiện trong một lần chạy nhiều nhất cũng chỉ bằng số token bạn đưa vào. Một mô hình xử lý một nghìn tỉ token trong cả đời nó cũng không chạm nổi một phần rất nhỏ của con số 123 chữ số kia. C(n, k)kích thước không gian chọn, không phải bằng chứng chất lượng, và bất kỳ ai dùng nó như bằng chứng chất lượng đều đang bán cho bạn một câu chuyện.

Hai câu hỏi thật thì sim không trả lời được. Chia nhỏ chuyên gia có làm mô hình chuyên môn hoá tốt hơn thật không. Tách riêng chuyên gia chia sẻ có bớt trùng lặp thật không. Cả hai đều phải huấn luyện mới biết: phải luyện hai mô hình cùng ngân sách rồi so điểm trên cùng bộ đánh giá. Không có phép nhân chia nào trên trang này kết luận thay được, và bài này cố ý không kể lại kết luận của bất kỳ báo cáo nào như thể nó là hệ quả của bảng tính. Lý do người ta tin vào hai ý tưởng này nằm trong các thí nghiệm ablation, không nằm trong bảng trên.

Vài đơn giản hoá nữa cần nói thẳng. Một chuyên gia ở đây được đếm là ba ma trận SwiGLU, nên nếu một mô hình dùng kiểu feed-forward khác thì hệ số 3 phải đổi. Ô nhúng đếm hai ma trận, vào và ra, nên với mô hình dùng chung trọng số cho hai đường đó thì chặn dưới đang cao hơn thực tế đúng một ma trận. Bảng chỉ đếm tầng feed-forward, không đếm chú ý. Cột số lần nạp là một mô hình rất thô của chi phí phần cứng: nó đếm số lần nạp và kích thước mỗi lần, chứ không mô phỏng bộ nhớ đệm, không mô phỏng gộp lô, và không biết gì về việc nhiều token trong một lô có thể dùng chung một chuyên gia. Nó đủ để thấy chiều của sự đánh đổi, không đủ để dự đoán thông lượng.

Vài chỗ dễ vấp

  • Chia nhỏ không phải là cắt giảm. Cả tổng tham số lẫn tham số hoạt động đều không đổi. Thứ duy nhất đổi là số cách phối hợp, cộng với hai cái giá về phần cứng và bộ định tuyến. Ai nói chia nhỏ giúp mô hình nhẹ đi là đang nhầm với chuyện khác.
  • Chuyên gia chia sẻ không nằm trong C(n, k). Nó luôn chạy nên không có lựa chọn nào để đếm. Trong bảng mục 3 nó cũng bị chia nhỏ theo m như mọi chuyên gia khác, đó là lý do cột chia sẻ đi 1, 2, 4, 8, 16 cùng nhịp.
  • C(n, 0) bằng 1 chứ không bằng 0. Đặt k về 0 rồi nhìn: có đúng một cách chọn tập rỗng. Đây là chỗ nhiều người viết sai công thức mà không ai phát hiện, vì nó chỉ lộ ra ở đúng ca biên.
  • Chiều trong phải chia hết cho m. Đặt m bằng 3 với chiều trong 2048 thì sim báo dư 2 và để trống dòng đó, chứ không làm tròn. Làm tròn ở đây sẽ đổi ngân sách tham số mà bạn không hay biết, và đó đúng là loại lỗi âm thầm mà cả môn này đang cố tránh.
  • Preset mang tên mô hình là ảnh chụp một thời điểm. Số của DeepSeek-V3 và Mixtral-8x7B-v0.1 đọc từ config.json phát hành kèm mô hình, ngày 27/07/2026. Lĩnh vực này đổi rất nhanh nên hãy tự đối chiếu lại. Cấu hình thứ ba cố tình không mang tên mô hình nào, nó chỉ là số tròn để tính tay.
Điều rút ra

Chia mỗi chuyên gia thành m phần rồi chọn nhiều gấp m lần thì tham số hoạt động không đổi một đơn vị nào, vì hai chữ m triệt tiêu trong k × m × 3 × d_model × w / m. Cái đổi là số tổ hợp C(n, k), và nó nổ rất nhanh. Cái mất là số lần nạp trọng số và kích thước bộ định tuyến, cả hai đều nhân lên m lần. Chuyên gia chia sẻ là ý tưởng bù: gom kiến thức chung vào một chỗ luôn bật để các chuyên gia còn lại không phải học lại, và ở ngân sách cố định nó tốn đúng một suất định tuyến. Còn chuyện cả hai có làm mô hình tốt hơn thật hay không thì chỉ huấn luyện mới trả lời được, bảng tính này thì không.

Câu hỏi tự kiểm0/3 đúngchưa trả lời
  1. 1Một lớp MoE có 64 chuyên gia, mỗi chuyên gia chiều trong 2048, mỗi token chọn k = 4. Bạn chia mỗi chuyên gia thành 4 phần, thành 256 chuyên gia chiều trong 512, và cho chọn k = 16. Tham số hoạt động mỗi lớp thay đổi thế nào?
  2. 2Ở bảng mục 3, chia nhỏ làm số tổ hợp đi từ 15 chữ số lên 123 chữ số trong khi tham số hoạt động đứng yên. Kết luận nào là kết luận đúng?
  3. 3Trong bảng ba dòng cùng ngân sách, dòng mịn cho C(256, 8) bằng 409.663.695.276.000, còn dòng mịn cộng chia sẻ cho C(255, 7) bằng 12.801.990.477.375, nhỏ hơn đúng 32 lần. Vì sao lại đúng 32?

Đi tiếp

Bạn vừa thấy ba con số của một lớp MoE tách hẳn nhau ra: tham số tổng, tham số hoạt động, và số tổ hợp chọn được. Chỉ hai con số đầu là chi phí thật, con số thứ ba là không gian thiết kế. Quay lại định tuyến và tham số hoạt động nếu bạn muốn xem lại vì sao hai con số đầu tách nhau, và sang mất cân bằng tải để thấy vì sao một kho 256 chuyên gia không tự động nghĩa là 256 chuyên gia đều có việc làm. Hạt mịn càng cao thì bài toán cân bằng tải càng khó, và đó là mối liên hệ trực tiếp giữa hai bài.