API hay self-host? Câu hỏi đó sai rồi
Không phải chọn một trong hai — mà là biết khi nào dùng cái nào. Chiến thuật phân tầng chi phí AI cho team thực tế.
Bụi WireCuộc tranh luận không có người thắng
"Nên gọi API hay tự host model?" — mình nghe câu này ít nhất ba lần mỗi tuần từ các team ở Việt Nam. Và mỗi lần, hai phe lại cãi nhau y chang: phe API bảo "nhanh, khỏi lo infra", phe self-host bảo "lâu dài rẻ hơn, dữ liệu an toàn hơn".
Khoan. Cả hai đều đúng — và cả hai đều sai. Vì câu hỏi đúng không phải "cái nào tốt hơn" mà là "workload nào nên chạy ở đâu".
Google Cloud vừa publish một bài khá chi tiết về chuyện này, và cái insight đáng giá nhất không phải là "dùng dịch vụ của Google đi" — mà là cách họ frame bài toán: tìm điểm cân bằng giữa chi phí và hiệu năng, thay vì chọn một cực.
Thật ra có ba tầng, không phải hai
Hầu hết mọi người nghĩ hạ tầng AI chỉ có hai lựa chọn: gọi API trả theo token hoặc tự host. Nhưng giữa hai thái cực đó còn một tầng mà ít team để ý: provisioned throughput — đặt trước capacity với giá cố định.
Nói thẳng ra thì ba tầng này hoạt động thế này:
Tầng 1 — Pay-as-you-go (PayGo): Gọi API, trả theo lượng token xài. Linh hoạt tuyệt đối, nhưng giá mỗi token cao nhất. Phù hợp khi traffic không đều hoặc đang thử nghiệm.
Tầng 2 — Provisioned throughput: Bạn cam kết một mức throughput nhất định (bao nhiêu request/phút), đổi lại giá rẻ hơn đáng kể so với PayGo. Giống mua gói cước data thay vì trả theo MB — có thể thừa, nhưng đơn giá thấp hơn nhiều.
Tầng 3 — Self-host: Chạy model trên infra của mình. Chi phí cố định bất kể xài bao nhiêu, nhưng phải lo ops, scaling, và cập nhật model.
Đa số team mình gặp đang kẹt ở tầng 1 — trả PayGo cho mọi thứ, kể cả những tác vụ lặp đi lặp lại hàng ngàn lần mỗi ngày. Đó là lý do bill cứ phình mà không ai hiểu tại sao.
Cùng bài toán chi phí, hai lời giải khác nhau
Team edtech, 5 người — chatbot hỗ trợ học viên:
Giả sử team bạn có một chatbot hỏi-đáp, chạy bằng API model lớn. Ban đầu vài trăm query/ngày, PayGo ổn. Nhưng sau khi launch campaign, traffic nhảy lên vài ngàn query/ngày.
Nếu cứ để PayGo, bill tháng tăng gấp đôi, gấp ba mà chất lượng không khác gì. Đây là lúc nên tách: những câu hỏi FAQ lặp lại (chiếm phần lớn traffic) chuyển sang một model nhỏ hơn self-host hoặc provisioned. Những query phức tạp cần reasoning mạnh thì giữ ở API model lớn.
Không phải trận nào cũng cần tung đội hình chính ra sân — trận giao hữu thì cho đội trẻ vào, chung kết mới cần ngôi sao.
Công ty logistics, 200 nhân viên — phân loại email khiếu nại:
Team ops dùng AI để phân loại email và tạo draft phản hồi. Volume ổn định: vài trăm email/ngày, đều đặn từ thứ Hai đến thứ Sáu.
Traffic dự đoán được + volume ổn định = ứng cử viên hoàn hảo cho provisioned throughput hoặc self-host. Chuyển từ PayGo sang provisioned, chi phí giảm rõ rệt mà latency thậm chí còn ổn định hơn vì capacity đã được reserve sẵn.
Chiều nay, mở billing dashboard lên
Bạn không cần hai sprint để bắt đầu. Ba bước, một buổi chiều:
Bước 1 — Liệt kê tất cả workload AI đang chạy. Mở dashboard billing — hoặc nếu chưa có dashboard, grep codebase xem bao nhiêu chỗ đang gọi API. Ghi ra: tên tác vụ, model đang dùng, volume trung bình/ngày.
Bước 2 — Phân loại theo pattern:
| Pattern traffic | Volume | Gợi ý tầng |
|---|---|---|
| Biến động, khó đoán | Thấp | PayGo |
| Ổn định, có lịch rõ | Trung bình — cao | Provisioned throughput |
| Tác vụ đơn giản, lặp lại | Rất cao | Self-host model nhỏ |
Bước 3 — Tính break-even sơ bộ. Với mỗi workload ổn định, so sánh: chi phí PayGo hiện tại/tháng vs chi phí provisioned (hoặc chi phí VM nếu self-host). Ví dụ minh họa: giả sử team đang trả khoảng $500/tháng cho tác vụ phân loại text chạy PayGo — chuyển sang self-host một model 7B-8B qua Ollama hoặc vLLM trên một VM nhỏ có thể chỉ tốn $50-80/tháng tiền compute. Con số chính xác tùy provider và region, nhưng chênh lệch thường đáng để mở spreadsheet ra cộng trừ.
Thẻ vàng cho mấy sai lầm kinh điển
Sai lầm phổ biến nhất: tối ưu sai tầng.
Mình từng thấy một team dành hai tuần fine-tune model để giảm output token — nghĩ rằng ít token hơn thì ít tiền hơn. Kết quả? Giảm được chút chi phí token, nhưng tốn gấp bội tiền compute cho training, cộng thêm hai tuần engineer không ship feature. Thẻ vàng.
Bẫy thứ hai: self-host mọi thứ quá sớm. Khi traffic còn thấp và thất thường, self-host nghĩa là bạn đang trả tiền VM 24/7 cho một service chỉ bận 2 tiếng mỗi ngày. PayGo lúc này ngược lại rẻ hơn nhiều.
Nguyên tắc đơn giản: bắt đầu bằng PayGo, theo dõi pattern ít nhất 2-4 tuần, rồi mới quyết chuyển tầng. Đừng tối ưu trước khi biết mình cần tối ưu cái gì.
Một chiến thuật, không phải một đáp án
Không có công thức chung. Startup 5 người và enterprise 500 người sẽ xếp ba tầng này theo tỷ lệ hoàn toàn khác nhau. Điều quan trọng là:
- Biết mình có nhiều hơn hai lựa chọn — PayGo, provisioned, self-host, và mọi cách kết hợp ở giữa.
- Phân loại workload trước khi phân bổ ngân sách — không phải tác vụ nào cũng cần model flagship.
- Đo lường liên tục — pattern traffic thay đổi, chiến thuật chi phí cũng phải xoay theo.
Mấy tool open-source như Ollama hay vLLM vẫn là lựa chọn self-host đáng cân nhắc cho tầng 3, đặc biệt với các model nhỏ đã quantize. Model nhỏ chạy tốt hơn bạn nghĩ, miễn đúng tác vụ — như mình đã chia sẻ trong các bài về quantization trước đây.
Đừng tin mình, thử đi rồi biết — mở billing dashboard chiều nay, phân ba cột, rồi tự thấy tiền đang chảy chỗ nào.
---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng