Azure AI Foundry giờ là Microsoft Foundry: FDE cần nắm gì khi triển khai model và agent trên Azure của khách

Một tin tuyển “Azure Forward Deployment Engineer” cấp kiến trúc sư, do Dice đăng cho Fusion Global Solutions, đòi kinh nghiệm thực chiến dựng AI agent trên Azure AI Foundry. Nếu bạn mở tài liệu của Microsoft hôm nay thì sẽ không gặp lại cái tên đó: sản phẩm giờ là Microsoft Foundry, portal chính ở ai.azure.com.

Lệch tên nghe thì vặt, nhưng nó phản ánh đúng việc của FDE. Ở khách doanh nghiệp, bạn sẽ đụng code viết theo API cũ, tài liệu nội bộ dùng tên cũ và những quyết định hạ tầng mà chẳng ai còn nhớ lý do. Muốn làm được việc thì phải biết nền tảng đã thay đổi ở đâu và chỗ nào hay vỡ khi triển khai thật.

Foundry thực ra gom những gì?

Microsoft mô tả Foundry là nơi gom agent, model và tool về chung một nhóm quản trị. Tracing, monitoring, evaluation, RBAC, networking và policy đều nằm trong cùng một Azure resource provider. Nhóm dịch vụ trước đây tên Azure AI Services nay được gọi là Foundry Tools.

Với FDE, thay đổi quan trọng nhất là Agent API: Assistants API (Agents v1) đã nhường chỗ cho Responses API (Agents v2). Nếu repo của khách vẫn gọi Assistants, bạn nên ghi việc chuyển đổi vào kế hoạch ngay từ đầu, đừng đợi tới tuần cuối mới phát hiện.

Câu hỏi đầu tiên: dữ liệu được xử lý ở đâu?

Lúc triển khai model, deployment type quyết định ba thứ: dữ liệu được xử lý ở đâu (global, data zone hay một Azure geography), cách tính tiền và hiệu năng. Microsoft khuyên phần lớn workload nên bắt đầu với Global Standard, vì model mới luôn ra mắt ở loại này trước, giá thấp nhất và phủ nhiều region nhất.

Giả sử bạn đang làm cho một công ty bảo hiểm ở châu Âu và bộ phận compliance yêu cầu prompt không được rời EU. Global Standard lúc này không còn là lựa chọn mặc định nữa. Data Zone EU chỉ xử lý prompt và response trong vùng dữ liệu đó. Nếu khách cần throughput ổn định cho giờ cao điểm thì xem thêm Provisioned, loại dùng PTU.

Deployment type	Khi nào chọn
Global Standard	Mặc định, khi khách không ràng buộc nơi xử lý dữ liệu
Data Zone (US, EU, APAC)	Khi compliance buộc việc xử lý phải nằm trong một vùng dữ liệu
Provisioned (PTU)	Khi cần throughput ổn định, đặt trước

Hỏi câu này ở buổi discovery đầu tiên, trước khi viết dòng code nào. Đổi deployment type khi demo đã chạy rồi tốn công hơn nhiều so với chọn đúng từ đầu.

Prompt agent hay hosted agent?

Agent Service có ba loại agent. Prompt agent viết theo kiểu khai báo và Foundry chạy hộ bạn. Voice-based prompt agent là biến thể dùng giọng nói. Hosted agent cho bạn nhiều quyền kiểm soát nhất: bạn mang code và framework riêng, đóng gói thành container hoặc file zip, còn Foundry lo endpoint, scaling và identity.

Hai loại này khác nhau rõ nhất ở phần networking. Theo tài liệu của Microsoft, private networking có sẵn cho prompt agent, còn hosted agent hỗ trợ BYO VNet: mỗi session chạy trong một sandbox cách ly ở mức VM và nối vào VNet của khách.

Thử hình dung một ngân hàng đã có agent viết bằng LangChain, cần gọi một API chấm điểm tín dụng chỉ mở trong mạng nội bộ.

Viết lại thành prompt agent nghĩa là bỏ đi code đang chạy, còn hosted agent cho phép đóng gói nguyên code thành container. Nhưng chỗ quyết định là BYO VNet: session có nối vào VNet của ngân hàng thì agent mới với tới được API kia.

Lỗi hay gặp là demo hosted agent ở môi trường mở, mọi thứ chạy trơn tru, rồi tới lúc đưa vào VNet của khách thì agent không gọi được hệ thống nội bộ vì chưa ai bàn với đội mạng.

Vì thế, với khách đã có agent viết bằng Semantic Kernel hay LangChain, hosted agent thường là lựa chọn hợp lý, nhưng hãy hẹn đội mạng ngay tuần đầu và liệt kê mọi hệ thống nội bộ mà agent cần gọi tới.

Việc thật nằm ở standard setup

Standard agent setup lưu trạng thái agent trên tài nguyên single-tenant do chính khách quản lý: Cosmos DB, Storage và AI Search. Dữ liệu ở lại trong tầm kiểm soát của khách, nhưng đồng nghĩa FDE thường phải tự dựng và cấp quyền cho từng tài nguyên.

Có vài cái bẫy cụ thể. Tài khoản Cosmos DB for NoSQL phải có tổng throughput tối thiểu 3000 RU/s, thiếu là provisioning thất bại. Với bản private networking, bạn cần một subnet được ủy quyền cho Microsoft.App/environments, tắt public access và cấu hình private DNS zone.

Bẫy dễ quên nhất là private endpoint tới AI Search, Storage và Cosmos DB không tự được tạo khi bạn triển khai Foundry resource. Microsoft có mẫu Bicep và Terraform chính thức, nên đừng dựng tay trên portal. Hãy bắt đầu từ mẫu, ghi lại từng chỗ đã chỉnh, rồi bàn giao cho đội platform của khách dưới dạng code.

Học gì trước để khớp với tin tuyển?

Tin tuyển của Fusion Global Solutions liệt kê Azure OpenAI, Azure AI Foundry, Semantic Kernel và LangChain cạnh nhau, kèm yêu cầu làm việc trực tiếp với khách doanh nghiệp. Đọc danh sách ấy, có thể thấy họ cần người vừa hiểu framework agent vừa đưa được agent vào hạ tầng Azure của doanh nghiệp.

Nên học theo thứ tự này: deployment type và data residency trước, sau đó là standard setup, cuối cùng là private networking bằng Terraform hoặc Bicep. Khi ghi CV, nêu kết quả cụ thể, ví dụ “triển khai Agent Service standard setup trong VNet riêng bằng Terraform, model chạy Data Zone EU”, thay vì chỉ liệt kê “Azure AI Foundry” trong mục kỹ năng.

Tên sản phẩm còn có thể đổi tiếp. Mấy câu hỏi về nơi dữ liệu được xử lý, ai sở hữu trạng thái agent và đường mạng nào đang mở thì vẫn sẽ có người phải trả lời, và người đó thường là FDE.