GPU always-on đang đốt tiền — case study chuyển chip chuyên dụng

Tomofun chạy VLM 24/7 trên GPU để phát hiện hành vi thú cưng. Khi hóa đơn vượt ngưỡng, họ chuyển sang chip chuyên dụng mà không viết lại code. Bài học cho team đang trả tiền inference mỗi tháng.

Bụi Wire

2026-05-07

Tuần trước mình ngồi review hóa đơn cloud cho một team ở Sài Gòn — 4 con GPU instance chạy inference model vision 24/7, tháng nào cũng đều đặn cháy tiền như đồng hồ taxi. Lead hỏi: "Có cách nào giảm mà không phải retrain model không?" Câu hỏi này hóa ra không chỉ team đó hỏi.

Tomofun — startup pet-tech Đài Loan đứng sau Furbo Pet Camera — vừa public một case đáng đọc: họ chạy vision-language model (VLM — model kết hợp xử lý ảnh và ngôn ngữ) liên tục để phát hiện hành vi thú cưng real-time, và đã chuyển từ GPU sang chip chuyên dụng AWS Inferentia2 mà giữ nguyên codebase PyTorch.

Bài này không kể lại thành tích của họ. Mình muốn bóc tách quyết định và điều kiện khiến bước chuyển đó hợp lý — rồi hỏi ngược: team bạn có đang ở cùng ngã rẽ không?

Bối cảnh: triệu chứng của workload always-on

Furbo thu video từ hàng trăm nghìn camera, chạy model BLIP (Bootstrapping Language-Image Pre-Training — kiến trúc liên kết ảnh-text phổ biến cho vision tasks) để nhận diện chó sủa, chạy nhảy, hành vi bất thường, rồi push alert cho chủ.

Đặc điểm workload này:

Always-on: không có giờ thấp điểm rõ ràng — thú cưng không ngủ theo lịch của bạn
Throughput ổn định: cần xử lý liên tục, không phải burst rồi idle
Latency vừa phải: alert chậm vài giây vẫn chấp nhận được, không cần sub-100ms

Hiểu nôm na: nếu bạn đang chạy một phòng khám thú y mở cửa 24/7, thì GPU giống như thuê bác sĩ chuyên khoa tim ngồi trực ca đêm — giỏi nhưng đắt, mà ca đêm chỉ cần ai đó biết đo huyết áp.

Quyết định: chuyển sang chip chuyên dụng

Tomofun chọn AWS Inferentia2 — chip được thiết kế riêng cho inference, không có khả năng training. Đây là quyết định có 3 ràng buộc quan trọng:

Không viết lại model: BLIP đã optimize cho PyTorch, team không muốn port sang framework khác. AWS Neuron SDK hỗ trợ compile trực tiếp từ PyTorch graph — đây là yếu tố quyết định.

Chấp nhận trade-off hiệu năng: chip chuyên dụng không nhanh hơn GPU trên mọi task. Lợi thế nằm ở giá/token khi chạy liên tục, không phải peak throughput.

Kiến trúc auto-scale vẫn giữ: EC2 Auto Scaling group + Elastic Load Balancing phía trước, chỉ thay đổi instance type bên dưới (từ GPU sang Inf2).

Hệ quả: cái được và cái phải trả

Được:

Chi phí inference giảm đáng kể so với GPU equivalent cho cùng throughput liên tục
Codebase PyTorch gần như nguyên vẹn — effort chuyển đổi tập trung ở bước compile model qua Neuron SDK
Scaling behavior dễ dự đoán hơn vì giá instance thấp hơn, team dám scale out sớm hơn

Phải trả:

Debugging khó hơn: khi model cho kết quả sai trên chip mới, bạn phải phân biệt giữa lỗi logic và lỗi numerical precision (độ chính xác số học). Fireworks AI vừa publish một bài chi tiết về vấn đề training-inference parity — hiện tượng cùng weight nhưng output lệch do cách chip xử lý phép cộng floating-point khác nhau.
Vendor lock-in rõ ràng hơn: Inferentia2 chỉ có trên AWS. Nếu mai bạn muốn chuyển sang GCP hay on-prem, phải compile lại.
Không phải model nào cũng compile trơn tru: model có dynamic shape phức tạp hoặc custom operator có thể cần refactor.

Bài học: khi nào nên "chẩn đoán" lại chip inference

Không phải team nào cũng nên nhảy sang custom silicon. Framework ra quyết định:

| Điều kiện | GPU vẫn hợp lý | Nên xét chip chuyên dụng |
|-----------|----------------|-------------------------|
| Workload pattern | Burst, không đều | Always-on, ổn định |
| Latency requirement | Sub-50ms bắt buộc | Vài trăm ms chấp nhận được |
| Model diversity | Thay model liên tục | Model ổn định 3-6 tháng |
| Team size | Có infra engineer rảnh | Muốn "set and forget" |
| Budget sensitivity | Tiền không phải vấn đề | Inference cost > 30% cloud bill |

Giả sử team bạn 5 người, đang chạy một VLM inference service 24/7 phục vụ vài chục nghìn request/ngày — bạn đang ở vùng mà custom silicon bắt đầu có nghĩa. Nhưng nếu bạn thay model mỗi 2 tuần (vì đang iterate nhanh), thì overhead compile lại mỗi lần sẽ triệt tiêu lợi ích.

Áp dụng: checklist cho team Việt Nam

Nếu bạn đang trả hóa đơn GPU inference hàng tháng và muốn đánh giá:

Bước 1 — Đo baseline: Ghi lại utilization thực tế của GPU instances trong 2 tuần. Nếu utilization trung bình dưới 40%, bạn đang trả tiền cho capacity không dùng — nhưng giải pháp có thể chỉ là right-size instance, chưa cần đổi chip.

Bước 2 — Xác định model stability: Model hiện tại đã ổn bao lâu? Nếu dưới 1 tháng kể từ lần thay cuối, chưa phải lúc.

Bước 3 — Thử compile: Với Inferentia2, dùng torch_neuronx.trace() để compile model hiện có. Nếu pass mà không cần sửa code → tín hiệu tốt. Nếu fail vì custom op → tính effort refactor.

Bước 4 — So sánh cost/token: Chạy benchmark cùng workload trên cả GPU instance và Inf2 instance trong 48 giờ, so tổng chi phí trên cùng số request.

Open-source alternative: Nếu không muốn lock vào AWS, xem xét ONNX Runtime hoặc OpenVINO (Intel) cho inference optimization trên CPU/custom hardware. Không rẻ bằng Inferentia2 cho GPU-class workload, nhưng portable hơn.

Dòng cuối

Case của Tomofun không phải câu chuyện "startup nhỏ thắng lớn" — nó là câu chuyện về việc kê đơn đúng thuốc cho đúng bệnh. GPU là thuốc tổng hợp mạnh, nhưng khi bạn đã biết chính xác mình cần chữa gì và cần chữa lâu dài, một liều chuyên biệt rẻ hơn và ít tác dụng phụ hơn.

Câu hỏi không phải "chip nào tốt hơn" mà là "workload của mình đã đủ ổn định để justify việc chuyển chưa?"

---

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