Lò Luyện Model

1. Model = hàm số có núm vặn

Quên chữ "trí tuệ" đi. Một model dịch như MoxhiMT-30 của bạn, về bản chất toán học, là:

P(y_t | x, y_<t; θ) → phân phối xác suất của token tiếng Việt kế tiếp

x     = toàn bộ câu nguồn tiếng Trung
y_<t  = các token tiếng Việt đã có trước vị trí t
θ     = ~30 triệu con số thực (tham số / weights)

Nó giống một bàn mixer khổng lồ có 30 triệu núm vặn. Mỗi cách vặn (mỗi bộ giá trị θ) cho ra một "kiểu dịch" khác nhau — đa số là dịch rác; một vùng rất nhỏ trong không gian 30-triệu-chiều đó là dịch hay. Training = quá trình tìm cách vặn 30 triệu núm để hàm này dịch tốt.

Ba điểm cần chốt ngay:

1. Tham số là thứ duy nhất thay đổi khi train. Kiến trúc (số layer, số head…) cố định từ trước — đó là hyperparameter: bạn chọn, model không học.
2. Kích cỡ model = số tham số. "Model 41M", "probe 90M" — là đếm số núm vặn. Nhiều núm hơn = sức biểu diễn lớn hơn, nhưng cần nhiều data hơn để vặn đúng hết (câu chuyện trần 41M vs 130M → Module 15).
3. Đầu ra là phân phối — mọi thứ về sau (loss, decode, eval) đều xoay quanh sự thật này.

2. Loss — thước đo "đang sai bao nhiêu"

Muốn vặn núm có phương hướng thì phải đo được độ sai. Với model ngôn ngữ / dịch máy, thước đo chuẩn là cross-entropy:

loss của 1 token = −ln( xác suất model gán cho token ĐÚNG )

Chỉ vậy thôi: gán xác suất cao cho đáp án đúng → loss nhỏ; gán thấp → loss lớn. Loss của cả câu / cả tập = trung bình loss từng token. Vài mốc để cảm nhận:

Đọc lại log của chính bạn

Gate checkpoint-5000 của bạn ghi: eval_loss 1.896 so với baseline 2.036. Giờ đọc được rồi:

• Loss 2.036 → trung bình nhân (geometric mean) của P(token đúng) là e^−2.036 ≈ 13%
• Loss 1.896 → xác suất “điển hình” theo cùng cách tính ≈ 15%

Đây không phải trung bình cộng xác suất từng token: vài token cực khó bị log phạt mạnh. Nghe thấp vẫn bình thường — rất nhiều token có nhiều đáp án cùng đúng ("Vâng/Ừ/Ừm" đều là bản dịch hợp lệ của 嗯 — chính bạn gặp ca này khi dedup). Model không thể và không nên đạt P=1. Cách đọc trực quan hơn: perplexity = e^loss — một “số nhánh lựa chọn hiệu dụng”, không phải số đáp án đếm được theo nghĩa đen:

ppl(2.036) = e^2.036 ≈ 7.7   → như phân vân giữa ~8 token
ppl(1.896) = e^1.896 ≈ 6.7   → như phân vân giữa ~7 token

Cải thiện 2.036 → 1.896 làm perplexity hiệu dụng giảm 7.7 → 6.7 trên cùng tokenizer/tập đánh giá. Đây là cải thiện thật, nhưng không nên diễn dịch cứng thành “loại đúng một token gây nhiễu”.

3. Gradient descent — dò dốc trong sương mù

Đứng trên sườn núi trong sương mù dày (không thấy đáy thung lũng), nhưng chân cảm nhận được độ dốc ngay chỗ đứng. Bước một bước nhỏ về hướng xuống dốc nhất. Lặp lại vài trăm nghìn lần.

• "Vị trí đang đứng" = bộ tham số θ hiện tại · "Độ cao" = loss
• "Độ dốc dưới chân" = gradient ∂L/∂θ — tính bằng backpropagation (Module 02)
• "Độ dài bước chân" = learning rate (lr)

θ_mới = θ_cũ − lr × (∂L/∂θ)

Tự tính tay — model 1 tham số

Model tí hon: dự_đoán = w × x. Dữ liệu: x = 2 thì đáp án y = 10 (w lý tưởng = 5). Loss bình phương: L = (w·x − y)², đạo hàm ∂L/∂w = 2·(w·x − y)·x. Bắt đầu w = 1:

Khi loss training của bạn vọt lên NaN/inf — cơ chế bên dưới chính là bảng bên phải. Với bài này L = 4(w−5)², nên sai lệch e = w−5 sau mỗi bước tuân theo e_mới = (1−8·lr)e_cũ: lr = 0.125 tới đáy đúng một bước; 0 < lr < 0.125 hội tụ không đổi bên; 0.125 < lr < 0.25 dao động nhưng co dần (lr = 0.2 là ví dụ); lr = 0.25 dao động mãi cùng biên độ; lớn hơn 0.25 thì phân kỳ. Mỗi bài toán có vùng lr vàng riêng — vì thế warmup và schedule tồn tại (Module 02). Bạn từng chạy arm ffn_up_only + lr0.005 — tức đã dùng learning rate riêng cho từng nhóm tham số.

Chữ S trong SGD — vì sao mỗi bước chỉ nhìn một nhúm dữ liệu?

Loss "thật" là trung bình trên toàn bộ dataset (vd 1M cặp câu) — tính đủ cho mỗi bước thì một đời không xong. Thay vào đó mỗi bước lấy một minibatch (32–2048 câu) và coi gradient của batch là ước lượng nhiễu của gradient thật — chữ S là Stochastic. Nhiễu không hẳn xấu: nó giúp nhảy khỏi các hố nông. Batch to → ước lượng mượt hơn nhưng tốn VRAM — trade-off là chuyện chính của Module 02.

4. Train / Validation / Test — và nỗi sợ leakage chính đáng của bạn

Model có thể đạt loss thấp bằng hai con đường rất khác nhau: học quy luật (sau 了 thường là hành động đã xong → "rồi/đã") hoặc học thuộc lòng ("câu số 48.213 có đáp án là…"). Nhìn loss trên tập train thì không phân biệt nổi. Vì vậy phải cắt dữ liệu:

Cách đọc cặp loss (train, val):

• Train giảm, val giảm → đang học quy luật. Tốt.
• Train giảm, val chững rồi tăng → bắt đầu học thuộc (overfit) — xử lý ở Module 09.
• Val đẹp bất thường → nghi ngờ ngay: leakage — câu val lọt vào train.

Tóm tắt bằng một câu chuyện: một lần train = thả người mù (optimizer) xuống dãy núi 30-triệu-chiều (không gian tham số), đưa máy đo độ cao tại chỗ (loss trên minibatch), dặn bước chân dài chừng này (lr), và tin rằng sau trăm nghìn bước anh ta đứng ở thung lũng đủ thấp. Validation là trạm kiểm tra độc lập xác nhận thung lũng có thật — chứ không phải anh ta đào hố tại chỗ rồi tự khai là thung lũng.

1. Backpropagation — dây chuyền trách nhiệm

Module 01 nói "tính gradient cho từng tham số" như thể miễn phí. Thực tế model là hàm lồng nhau hàng chục tầng. Backprop là quy tắc dây chuyền (chain rule) chạy ngược: bắt đầu từ loss, hỏi ngược từng tầng "đầu ra của anh lệch 1 đơn vị thì loss đổi bao nhiêu?" — như truy trách nhiệm trong dây chuyền sản xuất: QC cuối báo lỗi cho công đoạn N; công đoạn N tính phần lỗi do mình (→ update θ của mình) và phần chuyển tiếp cho công đoạn N−1.

Điều thứ hai đáng nhớ: backward tốn nhớ vì phải giữ activations — muốn tính gradient tầng k cần giá trị vào của tầng k lúc forward, nên toàn bộ kết quả trung gian phải nằm chờ trong VRAM. Đây là lý do batch to ngốn VRAM khủng khiếp (mục 6). Còn lại autograd của PyTorch lo hết.

2. Từ SGD đến AdamW — tiến hóa của người dò dốc

Cụ thể, Adam giữ cho mỗi tham số hai thống kê trượt:

m := trung bình trượt của gradient    (đà — hướng đi trung bình)
v := trung bình trượt của gradient²   (biên độ — gradient chỗ này thường to cỡ nào)
bước cập nhật ≈ lr × m / (√v + ε)

Chính m và v chiếm VRAM gấp đôi tham số (mục 6), và cũng là một lý do cần warmup (mục 3): mấy bước đầu v ước lượng từ quá ít mẫu — chia cho √v lúc này như chia cho số ngẫu nhiên.

Ghi chú thực chiến: fused AdamW trong recipe LFM2 của bạn không đổi toán học — nó gộp nghìn phép cập nhật nhỏ vào một GPU kernel cho nhanh. Khi đọc config lạ, luôn tách hai câu hỏi: đây là thay đổi toán học (ảnh hưởng chất lượng) hay thay đổi thực thi (chỉ ảnh hưởng tốc độ)?

3. Learning rate — hyperparameter số một

Lr theo nhóm tham số. Không luật nào bắt mọi tham số chung một lr. Arm ffn_up_only + lr0.005 bạn chạy ở 90M chính là kỹ thuật này: nhóm được chọn nhận lr riêng để "nới" khả năng học mà không làm loạn phần còn lại. LoRA (Module 10) là họ hàng cực đoan: chỉ vài % tham số được học, còn lại đóng băng.

Quy tắc kéo theo: đổi batch size thì phải nghĩ lại lr (batch to → gradient mượt → thường chịu được lr lớn hơn, heuristic phổ biến: scale tuyến tính). Đổi mình batch mà giữ lr là âm thầm đổi hai thứ.

4. Batch, microbatch, gradient accumulation

microbatch        = số token đưa vào GPU MỖI lần forward/backward
grad accumulation = gom gradient của k microbatch rồi mới update 1 lần
effective batch   = microbatch × k (× số GPU)   ← con số quyết định động học

Với MT, đo batch bằng token chuẩn hơn bằng câu (câu dài ngắn lệch nhau quá xa) — như bạn vẫn ghi "microbatch 16k/32k/65k token" trong bench Modal. Effective batch mới ảnh hưởng chất lượng; microbatch và accum chỉ là cách xếp lịch để đạt nó trong VRAM hữu hạn:

• 5070Ti 12GB không nhét nổi 32k token/lần? → microbatch 4k × accum 8 = effective 32k — chậm hơn nhưng cùng kết quả toán học.
• Nhờ đó có thể probe công thức ở local rồi scale lên H100 với cùng effective batch mà tin được kết quả.

5. Mixed precision & gradient clipping

Recipe của bạn — fp32 params + bf16 autocast — nghĩa là: bản chính tham số và bước cập nhật Adam giữ fp32 (cộng dồn chính xác các cập nhật tí hon), còn nhân ma trận trong forward/backward chạy bf16 (nhanh ~2×, nửa bộ nhớ activation). Đây là setup chuẩn công nghiệp hiện nay.

Gradient clipping — cầu chì chống bước nổ: nếu ‖gradient toàn cục‖ > ngưỡng (thường 1.0) thì co lại đúng bằng ngưỡng. Một batch xấu có thể tạo gradient đột biến; không clip thì một bước phá hỏng nghìn bước tích lũy. Trong log: "loss spike một nhát rồi từ từ hồi" thường là batch xấu đã được clip cứu; spike rồi đi luôn thường là thiếu clip hoặc lr quá cao.

6. VRAM đi đâu hết? — số học ai cũng nên thuộc

Mỗi tham số (AdamW, mixed precision) ≈
4 byte (param fp32) + 4 byte (gradient) + 8 byte (Adam m + v) = 16 byte/param

41M → ~0.66 GB      90M → ~1.44 GB      130M → ~2.1 GB   ← trạng thái train, CỐ ĐỊNH

Nhìn xong bạn sẽ thắc mắc đúng chỗ: vậy sao run 130M peak tận 36GB? Vì phần còn lại — thường là phần lớn — là activations, tỉ lệ thuận với token/microbatch × d_model × số layer:

Padding — kẻ ăn cắp throughput vô hình

Phát hiện trong run H100 của bạn: "bottleneck là padding/host chứ không phải compute". Batch gom câu dài ngắn khác nhau → pad tất cả lên bằng câu dài nhất → GPU nhân ma trận cả phần đệm vô nghĩa:

1. Trần chất lượng nằm ở data, không nằm ở model

Training (Module 01–02) chỉ làm một việc: kéo model khớp với phân phối của data. Hệ quả lạnh lùng:

Model tốt nhất có thể = data của bạn, trừ đi một chút. Không bao giờ cộng thêm.

• Data dịch sai 5% → model học đúng cái sai đó như chân lý.
• Data toàn tiên hiệp → model dịch Lovecraft (Quỷ Bí Chi Chủ) sẽ tự tin… theo giọng tiên hiệp.
• Data từ teacher yếu → student giỏi lắm là bằng teacher, trừ hao. Chính là lý do bạn loại tienhiep_baidu khỏi vai teacher cho CTC distillation: chất lượng nó không hơn Moxhi bao nhiêu → distill từ nó là tự đặt trần thấp (Module 11 đào tiếp).

Vì vậy khi chất lượng chưa đạt, thứ tự đầu tư đúng: soi data trước, đổi kiến trúc sau cùng — trùng khớp trải nghiệm của bạn: các cú nhảy chất lượng lớn nhất (style_gold, namefix, clean dataset) đều đến từ data, không phải từ đổi model.

2. Giải phẫu một pipeline data chuẩn

Pipeline stv-mt-clean-dataset của bạn đã hội tụ về đúng hình dạng giáo khoa — vẽ lại để gọi tên từng khối:

3. Dedup — môn tưởng dễ mà sâu

Vụ "嗯。" — ca giáo khoa của chính bạn

Phase 5A từng tranh luận: dedup theo source_hash (loại mọi câu nguồn trùng) hay theo cặp (source_hash, target_hash)? Câu "嗯。" xuất hiện nhiều lần với 3 bản dịch Vâng / Ừ / Ừm — đều đúng, tùy người nói. Quay về bản chất thống kê (Module 01): model học phân phối có điều kiện P(target | source):

• Giữ cả 3 cặp → model học P(Vâng) ≈ P(Ừ) ≈ P(Ừm) ≈ ⅓ → đúng phân phối thật ✓
• Dedup theo source, giữ 1 → model học P(Vâng) = 1 → tự tin sai, mất khả năng biến hóa ✗

Dedup cũng là chống leakage: audit reverse-AR của bạn tìm thấy 728 282 input Việt unique nhưng 567 086 exact replays — không dedup theo view training thì model "ôn lại" một câu hàng chục lần → memorize + loss đẹp giả. Còn 77 input có target mâu thuẫn → drop hẳn: mâu thuẫn ≠ đa dạng (cùng điều kiện mà đáp án chọi nhau là data bẩn). Quy trình bạn chốt — artifact gốc bất biến, dedup ở view training — là chuẩn: artifact để audit, view tùy mục đích.

4. Giải thích từng gate trong SOP của bạn

SOP bạn đúc kết: "dedup, eval overlap, Han leak, length, provider mix, book/domain balance, hot prefix buckets". Mỗi gate chặn một thảm họa cụ thể:

Bộ khung này đáng tái dùng cho mọi dataset mới (kể cả ngoài MT): bốn nhóm — trùng lặp, rò rỉ, bẩn, mất cân bằng — dataset nào cũng phải qua đủ bốn.

5. Probe trước, scale sau

6. Ba loại data, ba chuẩn chất lượng

Kim tự tháp ngược về số lượng, xuôi về độ khó tính: train cần nhiều nhất nhưng dễ tính nhất; eval ít nhất nhưng mỗi row sai là la bàn lệch — mọi quyết định sau đó lệch theo. Một row eval sai đắt hơn nghìn row train sai.

1. Vì sao phải có tokenizer?

Model chỉ ăn số — phải cắt văn bản thành đơn vị rồi tra số. Ba mức cắt:

Subword thắng tuyệt đối nhờ một tính chất đẹp: tần suất quyết định độ dài — hay gặp thì thành một token gọn, hiếm thì trả giá bằng nhiều token; vocab hữu hạn nhưng không bao giờ chịu thua chuỗi lạ (nhất là khi có byte-fallback).

2. BPE chạy tay trong 90 giây

Byte-Pair Encoding chỉ có một động tác lặp: đếm cặp kề nhau phổ biến nhất → dán thành token mới → lặp. Corpus tí hon: học học học hỏi hòa

Khởi đầu:  h-ọ-c   h-ọ-c   h-ọ-c   h-ỏ-i   h-ò-a
Đếm cặp:   (h,ọ)=3   (ọ,c)=3   (h,ỏ)=1   (ỏ,i)=1   (h,ò)=1   (ò,a)=1

Merge 1:   (h,ọ) → "họ"      ⇒   họ-c   họ-c   họ-c   h-ỏ-i   h-ò-a
Merge 2:   (họ,c) → "học"    ⇒   học    học    học    h-ỏ-i   h-ò-a
Merge 3:   … tần suất thấp dần, dừng khi đủ vocab

Sản phẩm gồm hai thứ: bảng vocab (token → id) và danh sách merge có thứ tự ưu tiên. Tokenize văn bản mới = áp lại các merge theo đúng thứ tự đã học — chi tiết này chính là gốc rễ vụ UNUSED pieces bạn từng đổ mồ hôi (mục 6).

SentencePiece (SPM) là "BPE đóng gói công nghiệp": tự lo chuẩn hóa, coi khoảng trắng là ký tự thường (ký hiệu ▁ Metaspace), không cần tách từ theo dấu cách — điểm sống còn với tiếng Trung vốn không có dấu cách.

3. Token/ký-tự — con số nhỏ, hệ quả lớn

Case của bạn: Moxhi (SPM 24k) đạt 0.73 tok/char trên tiếng Trung; model đối thủ 50M dùng byte-BPE kiểu GPT-2 (chữ Hán vỡ thành 3 byte rồi mới merge lại) đạt 0.88 tok/char → cùng một chương truyện, đối thủ xử lý 1.21× số token:

4. Byte-fallback, coverage và exposure

Vocab 24k không chứa nổi ~90k chữ Hán. Chữ ngoài vocab, thay vì thành <unk> (mất trắng), được xé xuống mức byte UTF-8 — luôn biểu diễn được:

Từ đó, cặp gate bạn đặt ra có chỗ đứng lý thuyết rõ ràng — hai gate độc lập đúng như bạn kết luận:

Audit stv-lite v3 minh họa luôn: 87 599 term, 0 <unk> (fallback hoạt động), nhưng chỉ 62% chữ Hán distinct "visible OK" — 38% sống kiếp byte, và danh sách đó dự báo trước các chữ sẽ dịch trượt. Giải pháp thực dụng cho tên hiếm mà bạn đã đi đúng: đừng bắt model học thuộc — cho nó cơ chế chép (hint-injection, glossary, pointer/copy — Module 08 & 10).

5. Chọn vocab size — chia ngân sách tham số

Vocab 24 001 × d_model 512 = 12.3M tham số embedding
Model A9-41M  → embedding chiếm ~30% toàn model (đã tied input/output — Module 05)
Model 500M    → cùng embedding đó chỉ chiếm ~2.5%

Model càng nhỏ, mỗi slot vocab càng đắt → 24k cho zh-vi nằm đúng vùng hợp lý. Spec bạn tự viết đã rất chuẩn: shared vocab zh+vi, NFC bắt buộc, không lowercase/strip dấu (tiếng Việt mất dấu = mất nghĩa!), train trên text thật (không JSON/metadata), control token tối giản <bos> <eos> <zh> <vi> <ctx> <glossary>.

6. Tokenizer là hợp đồng bất biến

Đổi tokenizer = đổi model. Mọi tham số được học theo một cách băm token cụ thể. Không tồn tại "nâng cấp tokenizer cho model cũ" — chỉ tồn tại train lại.

Thứ tự chuẩn khi mở project MT mới (đúc từ chính project của bạn): gom corpus đại diện → train thử 2–3 phương án tokenizer → đo fertility + coverage trên danh sách ký tự bắt buộc + audit tail vocab → chốt, version hóa, golden-test → rồi mới nói chuyện kiến trúc model.

1. Từ id vô hồn đến vector có nghĩa

Sau tokenizer, câu của bạn là dãy id: [8412, 209, 5771]. Nhưng id chỉ là số thứ tự — id 8412 chẳng "gần" id 8413 hơn id 20000 chút nào. Model cần thứ tốt hơn: mỗi token một vector dày đặc (vd 512 chiều).

Embedding table = ma trận vocab × d_model; lookup = lấy hàng thứ id. Với bạn: 24 001 × 512. Điều kỳ diệu duy nhất: ma trận này là tham số được học — gradient từ loss chảy về tận từng hàng (Module 02); token nào xuất hiện trong batch thì hàng của nó được cập nhật một chút. Vì các token dùng giống nhau thì đóng vai trò giống nhau trong việc giảm loss, sau trăm nghìn bước, một trật tự tự phát xuất hiện:

2. Đo "độ gần nghĩa": cosine similarity

Thước đo mặc định giữa hai vector là góc giữa chúng (bỏ qua độ dài):

cos(a, b) = (a·b) / (‖a‖ × ‖b‖)    ∈ [−1, 1]

a = (2, 1),  b = (3, 2),  c = (−1, 2)
a·b = 2·3 + 1·2 = 8      ‖a‖ = √5 ≈ 2.24     ‖b‖ = √13 ≈ 3.61
cos(a,b) = 8 / (2.24 × 3.61) ≈ 0.99   → gần như cùng hướng (rất giống nghĩa)
a·c = 2·(−1) + 1·2 = 0  →  cos(a,c) = 0   → vuông góc (không liên quan)

Ba điều khắc cốt khi dùng cosine thực tế:

1. Chỉ so được trong CÙNG một không gian. Vector model A không so cosine với vector model B — hai hệ tọa độ khác nhau.
2. Ngưỡng tuyệt đối vô nghĩa, thứ hạng mới có nghĩa. Nhiều encoder bị anisotropy — mọi vector chen chúc trong một hình nón hẹp, cặp câu nào cosine cũng > 0.6. Dùng top-k gần nhất, hoặc calibrate ngưỡng trên data có nhãn.
3. Embedding từ model dịch nhỏ ≠ sentence encoder xịn. Hidden state của Marian 41M học để phục vụ dịch — dùng được cho việc gần nghề (so term trong domain), nhưng đo "hai câu cùng ý?" thì sentence-transformers đa ngữ làm tốt hơn hẳn.

3. Tĩnh vs theo ngữ cảnh — nâng cấp quan trọng nhất

