Kiến trúc DeepSeek V4

Đọc thêm một chữ, mô hình ngôn ngữ phải ngoái lại tất cả những chữ nó đã đọc. Chữ thứ mười ngoái lại chín chữ. Chữ thứ chín trăm nghìn ngoái lại gần chín trăm nghìn chữ. Ba câu đó là toàn bộ lý do ngữ cảnh dài ngốn máy tới thế: mỗi chữ thêm vào bắt máy làm thêm một mớ phép tính, và bắt nó giữ lại thêm một mớ bộ nhớ.

Gỡ kiến trúc DeepSeek-V4 ra thì thấy nó chỉ là mấy cách khác nhau để trả lời đúng một câu: lần này ngoái lại bao nhiêu thì đủ.

Câu hỏi ấy già đúng bằng cơ chế đẻ ra nó. Cả hai cùng xuất hiện năm 2017, trong cùng một bài báo. Từ đó tới giờ mỗi đời mô hình lại gọt đi một ít, và V4 gọt tiếp rồi dừng ở một chỗ mà chính người viết ra nó nói là chưa hiểu.

Một agent phải nhớ 300 file

Thả một chương trình vào kho mã nguồn 300 file rồi bảo nó đi tìm. Nó tự mở file, tự chạy lệnh, tự đọc kết quả, rồi tự quyết mở tiếp cái gì. Loại chương trình chạy một mạch không chờ ai bấm nút như thế thì người ta gọi là agent. Năm trăm bước sau, bạn hỏi nó một câu mà đáp án nằm trong đúng cái file nó mở ở bước một.

Năm trăm bước tương tác với ngữ cảnh 512 nghìn token chính là thiết lập DeepSeek dùng để chấm điểm agent của chính họ, ghi ở trang 37 ^[1].

Muốn trả lời được, chương trình phải còn giữ được thứ nó đọc ở bước một. Giữ nổi hay không thì quy về hai con số: mỗi chữ mới bắt máy làm thêm bao nhiêu phép tính, và cần thêm bao nhiêu bộ nhớ để khỏi quên. Cứ để tình huống này trong đầu.

Năm 2017: thứ làm nó mạnh cũng là thứ làm nó nặng

Trước hết, mô hình đọc token chứ không đọc chữ. Token là mẩu chữ cắt sẵn, cỡ vài ký tự tới một từ. Ở đây thì bạn cứ hiểu token là một từ, sai lệch chả đáng bao nhiêu.

Cơ chế đẻ ra mọi mô hình ngôn ngữ hiện nay tên là attention, công bố năm 2017 ^[2]. Nôm na là: Token mới xuất hiện, nó gửi một câu hỏi ngược về mọi token đã đi qua trước đó. Mỗi token cũ đáp lại bằng một điểm số, tức mức độ nó dính dáng tới câu đang hỏi. Rồi mô hình trộn nội dung các token cũ theo đúng tỷ lệ điểm ấy, và mớ trộn ra chính là thứ nó dùng để hiểu token mới.

\[\mathrm{Attention}(Q, K, V) = \mathrm{softmax}\!\left(\frac{QK^\top}{\sqrt{d_k}}\right)V\]

\(Q\) là câu hỏi của token đang xét, \(K\) là phần để được tìm thấy của các token cũ, \(V\) là nội dung của chúng. Tích \(QK^\top\) chính là bảng điểm, softmax biến đổi lại sao cho tổng mỗi token cộng lại bằng 1 (để chuyển đổi nó thành dạng %), rồi nhân với \(V\) là bước trộn. Còn \(\sqrt{d_k}\) dưới mẫu người ta thêm vào bằng tay cho bảng điểm khỏi quá gắt.

Bạn thấy chứ?

Chỗ mạnh nằm ở chữ "mọi". Token thứ chín trăm nghìn vẫn biết và giữ quan hệ với token đầu tiên, không bị pha loãng dọc đường. Mấy kiến trúc trước nó không làm được chuyện đó, và đấy là lý do mô hình ngôn ngữ đọc nổi văn bản dài.

Chỗ nặng cũng nằm ở đúng chữ "mọi". Token mới hỏi lại tất cả token cũ, nên số câu hỏi phải đáp phình lên cùng chiều dài của văn bản (chính là chiều dài context length trong model). Mà muốn đáp thì mọi token cũ phải còn nằm đâu đó trong bộ nhớ. Cơ chế này rất mạnh mẽ nhưng cũng rất cồng kềnh, và đó là lý do ngữ cảnh dài ngốn Ram tới vậy.

