Bản vẽ inference trước khi xuống tiền

Inference production không nên bắt đầu bằng GPU mới nhất. Hãy bắt đầu bằng bản vẽ workload, benchmark có chủ đích, và quyết định vận hành rõ ràng.

Bạn có dám chốt cấu hình inference cho sản phẩm AI chỉ sau một buổi benchmark không?

Tuần trước, mình nghe một câu rất quen từ một team giả định tên là MộcLab: “Model chạy được rồi, giờ chỉ cần chọn GPU mạnh là xong.” Câu này nghe như thợ mới vào xưởng, thấy tấm gỗ cong thì lập tức vác máy bào lớn nhất ra xử. Có khi đúng, nhưng nhiều khi bào xong mới biết mình làm mỏng luôn cả mặt bàn.

MộcLab có một chatbot nội bộ dùng cho đội sales. Không phải frontier model, không phải traffic khủng, nhưng có đủ thứ làm tech lead đau đầu: lúc demo thì mượt, lúc người dùng thật vào thì latency nhảy múa; token output dài ngắn thất thường; chi phí endpoint không rõ sẽ đội lên bao nhiêu nếu mở cho cả công ty.

Điểm đáng bàn ở các release inference gần đây không nằm ở việc “có thêm UI mới” hay “chip mới được định giá cao”. Điểm thật sự là: inference đang chuyển từ cuộc chơi chọn phần cứng sang cuộc chơi thiết kế quyết định vận hành.

Sau bài này, mình muốn bạn đổi một ý nghĩ: đừng hỏi “nên dùng GPU nào?” trước. Hãy hỏi “workload của mình cần được đóng khung ra sao để chọn cấu hình không bằng cảm giác?”

Sơ đồ tóm tắt ý chính của bài viết.

Cú va đầu tiên: benchmark thủ công không còn đủ sạch

MộcLab bắt đầu bằng cách khá phổ biến: lấy model, thử vài instance, đổi batch size, đổi runtime, ghi kết quả vào spreadsheet. Một bạn ML engineer chạy test, một bạn backend nhìn latency, lead nhìn bill ước tính. Ai cũng có lý, nhưng không ai có cùng một thước đo.

Vấn đề không phải benchmark thủ công sai. Vấn đề là nó dễ biến thành đục chạm theo cảm hứng: hôm nay test prompt ngắn, mai test prompt dài; hôm nay endpoint còn lạnh, mai đã warm; hôm nay đo trung bình, mai lại cãi nhau p95.

Amazon SageMaker AI vừa đưa phần inference recommendations lên UI trong Studio: chọn workload profile, cấu hình optimization job, so sánh kết quả trực quan, rồi deploy cấu hình được đề xuất. API đã có trước đó, nhưng UI kéo quyết định này ra khỏi vùng “chỉ infra rất rành mới đọc nổi raw benchmark”. Với team builder, chi tiết quan trọng không phải low-code hay no-code. Chi tiết quan trọng là nó ép bạn khai báo workload trước khi nhìn kết quả.

Nói thẳng ra thì: một UI tốt ở đây không thay kỹ sư giỏi. Nó bắt team ngồi xuống vẽ bản trước khi cưa gỗ.

Mổ xẻ: một cấu hình inference không chỉ là instance

Khi nói “chọn cấu hình inference”, nhiều team chỉ nhìn vào instance type. Nhưng trong production, cấu hình thật có ít nhất bốn mảnh:

| Mảnh quyết định | Câu hỏi cần trả lời | Nếu bỏ qua sẽ đau ở đâu |
|---|---|---|
| Workload shape | Prompt dài cỡ nào, output dài cỡ nào, concurrency ra sao? | Benchmark đẹp nhưng lệch đời thật |
| Serving runtime | Dùng container/runtime nào, như vLLM, TGI, SGLang hoặc runtime managed? | Tối ưu sai tầng, khó debug |
| Optimization strategy | Quantization, batching, compilation, hay cấu hình memory? | Tiết kiệm chi phí nhưng hỏng latency, hoặc ngược lại |
| Operational boundary | Monitoring, data capture, IAM, rollout, rollback nằm ở đâu? | Demo chạy, production mù |

SageMaker AI Studio inference recommendations chạm trực tiếp vào ba mảnh đầu: workload, model, cấu hình phục vụ. HyperPod inference thì cho thấy mảnh thứ tư đang được đẩy lên thành first-class concern: data capture ở endpoint, load balancer, model pod; kéo model từ Hugging Face với revision pinning; node-local NVMe để giảm cold start; IAM ở mức pod.

Đây là tín hiệu đáng giữ. Inference không còn là “deploy model lên một endpoint”. Nó là một đường đi có nhiều điểm quan sát, nhiều điểm kiểm soát, và nhiều chỗ có thể gãy.

Ví dụ cụ thể: giả sử MộcLab có chatbot nội bộ, phần lớn câu hỏi ngắn nhưng câu trả lời hay dài vì phải trích chính sách bán hàng. Nếu chỉ benchmark prompt ngắn và output ngắn, team có thể chọn cấu hình nhìn rẻ. Đến khi người dùng hỏi “so sánh chính sách chiết khấu theo vùng trong 6 tháng gần nhất”, output dài hơn, latency tăng, queue dồn, rồi mọi người kết luận “model chậm”. Thật ra bản vẽ workload ban đầu bị thiếu nét.

Ba lựa chọn của MộcLab, và tradeoff thật

MộcLab đứng trước ba hướng.

Hướng 1: tự benchmark toàn bộ.

Ưu điểm: kiểm soát sâu, linh hoạt, hợp với team có hạ tầng mạnh. Bạn muốn đo từng runtime, từng batch policy, từng biến môi trường đều được.

Nhược điểm: dễ tốn thời gian vì phải tự chuẩn hóa workload, tự lưu kết quả, tự so sánh, tự tránh sai lệch. Nếu team chưa có benchmark harness tử tế, kết quả dễ thành “ai chạy hôm đó thì người đó thắng”.

Hướng 2: dùng recommendation UI làm vòng lọc đầu.

Ưu điểm: nhanh có danh sách cấu hình đáng thử, dễ cho tech lead và ML engineer cùng nhìn một mặt phẳng cost-performance. Với workload phổ biến, nguồn nói chu kỳ có thể rút xuống tính bằng phút; với workload custom thì tính bằng vài giờ. Quan trọng hơn, nó giảm tranh luận mơ hồ.

Nhược điểm: vẫn phải kiểm chứng bằng traffic giống production. UI không biết hết business constraint của bạn: giờ cao điểm, request kỳ quặc, prompt injection, giới hạn dữ liệu nhạy cảm, hay quy trình rollback nội bộ.

Hướng 3: nhảy thẳng vào hạ tầng inference chuyên sâu.

Ở đây có thể là HyperPod, cụm GPU tự quản, hoặc thậm chí theo dõi các hướng chip chuyên biệt như Etched đang quảng bá cho frontier inference cluster. Ưu điểm là có tiềm năng tối ưu sâu về performance, cold start, data locality và governance.

Nhược điểm: chi phí quyết định cao. Một khi đã đi vào cụm riêng, bạn không chỉ mua tốc độ. Bạn mua luôn trách nhiệm vận hành: capacity planning, observability, security boundary, upgrade runtime, và xử lý sự cố lúc nửa đêm.

Với MộcLab, hướng hợp lý không phải hướng “ngầu” nhất. Họ dùng recommendation UI để chọn 2-3 cấu hình ứng viên, rồi chạy lại test bằng log thật đã được làm sạch dữ liệu nhạy cảm. Sau đó mới quyết có cần tầng HyperPod-like hay chưa.

Framework nhỏ: W-S-O-G trước khi deploy

Đây là khung mình muốn bạn mang về cho team builder: W-S-O-G.

W — Workload: mô tả hình dạng request. Input token, output token, concurrency, streaming hay non-streaming, p95 latency kỳ vọng. Context window là vùng ngữ cảnh model xử lý được trong một lượt; nếu workload thường nhét tài liệu dài, đừng benchmark bằng câu hỏi một dòng.

S — Serving: chọn runtime và container. Runtime không chỉ là “chạy model”; nó quyết định batching, memory layout, streaming, và khả năng tận dụng GPU. Nếu bạn đổi runtime, hãy coi đó là đổi một mộng gỗ trong khung, không phải thay cái nhãn dán.

