Dùng API khi: lượng dùng còn thấp hoặc trồi sụt, cần đúng model mạnh nhất hiện có mà bên open weights chưa theo kịp, chưa có người vận hành ML, hoặc cần ra mắt nhanh. Về dữ liệu, thoả thuận không lưu trữ (ZDR) đáp ứng được phần lớn yêu cầu compliance.
Tự vận hành khi: lượng dùng rất lớn và đều; ngành bị quản lý chặt buộc dữ liệu không được rời hệ thống (y tế, tài chính, khu vực công); cần độ trễ cực thấp nên phải đặt model cạnh ứng dụng; đã fine-tune model riêng; cần chi phí biết trước thay vì tính theo token; hoặc chạy trong môi trường không có internet.
Điểm hoà vốn — nhớ cách tính, đừng nhớ con số: so chi phí theo token của API với chi phí thuê GPU theo giờ — GPU bật là tính tiền, kể cả lúc rảnh. Một cụm 2×H100 phục vụ được vài chục request/giây; lấy lượng token mục tiêu chia ra là biết cần bao nhiêu cụm. Với model cỡ 70B, điểm hoà vốn thường rơi vào vùng hàng chục tới hàng trăm triệu token/ngày — nhưng phải tính lại theo giá hiện hành, vì giá API giảm nhanh hơn giá GPU.
Quan trọng hơn: đừng chỉ so chi phí biến đổi với nhau. Tính TCO 2–3 năm, cộng cả nhân sự vận hành (thường 1–3 người toàn thời gian), hệ observability phải tự dựng, và chu kỳ nâng cấp model.
Thách thức khi tự vận hành — phần hay bị đánh giá thấp:
- Hoạch định công suất: tải không đều nên dư thì phí, thiếu thì trễ và lỗi. Đây chính là việc mà API đang co giãn hộ bạn.
- Phần cứng: GPU hỏng, xung đột phiên bản driver/CUDA là chuyện thường ngày.
- Nâng cấp model: mỗi thế hệ mới là một đợt tự kiểm thử và triển khai, thay vì đổi một tham số.
- Observability, đa vùng, dự phòng: phải tự dựng toàn bộ.
Stack tối thiểu nếu tự vận hành: một open weights cỡ 70B, vLLM làm serving engine, Kubernetes với node pool GPU co giãn theo độ sâu hàng đợi, và một gateway (LiteLLM) giữ nguyên API chuẩn OpenAI cho phía app.
Thực tế phổ biến là lai: route phần lớn truy vấn đơn giản vào model tự vận hành và đẩy phần khó sang API; hoặc lấy API làm chính, self-host làm dự phòng khi provider gặp sự cố.