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.


📚 Điều kiện tiên quyết
Nên đọc Bài 5 trước — bảng điểm benchmark ở đó chính là tiêu chí để quyết định 1 phiên bản model có đủ điều kiện triển khai hay không, được dùng lại ở mục 2 bài này.

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:

model-version-schema.json
{
  "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"
}
⚠️ Vì sao không thể chỉ "ghi đè" model cũ
Nếu không version hoá rõ ràng, khi phát hiện regression sau deploy, đội vận hành sẽ không biết chính xác phiên bản NÀO đang chạy, dùng dữ liệu train NÀO, đã qua benchmark NÀO — khiến việc điều tra sự cố (và rollback đúng đích) gần như bất khả thi. Mỗi model version phải là bất biến (immutable) — không bao giờ sửa trực tiếp, chỉ tạo version mới.

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:

canary-ramp.js
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.
🕳️ Cạm bẫy: Cố "sửa nóng" thay vì rollback ngay
Sai lầm phổ biến là cố "sửa nóng" (hotfix) ngay trên phiên bản đang gặp sự cố thay vì rollback ngay. Nguyên tắc vận hành đúng: LUÔN rollback về phiên bản đã biết là ổn định trước, giảm thiểu tác động tới người dùng, rồi mới bình tĩnh điều tra nguyên nhân trên môi trường tách biệt. Vá lỗi giữa lúc đang cháy nhà thường tạo ra lỗi MỚI chồng lên lỗi cũ.

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ó:

infra-cost-estimate.js
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:

🚦 Fleet Dashboard — v2 (Stable) vs v3 (Canary)
Bước hiện tại: 0
aisys-fleet-dashboard.js (trích)
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 về aisys-fleet-dashboard.js

📖 Tài liệu tham khảo

Bài viết liên quan trong series

Bài 5: Red-Teaming & Đánh Giá Benchmark Bài 7: Tool-Calling — Thiết Kế Interface Tool Quay lại Lộ trình Kỹ Thuật Hệ Thống AI

Bình luận