Một API gọi hết mọi model — trò gì đây?

Cloudflare vừa biến mình thành inference layer — một binding gọi được mọi provider. Câu hỏi thật: bạn có nên đặt cược hạ tầng AI vào một tầng trung gian duy nhất?

Bạn đang giữ bao nhiêu API key?

Nếu câu trả lời là "một" thì bạn hoặc rất kỷ luật, hoặc chưa build agent thật sự. Thực tế mà mình thấy ở hầu hết team Việt Nam đang làm AI: ít nhất 3 provider, 3 bộ SDK, 3 trang billing khác nhau, và một spreadsheet theo dõi chi phí mà tháng nào cũng quên cập nhật.

Cloudflare vừa tuyên bố muốn giải bài toán đó. Họ gọi nó là "unified inference layer" — nói thẳng ra thì đó là một tầng trung gian: bạn gọi một API duy nhất, Cloudflare route request đến provider phù hợp — OpenAI, Anthropic, hay model nào khác.

Hậu trường của một lần gọi model

Khi agent của bạn gọi inference, có rất nhiều thứ diễn ra mà user không thấy — giống khán giả xem vở diễn chỉ thấy diễn viên trên sân khấu, nhưng phía sau cánh gà là cả đội kỹ thuật lo âm thanh, ánh sáng, chuyển cảnh.

Cloudflare đang muốn làm đội hậu trường đó. Cụ thể:

Kịch bản thật: team 5 người, 3 model, 1 agent

Giả sử team bạn đang build một customer support agent. Flow như sau:

  1. User gửi message — dùng model nhỏ, nhanh để phân loại: hỏi giá, khiếu nại, hay hỏi kỹ thuật?
  2. Dựa trên phân loại, gọi model reasoning lớn hơn để lên kế hoạch trả lời
  3. Thực thi từng bước nhỏ bằng model nhẹ

Một flow đơn giản vậy đã chain 3 lần gọi inference. Nhân lên hàng nghìn user, mỗi lần một model chậm thêm chút, tổng cộng bạn đang cộng dồn latency đáng kể vào mỗi request. Mà nếu một provider sập giữa chain? Cả flow đổ theo.

Đây là lý do inference layer có ý nghĩa — không phải vì nó trendy, mà vì nó giải quyết bài toán operational rất cụ thể: reliability và cost visibility khi bạn phụ thuộc nhiều provider cùng lúc.

Email — cánh cửa agent mà ít ai nghĩ tới

Cùng đợt này, Cloudflare mở public beta cho Email Service — cho phép agent gửi và nhận email trực tiếp từ Workers.

Nghĩ lại thì email là giao thức mà ai cũng có sẵn. Không cần user cài app, không cần webhook phức tạp. Giả sử bạn build một pipeline xử lý hóa đơn cho đội kế toán: khách hàng forward email hóa đơn vào một địa chỉ chuyên dụng, agent tự extract thông tin, đối soát, rồi reply kết quả — tất cả không cần UI riêng.

Ở Việt Nam, mình thấy pattern này cực kỳ hợp cho các team nhỏ đang build internal tools. Đội procurement, đội support, đội vận hành — email là interface sẵn có, không cần training user, không cần budget làm frontend.

Ba cái bẫy mình muốn nói trước

Bẫy 1: Vendor lock-in kiểu mới. Bạn dùng inference layer để tránh lock-in vào một model provider, nhưng lại lock-in vào chính inference layer đó. Mọi routing logic, fallback config, cost dashboard — đều nằm trong ecosystem của Cloudflare. Di chuyển đi? Viết lại.

Bẫy 2: "Một API cho tất cả" không có nghĩa là bạn bớt việc. Bạn vẫn phải hiểu đặc tính từng model, vẫn phải test prompt trên từng provider, vẫn phải tune latency cho từng use case. Inference layer giúp phần ops, nhưng phần engineering thì vẫn là của bạn.

Bẫy 3: Latency overhead. Thêm một layer trung gian nghĩa là thêm một hop. Cloudflare có edge network nên overhead nhỏ, nhưng "nhỏ" nhân lên 10 lần gọi trong một agent chain thì không còn nhỏ nữa. Đo trước khi commit.

Thử ngay chiều nay

Nếu bạn muốn test mà không cần migrate cả hệ thống:

  1. Tạo một Cloudflare Workers project — free tier đủ dùng thử
  2. Gọi một model hosted sẵn trên Cloudflare qua AI.run() (ví dụ Llama hay Mistral)
  3. Đổi sang gọi OpenAI qua cùng binding đó, so sánh latency và response format
  4. Bật AI Gateway logging để xem chi tiết từng request — đây là phần có giá trị nhất để đánh giá

Mục tiêu: không phải migrate production, mà là có data thật để quyết định inference layer có đáng cho use case của bạn không.

Open-source alternatives

Cloudflare không phải lựa chọn duy nhất. Nếu bạn muốn tự kiểm soát:

Sự khác biệt chính: Cloudflare tích hợp sâu với Workers ecosystem (edge computing, email, storage), còn LiteLLM cho bạn toàn quyền kiểm soát nhưng bạn tự lo vận hành.

Rốt cuộc thì nên nghĩ gì?

Cloudflare đang đặt cược rằng tương lai AI là multi-model, multi-provider — và ai kiểm soát tầng routing ở giữa, người đó nắm vị trí chiến lược. Đội hậu trường tốt thì không ai nhớ tên, nhưng thiếu họ thì vở diễn sập sân khấu.

Bài toán thật cho bạn không phải "có nên dùng Cloudflare" mà là: infra hiện tại của bạn đã sẵn sàng cho multi-model chưa? Nếu chưa, thì dù chọn tool nào, đó vẫn là bài tập phải làm.

Plot twist: cái khó nhất không phải chọn inference layer — mà là thuyết phục cả team dọn dẹp đống API key đang rải khắp nơi trong repo.

---

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

Nguồn tham khảo