ở bước một nó hỏi lại vài nghìn token, ở bước năm trăm nó cũng hỏi lại vài trăm nghìn. Rất tốn tài nguyên tính toán.

Phép tính và bộ nhớ

Phép tính là thứ dễ thấy hơn. Mỗi token mới hỏi lại mọi token cũ, nên tổng số phép tính cho cả văn bản tăng theo bình phương chiều dài. Văn bản dài gấp mười thì riêng phần attention tốn gấp một trăm.

Bộ nhớ thì khó thấy hơn. Mỗi token đi qua đều để lại một bản ghi, để các token sau còn quay về tra lại nó. Bản ghi đó gọi là một entry, và chỗ chứa tất cả entry gọi là KV cache, một cuốn sổ mà mỗi token thêm vào một dòng.

Cuốn sổ này dày thêm đều đặn: đọc gấp đôi số token thì nó dày gấp đôi, chứ không phình theo bình phương như phép tính. Nhưng nó có một tật mà phép tính không có. Phép tính xong một bước là xong, còn entry thì nằm lại. Suốt năm trăm bước của con agent kia, cuốn sổ chỉ có dày thêm, không một lần nào mỏng đi.

Nó là như này:

\[C(L) \;\propto\; L^{2}, \qquad M(L) \;\propto\; L\]

\(L\) là số token đã đọc, \(C\) là phép tính phần attention phải làm, \(M\) là chỗ KV cache chiếm. Bảng điểm \(QK^\top\) có \(L\) hàng và \(L\) cột nên \(C\) mang số mũ hai, còn KV cache chỉ dài thêm mỗi token một dòng nên \(M\) mang số mũ một. Mọi mẹo trong V4 đều là cách kéo một trong hai xuống: có cái hạ hẳn số mũ, có cái chỉ cắt bớt hằng số nhân đằng trước.

Trong phần tóm tắt của báo cáo, ở ngữ cảnh một triệu token, bản DeepSeek-V4-Pro chỉ cần 27% số phép tính cho mỗi token và 10% dung lượng KV cache. Bản nhỏ hơn, DeepSeek-V4-Flash, xuống còn 10% phép tính và 7% KV cache ^[1].

Mấy chỗ dễ hiểu nhầm:

Hai con số ấy không thuộc về cùng một mô hình. Số 10% xuất hiện hai lần trong cùng một đoạn với hai nghĩa khác hẳn nhau: nó vừa là KV cache của bản Pro, vừa là phép tính của bản Flash.

Mốc so sánh cũng không phải một mô hình attention thông thường, mà là DeepSeek-V3.2 ^[3], tức đời trước của chính họ. Muốn so với loại thông thường thì phải lật sang trang 13 của bài nghiên cứu, và con số ở đó khác hẳn: chi phí attention của V4 vào khoảng 2% ^[1].

DeepSeek cho các tham số chuyên gia chạy ở định dạng số bốn bit (FP4), chính họ viết rằng trên phần cứng hiện có, nhân bốn bit với tám bit chỉ nhanh đúng bằng nhân tám bit với tám bit. Phần lợi thêm một phần ba là thứ về lý thuyết làm được, trên phần cứng tương lai. Chưa tồn tại. Hay nói chính xác hơn là chưa hoàn thiện để công bố, GPU của Trung Quốc.

2019 tới 2026: ba mẹo V4 không tự nghĩ ra

V4 không bắt đầu từ số không. Trang 7 liệt kê những gì họ bê nguyên từ đời V3 ^[4]: cách chia mô hình thành một nhóm chuyên gia (mixture-of-experts) mà mỗi token chỉ đánh thức vài người trong đó thay vì dựng cả nhóm dậy ^[5], và cách cho mô hình đoán trước nhiều token một lúc. Hai thứ đó có sẵn rồi, mình bỏ qua.

Cả ba mẹo đều có tiền lệ trước V4.

