Fine-tune serverless: đừng chọn vì mới

Fine-tune model không phải cuộc thi chọn công nghệ ồn ào nhất. Đây là playbook để team builder quyết định khi nào nên dùng serverless customization, khi nào nên đứng ngoài.

Bụi Wire

2026-07-11

Có một niềm tin mình thấy lặp lại khá đều trong các team đang build AI: hễ thấy cloud provider hỗ trợ fine-tune model mới, lại có người muốn lập tức kéo dữ liệu nội bộ lên thử. Lý do nghe rất hợp lý: khỏi quản GPU, khỏi dựng pipeline, khỏi đau đầu infra. Bấm vài bước trong console, model biết nghiệp vụ công ty hơn. Quá tiện.

Nhưng nếu đưa niềm tin đó ra trước hội đồng xét xử kỹ thuật, câu hỏi đầu tiên không phải là “có chạy được không?”. Câu hỏi đúng hơn là: team bạn đang mua khả năng học domain, hay chỉ đang thuê một đường tắt triển khai?

SageMaker AI vừa hỗ trợ serverless model customization cho NVIDIA Nemotron 3, gồm Nemotron 3 Nano với 30B total parameters, 3B active, và Nemotron 3 Super với 120B total parameters, 12B active. Đây là tín hiệu đáng chú ý, nhưng không phải lệnh triệu tập bắt buộc mọi team phải fine-tune ngay.

Sơ đồ minh họa cho bài Fine-tune serverless: đừng chọn vì mới

Sơ đồ tóm tắt ý chính của bài viết.

Mục tiêu: quyết định trước khi đổ dữ liệu vào máy

Playbook này dành cho bạn nếu đang ở vai developer hoặc tech lead và cần trả lời một câu rất đời: có nên fine-tune open-weight model bằng dịch vụ serverless hay không?

Một vài thuật ngữ cần neo nhanh:

open-weight model: model công khai trọng số để bạn có thể tùy biến hoặc triển khai linh hoạt hơn model đóng.
serverless model customization: fine-tune mà bạn không phải tự provision GPU, cluster, job queue; cloud lo phần hạ tầng chạy phía sau.
SFT — supervised fine-tuning: dạy model bằng cặp input/output mẫu, giống đưa đáp án chuẩn để nó học cách trả lời.
RLVR — reinforcement learning with verifiable rewards: tối ưu bằng reward có thể kiểm chứng, hợp với bài có đúng/sai rõ như toán, code, rule nghiệp vụ.
RLAIF — reinforcement learning with AI feedback: dùng AI khác phản hồi/chấm để cải thiện hành vi model.
PEFT — parameter-efficient fine-tuning: nhóm kỹ thuật fine-tune ít tham số hơn để giảm bộ nhớ và chi phí.
LoRA: một kỹ thuật PEFT phổ biến, thêm các adapter nhỏ thay vì sửa toàn bộ model.

Luận điểm của mình: serverless fine-tuning đáng dùng khi rủi ro vận hành của tự host cao hơn rủi ro phụ thuộc nền tảng; còn nếu bài toán chưa có tiêu chí thắng rõ, fine-tune chỉ làm bạn bọc sự mơ hồ trong một invoice đẹp hơn.

Checklist 15 phút: vụ này có đủ chứng cứ chưa?

Trước khi mở SageMaker Studio hay bất kỳ notebook nào, team nên tự đối chất với 5 câu này:

| Câu hỏi | Nếu trả lời “có” | Nếu trả lời “không” |
|---|---|---|
| Bạn có dataset sạch, có nhãn, có ví dụ thất bại thật? | Có thể nghĩ tới SFT hoặc PEFT | Quay lại logging, evaluation, data prep |
| Output có thể chấm được không? | Có thể cân nhắc RLVR | Đừng nhảy vào RL nếu reward mơ hồ |
| Dữ liệu có ràng buộc bảo mật/ngành không? | Cần kiểm tra vùng triển khai, IAM, retention | Cloud serverless dễ thử hơn |
| Model base hiện tại sai vì thiếu domain hay vì thiếu context? | Fine-tune có cửa thắng | Có thể RAG hoặc prompt/router đủ rồi |
| Team có năng lực vận hành GPU không? | Self-host là phương án thật | Serverless đáng để giảm tải infra |

Hình dung thế này: bạn đang build assistant cho support nội bộ. Model trả lời sai không phải vì không biết tiếng Việt, mà vì nhầm chính sách hoàn tiền, tên gói, ngoại lệ hợp đồng. Nếu các quy tắc này nằm trong tài liệu hay thay đổi, RAG — truy xuất tài liệu liên quan trước khi trả lời — có thể tốt hơn fine-tune. Nhưng nếu bạn cần model học giọng trả lời, cấu trúc escalation, cách phân loại case, fine-tune bắt đầu có lý.

Bước 1: tách “học kiến thức” khỏi “học hành vi”

Nhiều team nhầm fine-tune là cách nhồi toàn bộ tri thức công ty vào model. Sai ở chỗ: kiến thức thay đổi nhanh thì fine-tune rất dễ cũ. Bạn không muốn mỗi lần đổi chính sách bảo hành lại train lại model.

Cách chia đơn giản:

Kiến thức biến động: bảng giá, policy, SKU, guideline mới → ưu tiên RAG hoặc semantic dataset.
Hành vi ổn định: tone of voice, format trả lời, cách suy luận theo checklist, nhãn phân loại → fine-tune.
Quy tắc có đúng/sai rõ: validate JSON, phân loại theo taxonomy, giải bài có đáp án kiểm chứng → cân nhắc RLVR.

Nguồn về Amazon QuickSight gợi một ý rất đáng mượn: business context nên sống gần dữ liệu, không tách thành lớp dễ lệch. Với AI app cũng vậy. Đừng bắt fine-tuned model ghi nhớ thứ đáng ra nên nằm trong dataset, metadata, hoặc semantic layer — lớp ngữ nghĩa mô tả business terms, quan hệ, rule để hệ thống dùng thống nhất.

Bước 2: chọn đường fine-tune theo rủi ro, không theo trend

Nếu đã xác định cần customization, bạn có ba hướng thực tế:

Hướng A: Serverless customization trên cloud

Phù hợp khi bạn muốn giảm gánh infra, thử nhanh các kỹ thuật như SFT, RLVR, RLAIF, và chấp nhận làm việc trong biên giới của nền tảng. Với Nemotron 3 trên SageMaker AI, điểm hấp dẫn là không phải tự quản hạ tầng để tùy biến model open-weight.

Đổi lại, bạn cần kiểm tra kỹ: dữ liệu được lưu ở đâu, job artifact nằm ở đâu, quyền truy cập model output thế nào, có export/serve ngoài môi trường đó được không. Đây không phải phần trang trí compliance; đây là phần quyết định bạn có ngủ được không.

Hướng B: PEFT/LoRA tự quản

LoRA phổ biến vì nhẹ hơn full fine-tuning, checkpoint nhỏ, dễ phục vụ nhiều adapter trên cùng base model. Nhưng bài của Hugging Face nhắc một điểm quan trọng: LoRA không phải lựa chọn duy nhất trong PEFT. Với builder, câu hỏi không phải “LoRA có tốt không?”, mà là “kỹ thuật PEFT nào phù hợp với giới hạn bộ nhớ, latency, khả năng serve nhiều biến thể, và mức độ quên kiến thức cũ?”.

Nếu team đã có MLOps tương đối ổn, tự quản PEFT giúp linh hoạt hơn. Nhưng bạn sẽ tự nhận phần việc khó: reproducibility, tracking, evaluation, rollback, packaging.

Hướng C: Không fine-tune, chỉ dựng prototype giới hạn

Nguồn về Cosmos-framework làm rất đúng một việc: kiểm tra runtime, GPU, CUDA, memory, disk trước, rồi mới quyết định chạy bản thật hay miniature. Với các model lớn, đôi khi hành động trưởng thành nhất là không giả vờ demo của mình đại diện cho production.

Nguồn về MedGemma chạy local cũng nhắc một bài học tương tự: dữ liệu nhạy cảm có thể khiến cloud không phù hợp, nhưng local prototype không đồng nghĩa với sản phẩm an toàn. Với healthcare hay tài chính, model “chạy được” mới là biên bản mở đầu, chưa phải phán quyết cuối.

Bước 3: dựng một buổi thử có tiêu chí dừng

Nếu là mình, mình sẽ không bắt đầu bằng training job. Mình sẽ bắt đầu bằng một “hồ sơ vụ án” nhỏ:

Chọn 50-100 case đại diện

Giả sử team bạn làm support SaaS: lấy ticket có nhãn, câu trả lời chuẩn, lỗi model hiện tại, và business rule liên quan. Đây là ví dụ minh họa, không phải con số chuẩn cho mọi team.

Chạy baseline trước

Dùng model hiện tại với prompt/RAG tốt nhất bạn có. Ghi lại lỗi: sai policy, sai format, thiếu bước xác minh, nói quá quyền hạn.

Phân loại lỗi thành 3 nhóm

Thiếu context → sửa retrieval hoặc semantic layer.
Sai hành vi lặp lại → ứng viên cho SFT/PEFT.
Có đáp án kiểm chứng → ứng viên cho RLVR.

Fine-tune thử một lát cắt nhỏ

Đừng gom toàn bộ dữ liệu công ty vào lượt đầu. Chọn một workflow hẹp: phân loại ticket, viết email phản hồi, kiểm tra JSON, hoặc tạo checklist compliance.

So sánh bằng failure log, không chỉ cảm giác

Lưu lại prompt, input, output, expected output, loại lỗi. Nếu fine-tune giảm lỗi hành vi nhưng tăng hallucination — bịa tự tin — bạn chưa thắng, bạn chỉ đổi loại rắc rối.

Những bẫy dễ làm team tốn tiền

Bẫy đầu tiên: fine-tune để che dữ liệu bẩn. Nếu nhãn không thống nhất, model sẽ học sự hỗn loạn rất chăm chỉ.

Bẫy thứ hai: chọn model vì thông số lớn. Nemotron 3 có kiến trúc với active parameters thấp hơn total parameters, nên chi phí suy luận có thể hợp lý hơn model dense cùng tổng kích thước. Nhưng model lớn hơn vẫn không tự biến dataset kém thành sản phẩm tốt.

Bẫy thứ ba: quên đường ra. Trước khi train, hỏi luôn: artifact có export được không, serving path là gì, rollback ra sao, log có đủ để điều tra lỗi không. Nếu không có câu trả lời, bạn đang ký hợp đồng mà chưa đọc điều khoản nhỏ.

Bẫy cuối: đánh đồng privacy với local. Chạy local bằng Ollama/Open WebUI có ích cho prototype và dữ liệu nhạy cảm, nhưng production còn cần audit, access control, redaction, evaluation, monitoring. Local không miễn trừ trách nhiệm.

Nếu là mình, mình sẽ chọn thế này

Team nhỏ, chưa có GPU/MLOps, có workflow hẹp và dữ liệu không bị cấm lên cloud: thử serverless customization, nhưng bắt buộc có baseline và failure log.
Team có dữ liệu cực nhạy cảm hoặc yêu cầu kiểm soát artifact chặt: ưu tiên local/self-managed PEFT, chấp nhận vận hành nặng hơn.
Team chưa phân biệt được lỗi do thiếu context hay sai hành vi: đừng fine-tune vội. Làm evaluation set và semantic/RAG cleanup trước.
Team chỉ muốn “model riêng của công ty” để trình bày roadmap: dừng lại uống nước. Proprietary AI asset chỉ có nghĩa khi nó encode được workflow và tiêu chuẩn vận hành thật, không phải khi tên model nằm trong slide.

Sau bài này, điều mình muốn bạn nghĩ khác là: fine-tune serverless không phải lựa chọn mặc định khi có model mới; nó là một quyết định mua-bán rủi ro giữa dữ liệu, hành vi model, infra và quyền kiểm soát.

Công nghệ mới có thể đứng trước vành móng ngựa rất oai, nhưng production chỉ tuyên trắng án cho thứ qua được chứng cứ.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng