Hạ tầng quản lý phiên bản mô hình: Quản lý artifact ML ở quy mô lớn

Cập nhật ngày 11 tháng 12, 2025

Cập nhật tháng 12/2025: MLflow 3.0 mở rộng registry cho AI tạo sinh và AI agent—kết nối mô hình với phiên bản mã nguồn chính xác, prompt, kết quả đánh giá và metadata triển khai. Quản lý phiên bản mô hình giờ đây không chỉ theo dõi trọng số mà còn cả các adapter đã fine-tune, template prompt và cấu hình retrieval. Các LLM với trọng số hàng trăm GB đòi hỏi hạ tầng chuyên biệt vượt xa Git.

MLflow 3.0 đã mở rộng model registry để xử lý các ứng dụng AI tạo sinh và AI agent, kết nối mô hình với phiên bản mã nguồn chính xác, cấu hình prompt, kết quả đánh giá và metadata triển khai.¹ Sự phát triển này phản ánh một thay đổi căn bản trong ý nghĩa của "quản lý phiên bản mô hình"—từ việc theo dõi các file pickle đơn giản sang quản lý các hệ thống phức tạp với nhiều adapter đã fine-tune, template prompt và cấu hình retrieval. Các tổ chức vận hành AI production cần hạ tầng quản lý phiên bản không chỉ trọng số, mà còn toàn bộ ngữ cảnh cần thiết để tái tạo và triển khai mô hình một cách đáng tin cậy.

Khác với quản lý phiên bản phần mềm truyền thống, quản lý phiên bản mô hình ML liên quan đến việc theo dõi các file nhị phân khổng lồ, cấu hình huấn luyện phức tạp, phiên bản dataset và các metric đánh giá—tất cả trong khi duy trì yêu cầu về khả năng tái tạo và tuân thủ.² Thách thức này nhân lên với LLM khi các mô hình fine-tune phát triển nhanh chóng và prompt engineering thêm một lớp artifact khác cần quản lý phiên bản.

Tại sao quản lý phiên bản mô hình quan trọng

Các hệ thống ML production thất bại một cách âm thầm. Mô hình suy giảm theo thời gian, các phiên bản fine-tune hoạt động kém hơn dự kiến, và nếu không có quản lý phiên bản đúng cách, đội ngũ không thể xác định điều gì đã thay đổi hoặc rollback về trạng thái ổn định đã biết.

Thách thức quản lý phiên bản

Artifact nhị phân: Trọng số mô hình dao động từ vài megabyte cho ML cổ điển đến hàng trăm gigabyte cho các mô hình ngôn ngữ lớn. Git không thể xử lý các file này hiệu quả; hạ tầng chuyên biệt trở nên thiết yếu.

Bùng nổ cấu hình: Một mô hình đơn lẻ bao gồm mã huấn luyện, hyperparameter, tiền xử lý dữ liệu, feature engineering và cấu hình triển khai. Bất kỳ thay đổi nào cũng có thể ảnh hưởng đến hành vi của mô hình.

Phụ thuộc dataset: Chất lượng mô hình phụ thuộc vào dữ liệu huấn luyện. Không có quản lý phiên bản dataset, việc tái tạo mô hình trở nên bất khả thi ngay cả với mã nguồn giống hệt.

Liên kết đánh giá: Các metric hiệu suất trên tập test cụ thể quyết định việc triển khai. Những metric đó phải được liên kết vĩnh viễn với phiên bản mô hình.

Yêu cầu kinh doanh

Khả năng tái tạo: Các yêu cầu quy định trong tài chính và y tế đòi hỏi khả năng tái tạo chính xác phiên bản mô hình đã triển khai tại bất kỳ thời điểm nào.³

Khả năng kiểm toán: Tuân thủ đòi hỏi truy vết các mô hình đã triển khai ngược về dữ liệu huấn luyện, mã nguồn và người quyết định phê duyệt triển khai.

Khả năng rollback: Các sự cố production đòi hỏi quay lại phiên bản mô hình trước trong vài phút, không phải hàng giờ.

Cộng tác: Nhiều data scientist làm việc trên cùng một mô hình cần quyền sở hữu rõ ràng và giải quyết xung đột cho các artifact mô hình.

Kiến trúc model registry

Model registry đóng vai trò như kho lưu trữ trung tâm quản lý vòng đời của mô hình ML từ phát triển đến production:⁴

Các thành phần cốt lõi

Quản lý phiên bản: Mỗi phiên bản mô hình nhận một định danh duy nhất, thường kết hợp tên mô hình với phiên bản ngữ nghĩa (v1.2.3) hoặc định danh dựa trên hash.

Lưu trữ metadata: Tham số huấn luyện, metric đánh giá, lineage dữ liệu và lịch sử triển khai được lưu trữ cùng với artifact mô hình.

Lưu trữ artifact: Trọng số mô hình, file cấu hình và các asset liên quan được lưu trong object storage có khả năng mở rộng (S3, GCS, Azure Blob).