Key và value gộp làm một. Kiến trúc gốc để mỗi entry mang hai thứ tách rời. Một phần để được tìm thấy, giống chữ ghi trên gáy hộp hồ sơ, gọi là key. Một phần chứa nội dung thật, gọi là value. Ai làm lập trình thì cứ hình dung đúng cái dictionary. Tìm bằng phần trước, đọc ra phần sau. Ý tưởng cắt bớt chỗ này có từ một bài báo năm 2019 ^[6], DeepSeek-V4 chỉ đẩy nó tới mức cực đoan hơn: mỗi entry nén xuống còn đúng một dãy số, vừa là gáy hộp vừa là ruột hộp. Chọn được cái nào thì chính cái đó là thứ đọc ra. Bộ nhớ mỗi entry giảm một nửa, đổi lại mô hình mất một bậc tự do. Nó không còn cách nào làm cho một entry dễ tìm vì lý do này mà lại chứa nội dung kia. Dấu để tìm và thứ tìm được giờ là một.

128 chữ gần nhất được miễn nén. Mấy cơ chế nén ở trên chỉ làm việc trên các khối đã nén xong, nên mấy chữ vừa mới xuất hiện thì không cơ chế nào nhìn thấy: chúng còn đang nằm trong một khối chưa gom đủ. Mà trong ngôn ngữ, mấy chữ ngay trước đó thường lại là mấy chữ quan trọng nhất. DeepSeek gắn thêm một nhánh phụ gọi là cửa sổ trượt (sliding window), giữ nguyên xi 128 token gần nhất, không nén gì hết, và mọi tầng đều đọc thẳng vào đó. Đổi lại thì có thêm một nhánh phải chạy và một chỗ phải lưu, ở mọi tầng và mọi bước, kể cả những lúc phần gần chẳng có gì đáng đọc.

Quyền không nhìn gì cả. Attention kiểu gốc bắt mỗi token chia hết 100% phần attention của nó cho các token trước. Tổng luôn bằng một. Nếu thật sự chẳng có gì đáng nhìn, nó vẫn phải đổ chỗ đó vào đâu đấy, và thường là đổ vào vài token đầu văn bản, biến mấy token vô nghĩa ấy thành cái chậu hứng. Hiện tượng này được đặt tên từ năm 2024, trước V4 ^[7]. DeepSeek lấy lại ý đó, và họ mô tả hệ quả ở trang 13: kỹ thuật này cho phép tổng điểm attention của mỗi đầu đọc khác 1, thậm chí gần bằng 0 ^[1]. Dấu bằng bị nới thành dấu bé hơn:

\[\sum_{j} a_{ij} = 1 \qquad \longrightarrow \qquad \sum_{j} a_{ij} \le 1\]

\(a_{ij}\) là phần attention mà token \(i\) rót cho token \(j\), và vế phải giờ có khi gần bằng không. Nói bình dân là mô hình được quyền trả lời rằng bước này tôi chả cần nhìn lại gì cả. Với một triệu token thì quyền đó rất đáng kể, vì phần lớn token thật sự chẳng liên quan gì tới nhau. Chỗ mất là từ giờ mô hình phải mang theo một mục giả không ứng với chữ nào trong văn bản, ở mọi tầng và mọi bước, và câu hỏi nó đã nhìn vào đâu không còn trả lời được bằng cách cộng cho đủ 100% nữa.

Năm 2026: dài bao nhiêu cũng chỉ đọc 1024 entry

Hai cơ chế chính của V4 mang hai cái tên do chính họ đặt, không có tiền lệ nào mang tên đó. Cái đầu tiên là attention nén thưa (Compressed Sparse Attention), và mình gọi tầng dùng nó là tầng nén thưa cho gọn.

Tầng nén thưa làm hai việc nối đuôi nhau.

Gom trước. Cứ bốn token liên tiếp thì ép lại thành một entry, thay vì giữ cả bốn. Đây không phải phép lấy trung bình máy móc, mô hình tự học xem trong bốn token đó cái nào đáng giữ hơn. Riêng bước này số entry đã bớt đi bốn lần.

Lọc sau. Gom xong rồi thì số entry vẫn còn nhiều quá. Tầng nén thưa gắn thêm một bộ phận nhỏ, việc duy nhất của nó là chấm điểm thật nhanh xem với token đang xét thì entry nào đáng đọc. Nó lấy đúng 1024 cái điểm cao nhất, còn lại bỏ hết ^[1]. Con số 1024 là của bản Pro, bản Flash lấy 512.

Phần lọc này chả phải đồ mới. Nó vốn là cơ chế chọn thưa DeepSeek đã công bố ở đời V3.2, dùng lại gần như nguyên xi ^[3]. Cái mới của V4 là ghép nó với bước gom ở trên, rồi ghép tiếp với cơ chế thứ hai ở mục sau.

Ghép gom với lọc lại thì số lần tra cứu của một tầng nén thưa là

\[n_{\text{CSA}}(L) = \min\!\left(1024,\; \left\lceil L/4 \right\rceil\right)\]

CSA là viết tắt tên riêng của tầng này trong báo cáo, còn \(n\) là số entry nó thật sự phải mở ra đọc. Dưới bốn nghìn token, gom bốn xong vẫn chưa đủ 1024 entry nên nó đọc hết. Qua mốc đó thì vế 1024 thắng và đứng yên mãi mãi: một triệu token hay mười triệu token thì vẫn đúng 1024 lần tra cứu. Đường cong bình phương ở mục trên, riêng ở tầng này, bị bẻ thành một đường nằm ngang từ đúng chỗ ấy.

Rủi ro nằm ở bộ chấm điểm. Nó mà chọn nhầm thì thông tin cần thiết nằm ngoài 1024 entry kia sẽ không bao giờ được nhìn tới, và chả có bước hai nào để sửa. Ở đây có luôn câu trả lời cho một hiểu lầm khá phổ biến: một triệu token không có nghĩa là mô hình nhớ hết một triệu token. Ở tầng nén thưa, nó cố ý không nhìn gần hết.

Con agent 300 file: ép ba trăm file thành entry thì ra một con số lớn, mà mình không tự tính vì báo cáo không cho đủ số. Cái đọc được là con số bên kia. Dù có bao nhiêu entry đi nữa, một tầng nén thưa chỉ đọc 1024 cái.

Cùng năm đó, hướng ngược lại: gom 128 nhưng đọc hết

Cơ chế thứ hai tên là attention nén mạnh (Heavily Compressed Attention), và nó đi ngược hẳn. Mình gọi tầng dùng nó là tầng nén mạnh.

Tầng nén mạnh chả lọc gì cả. Entry nào cũng đọc, không bỏ cái nào. Đổi lại nó nén nặng tay hơn hẳn: 128 token liên tiếp ép thành một entry duy nhất, so với bốn của bên kia ^[1]. Nén tới mức đó thì số entry còn lại ít đến nỗi đọc hết vẫn nhẹ.

Hai tầng chọn hai vế khác nhau của cùng một cái tích:

\[n_{\text{HCA}}(L) = \left\lceil L/128 \right\rceil \qquad\qquad n_{\text{CSA}}(L) = \min\!\left(1024,\; \left\lceil L/4 \right\rceil\right)\]

Ở một triệu token, vế trái ra khoảng tám nghìn lần tra còn vế phải vẫn đứng ở 1024. Tầng nén mạnh tra nhiều hơn nhưng mỗi lần moi ra được ít hơn; tầng nén thưa tra ít hơn nhưng mỗi lần moi ra rõ hơn.

Tầng nén thưa giống người lướt mục lục rồi mở đúng vài trang cần. Tầng nén mạnh giống người đọc bản tóm tắt cả cuốn sách, mỗi đoạn còn một câu, nhưng không sót đoạn nào.

Chỗ mất là độ phân giải. Một entry gánh 128 token thì không giữ nổi chi tiết riêng lẻ nào. Chỉ có tầng nén mạnh thôi thì mô hình sẽ nhớ rằng đoạn này nói về một hợp đồng thuê nhà, nhưng không nhớ số tiền.

Bản Pro có 61 tầng, và báo cáo nói đúng hai điều về cách xếp: hai tầng đầu là tầng nén mạnh, các tầng còn lại thì hai loại xen kẽ nhau ^[1]. Bản Flash có 43 tầng, hai tầng đầu dùng cửa sổ trượt thuần tuý.

Ý đồ của việc xen kẽ thì đọc ra được. Toàn tầng nén thưa thì thứ bị bỏ ở tầng dưới không bao giờ quay lại được ở tầng trên, vì tầng trên chỉ nhìn thấy đúng thứ tầng dưới chuyển lên. Toàn tầng nén mạnh thì chả tầng nào nhìn thấy chi tiết. Xen kẽ cho tầng nén mạnh giữ tấm bản đồ tổng thể còn tầng nén thưa phóng to vào vùng đang quan tâm, hai loại thay phiên nhau suốt chiều sâu của mạng.

