Mở đầu: Bài học cuối cùng của Track A — vận hành, không chỉ xây dựng
Model đã qua đủ 5 giai đoạn trước: thu thập dữ liệu (Bài 2), huấn luyện (Bài 3), alignment (Bài 4), red-team/benchmark (Bài 5) — giờ là lúc đưa nó ra phục vụ người dùng thật. Đây là nơi tư duy kỹ sư phần mềm truyền thống (versioning, deploy an toàn, rollback) gặp gỡ đặc thù của AI: một "bug" ở đây không phải lúc nào cũng là lỗi logic rõ ràng — nó có thể là "model trả lời tệ hơn một chút" mà chỉ số liệu mới phát hiện ra.
Bài học này khép lại Track A bằng 4 mảnh ghép vận hành: cách đánh version cho model, kỹ thuật canary/A-B deploy để phát hiện vấn đề trước khi ảnh hưởng toàn bộ người dùng, cơ chế rollback tức thời, và cách ước lượng chi phí hạ tầng — mảnh ghép cuối cùng khép lại vòng lặp chi phí đã mở ra từ Bài 1.
1. Semantic Versioning cho Model/Weight
Phần mềm truyền thống dùng semantic versioning (MAJOR.MINOR.PATCH) để báo hiệu mức độ thay
đổi. Model AI cũng cần một quy ước tương tự — nhưng "thay đổi" ở đây không phải dòng code mà là trọng số
(weights), dữ liệu huấn luyện, và cấu hình alignment:
{
"modelName": "assistant",
"version": "3.2.1",
"changeType": {
"major": "Kiến trúc/kích thước model thay đổi, hoặc dữ liệu train làm lại từ đầu",
"minor": "Thêm dữ liệu mới đáng kể hoặc chạy thêm 1 vòng RLHF, giữ kiến trúc cũ",
"patch": "Vá lỗi cụ thể (ví dụ 1 lớp jailbreak mới phát hiện ở Bài 5), không train lại toàn bộ"
},
"weightsChecksum": "sha256:9f8a...",
"trainingDataSnapshot": "corpus-v7-2026-06",
"benchmarkReportRef": "benchmark-report-v3.2.1.json"
}
2. Canary / A-B Deploy
Thay vì đẩy phiên bản mới cho 100% người dùng ngay lập tức, canary deploy cho phiên bản mới phục vụ một phần nhỏ traffic trước (ví dụ 5%), so sánh các chỉ số (tỷ lệ lỗi, độ trễ, benchmark chất lượng) với phiên bản đang chạy ổn định, rồi mới tăng dần tỷ lệ nếu mọi thứ ổn:
function nextCanaryTrafficPct(currentPct, errorRatePct, errorThresholdPct) {
if (errorRatePct > errorThresholdPct) {
return currentPct; // dừng tăng, KHÔNG tự động rollback — cần con người xác nhận
}
return Math.min(100, currentPct + 15); // healthy -> tăng dần 15%/lần kiểm tra
}
Đây chính xác là cơ chế đứng sau demo tương tác ở mục 5 — traffic canary chỉ tăng khi tỷ lệ lỗi dưới ngưỡng an toàn.
3. Rollback Khi Phát Hiện Regression
Khi metric của canary vượt ngưỡng an toàn, hệ thống cần khả năng đưa 100% traffic quay lại phiên bản ổn định NGAY LẬP TỨC — không chờ điều tra xong nguyên nhân gốc rễ trước (đó là việc làm SAU khi đã rollback, không phải điều kiện để rollback):
- Tiêu chí kích hoạt: tỷ lệ lỗi/độ trễ vượt ngưỡng định trước, hoặc benchmark tự động (Bài 5) phát hiện điểm an toàn giảm đột ngột.
- Tốc độ: rollback phải là thao tác gần như tức thời (đổi route traffic), KHÔNG phải deploy lại từ đầu — đó là lý do version cũ vẫn phải giữ chạy song song trong giai đoạn canary.
- Sau rollback: điều tra nguyên nhân, vá lỗi, tạo version PATCH mới, và lặp lại canary từ đầu — không bao giờ đẩy thẳng phiên bản đã rollback trở lại 100% traffic.
4. Ước Lượng Chi Phí Hạ Tầng
Bài 1 đã chỉ ra huấn luyện là chi phí MỘT LẦN còn phục vụ (serving) là chi phí LIÊN TỤC. Ở bước vận hành này, ta cần công cụ ước lượng cụ thể hơn để ra quyết định — ví dụ khi nào nên dùng model nhỏ hơn (rẻ hơn, nhanh hơn) thay vì model lớn nhất hiện có:
function estimateMonthlyServingCost(requestsPerDay, costPerThousandRequests, gpuHourFleetCost) {
const requestCost = (requestsPerDay / 1000) * costPerThousandRequests * 30;
return requestCost + gpuHourFleetCost * 24 * 30; // hạ tầng GPU chạy 24/7 phục vụ traffic
}
// So sánh nhanh: model lớn (chất lượng cao hơn, costPerThousandRequests cao,
// gpuHourFleetCost cao) vs model nhỏ hơn (rẻ hơn nhưng chất lượng thấp hơn) —
// quyết định phụ thuộc benchmark chất lượng (Bài 5) có đủ đáp ứng yêu cầu
// sản phẩm hay không, KHÔNG chỉ dựa vào chi phí đơn thuần.
| Tiêu chí | Model lớn | Model nhỏ |
|---|---|---|
| Chi phí inference/request | Cao | Thấp |
| Chất lượng câu trả lời | Thường cao hơn | Có thể thấp hơn ở tác vụ phức tạp |
| Độ trễ | Cao hơn | Thấp hơn |
| Phù hợp khi nào | Tác vụ phức tạp, ít nhạy cảm về chi phí/độ trễ | Tác vụ đơn giản/lặp lại, cần phản hồi nhanh, quy mô lớn |
5. Thực hành tương tác: Fleet Dashboard
Bật "Có lỗi tiềm ẩn" để mô phỏng một canary có bug (chỉ lộ rõ sau vài bước), rồi bấm "Bước tiếp theo" nhiều lần và quan sát: traffic canary tự tăng dần khi khoẻ mạnh, cảnh báo đỏ xuất hiện ngay khi tỷ lệ lỗi vượt ngưỡng, và bấm "Rollback ngay" để xem toàn bộ traffic quay về v2 tức thời:
export function computeCanaryMetrics(step, buggy) {
if (!buggy) return { errorRatePct: Math.min(1.2, 0.4 + step * 0.02), latencyMs: Math.min(130, 115 + step) };
const regressionSteps = Math.max(0, step - 1); // bug chỉ lộ ra từ bước 2
return { errorRatePct: 0.5 + regressionSteps * 1.8, latencyMs: 120 + regressionSteps * 20 };
}
Nếu bạn muốn xem góc nhìn "đánh giá liên tục sau deploy" ở tầm ứng dụng AI Engineer (không chỉ hạ tầng), xem thêm Series 16 — MLOps & Evaluation. Bài 13 (Capstone) của series này sẽ ghép chính cơ chế rollback ở đây với 1 agent tự động giám sát và tự kích hoạt rollback — không cần con người bấm nút.
Tải file code thực hành minh họa bài học
File JavaScript aisys-fleet-dashboard.js — logic metric canary/stable, ramp traffic, và
rollback dùng trong bài:
📖 Tài liệu tham khảo
- Canary deployment: Martin Fowler — Canary Release — khái niệm gốc của kỹ thuật triển khai dần ở mục 2.
- MLOps vòng đời model: ml-ops.org — MLOps Principles — thực hành versioning/rollback cho hệ thống ML trong công nghiệp.
- Site Reliability Engineering: Google — Site Reliability Engineering (sách online miễn phí) — nguyên lý rollback-trước-điều-tra-sau ở mục 3 vay mượn trực tiếp từ SRE truyền thống.
Bình luận