Inference production — GPU ngốn tiền nhanh hơn user signup

Dựng infra cho AI inference giống xây đường cao tốc — sai thiết kế từ đầu thì càng mở rộng càng tắc.

Cái ngày anh bạn mình nhận hóa đơn GPU

Hồi đầu năm, một anh bạn tech lead ở Sài Gòn nhắn mình: "Ê, tháng này bill GPU inference gấp 3 lần tháng trước, mà traffic chỉ tăng có tí." Mình hỏi lại: "Autoscaling chưa?" — "Có, nhưng nó scale lên mà quên scale xuống."

Chuyện này không hiếm. Triển khai model AI lên production giống xây một con đường cao tốc: thiết kế sai từ đầu thì càng đông xe càng kẹt, mà đường vắng thì vẫn tốn phí bảo trì như thường.

Trước khi có managed inference — ba cơn đau quen thuộc

Cơn đau thứ nhất: setup infrastructure như lắp ráp xe đua từ linh kiện rời. Bạn cần Kubernetes cluster, GPU node pools, load balancer, model serving framework (vLLM, TGI, hay TensorRT-LLM), health checks, logging... Mỗi thứ một repo, một version, một cách config. Giả sử team bạn 4 người — ít nhất 1 người phải full-time babysit infra thay vì tập trung vào model.

Cơn đau thứ hai: traffic lên xuống như tàu lượn. Giờ cao điểm user đổ vào, GPU đỏ lửa. 2 giờ sáng thì GPU ngồi chơi — nhưng bill vẫn chạy. Over-provisioning thì tốn tiền, under-provisioning thì user chờ timeout rồi chửi trên group.

Cơn đau thứ ba: GPU fail mà không ai biết. Node chết, GPU bị lỗi memory — nếu không có self-healing, request cứ thế bay vào node zombie rồi trả về lỗi 500. Ai đã từng dựng inference pipeline trên Kubernetes (mình có nhắc trong bài trước về K8s) thì biết: mấy cơn đau này không phải lý thuyết — nó là thứ ám ảnh on-call hàng đêm.

Khi đường cao tốc có trạm điều phối thông minh

Amazon SageMaker HyperPod inference — nói thẳng ra — là AWS gói gọn mấy thứ bạn phải tự ráp thành một managed platform chạy trên EKS.

Dynamic scaling thật sự. Không chỉ scale theo CPU/memory — HyperPod theo dõi queue depth, latency percentiles, và GPU utilization để quyết định lúc nào cần thêm node, lúc nào thu gọn. Hình dung thế này: thay vì bạn tự đứng giữa ngã tư vẫy tay điều phối xe, giờ có hệ thống đèn giao thông thông minh tự chuyển xanh-đỏ theo lưu lượng thực tế.

Self-healing cho GPU nodes. Node chết? HyperPod tự detect, drain traffic, thay node mới. Không cần ai viết custom health check scripts lúc nửa đêm.

Deployment gọn hơn nhiều. Thay vì ráp 5-6 components, bạn chọn model, chọn instance type, deploy. Platform lo phần routing, monitoring, scaling.

Theo tài liệu AWS, cách tiếp cận này có thể giảm tổng chi phí sở hữu (TCO) lên đến 40% — chủ yếu nhờ auto-scaling xuống khi vắng và tận dụng GPU hiệu quả hơn.

Hai kịch bản team Việt Nam — bạn ở team nào?

Kịch bản 1: Startup chatbot B2B, team 3 dev. Đang serve model 7B trên 2 con g5.xlarge tự quản lý bằng Helm charts. Mỗi lần update model, deploy mất nửa ngày vì phải test rolling update thủ công. Chuyển sang HyperPod, phần deploy rút xuống còn config + một lệnh — thời gian còn lại dành cho prompt engineering và eval, thứ thật sự tạo ra giá trị cho sản phẩm.

Kịch bản 2: Công ty fintech, team AI 8 người. Traffic inference biến động mạnh — giờ giao dịch sáng thì request gấp 10 lần, cuối tuần gần như bằng 0. Trước đây để 4 GPU nodes chạy 24/7 "cho chắc." Với auto-scaling policies, cuối tuần cluster tự co lại — bill giảm rõ rệt mà không hy sinh latency giờ cao điểm. Giống như thuê thêm làn đường phụ chỉ khi kẹt xe, xong trả lại.

Thử ngay chiều nay

Nếu bạn có AWS account và đã quen EKS, flow cơ bản gồm 5 bước:

  1. SageMaker console → HyperPod Clusters → Create HyperPod cluster → chọn "Orchestrated by Amazon EKS"
  2. Quick setup cho lần đầu — để AWS tạo default resources. Chuyển sang custom setup khi bạn đã có VPC/subnet riêng muốn tích hợp
  3. Enable add-ons — Kubernetes controllers cho autoscaling, monitoring, health checks đều có sẵn dạng toggle bật/tắt
  4. Deploy model — trỏ model artifact từ S3, chọn instance type (bắt đầu với ml.g5.xlarge cho model dưới 13B)
  5. Stress test — dùng locust hoặc k6 simulate load, quan sát cluster scale up/down trong CloudWatch

Mẹo từ người đi trước: bắt đầu với quick setup, chạy thử model nhỏ. Đừng nhảy thẳng vào 70B với custom networking — đó là công thức biến "một buổi chiều" thành "một tuần debug."

Ba cái bẫy mình thấy người ta hay dính

"Instance to nhất cho chắc ăn." Sai lầm kinh điển. GPU lớn hơn không tự động nghĩa là inference nhanh hơn. Model 7B chạy trên p5.48xlarge thì GPU utilization có khi chưa tới 10% — tiền bay mà performance không khá hơn. Giống lái container đi mua ổ bánh mì vậy.

Quên set minimum nodes = 0. Nhiều team set min = 2 "phòng hờ," rồi quên. Cuối tháng nhìn bill thắc mắc sao traffic thấp mà chi phí vẫn đều đều. Nếu use case cho phép cold start, hãy mạnh dạn min = 0.

Không test cold start latency. Khi cluster scale from zero, request đầu tiên sẽ chậm vì phải pull model + warm up. Nếu cần latency thấp liên tục, giữ ít nhất 1 node luôn warm — nhưng ý thức được mình đang trade-off gì.

Không muốn vendor lock-in? Vẫn có đường

Mình hiểu — không phải ai cũng muốn all-in một cloud provider. Vài lựa chọn open-source đáng cân nhắc:

Trade-off thì rõ: open-source cho toàn quyền kiểm soát, nhưng operational overhead là thật. Managed platform đánh đổi flexibility lấy thời gian — mà thời gian dev thì đắt hơn bạn tưởng.

Một câu gối đầu giường

Inference production không khó ở chỗ "chạy được" — khó ở chỗ "chạy được lúc 3 giờ sáng khi mình đang ngủ mà bill không cháy túi." Dù bạn chọn managed hay self-hosted, hãy setup autoscaling, health checks, và cost alerts từ ngày đầu. Đừng đợi đến khi nhận hóa đơn rồi mới vỗ trán — lúc đó thì tiền đã chạy xa lắm rồi.

---

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

Nguồn tham khảo