Cơ chế biến tĩnh thành ngữ cảnh chính là attention — Module 06. Ở đây chỉ cần trực giác: vector đi qua các layer được "nhuộm" dần bởi ngữ cảnh quanh nó.

4. Tied embedding — một ma trận, hai vai

Model sinh text có hai đầu chạm vào vocab: input embedding (id → vector, vào model) và output projection (vector → điểm cho 24 001 token, ra phân phối). Hai ma trận cùng cỡ, và về nghĩa là cùng một ánh xạ nhìn hai chiều → buộc dùng chung (weight tying).

1. Vấn đề cần giải: trộn ngữ cảnh vào từng token

Module 05 dừng ở chỗ: embedding tra bảng là tĩnh — 打 trong 打电话 (gọi điện) và 打人 (đánh người) cùng một vector. Cần một cơ chế cho mỗi token nhìn quanh câu và tự pha lại nghĩa của mình. Cơ chế đó là attention, và ý tưởng gốc giản dị bất ngờ:

Mỗi token phát một câu hỏi (Query), mang một nhãn tìm kiếm (Key) và một gói nội dung (Value). Token mới của tôi = trung bình có trọng số các gói Value trong câu, trọng số cao cho token nào có Key khớp Query của tôi.

2. Tính tay một phép attention

Câu: 他 · 打 · 电话. Xét token 打 đang "hỏi". Ba tích vô hướng q(打)·k(·) cho ra ba điểm khớp, rồi softmax biến điểm thành trọng số dương có tổng = 1:

vector mới của 打 = 0.090·v(他) + 0.245·v(打) + 0.665·v(电话)

Multi-head: làm phép trên 8–16 lần song song với các bộ chiếu Q/K/V khác nhau — mỗi "đầu" tự học một kiểu quan hệ (đầu này soi cú pháp ai-làm-gì, đầu kia soi đồng tham chiếu, đầu khác soi ranh giới tên riêng…), rồi ghép kết quả lại. Không ai chỉ định vai trò từng đầu — chúng tự phân công trong lúc train, cùng cơ chế "trật tự tự phát" như embedding.

Và vì self-attention không vị trí vốn mù thứ tự: hoán vị token sẽ hoán vị các đầu ra tương ứng (permutation-equivariant), nhưng mạng không biết cái nào đứng trước. Vì vậy phải tiêm vị trí. Marian trong Transformers dùng MarianSinusoidalPositionalEmbedding cố định, được cấp capacity theo max_position_embeddings; GPT-2 dùng embedding vị trí học được; nhiều LLM mới dùng RoPE. Trần 512 của model Marian 41M là giới hạn capacity/config/runtime của bảng sin/cos, không phải vì nó là một bảng vị trí học được.

3. Giải phẫu một block

4. Encoder, decoder, và cross-attention — chính là Marian của bạn

Ba biến thể chỉ khác nhau ở ai được nhìn ai:

• Encoder (hiểu): mọi token nhìn mọi token — hai chiều.
• Decoder (sinh): token chỉ nhìn quá khứ (causal mask — che tương lai, không thì "nhìn trước đáp án" khi train).
• Encoder–decoder (dịch — Marian/Hachimi/Moxhi): decoder có thêm cross-attention — Query từ decoder, Key/Value từ đầu ra encoder: mỗi bước sinh tiếng Việt đều "ngoái nhìn" câu Trung đã mã hóa.

5. Đếm tham số: cân đúng 57M của Hirashiba

Với d_model = 512, FFN = 2048, vocab 24k, 6 layer encoder + 6 layer decoder:

Embedding (tied):                24 001 × 512                    ≈ 12.3M
Block encoder:  attention 4×(512×512) ≈ 1.05M
                FFN 2×(512×2048)      ≈ 2.10M     → ~3.15M/block × 6 ≈ 18.9M
Block decoder:  như trên + cross-attention (thêm ~1.05M)
                                       → ~4.20M/block × 6 ≈ 25.2M
────────────────────────────────────────────────────────────────────────
Tổng ≈ 12.3 + 18.9 + 25.2 ≈ 56.4M  ≈  hira_medium_57m của bạn ✓

Bài học kép: (1) nhìn config là cân được model — không cần chạy code; (2) thấy rõ tiền nằm ở đâu: ở cỡ 57M, embedding chiếm ~22%, FFN ~45%, attention ~33%. Muốn model nhỏ mà khỏe, mỗi dòng config (vocab, d, FFN ratio, số layer) là một quyết định phân bổ ngân sách — nền tảng cho bài toán "trần 41M vs 130M" ở Module 15.

6. KV cache — vì sao decode không chậm như lý thuyết

Sinh token thứ 200 mà phải tính lại attention của cả 199 token cũ thì chết. May thay K và V của các token cũ không đổi → tính một lần, cất vào KV cache; mỗi bước mới chỉ tính Q/K/V cho một token mới rồi tra cache:

KV cache (self-attn decoder, fp16)
= số layer × 2 (K và V) × số vị trí × d_model × 2 byte
= 6 × 2 × 512 × 512 × 2  ≈ 6.3 MB / câu     ← model 57M của bạn: quá rẻ

LLM 26B (d≈4096, 40+ layer, context 8k, nếu MHA) → hàng GB       ← Module 14

Công thức trên là cho multi-head attention (MHA), nơi số KV head bằng số query head. Với GQA/MQA, nhân thêm tỉ lệ n_kv_heads / n_heads; ví dụ 8 KV head / 32 head làm cache còn khoảng 1/4. Hai điểm tinh tế đáng biết vì bạn đã đụng chúng ở webMT: (1) cross-attention K/V tính một lần duy nhất từ encoder — phần này không phình theo số token đích đã sinh; (2) cache là trạng thái phải quản lý: cấp phát theo capacity, LRU khi nhiều câu. Đổi lấy tiện, cache ăn VRAM tuyến tính theo context và batch.

bytes = batch × layer × 2(K,V) × token × d_model
        × byte/phần tử × (n_kv_heads / n_heads)

1. Nhánh thứ ba của gia phả transformer

Module 06 mổ xẻ một block transformer; Module 08 sẽ nói về các kiến trúc sinh chữ. Nhưng cả một mảng project của bạn — tách từ, gán POS, bắt entity, chấm keep/reject cho term — không cần sinh chữ nào cả. Chúng cần hiểu: nhận văn bản, trả về nhãn, điểm số, hoặc vector. Đó là lãnh địa của encoder-only:

2. MLM — dạy "hiểu" bằng trò điền vào chỗ trống

Encoder không có "token tiếp theo" để đoán (nó nhìn cả câu rồi còn gì). Mục tiêu pretrain của nó là masked language modeling: che ngẫu nhiên ~15% token, bắt model đoán lại từ cả hai phía ngữ cảnh:

Sau pretrain, encoder là một "cỗ máy đọc hiểu" đầy tri thức ngôn ngữ nhưng chưa biết làm việc gì cụ thể — đúng trạng thái "nền" của trục fine-tune Module 10. MiniRBT-H256 bạn dùng trong ltp-ft chính là một RoBERTa tiếng Trung thu nhỏ bằng distillation (Module 11 áp cho encoder!): hidden 256, vỏn vẹn 10.28M tham số — nhỏ hơn cả model dịch tiny của bạn.

3. Thân + đầu: một encoder, nhiều nghề

4. Sequence labeling — đọc BMES/BIO trong 2 phút

Bài gán nhãn chuỗi mã hóa "khoanh vùng" thành nhãn per-token. Tách từ (CWS) dùng BMES (Begin-Middle-End-Single); NER dùng BIO (Begin-Inside-Outside) kèm loại entity. Ví dụ với đúng cái tên trong audit của bạn:

Hai điểm thực chiến:

• Decode có ràng buộc: chuỗi nhãn phải hợp lệ (I-Nh không được đứng sau O; M không được mở đầu từ). Model per-token đôi khi phát nhãn vô lý → cần lớp sửa (CRF/Viterbi hoặc rule) trước khi dùng — cùng tinh thần "collapse" của CTC ở Module 08.
• Vì sao NER của LTP cần CWS (điều bạn phát hiện khi tối ưu pipeline): LTP là multi-task — một thân encoder chung, sáu đầu (CWS/POS/NER/DEP/SRL/SDP), và đầu NER chấm trên ranh giới từ do CWS cung cấp chứ không trên từng ký tự. Nên bạn drop được POS/DEP/SRL/SDP cho nhẹ, nhưng CWS là xương sống không bỏ được:

5. Bài học ngược chiều: verifier v1 — khi nào KHÔNG cần BERT

Cùng lúc đó, TermCandidateVerifier v1 trong webapp của bạn lại cố tình không dùng encoder: logistic regression / MLP 1 lớp ẩn trên 80–150 feature tính tay (PMI, freedom, spread, shape flags kiểu họ+tên/hậu tố xưng hô, context flags, xung đột từ điển…), xuất ra JSON <100KB, chạy tức thời trong browser worker. Và nó tốt: bench-gt v2 đạt 0/213 positive bị giết oan, chặn 94.56% của 92 negative. Vì sao mô hình "cổ điển" thắng ở đây?

Nguyên tắc rút ra — "câu hỏi hẹp thì model hẹp": verifier không hỏi "mọi entity ở đâu trong văn bản" (full NER — cần encoder) mà chỉ hỏi "candidate ĐÃ ĐƯỢC detector đề cử này có nên hiện không?" — bài nhị phân trên đối tượng đã khoanh vùng, feature tay mô tả được gần hết tín hiệu → vài nghìn nhãn là đủ, và latency browser ~0 là tính năng sản phẩm. Chỉ khi nào chạm trần của feature tay (các ca cần đọc ngữ cảnh thật — đúng các ca bạn mô tả hôm 13/08) thì mới leo lên nấc encoder, và leo theo kiểu Module 05: encoder làm một phiếu bên cạnh rules + policy, không thay thế chúng. Kèm một viên ngọc ẩn trong thiết kế v1 của bạn: Phase 3 active learning — mỗi lần user review một term là một nhãn mới rơi vào kho retrain. Đó là data flywheel: sản phẩm tự nuôi model của chính nó.

1. Ba họ kiến trúc — ba cách trả lời "sinh câu đích thế nào"

2. AR: trả tiền theo token — và beam search

Decode AR chọn token thế nào từ phân phối? Greedy: lấy max mỗi bước — nhanh, nhưng tham lam cục bộ (chọn sớm một từ khiến cả câu sau bí). Beam search: nuôi song song k giả thuyết tốt nhất (k = beam size, thường 4–5 cho MT), cuối cùng lấy chuỗi tổng điểm cao nhất. Beam to hơn không đồng nghĩa tốt hơn — quá to còn tệ đi ("beam curse": nghiêng về câu ngắn, an toàn, nhạt). Chi phí: thời gian ≈ số bước × chi phí một lượt decoder × beam — nhân ba thừa số là hiểu mọi bài toán tốc độ AR.

3. NAR: sinh một lượt — và cái giá của sự song song

NAT sinh mọi vị trí cùng lúc: nhanh cố định, nhưng các vị trí không nhìn thấy lựa chọn của nhau. Câu nguồn có nhiều bản dịch hợp lệ (嗯 → Vâng/Ừ/Ừm — multimodality), mỗi vị trí tự chọn theo phân phối riêng thì dễ ra trộn chéo hai bản dịch: nửa đầu theo bản A, nửa sau theo bản B — sinh đúng loại lỗi bạn đo được ở CTC: independence (từ cạnh nhau vênh nhau), omission (hai vị trí cùng "tưởng bên kia lo rồi"), reorder yếu.

Vì thế NAT sống được nhờ distillation (Module 11): cho teacher AR dịch lại toàn bộ train data → data mới chỉ còn một kiểu dịch nhất quán (đơn-mode) → NAT student không còn bị xé giữa nhiều bản dịch. Đây là lý do mọi paper NAT đều distill trước, và là lý do chất lượng teacher quyết định trần NAT của bạn.

CTC — biến thể NAT bạn dùng — thêm một chiêu khéo: sinh chuỗi slot dài hơn output (thường 2× số token nguồn), cho phép mỗi slot phát token thật hoặc ∅ (blank), rồi collapse (gộp lặp liền kề, xóa blank). Model nhờ đó tự học cách "canh hàng" nguồn–đích mà không cần biết trước độ dài output — đổi lại, alignment bị ép monotonic (trái sang phải), nên reorder xa là điểm mù cấu trúc:

4. Bản đồ các hướng NAT nâng cao — đặt tên cho những gì bạn đã nghiên cứu

Vì sao speculative NO-GO cho model nhỏ: speculative có lãi khi một lượt model chính rất đắt (LLM 70B) — thuê "thư ký nháp" rẻ là hời. Model 41M mỗi lượt đã rẻ sẵn → tiền thuê thư ký (chạy draft + verify + đồng bộ) cao hơn tiền tiết kiệm. Kết luận bạn ghi trong memo ("premise rejected: small model's low per-step overhead doesn't amortize draft+verify") chính xác là định lý này — giá trị của speculative tỉ lệ thuận với độ đắt mỗi bước của model chính.

5. Track G của bạn dưới ánh sáng lý thuyết

Thiết kế shallow-AR hybrid (4 encoder / 1 decoder + pointer/copy head) là một câu trả lời "đúng sách" cho đúng ba điểm yếu đã đo của CTC:

• 1 layer decoder AR → trả lại sự phối hợp tuần tự giữa các vị trí (chữa independence/omission/reorder) mà chỉ trả giá 1 lượt mỏng mỗi token — nằm giữa hai đường của đồ thị crossover.
• Pointer/copy head → với tên riêng (83% chép thẳng từ input theo đo đạc của bạn), cho model một "cần gạt" chọn giữa sinh từ vocab và chỉ tay vào vị trí nguồn rồi chép — né hoàn toàn bài toán exposure chữ hiếm (Module 04–05).
• ZH làm chuỗi chính (1×), VP làm feature đính kèm → tránh 2.4× thuế độ dài chuỗi.

Từ vựng để nhớ: đây là mẫu "AR mỏng trên nền encode dày" — giữ phần đắt (hiểu) chạy một lần, phần tuần tự (phối hợp) làm mỏng nhất có thể.

1. Trước khi bấm nút — 4 thứ phải có trên giấy

SOP bạn tự đúc kết đã gọi đủ tên: "defined objectives, data accountability, proof gates, stop criteria trước khi launch". Diễn giải thành checklist:

Thêm hai dòng "rẻ mà lãi": đóng băng config vào file version-hóa (tên run chứa thông tin: model, data version, effective batch, lr, seed) và chạy smoke 100 bước trước run dài — bắt lỗi OOM/tokenizer/dataloader với giá 5 phút.

2. Đọc "tướng" loss curve

Nhớ ghép với đường validation (hình ở Module 01): tướng train đẹp + val tách sớm = overfit / data train có vấn đề; train đẹp + val đẹp + eval hành vi tệ = bài của Module 13 (loss và chất lượng không phải một thứ).

3. Checkpoint: lưu thế nào, chọn thế nào

Case thật của bạn — style_gold_v5, chấm trên 9-chapter gate:

Quy tắc thực dụng:

• Lưu: định kỳ theo bước (không chỉ theo epoch) + giữ "best so far" theo metric quyết định (không phải theo train loss). Fine-tune ngắn thì lưu dày (như dãy 128/384/768 của bạn).
• Chọn: chấm mọi ứng viên trên cùng một eval set niêm phong; nếu 2 ứng viên trong khoảng nhiễu (Module 02 câu 4) → ưu tiên checkpoint sớm hơn (ít overfit hơn, thường generalize tốt hơn trên phân phối lạ).
• Eval đủ dày: eval quá thưa có thể trượt mất đỉnh giữa (nếu bạn chỉ chấm 128 và 768, bạn đã không bao giờ biết 384 tồn tại).

4. Thí nghiệm có kiểm soát: mẫu "2-arm + budget guard" của bạn

Run 130M capacity probe bạn thiết kế tháng 7 là mẫu đáng đóng khung, vì nó gói đủ 4 nguyên tắc:

1. Đổi đúng MỘT biến: hai arm (A9-scale 129.35M vs stock-scale 134.68M) — cùng data, cùng lịch train, cùng eval; khác duy nhất cấu hình cần so.
2. Chốt bảng kết quả trước khi chạy: "4-epoch table: chrF2 / BLEU / names / hygiene per arm, so với A9-41M e3, matched stock e3, Marian" — biết trước sẽ đọc gì thì không thể bẻ cong kết luận theo kết quả.
3. Budget guard cứng: ~$19–22 dự toán, hard stop $13/arm — thí nghiệm là mua thông tin, đặt giá trần cho thông tin đó.
4. Có baseline neo: so với các mốc đã biết (41M e3: chrF 63.065; Marian: 64.46) — không có neo thì mọi con số mới đều "trông cũng được".

Và nguyên tắc thứ năm nằm ở việc bạn đã làm trước đó: probe 90M 10k bước trước khi cam kết tiền lớn — với kết luận kỷ luật đáng nể: "90M vượt scratch local nhưng chưa vượt Hirashiba → chưa scale 150M". Không scale khi chưa thắng baseline ở cỡ hiện tại.

5. Reproducibility — run không ghi chép là run không tồn tại

Đi kèm MỖI checkpoint phải truy ra được:
  config đầy đủ (kiến trúc + optimizer + lr schedule + effective batch + seed)
  data pool version + gates report        tokenizer version (hợp đồng! — Module 04)
  git commit của code train               log loss/eval theo bước
→ tên run nên tự chứa phần cốt lõi: scratch_probe_90m_ffnup_lr005_bs32k_s1

Lý do không phải "gọn gàng cho đẹp": ba tuần sau, khi model hành xử lạ, câu hỏi luôn là "nó được train từ gì, bằng gì?" — và bạn đã trả lời được trong 30 giây thay vì một buổi khảo cổ. Đây cũng là điều kiện để so hai run cách nhau một tháng mà không tự lừa.

1. Phổ liên tục của "train tiếp"

2. Ba mức can thiệp: full FT · freeze-partial · LoRA

LoRA trong một hình

3. Catastrophic forgetting — và túi thuốc giải

Fine-tune trên data hẹp là kéo model về một góc không gian; kéo quá tay thì mất nền cũ ("quên thảm khốc"): dịch giọng mới rất hay, nhưng vỡ ở novel khác / câu dài / entity. Bốn thuốc, thường phối hợp:

• Ít bước + lr nhỏ — liều tối thiểu có tác dụng (bạn đã thấy: 384 bước đẹp, 768 bước hỏng — Module 09).
• Replay: trộn 5–20% data nền cũ vào batch fine-tune — nhắc bài liên tục.
• Anchor loss: cộng thêm một phần loss giữ model gần bản gốc — chính là "SFT anchor 0.4" trong recipe DPO-lite của bạn: 40% lực kéo dành cho "đừng rời xa hành vi SFT" trong khi phần preference kéo về hướng mới (Module 12).
• Regression gate: golden set niêm phong chấm TRƯỚC và SAU mỗi fine-tune (golden 29/30, 28/30 của bạn) — fine-tune là phẫu thuật; golden test là kiểm tra "không cắt nhầm dây thần kinh". Fine-tune nào không kèm regression gate là phẫu thuật không theo dõi hậu phẫu.

4. Chọn kỹ thuật nào — bảng quyết định

1. Hai chế độ distillation

2. Chọn teacher — bốn tiêu chí, có thứ tự

Multi-teacher: trộn nhiều teacher tăng độ phủ và giảm "di truyền tật một nhà" — nhưng phải tag provider từng row (gate provider-mix Module 03) và nhớ hệ quả đo lường: eval bằng reference của teacher X sẽ nịnh mọi model học từ X (Module 13 — quy tắc same-teacher bạn đã tự đặt).

3. Hai nhà máy data tổng hợp

Cùng tạo cặp (zh, vi) nhưng ngược chiều nhau về "bên nào là đồ thật":

Phối hợp kinh điển: seq-KD làm xương sống khối lượng, back-translation nêm thêm để kéo giọng văn về "văn người" — trộn theo tỉ lệ và tag nguồn gốc để gate mix soi được.

4. Student có vượt được teacher không?

Về "kiến thức thô": không — trần vẫn là teacher (Module 03). Nhưng có ba cửa hợp lệ khiến student đo được tốt hơn:

1. Chuyên hóa: teacher đa năng, student dồn toàn bộ 41M tham số cho đúng một domain → trong domain đó student "đặc" hơn, nhất quán hơn (ít dao động giọng/term hơn teacher vốn sáng tạo thất thường).
2. Selective distillation: không nuốt cả output teacher — lọc giữ phần tốt (rules, QE score, review) rồi mới train. Student học từ "teacher những ngày đẹp trời" → có thể vượt teacher-trung-bình. Các pool gold bạn xây (style_gold, gold4) chính là kỹ thuật này.
3. Ensemble tri thức: multi-teacher + data người → student tổng hợp thứ không teacher đơn lẻ nào có.

Còn lại là ảo giác đo: student "thắng" trên eval lấy reference từ chính phân phối data nó học — bài của Module 13.

1. SFT dạy "thế nào là tốt" — không dạy "cái nào tốt hơn"

Sau SFT, model của bạn dịch mượt. Lỗi còn lại toàn loại tinh vi: hai bản dịch đều "hợp lệ" nhưng một bản lệch nghĩa nhẹ, sai xưng hô, hơi văn dịch. SFT thêm không chữa được — vì cả hai kiểu đều xuất hiện trong data với tư cách "đáp án đúng". Thứ còn thiếu là tín hiệu so sánh: cho model xem từng cặp (chosen, rejected) trên cùng một nguồn và dạy nó nghiêng về bên chosen.

Bức tranh đầy đủ là RLHF (train reward model + PPO/GRPO) — bạn đã đánh giá đúng: overkill cho 57M, không có reward model, hạ tầng đắt. DPO là đường tắt: bỏ reward model, rút tín hiệu trực tiếp từ cặp preference.

2. DPO — đọc công thức từng mảnh

loss = −log σ( β · [ margin ] )

margin = (log π(chosen) − log π_ref(chosen)) − (log π(rejected) − log π_ref(rejected))
          └────────── "thiên vị chosen" ─────────┘   └───────── "thiên vị rejected" ────────┘
π     = model đang train        π_ref = bản SFT đóng băng làm mốc
β     = hệ số KL trong suy diễn DPO; đồng thời nhân logit loss     σ = sigmoid

Diễn nghĩa: mỗi log-ratio đo "so với bản gốc, model hiện tại đã nghiêng thêm về câu này bao nhiêu". Margin = nghiêng-về-chosen trừ nghiêng-về-rejected. DPO đẩy margin dương — thích chosen hơn rejected một cách tương đối, chứ không ép xác suất chosen tuyệt đối lên 1.

3. Data preference — gates riêng của nó

• Số lượng: gate 100–300 cặp sạch bạn đặt ra là hợp lý cho một trục lỗi; dưới đó nhiễu thắng tín hiệu (Module 03 câu 3 đã chứng minh vì sao từng cặp phải chắc tay).
• Hẹp chủ đề: mỗi đợt DPO một trục lỗi (vd riêng xưng hô, riêng văn dịch cứng). 300 cặp trải 10 loại lỗi = mỗi loại 30 cặp — không đủ cho loại nào; 300 cặp một loại = tín hiệu đậm đặc. Đây chính là khác biệt v1 vs DPO-lite.
• Cùng nguồn, khác đúng chỗ cần dạy: cặp lý tưởng chỉ khác nhau ở trục muốn dạy; khác nhau thêm ở chỗ khác là dạy nhầm thêm thứ khác.
• Đa người duyệt hoặc duyệt hai lượt: preference là "gu" — một reviewer gu lệch thì model học đúng cái gu lệch đó, rất khó phát hiện về sau.

4. Ghi chú cho MT nói riêng

Nghiên cứu bạn đã sưu tầm (CPO/ALMA-R, TIM, DPO-for-NMT/MBR) hội tụ về hai ý: (1) CPO ≈ DPO + thành phần giữ SFT — tức giới học thuật cũng đi đến "SFT anchor" như recipe của bạn; (2) cảnh báo WMT 2024: preference alignment có thể làm metric tự động dao động (BLEU/chrF lên xuống không phản ánh chất lượng) → chọn checkpoint sau DPO bằng hardcase + review người, không bằng BLEU — bạn đã ghi đúng điều này thành SOP; Module 13 cho nó nền móng.

1. Eval là hệ điều hành của project

Mọi quyết định bạn đưa ra — chọn checkpoint (Module 09), có scale không (Module 15), merge PR webMT không — đều đi qua một phép đo. Thước lệch một li, mọi quyết định lệch một dặm; vì thế eval đáng được đầu tư như code sản phẩm: có version, có niêm phong, có review queue — đúng những gì bạn đã làm với eval_locked 1 043 rows. Trước khi vào kỹ thuật, đóng khung lại trật tự bạn đã tự đúc kết (và là trật tự chuẩn của nghề):

Loss → chỉ để debug training. BLEU/chrF → phụ trợ: regression, sanity, so sánh thô. Quyết định chất lượng → blind review theo nguồn, entity preservation, severity — người chấm, có cấu trúc.

2. BLEU — tính tay một lần để biết nó mù chỗ nào

Ứng viên :  Hắn đi rồi                (3 token)
Reference:  Hắn đã đi rồi             (4 token)

1-gram: Hắn ✓  đi ✓  rồi ✓            → precision 3/3
2-gram: "Hắn đi" ✗   "đi rồi" ✓       → precision 1/2
Brevity penalty (phạt dịch ngắn): c=3 < r=4 → BP = e^(1−4/3) ≈ 0.72

BLEU-2 = 0.72 × (3/3 × 1/2)^(1/2) ≈ 0.72 × 0.707 ≈ 0.51

Bài dịch đúng nghĩa hoàn toàn mà chỉ được 0.51 vì thiếu chữ "đã". Ngược lại một bản chép đủ n-gram nhưng đảo logic có thể điểm cao hơn. BLEU đo trùng khớp bề mặt với MỘT reference — không đo nghĩa. Ba điểm mù kinh điển: (1) đồng nghĩa/diễn đạt khác bị phạt oan; (2) lỗi nghĩa nhỏ mà trùng chữ nhiều thì thoát; (3) nhạy cắt từ — tiếng Việt tách âm tiết kiểu khác nhau là điểm khác nhau.

chrF chấm F-score trên n-gram ký tự thay vì từ → né bài toán cắt từ (quý với zh không dấu cách + vi đa âm tiết), một phần credit cho biến thể gần đúng ("đã đi"/"đi") → ổn định hơn BLEU trên cặp zh-vi. Vì thế bạn ưu tiên chrF làm chỉ số phụ trợ chính là hợp lý. Neural metrics (COMET-style, học từ phán xét người) mạnh hơn nữa nhưng lưu ý: được train chủ yếu trên cặp ngôn ngữ giàu tài nguyên — với zh→vi văn tu tiên, hãy coi nó là một reviewer máy có gu riêng cần kiểm chứng, không phải chân lý.

3. Same-teacher bias — vòng lặp tự khen

4. Tháp eval — hệ thống bạn đang chạy, gọi đúng tên

Hai tầng trên cùng của bạn đã có công nghệ riêng đáng gọi tên:

• Blind review theo nguồn (không biết bản nào của model nào, chấm dựa trên câu gốc) với severity 0–3 và chọn winner — chuẩn WMT thu nhỏ. Tiêu chí bạn viết thành văn: fidelity trước fluency — không thưởng cho bản mượt mà sai nghĩa/sót ý/sai entity. Đây là hàng rào chống đúng loại lỗi mà BLEU tha bổng.
• Taxonomy lỗi bạn đặt cho style_gold_v5 — semantic_shift, hallucination, omission, entity_term, literal_idiom, modern_lexical, bad_vietnamese, too_free, source_noise, punct_quote — biến "cảm giác dở" thành phân phối đếm được, so được giữa hai model, và chỉ thẳng loại data cần bổ sung (Module 03/09).
• Paired comparison by-bucket (script compare_eval_runs của bạn): so cùng câu giữa hai model (khử nhiễu chọn mẫu — mạnh hơn hẳn so điểm trung bình hai lần chạy), rồi tách theo nguồn/bucket để trung bình không che thoái hóa cục bộ.

5. Một chút thống kê đủ dùng

• Golden 30 câu bắt được thoái hóa lớn (3/30 rớt là tín hiệu thật) nhưng không phân giải nổi chênh lệch nhỏ — đừng đọc "29/30 vs 28/30" như một khác biệt có nghĩa; nó là "cùng hạng".
• Chênh 0.3–0.5 chrF cần nhiều trăm–nghìn câu và/hoặc nhiều seed mới đáng tin (nhớ nhiễu seed 0.4 chrF ở Module 02). Trên 60 câu review, hãy tin phân phối severity và số winner hơn là điểm trung bình.
• So paired luôn thắng unpaired: cùng câu, hai model, đếm thắng/thua/hòa — mỗi câu tự làm đối chứng của nó.

1. Inference nghẽn ở đâu?

Không còn gradient, không còn Adam (Module 02) — VRAM chỉ còn weights + KV cache + activations mỏng. Nhưng xuất hiện nút nghẽn mới: decode batch-1 phải đọc lại toàn bộ weights cho MỖI token sinh ra (mỗi lượt forward chạm hết các ma trận). Phép nhân thì GPU thừa sức — khiêng weights từ VRAM vào compute unit mới là việc nặng:

tok/s (trần lý thuyết, batch 1) ≈ băng thông VRAM ÷ dung lượng model phải đọc mỗi token

→ Giảm bytes (quantize) = tăng tốc GẦN NHƯ TỈ LỆ THUẬN, chưa cần kernel nào thông minh hơn
→ Batch nhiều câu = chia đều một lần đọc weights cho nhiều token → throughput server tăng vọt
  (đổi bằng latency từng câu — trade-off bạn thấy rõ trong B8/B192/B576 của webMT)

2. Quantization — tính tay một lần

Ý tưởng: thay float bằng số nguyên nhỏ + một hệ số scale chung cho cả nhóm:

Nhóm weights:  [−0.80, 0.31, 0.02, 0.60]        (fp16/fp32)
scale = max|w| ÷ 127 = 0.80 ÷ 127 ≈ 0.0063
w_q   = round(w ÷ scale) = [−127, 49, 3, 95]     (int8 — 1 byte/số)
khôi phục ≈ w_q × scale = [−0.800, 0.309, 0.019, 0.599]   → sai số ~0.001

Toàn bộ các format bạn dùng chỉ là biến tấu của công thức trên — khác nhau ở phạm vi nhóm chung scale và độ rộng số nguyên:

Tên ghép kiểu int8_float32 đọc là: weights int8, phép tính/tích lũy float32 — lai để giữ chất lượng: chỗ nhạy (accumulate, layernorm, logits) vẫn float. Còn PTQ vs QAT: mọi export trên của bạn là PTQ (quantize sau train — nhanh, đủ tốt cho int8/Q8); QAT (train có mô phỏng quantize) chỉ cần khi ép xuống 4-bit mà chất lượng rơi — như dòng Unsloth QAT GGUF bạn đã gặp.

Luật sắt đi kèm: golden test chạy trên artifact CUỐI — đúng file int8/Q4 sẽ ship, không phải bản fp16 "gần giống". Bạn đã làm chuẩn ("quality parity trước khi update Space"), và vụ monkey-patch _remove_pad_weights (bug pad-at-0 vocab trim của converter CT2 với Marian) là bằng chứng sống: công cụ convert cũng có bug theo model — chỉ golden end-to-end mới bắt được.

3. Trong VRAM hay tràn ra ngoài — câu hỏi trước mọi câu hỏi

Ráp với mục 1 thành checklist tốc độ theo thứ tự: (1) vừa VRAM chưa? → (2) bytes/param giảm được nữa không (quantize)? → (3) KV cache có phình theo context không (giới hạn capacity/quantize KV)? → (4) batch được không (throughput)? → (5) rồi mới đến kernel/graph (fused, immediates, bind-group cache như webMT — ăn thêm 5–25%, không đổi bậc).

4. Bài học bench từ webMT — đo cho đúng đã, nhanh tính sau

• Thermal drift phá A/B trên laptop: đo A xong mới đo B thì B luôn thiệt (máy đã nóng, clock tụt). Fix của bạn — alternate arm order per round (đảo thứ tự A/B mỗi vòng để trung bình triệt tiêu drift) — chính là randomized experiment design; vụ "12% subgroup flip hóa ra là one-sided ramp" là học phí đã đóng, đừng đóng lại. Kèm quy trình iPhone của bạn: nghỉ ~1 phút giữa các round, chạy 2–3 round.
• Khoan tin edge case: B1 +164.74% là CPU-dispatch edge case — không ngoại suy (Module 08 đã dùng); báo cáo theo phân phối batch thật.
• Đường ống quantize cũng tốn tài nguyên: chuyển f16→Q8 trực tiếp từng hàng (không materialize Float32 toàn cục) giảm peak memory 51–66 MiB và thời gian load 161.6→64.4ms — trên mobile, load path là một phần của sản phẩm, không chỉ steady-state.
• Không bit-exact giữa hai routing (sg on/off) là bình thường — floating-point cộng khác thứ tự; định nghĩa "tương đương" bằng token-level golden (0 mismatch trên 3.3M token như bạn đã gate) chứ không phải so bit.

5. Ma trận triển khai của bạn

Quy luật chung rút từ bảng: format đi theo phần cứng đích và mức kiểm soát của bạn với nó, không có "format tốt nhất" tuyệt đối. Và mỗi ô của bảng đều phải có golden test riêng của nó (tokenizer contract Module 04 + parity mục 2).

1. Scaling laws — bản đồ ba trục N, D, C

Kết quả thực nghiệm lặp lại bền vững của cả ngành: loss giảm đều và dự đoán được (theo hàm mũ âm) khi tăng N (tham số), D (data), C (compute) — miễn là không trục nào bị nghẽn. Điều đáng tiền nằm ở vế sau: tăng một trục trong khi trục kia đứng yên thì đường cong gãy ngang:

Áp thẳng vào chương trình của bạn — và thấy các quyết định đã đúng trình tự:

• Probe 90M: "vượt scratch local nhưng chưa vượt Hirashiba → không scale 150M" — đúng logic đường đỏ: chưa thắng baseline ở cỡ này thì cỡ to hơn không phải câu trả lời.
• 2-arm 130M đối chiếu A9-41M (chrF 63.065) và Marian (64.46): nếu 130M chỉ nhích nhẹ so với 41M mà vẫn thua Marian → nút thắt nằm ở data/recipe, không phải capacity — tiền tiếp theo nên rót vào pool + distillation (Module 03, 10), không phải vào N.
• Gate bạn đặt cho 150M–220M (baseline comparison + entity/long-row stress) chính là "đo xem mình đang ở đường đỏ hay đường ngọc".

2. Với model ship đi: nhỏ-mà-no thắng to-mà-đói

Chinchilla tối ưu cho chi phí train. Nhưng model của bạn ship tới người đọc — chi phí thật nằm ở inference, trả mỗi token, mãi mãi (băng thông — Module 14). Vì thế thế giới model nhỏ dùng chiến lược "overtrain": train model nhỏ lâu hơn mức Chinchilla trên nhiều data hơn — mua chất lượng bằng compute một lần, giữ chi phí serve thấp vĩnh viễn. Đây là chỗ đứng lý thuyết cho mục tiêu 15–30M "chất lượng bằng medium, nhanh hơn" bạn từng đặt: đường đến đó là data tốt hơn + distill khéo hơn + train no hơn, không phải thêm param. Bảng cân nhắc mỗi lần muốn tăng cỡ:

3. Những hướng mới trên bản đồ cũ

• Diffusion LM (DiffusionGemma): sinh cả "canvas" token rồi tinh chỉnh song song qua nhiều vòng khử nhiễu — họ hàng trực tiếp của CMLM/iterative-NAT bạn nghiên cứu cho vp2vi (Module 08): cùng triết lý "song song + lặp", khác công thức toán. Số vòng = núm chỉnh chất lượng/tốc độ — đúng cái bạn bench: 16/32/48 steps → 6.7/3.4/2.2 tok/s. Kết luận thực dụng của bạn giữ nguyên giá trị: trên 12GB hiện tại, transformer MoE Q4 vẫn nhanh hơn; diffusion đáng theo dõi (quant nhỏ hơn, VRAM to hơn, kernel chín hơn) chứ chưa đáng đặt cược.
• MoE (Gemma A4B): 26B tham số nhưng mỗi token chỉ kích hoạt ~4B → đọc ít weights mỗi token → nhanh theo đúng mental model bandwidth của Module 14. MoE là cách "to mà không trả thuế to mỗi token" — chưa liên quan model MT nhỏ của bạn, nhưng là lý do vì sao con 26B lại chạy nổi trên laptop.
• MTP (multi-token prediction): AR đoán nhiều token mỗi lượt bằng head phụ — cần train head từ đầu, llama.cpp mới hỗ trợ Qwen 3.5/3.6; không áp được cho DiffusionGemma lẫn Marian của bạn (đúng như bạn đã tra). Nếu một ngày bạn build model AR from-scratch thế hệ mới, MTP là thứ đáng cân nhắc từ lúc thiết kế, không phải gắn sau.

4. Bản đồ quyết định tổng — treo tường

5. Mười điều, nếu chỉ được nhớ mười điều

Hết 15 module. Giáo trình này không dạy bạn điều gì bạn chưa từng chạm — nó gắn tên, gắn khung và gắn số cho những trực giác bạn đã trả học phí để có. Lần tới khi log hiện loss 0.693, khi có người rủ scale lên 200M, khi teacher mới chào hàng — mở đúng module, đọc 10 phút, quyết trong 5. Chúc luyện đan thành công. ⚗