Model chạy tốt — nhưng cho use case nào?

Cùng một model, deploy cho summarization khác hoàn toàn với Q&A. Chọn sai config là đốt tiền mà không biết.

Bạn có bao giờ thắc mắc: cùng một model, team A bảo "nhanh lắm", team B bảo "chậm không chịu được" — ai nói thật?

Cả hai. Vì hai team đó đang dùng cùng model cho hai bài toán hoàn toàn khác nhau, với cùng một config deploy mặc định. Và đó chính xác là vấn đề.

Không phải model dở — thuyền đang đi sai luồng

Khi deploy một model AI, hầu hết team dừng ở bước: chọn model, chọn instance, bấm deploy. Config mặc định, concurrent users mặc định — xong, chuyển sang việc khác.

Nhưng "chạy được" khác xa "chạy tốt cho bài toán của bạn". Nói thẳng ra: một model serve content generation — output dài, cần xử lý nhiều request song song — đòi hỏi config khác hẳn so với model serve chatbot Q&A, nơi user ngồi chờ từng mili-giây để thấy chữ đầu tiên hiện ra.

Ba metric quyết định mọi thứ: latency (đặc biệt time-to-first-token — TTFT), throughput (token/giây), và cost per token. Tùy use case, bạn sẽ cần ưu tiên metric khác nhau. Và cách ưu tiên đó nằm ở config deploy, không phải ở việc đổi model.

AWS vừa cập nhật SageMaker JumpStart với "optimized deployments" — cho phép chọn deployment config theo use case cụ thể (content generation, summarization, Q&A) thay vì chỉ chọn theo số concurrent users như trước. Mỗi preset tối ưu cho metric phù hợp nhất với bài toán đó.

Nhưng bỏ AWS sang một bên — nguyên tắc này áp dụng cho bất kỳ platform nào bạn đang dùng.

Hai team, cùng model, khác số phận

Team content ở một agency Sài Gòn:

Giả sử team 4 người, dùng LLM để sinh blog draft, email marketing, product description. Vài trăm request mỗi ngày, output trung bình 500–800 token/request. Không ai ngồi chờ real-time — content được queue rồi review sau.

Bài toán này cần throughput cao. Bạn muốn model nuốt được nhiều request cùng lúc, output dài, batch processing hoàn toàn chấp nhận được. Config hợp lý: batch size lớn, max tokens cao, chấp nhận P50 latency cao hơn một chút để giá per token rẻ hơn đáng kể.

Chatbot hỗ trợ khách hàng cho fintech startup Hà Nội:

Cùng model đó, nhưng giờ serve chatbot cho user thật. Câu hỏi ngắn, output cũng ngắn (100–200 token), nhưng user đang nhìn chằm chằm vào màn hình chờ phản hồi.

Bài toán này cần TTFT thấp. Sẵn sàng trả nhiều hơn per token, đổi lấy response gần như tức thì. Config: batch size nhỏ, ưu tiên latency, instance mạnh hơn nếu cần.

Cùng model, cùng cloud — hai cách deploy cho hai kết quả và hai hóa đơn rất khác nhau.

Cái bẫy "cứ upgrade instance là xong"

Mình biết một anh CTO deploy model summarization cho app đọc tin nội bộ. Ban đầu traffic thấp, config mặc định chạy phà phà. User tăng lên vài trăm, latency bắt đầu nhảy loạn. Phản xạ đầu tiên của anh ấy: upgrade lên instance GPU lớn hơn. Kết quả? Latency giảm được chút, nhưng hóa đơn cloud tháng đó tăng gấp ba.

Vấn đề thật ra không phải thiếu sức mạnh phần cứng — mà config deploy không match với pattern sử dụng thực tế. Summarization nhận input dài, trả output ngắn — batch size và concurrent request cần tune hoàn toàn khác so với generation. Sau khi ngồi lại điều chỉnh config cho đúng profile, latency về mức chấp nhận được — trên chính con instance cũ, giá cũ.

Đôi khi gió ngược không phải do thuyền yếu — mà bạn đang căng buồm sai hướng.

Thử ngay chiều nay

Nếu đang dùng SageMaker JumpStart:

  1. Xác định use case chính của mỗi endpoint hiện tại — generation, summarization, hay Q&A?
  2. Vào console, chọn model đang dùng, tìm mục "optimized deployments" mới
  3. So sánh preset configs — AWS giờ hiển thị P50 latency, TTFT, throughput cho từng use case. Đọc kỹ trước khi quyết định
  4. Deploy endpoint mới song song với endpoint cũ để A/B test
  5. Đo 3 metric: latency, throughput, cost — đây là cơ sở duy nhất để quyết định switch

Không dùng AWS? Logic vẫn y hệt:

Bất kể platform nào, quy trình không đổi: xác định bài toán → chọn config phù hợp → đo lường → điều chỉnh.

Khi nào thì chưa cần bận tâm?

Nếu team bạn mới bắt đầu, traffic còn thấp, chưa rõ use case nào là chính — một endpoint config mặc định là đủ. Đừng tối ưu cho vấn đề chưa tồn tại.

Nhưng khi bạn bắt đầu thấy: latency nhảy bất thường giữa các feature, hóa đơn cloud tăng mà output không tăng tương ứng, hoặc cùng model mà team nào cũng phàn nàn khác nhau — đó là tín hiệu rõ ràng. Ngồi lại, map từng use case với config deploy riêng, rồi đo lại.

Chọn đúng model mới là nửa chặng đường. Nửa còn lại là deploy cho đúng bài toán. Đừng tin mình, thử đi rồi biết.

---

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

Nguồn tham khảo