Nén ở đây cũng không phải là đem một mô hình xịn hơn cắt bớt đi cho nhẹ. Hai loại tầng bù cho nhau, và thứ mất đi là độ phân giải ở một nửa số tầng.

Nhưng báo cáo không công bố tỷ lệ xen kẽ. Họ dùng đúng chữ "xen kẽ" rồi dừng, không nói một đổi một, không nói tầng nào là tầng nào. Mọi hình vẽ ở đây, kể cả hình dưới, mình dựng theo kiểu một đổi một cho dễ nhìn, và đó là quy ước của mình chứ không phải cấu hình đã công bố. Chỗ duy nhất tra ra được con số thật là mã nguồn tham chiếu họ mở kèm.

Thứ mà con agent kia bỏ qua ở bước mười hai, có cứu lại được không. Kiến trúc trả lời là có, nhưng chỉ ở mức bản đồ. Các tầng nén mạnh vẫn giữ dấu vết của phần mà tầng nén thưa đã quyết định không nhìn, đủ để biết vùng đó nói về cái gì. Còn số tiền trong hợp đồng thì không.

61 tầng chồng lên nhau, và luật không túi nào được phình

Chồng 61 tầng lên nhau thì đẻ ra một vấn đề khác hẳn, chả dính gì tới độ dài văn bản.

Trong mạng sâu, tầng nào cũng không viết đè lên kết quả của tầng trước. Nó cộng thêm phần đóng góp của mình vào một dòng chảy chung. Đường đó tên là residual connection, và nó chính là lý do các mạng rất sâu vẫn train được: thứ mà tầng thứ ba nhận ra vẫn còn nguyên trong dòng chảy khi tới tầng thứ sáu mươi.

Có một ý mở rộng đường chảy đó ra. Thay vì một dòng thì cho chạy bốn dòng song song, và cho phép chúng trộn vào nhau mỗi lần đi qua một tầng. Cách này làm mô hình mạnh hơn thật. Nó cũng làm mô hình mất ổn định: chồng đủ nhiều tầng thì các con số trong mạng hoặc phình to dần hoặc teo dần, tới một lúc nào đó thì train sụp đổ.

Cách chữa của DeepSeek, công bố thành một công trình riêng ^[8], là đặt một cái luật lên bảng trộn giữa các dòng. Dòng nào đi ra cũng chỉ được chia lại đúng 100% thứ nó nhận, không hơn. Dòng nào đi vào cũng chỉ được nhận đúng 100%, không hơn. Và chả phần nào được âm, tức là không có chuyện rút của dòng này bù cho dòng kia. Không túi nào phình, không túi nào rỗng đi vì nơi khác.

\[A\mathbf{1} = \mathbf{1}, \qquad A^{\top}\mathbf{1} = \mathbf{1}, \qquad A_{ij} \ge 0\]

\(A\) là bảng trộn, \(\mathbf{1}\) là cột toàn số một. Dòng đầu bắt mỗi hàng cộng đủ một, dòng giữa bắt mỗi cột cộng đủ một, dòng cuối cấm ô âm. Tập hợp mọi bảng thoả cả ba có tên riêng là đa diện Birkhoff, và đó đúng là chỗ DeepSeek ép bảng trộn của họ về ^[8].

Hệ quả báo cáo nêu ra là bước trộn không bao giờ phóng đại tín hiệu đi qua nó. Mà ghép hai bảng trộn tuân luật lại thì kết quả vẫn tuân luật, nên chồng bao nhiêu tầng cũng không làm tín hiệu nở ra ngoài tầm kiểm soát ^[1].

Ép một bảng trộn bất kỳ về đúng luật thì không làm được trong một bước. DeepSeek dùng một thủ tục lặp tên là Sinkhorn-Knopp, mà một vòng của nó chỉ là hai phép chia:

\[A \leftarrow \operatorname{diag}(A\mathbf{1})^{-1} A, \qquad A \leftarrow A \operatorname{diag}(A^{\top}\mathbf{1})^{-1}\]