Quản lý vòng đời: Mô hình chuyển đổi qua các giai đoạn—development, staging, production, archived—với các kiểm soát quản trị tại mỗi chuyển đổi.

Quy trình registry

Training Job → Register Model → Staging Review → Production Deployment
     ↓              ↓               ↓                    ↓
  Metrics      Version ID      Approvals          Traffic Routing
  Logged       Generated       Recorded            Monitored

Đăng ký: Pipeline huấn luyện tự động đăng ký các mô hình thành công với metadata liên quan: - ID training run và ngữ cảnh experiment - Hyperparameter và cấu hình - Metric đánh giá trên dữ liệu held-out - Tham chiếu phiên bản dữ liệu - Hash commit mã nguồn

Staging: Các mô hình ứng viên trải qua validation trước production: - Testing tự động so với benchmark - Review thủ công cho các ứng dụng nhạy cảm - A/B testing so với mô hình production hiện tại - Profiling hiệu suất cho độ trễ inference

Promotion: Các mô hình được phê duyệt triển khai lên production: - Traffic dần chuyển sang phiên bản mới - Monitoring phát hiện suy giảm - Rollback kích hoạt nếu metric giảm

So sánh các nền tảng

MLflow

MLflow cung cấp model registry mã nguồn mở toàn diện nhất:⁵

Tính năng Model Registry: - Kho mô hình tập trung với quản lý phiên bản và alias - Theo dõi lineage (experiment → run → model) - Chuyển đổi stage (Staging, Production, Archived) - Annotation và gắn tag metadata - REST API cho truy cập theo chương trình

Cải tiến MLflow 3.0: - Entity LoggedModel kết nối mô hình với mã nguồn, prompt và đánh giá - Tracing nâng cao cho ứng dụng AI tạo sinh - Hỗ trợ agent cho các hệ thống AI phức tạp - Databricks cung cấp phiên bản enterprise được quản lý

Ví dụ quy trình:

import mlflow

# Log model trong quá trình huấn luyện
with mlflow.start_run():
    mlflow.log_params({"learning_rate": 0.001, "epochs": 10})
    mlflow.log_metrics({"accuracy": 0.95, "f1": 0.92})
    mlflow.pyfunc.log_model("model", python_model=trained_model)

# Đăng ký vào model registry
model_uri = f"runs:/{run_id}/model"
mlflow.register_model(model_uri, "fraud-detection-model")

# Promote lên production
client = mlflow.tracking.MlflowClient()
client.transition_model_version_stage(
    name="fraud-detection-model",
    version=3,
    stage="Production"
)

Phù hợp nhất cho: Các tổ chức muốn khả năng MLOps toàn diện với sự linh hoạt của mã nguồn mở.

Weights & Biases

W&B nhấn mạnh experiment tracking với quản lý phiên bản artifact mạnh mẽ:⁶

Khả năng chính: - Experiment tracking với visualization phong phú - Quản lý phiên bản artifact với đồ thị lineage - Model registry với alias (@champion, @production) - Tính năng cộng tác cho quy trình làm việc nhóm - Tích hợp với các framework ML chính

Quản lý phiên bản artifact:

import wandb

run = wandb.init(project="nlp-models")

# Log model như artifact
artifact = wandb.Artifact("bert-classifier", type="model")
artifact.add_file("model.pt")
run.log_artifact(artifact)

# Liên kết đến registry với alias
run.link_artifact(artifact, "model-registry/bert-classifier",
                  aliases=["latest", "production"])

Lưu ý: Kiến trúc ưu tiên cloud yêu cầu gửi dữ liệu đến server bên ngoài, có thể xung đột với yêu cầu bảo mật dữ liệu nghiêm ngặt.

Phù hợp nhất cho: Các đội ưu tiên experiment tracking và cộng tác với chi phí thiết lập tối thiểu.

DVC (Data Version Control)

DVC mở rộng Git cho các file lớn và dataset:⁷

Kiến trúc: - Các lệnh giống Git (dvc add, dvc push, dvc pull) - File metadata được theo dõi trong Git, file lớn trong remote storage - Định nghĩa pipeline cho experiment có thể tái tạo - Nhiều storage backend (S3, GCS, Azure, SSH)

Phát triển gần đây: DVC đã gia nhập hệ sinh thái lakeFS, với lakeFS đóng vai trò tiêu chuẩn enterprise cho quản lý phiên bản dữ liệu quy mô petabyte.

Ví dụ quy trình:

# Thêm file mô hình lớn vào DVC
dvc add models/bert-finetuned.pt

# Commit metadata vào Git
git add models/bert-finetuned.pt.dvc .gitignore
git commit -m "Add fine-tuned BERT model v1.0"

# Push lên remote storage
dvc push

# Tái tạo từ bất kỳ commit nào
git checkout v1.0
dvc checkout

Phù hợp nhất cho: Các đội với quy trình Git hiện có muốn quản lý phiên bản dữ liệu và mô hình nhẹ nhàng.

Registry native cloud

Vertex AI Model Registry (Google Cloud):⁸ - Tích hợp native GCP - Triển khai trực tiếp đến endpoint - Theo dõi lineage tự động - Tích hợp với Vertex AI Pipelines

Amazon SageMaker Model Registry: - Tích hợp hệ sinh thái AWS - Quy trình phê duyệt - Chia sẻ mô hình cross-account - Tích hợp với SageMaker Pipelines

Azure ML Model Registry: - Tích hợp Azure - Tương thích MLflow - Triển khai endpoint được quản lý

Phù hợp nhất cho: Các tổ chức cam kết với nhà cung cấp cloud cụ thể muốn tích hợp native.

Các cân nhắc đặc thù cho LLM

Các mô hình ngôn ngữ lớn đặt ra thách thức quản lý phiên bản độc đáo vượt xa ML truyền thống:⁹

Cần quản lý phiên bản những gì

Mô hình nền tảng: Theo dõi mô hình foundation nào (Llama 3.1-8B, GPT-4, Claude) làm điểm khởi đầu.

Trọng số đã fine-tune: Fine-tuning đầy đủ tạo ra file trọng số hoàn toàn mới; adapter LoRA tạo ra file delta nhỏ tham chiếu đến mô hình nền tảng.

Template prompt: System prompt, few-shot example và định dạng instruction ảnh hưởng đáng kể đến hành vi mô hình.

Cấu hình retrieval: Các hệ thống RAG yêu cầu quản lý phiên bản của embedding model, chiến lược chunking và tham số retrieval.

Semantic versioning cho LLM

Áp dụng semantic versioning để truyền đạt mức độ quan trọng của thay đổi:¹⁰

Phiên bản major (v2.0.0): - Mô hình nền tảng khác - Thay đổi kiến trúc - Thay đổi API không tương thích ngược

Phiên bản minor (v1.3.0): - Fine-tuning trên dữ liệu mới - Cải thiện hiệu suất đáng kể - Thêm khả năng mới

Phiên bản patch (v1.2.1): - Sửa lỗi - Tối ưu hóa nhỏ - Cập nhật cấu hình

Quản lý adapter

LoRA và QLoRA tạo ra các file adapter phát triển nhanh đòi hỏi tổ chức có hệ thống:

base-model/
├── llama-3.1-8b/
│   └── v1.0.0/
│       ├── weights/
│       └── config.json
└── adapters/
    ├── customer-support-v1/
    │   ├── adapter_model.bin
    │   └── adapter_config.json
    ├── code-generation-v2/
    └── summarization-v1/

Chiến lược quản lý phiên bản adapter: - Quản lý phiên bản adapter độc lập với mô hình nền tảng - Ghi nhận các phiên bản mô hình nền tảng tương thích - Theo dõi dữ liệu huấn luyện và hyperparameter cho mỗi adapter - Cho phép chuyển đổi nhanh giữa các adapter trong serving

Chiến lược triển khai

Triển khai canary

Định tuyến tỷ lệ nhỏ traffic đến phiên bản mô hình mới trước khi triển khai đầy đủ:¹¹

# Cấu hình canary Kubernetes
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
spec:
  http:
  - route:
    - destination:
        host: model-service
        subset: v1
      weight: 90
    - destination:
        host: model-service
        subset: v2
      weight: 10

Quy trình: 1. Triển khai phiên bản mới song song với production 2. Định tuyến 5-10% traffic đến phiên bản mới 3. Giám sát metric (độ trễ, tỷ lệ lỗi, metric kinh doanh) 4. Dần tăng traffic nếu metric ổn định 5. Hoàn thành triển khai hoặc rollback dựa trên kết quả

Công cụ: Istio, Argo Rollouts và Flagger tự động hóa progressive delivery với rollback tự động khi metric suy giảm.

A/B testing

So sánh các phiên bản mô hình để đo lường tác động kinh doanh:¹²

Khác biệt chính so với canary: - Canary phát hiện vấn đề (phút đến giờ) - A/B testing đo lường tác động (ngày đến tuần) - Cần ý nghĩa thống kê cho kết luận A/B

Triển khai: - Hash user ID để định tuyến nhất quán - Theo dõi metric chuyển đổi cho mỗi variant - Chạy đến khi đạt ý nghĩa thống kê - Ghi nhận kết quả để tham khảo sau

Triển khai shadow

Định tuyến traffic production đến mô hình mới mà không phục vụ response:

Lợi ích: - Test với pattern traffic thực - So sánh output mà không ảnh hưởng người dùng - Xác định edge case trước khi triển khai

Triển khai: - Mô hình production phục vụ response - Mô hình shadow xử lý cùng request - Output được so sánh nhưng không trả về người dùng - Sự khác biệt kích hoạt điều tra

Quy trình rollback

Mọi triển khai cần khả năng rollback:

Rollback ngay lập tức:

# Rollback định tuyến traffic
kubectl set image deployment/model-service model=model:v1.2.0

# Rollback feature flag
feature_flags.disable("new_model_v2")

Rollback dựa trên registry: ```py

[Nội dung bị cắt để dịch]