AICB-P2T3 · Ngày 21 · Chương 5 — Fine-tuning & An Toàn
Đi kèm deck day21-fine-tuning-llms-lora-qlora.tex (90 trang · 20 mục).
Một câu tóm tắt lab: fine-tune một model mở bằng LoRA — rồi chứng minh nó thắng
được chính model đó khi đã được prompt tử tế. Nếu không chứng minh được, phát hiện ra
điều đó cũng được tính điểm đầy đủ.
Submission snapshot — Nguyễn Tuấn Đức · 2A202601380
Đây là repo nộp bài cho Lab 21. Bằng chứng chạy Kaggle nằm trong
lab21.ipynb; tại máy local, notebook này được lưu ở
D:\codein\misp@ce\aiaction\Day21-Track3-2A202601380-NguyenTuanDuc\lab21.ipynb.
Notebook ghi nhận Tesla T4, full evaluation và quá trình tạo artefact. Các số liệu nộp
bài được lưu trong results/ và được diễn giải chi tiết ở
submission/REPORT.md. Adapter, report, results và notebook
đã được công bố công khai tại
Hugging Face model repository.
Kiểm chứng
Kết quả
Unit test + gatekeeper local
26 PASS, 1 WARN, 0 FAIL
Target: base + optimized prompt
0.765
Target: LoRA correct
0.965
Chênh target
+0.200
Regression: base + optimized prompt
0.7578
Regression: LoRA correct
0.5889
Chênh regression
−0.169
Verdict
FAILED do regression gate
Kết quả này đạt yêu cầu pipeline và đánh giá của lab, nhưng không phải là bằng chứng
để deploy adapter như thay thế an toàn cho base model: LoRA tăng mạnh hiệu quả triage,
đồng thời làm giảm năng lực regression vượt tolerance 0.020. Verdict FAILED được giữ
nguyên và phân tích trong report; đó là điều kiện liêm chính của bài lab, không phải lỗi
thực thi. Các artefact đã có gồm mask proof, baseline đóng băng, bốn run công bằng,
autopsy, verdict, qualitative cases và adapter correct.
Kỳ vọng là Ready to submit; lời nhắc về verdict FAILED là warning hợp lệ. Khi đẩy
lên GitHub, cần force-add results/ và adapters/correct/ vì .gitignore bỏ qua các
artefact tái sinh. adapter_model.safetensors lớn hơn 100 MB, do đó dùng Git LFS hoặc
đưa adapter lên Hugging Face Hub; không commit cache model, .env, token hay checkpoint
optimizer. Xem rubric.md để biết cấu trúc và URL được chấp nhận.
Hai câu hỏi lab bắt bạn trả lời
Phần được tính loss có đúng là câu trả lời không? (NB1 — chạy được trên CPU)
Bản fine-tune có thắng base model đã prompt tử tế không — và bạn có phát hiện được
nếu nó không thắng? (NB2 đóng băng mốc, NB5 phán quyết)
Mọi thứ còn lại là chi tiết kỹ thuật phục vụ hai câu này.
Chọn tier
Tier
Phần cứng
Model
VRAM (bf16 LoRA)
Chạy được gì
CPU
không GPU
Qwen3.5-0.8B
—
NB1 + toàn bộ test
LAPTOP
GPU 8–12 GB
Qwen3.5-2B
~5 GB
tất cả
T4(mặc định)
Colab Free T4 16 GB
Qwen3.5-4B
~10 GB
tất cả
BIGGPU
L4 / A100 / 3090+
Qwen3.5-9B
~22 GB
tất cả, nhanh hơn
Đổi tier = sửa COMPUTE_TIER trong .env. Chi tiết: HARDWARE-GUIDE.md.
Không có GPU? Vẫn làm được NB1 và toàn bộ test suite — đó là phần lab kiểm tra
thứ quyết định kết quả nhiều nhất. Phần huấn luyện thì dùng Colab Free T4.
Mỗi lần repo đổi, hãy mở LẠI tab (reload), đừng chỉ reconnect. Colab đọc mã
notebook từ GitHub đúng một lần, lúc URL được mở; reconnect, đổi runtime hay máy ảo
mới đều không nạp lại. Ô Setup cũ vẫn chạy "xanh" và vẫn in đúng commit mới nhất — vì
chính nó git pull repo — nhưng cài theo danh sách gói cũ. Lỗi sẽ nổ ~10 phút sau,
bên trong get_peft_model(). Xem F-19 trong SIMULATION-FINDINGS.md.
Máy cá nhân
bash
1git clone https://github.com/hieutrungdao/Day21-Track3-Finetuning-Lab.git
2cd Day21-Track3-Finetuning-Lab
3cp .env.example .env
45# Không GPU — NB1 + test (đủ để bắt đầu, ~2 phút)6make setup-cpu &&make smoke &&make nb1
78# Có GPU — cài torch cho CUDA của bạn TRƯỚC (xem đầu requirements.txt), rồi:9make setup &&make smoke
10make pipeline # NB1 -> NB5, ~100-130 phút trên T4 (đo thật, xem docs/)11make verify # cổng kiểm tra trước khi nộp
Các lệnh make
make setup-cpu Cài bản CPU (NB1 + test)
make setup Cài đầy đủ (GPU)
make smoke Import + data + unit test, không cần GPU
make nb1 .. nb6 Chạy từng notebook
make pipeline CORE: NB1 -> NB5
make verify Gatekeeper trước khi nộp
make clean Xoá artefact sinh ra (giữ corpus gốc)
đóng băng eval + đo baseline (a) và (b) trước khi train
3
03_train_correct
~15–25 ph
✓
cấu hình vùng-không-hối-tiếc; in layer_types của chính model
4
04_misconfig_autopsy
~45–60 ph
✓
3 run đối chứng cùng step: attn_only · wrong_lr · qlora
5
05_evaluate_and_verdict
~21 ph
✓
4 nhóm · bảng 3 baseline · cổng hồi quy · chấm 3 run đối chứng
6
06_merge_and_serve
~10 ph
✓
merge + assert không tụt điểm + hot-swap adapter (tuỳ chọn)
Ngân sách thật: ~100–130 phút cho core trên T4 free (lần đầu cộng thêm ~1,5 ph tải
9,32 GB trọng số). Đo thật 2026-08-20 với fp16 — xem docs/MEASURED-T4-2026-08-20.md.
Đây là khoảng: cùng một cấu hình 30 step chạy 1456 s rồi 1021 s trên đúng mã đó,
vì T4 free bị chia sẻ. Sinh văn bản chiếm phần lớn: tập eval được sinh ba lần —
baseline (a), baseline (b), và bản fine-tune. Đó là cái giá của thiết kế ba-baseline,
và nó đáng.
Hai cần gạt khi bạn bị bó thời gian. Cả hai đều để mặc định khi nộp bài;
results/ ghi lại nếu bạn chạy chế độ rút gọn.
bash
1EVAL_LIMIT=8make pipeline # ít mẫu eval hơn -> phần SINH ngắn lại2EPOCHS=1make pipeline # nửa số step -> phần HUẤN LUYỆN ngắn lại
Đo thật: EPOCHS=1 EVAL_LIMIT=8 chạy NB1+NB2+NB3+NB5 hết 17 phút (13s / 1,9 ph /
9,2 ph / 5,7 ph). Thêm NB4 thì cộng khoảng 25–30 ph nữa — ba run đối chứng vẫn phải
train thật, EVAL_LIMIT không rút ngắn phần đó.
EPOCHS áp cho cả NB3 lẫn NB4 — không thể chỉnh một nửa. Đó là cố ý: ba run đối
chứng chỉ có nghĩa khi chúng chạy đúng bằng số step của correct, và make verify
đọc runs.csv để kiểm tra điều đó thật sự đã xảy ra.
Nếu NB4 bị đứt giữa chừng, đừng chạy lại từ đầu. Adapter nào đã lưu thì được bỏ
qua; FORCE_RETRAIN=1 để train lại tất cả, ONLY=qlora để train lại đúng một run.
NB1–NB5 là core. NB6 là tuỳ chọn (có điểm thưởng).
notebooks/*.py là bản gốc (jupytext py:percent) — chạy trực tiếp bằng python
được, mở bằng Jupyter cũng được. colab/*.ipynb sinh ra từ chúng bằng make colab.
Bài toán
Ticket CSKH tiếng Việt → JSON triage 4 trường (intent, urgency, product,
sentiment). Chọn bài này vì mọi nhóm điểm đều có thang khách quan — không cần
LLM judge, nên không có "điểm cho không":
Nhóm
Đo bằng
target
độ chính xác từng trường so với nhãn
regression
15 câu hỏi kiến thức/chỉ dẫn phổ thông — fine-tune không được làm hỏng
format
JSON parse được + đủ 4 khoá
latency
ms/mẫu, greedy decode
Đổi dataset của riêng bạn
Được khuyến khích — nhưng chạy hết một lượt với corpus mặc định trước để có mốc.
Khi đổi: thêm data/CUSTOM_DATASET.md mô tả nguồn, kích thước và cách khử nhiễm; nếu
không, make verify sẽ báo FAIL vì checksum tập eval đã đổi. (Đó là chủ ý: sửa tập eval
sau khi thấy kết quả sẽ làm hỏng toàn bộ phép so sánh.)
Nộp bài
Xem rubric.md — 100 điểm + tối đa 15 thưởng, ba lựa chọn định dạng nộp.
Chạy make verify trước khi nén file: nó kiểm tra artefact và kiểm tra rằng phép so
sánh bạn được chấm là một phép so sánh công bằng.
Điểm không nằm ở chỗ fine-tune của bạn thắng. Điểm nằm ở chỗ bạn biết nó có thắng hay không.