Phép đầu chia mỗi hàng cho tổng của chính hàng đó, phép sau chia mỗi cột cho tổng của chính cột đó. Chỉnh chiều này thì chiều kia lệch đi một chút, nhưng lệch ít dần. Họ chạy hai mươi vòng rồi dừng, ở mỗi tầng, mỗi lần chạy.

Bản gốc viết cái luật này thành hai công thức đánh số ở trang 8, và vệt vàng dưới đây là đúng chỗ đó.

Cùng mục này họ đổi luôn optimizer, tức thứ quyết định sau mỗi lượt train thì chỉnh tham số của mạng đi bao nhiêu và theo hướng nào. V4 bỏ optimizer tiêu chuẩn lâu nay để sang một cái tên Muon ^[9].

Tín hiệu của bước một có còn sống tới tầng 61 hay không thì luật này không trả lời. Nó chỉ chặn đúng một nguyên nhân làm mất: các con số phình lên hay teo lại dọc đường.

Hai mẹo giữ cho train khỏi sụp đổ, mà chính họ nói chưa hiểu vì sao

Train một mô hình cỡ này có thể sụp đổ giữa chừng theo những kiểu chẳng ai đoán trước được. Mục 4.2.3 trang 26 kể hai kỹ thuật họ tìm ra để chặn chuyện đó: định tuyến đón trước (Anticipatory Routing) và kẹp trần SwiGLU (SwiGLU Clamping).

Nhưng ngay sau khi giới thiệu hai kỹ thuật ấy, họ viết:

Fortunately, we discovered two practical techniques that effectively maintain training stability. Although a comprehensive theoretical understanding of their underlying mechanisms remains an open question for now, we are sharing them openly to foster further exploration by the community.

Tạm dịch: may thay, chúng tôi tìm ra hai kỹ thuật thực dụng giữ được sự ổn định khi huấn luyện; tuy hiểu biết lý thuyết đầy đủ về cơ chế bên dưới chúng hiện vẫn còn là một câu hỏi mở, chúng tôi vẫn chia sẻ công khai để cộng đồng khám phá tiếp ^[1].

Họ nói lại lần nữa ở phần kết luận, trang 44: hai kỹ thuật đã chứng minh được là có tác dụng chống bất ổn, nhưng nguyên lý bên dưới vẫn chưa được hiểu đủ.

Họ ghi rằng đây mới là bản xem trước của dòng V4, rằng kiến trúc hiện tại tương đối phức tạp, và rằng họ định đơn giản hoá nó ở bản sau.

Train xong rồi còn phải dạy lại

Train xong chưa phải là hết. Còn một giai đoạn nữa, dạy cho mô hình cách trả lời chứ không chỉ cách đoán chữ tiếp theo, và đây là chỗ V4 khác đời trước nhiều nhất.

Trước hết phải sửa một cái sai đang bị lan truyền. DeepSeek không bỏ học tăng cường (reinforcement learning), tức cách dạy bằng thưởng phạt theo kết quả. Thứ bị bỏ là một giai đoạn cụ thể: trang 28 viết rằng giai đoạn học tăng cường trộn của DeepSeek-V3.2 đã bị thay thế hoàn toàn bằng chưng cất theo chính sách (on-policy distillation) ^[1]. Học tăng cường vẫn còn nguyên, chỉ là nó chuyển sang chỗ khác.

Chỗ khác đó là bước đầu tiên: train từng chuyên gia riêng. Mỗi lĩnh vực một mô hình, toán, lập trình, tự gọi công cụ, tuân thủ chỉ dẫn, và chính mấy mô hình đó mới đi qua học tăng cường, mỗi cái với tín hiệu thưởng hợp với lĩnh vực của nó. Kết quả là hơn mười mô hình, mỗi cái giỏi một mảng.

Giống Quách Tĩnh có 7 sư phụ vậy, mỗi người giỏi một mảng và cùng truyền dạy cho 1 đệ tử

Chữ "chuyên gia" ở đoạn trên phải đọc cho đúng, vì nó trùng tên với một thứ khác trong cùng báo cáo. Chuyên gia trong kiến trúc, thứ DeepSeek đặt tên từ năm 2024 ^[5], là các khối nhỏ nằm bên trong một mô hình, mỗi token chỉ đánh thức vài khối. Chuyên gia trong đoạn này là hơn mười mô hình hoàn chỉnh, tách rời, chạy riêng. Hai nghĩa, một chữ, và họ để nguyên như thế.

Bước sau là gộp hơn mười mô hình ấy lại thành một. Cách cũ là trộn thẳng trọng số, mà cách đó hay làm hỏng cả đàn. DeepSeek làm khác. Mô hình cuối cùng đóng vai học trò, tự sinh ra câu trả lời cho từng câu hỏi, rồi với mỗi câu thì chỉnh mình theo cách trả lời của đúng ông thầy hợp với loại câu đó. Toán thì học thầy toán, mã nguồn thì học thầy mã nguồn. Vì học trò tự sinh câu trả lời của chính nó để học, nó học đúng những tình huống nó thật sự gặp, chứ không học thuộc lòng bài mẫu của thầy.

Một thiên lệch chẳng ai cố ý tạo ra, và nó không nằm trong mã nguồn

Chuyện đáng kể nhất của giai đoạn dạy lại thì lại nằm ở cụm máy chạy train.

Cụm máy của DeepSeek có quyền ngắt ngang một công việc bất cứ lúc nào để nhường chỗ cho việc ưu tiên hơn. Cách xử lý ngây thơ là quay lại thì sinh lại từ đầu mấy câu trả lời chưa xong. Báo cáo chỉ ra rằng làm vậy là sai, và đây là nguyên văn:

Importantly, it is mathematically incorrect to regenerate unfinished requests from scratch, as this introduces length bias. Because shorter responses are more likely to survive interruption, regenerating from scratch makes the model more prone to producing shorter sequences whenever an interruption occurs.

Tạm dịch: điều quan trọng là sinh lại từ đầu các yêu cầu chưa xong là sai về mặt toán học, vì nó tạo ra thiên lệch độ dài (length bias); do các câu trả lời ngắn có khả năng sống sót qua gián đoạn cao hơn, việc sinh lại từ đầu khiến mô hình dễ trả lời ngắn hơn mỗi khi xảy ra một lần gián đoạn ^[1].

Gián đoạn rơi vào một thời điểm ngẫu nhiên trong lúc mô hình đang viết. Câu trả lời nào viết xong trước thời điểm ấy thì thoát, câu nào còn đang viết thì bị vứt và làm lại. Mà câu càng dài thì càng dễ còn đang viết. Nên trong đống câu sống sót, câu ngắn nhiều hơn mức lẽ ra phải có, và mô hình học từ đúng cái đống lệch đó.

Gọi \(p(\ell)\) là phân bố độ dài mà mô hình lẽ ra phải học, còn \(s(\ell)\) là xác suất một câu dài \(\ell\) sống sót qua gián đoạn. Sinh lại từ đầu thì thứ mô hình thật sự học là

\[q(\ell) \;\propto\; p(\ell)\,s(\ell)\]

mà \(s(\ell)\) giảm khi \(\ell\) tăng, nên \(q\) lệch sang trái so với \(p\). Báo cáo không đưa công thức nào ở chỗ đó, họ nói bằng lời rồi chuyển thẳng sang cách chữa; công thức trên là mình tự viết lại cho gọn.

Chẳng ai cố ý tạo ra thiên lệch này. Nó không phải một lỗi trong mã nguồn, nên nó không hiện ra trong bất kỳ báo cáo lỗi nào, không làm hỏng phép kiểm tra nào, và chả có cách nào nhìn thấy nó ngoài việc ngồi nghĩ về xác suất sống sót của một câu trả lời dài. Câu tiếp nối của đoạn trích trên bị cắt ngang sang trang 35, và ở đó họ nói thêm rằng nếu hạ tầng suy luận cho ra kết quả lặp lại được thì có thể chữa bằng cách sinh lại với cùng một hạt giống ngẫu nhiên, nhưng cách đó vẫn phải chạy lại toàn bộ phần đã sinh nên tốn hơn hẳn. Cách họ chọn là ghi nhật ký từng token một: bị ngắt thì lưu chỗ đang đứng, quay lại thì đọc nhật ký rồi viết tiếp đúng chỗ đã dừng.

Con agent 300 file không bao giờ gặp lần gián đoạn nào, vì nó xảy ra lúc train chứ không phải lúc chạy. Nhưng nếu thiên lệch kia không bị chặn, nó sẽ nằm sẵn trong chính cái mô hình mà con agent chạy trên đó, dưới dạng một xu hướng trả lời ngắn hơn mức cần, ở đúng những chỗ cần dài.

Điểm số của V4 và cách đọc cho đúng

Ở bảng so sánh phần nền, tức là trước khi mô hình được dạy cách trả lời, DeepSeek đo bằng một bộ đề đọc hiểu văn bản dài tên LongBench v2 ^[10]. Đời V3.2 được 40,2. Bản Flash của V4 được 44,7. Bản Pro được 51,5 ^[1].

MRCR ở một triệu token là bộ đề của bên thứ ba, đo khả năng tìm lại nhiều mẩu thông tin đã bị chôn trong một khối văn bản rất dài ^[11]. DeepSeek-V4-Pro được 83,5. Gemini-3.1-Pro được 76,3. Claude Opus 4.6 được 92,9.

CorpusQA ở một triệu token thì gần với tình huống thật hơn: 62,0 cho DeepSeek, 53,8 cho Gemini, 71,7 cho Claude ^[1].

Mà hai dòng số đó chỉ đọc đúng khi kèm mấy điều sau.

Điểm của Claude với của Gemini trong bảng này là do chính DeepSeek chạy lại, không phải số Anthropic hay Google công bố. Lý do họ ghi rõ ở trang 37: chạy lại để mọi mô hình dùng chung một cấu hình.

Các cột cũng không cùng một chế độ suy nghĩ. DeepSeek và Claude ở chế độ cao nhất, còn Gemini ở một chế độ thấp hơn chế độ cao nhất của nó.

Dấu gạch trong bảng nghĩa là không đánh giá, chứ không phải điểm thấp. GPT-5.4 để trống ở hai dòng này vì theo lời họ, cổng giao tiếp của mô hình đó không trả lời phần lớn truy vấn.

Và chính báo cáo nói thẳng cả hai vế ở trang 39 chứ không chỉ vế thắng: DeepSeek-V4-Pro vượt Gemini-3.1-Pro ở MRCR, nhưng vẫn đứng sau Claude Opus 4.6.

Còn một câu nữa của chính họ, và đó là câu tự nhận rõ nhất trong cả báo cáo. Trang 5, sau khi kể rằng bản Pro chạy hết sức thì vượt được GPT-5.2 và Gemini-3.0-Pro trên các bài kiểm suy luận tiêu chuẩn, họ viết tiếp rằng nó vẫn kém GPT-5.4 và Gemini-3.1-Pro một chút, và điều đó cho thấy một quỹ đạo phát triển đi sau các mô hình dẫn đầu khoảng ba tới sáu tháng ^[1]. Câu này chỉ xuất hiện đúng một lần trong cả 58 trang, và nó nói riêng về mảng suy luận, với đúng hai mốc so sánh vừa nêu.

Mình bỏ đi gần một phần ba báo cáo, toàn bộ phần hạ tầng: cách họ chồng lấn tính toán với truyền tin, thư viện sinh mã cho phần cứng, các phép tính cho ra kết quả lặp lại được, cách trải ngữ cảnh dài qua nhiều máy, cách đẩy KV cache xuống đĩa, cái hộp cát để agent chạy an toàn. Đó là một bài khác, và ai viết hạ tầng thì nên đọc thẳng bản gốc.

Ai nên quan tâm tới những gì mình vừa kể thì mình đoán thế này. Người tự chạy mô hình trên máy của mình, vì phép tính và bộ nhớ quyết định mô hình có nạp nổi vào máy hay không. Người viết agent, vì cái quyết định chương trình của họ còn nhớ được gì sau năm trăm bước không phải con số một triệu in trên trang giới thiệu, mà là 1024 entry ở tầng nén thưa với độ phân giải còn lại ở tầng nén mạnh. Và người trả tiền cho từng token, vì phần lớn số tiền đó là tiền mua đúng hai thứ ấy, đổi sang một đơn vị khác.

Bài viết dừng ở đây, đó là toàn bộ kiến trúc của DeepSeek V4. Mình chắc chắn sẽ viết thêm một bài khác về cách mà DeepSeek Optimize hạ tầng vận hành. Mình có nói về việc Kimi K3 Optimize hạ tầng vận hành ở một Video dài 1 giờ, bạn có thể tìm xem.

Bình 🙌