O — Optimization: xác định bạn đang tối ưu cái gì. Chi phí mỗi request, latency p95, throughput, cold start, hay độ ổn định? Provisioned throughput là đặt trước năng lực xử lý với giá gần cố định; hợp khi traffic ổn định, không hợp nếu sản phẩm còn đang dò nhu cầu.

G — Governance: ai được deploy, ai xem log, data capture ở đâu, credential nằm chỗ nào. Claude apps gateway for AWS là một tín hiệu cùng chiều: khi AI tools đi vào enterprise, control plane cho access, cost và policy quan trọng không kém model. Với inference endpoint cũng vậy. Không có governance, bạn chỉ đang hy vọng mọi người cư xử ngoan.

Framework này giúp bạn tránh câu hỏi sai. Thay vì “A10 hay L4 hay H100?”, team hỏi: “Workload này cần p95 bao nhiêu, runtime nào phù hợp, optimization nào đáng đánh đổi, và ai chịu trách nhiệm quan sát nó?”

Điều đáng giữ, điều nên bỏ qua

Đáng giữ nhất từ các release kiểu SageMaker inference recommendations UI là cách sản phẩm hóa quyết định kỹ thuật. Nó không biến người không biết infra thành chuyên gia inference sau một cú click. Nhưng nó làm một việc rất hữu ích: đưa benchmark, cost-performance, và deployment vào cùng một luồng.

Đáng giữ từ HyperPod là quan điểm “production cần mắt”. Data capture ở nhiều tầng giúp debug và audit tốt hơn, miễn là bạn thiết kế chính sách dữ liệu cẩn thận. Ghi input/output bừa bãi có thể biến observability thành rủi ro bảo mật.

Đáng giữ từ làn sóng chip inference chuyên biệt là áp lực thị trường: inference đang là bottleneck đủ lớn để nhiều người đặt cược phần cứng mới. Nhưng với đa số team Việt Nam, đó chưa phải quyết định tuần này. Đừng để tin định giá hay đơn hàng lớn khiến bạn bỏ qua bài toán gần hơn: endpoint hiện tại có đang được đo đúng không?

Còn điều nên bỏ qua? Bỏ qua ý nghĩ rằng UI recommendation là phán quyết cuối. Nó là bản nháp có căn cứ. Bạn vẫn cần bào phẳng bằng workload thật, security thật, và ngân sách thật.

Một buổi chiều đủ để kiểm tra lại hướng đi

Nếu bạn đang có một model sắp lên production, làm thử quy trình này trong một buổi:

1. Lấy 50-100 request đại diện từ log hoặc từ kịch bản QA. Nếu có dữ liệu nhạy cảm, làm sạch trước.
2. Chia request thành 3 nhóm: ngắn, trung bình, dài. Đừng chỉ lấy prompt đẹp nhất trong demo.
3. Định nghĩa tiêu chí thắng trước khi chạy: p95 latency, cost tương đối, throughput, hoặc độ ổn định streaming.
4. Chạy recommendation hoặc benchmark có cấu trúc để lấy vài cấu hình ứng viên, không chọn một cấu hình duy nhất quá sớm.
5. Deploy canary nhỏ: cho một phần traffic nội bộ chạy thử, bật monitoring và data capture ở mức vừa đủ.
6. Ghi quyết định bằng W-S-O-G: workload nào, serving nào, optimization nào, governance nào. Sau này có sự cố, bạn biết mình đã chọn vì lý do gì.

Điểm mấu chốt: đừng biến inference thành cuộc thi khoe cấu hình. Hãy biến nó thành quy trình ra quyết định có thể lặp lại.

MộcLab cuối cùng không chọn GPU mạnh nhất. Họ chọn cấu hình có latency ổn cho nhóm câu hỏi dài, chi phí chấp nhận được, và có đường rollback rõ. Nghe ít hào nhoáng hơn, nhưng production thường thích những thứ ít hào nhoáng.

Takeaway gọn: inference tốt không bắt đầu từ phần cứng mạnh, mà từ bản vẽ workload đủ thật để team không cưa nhầm tấm gỗ đắt tiền.

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