Bedrock, Azure OpenAI, Vertex AI: đưa mô hình vào đúng đám mây của khách

Thử hình dung tuần đầu tiên của bạn ở chỗ khách. Bản demo đang chạy trơn tru bằng API key cá nhân. Rồi đội an ninh của khách nhắn đúng một câu: mọi lời gọi mô hình phải đi qua tài khoản đám mây của công ty, ở vùng đã được duyệt, và dùng quyền truy cập do họ cấp.

Lúc này bản demo gần như phải viết lại. Mô hình không có lỗi gì cả. Chỉ là bản demo chưa được dựng trong môi trường của khách.

Đây là chỗ khác nhau lớn nhất giữa một developer làm sản phẩm và một FDE. Developer thường được tự chọn công nghệ. FDE thì bước vào một đám mây mà khách đã chọn từ nhiều năm trước, và phải đi lại trong đó thành thạo như người nhà.

Nắm được ba dịch vụ dưới đây, bạn sẽ không mất cả tuần đầu chỉ để hỏi “gọi mô hình ở đâu”.

Bạn không chọn đám mây, nhưng phải biết cách đi vào

Trên AWS, cửa vào là Amazon Bedrock. AWS mô tả đây là dịch vụ được quản lý hoàn toàn, giúp doanh nghiệp truy cập foundation model của nhiều hãng AI. Bedrock hỗ trợ hơn 100 mô hình, từ Amazon, Anthropic, DeepSeek, Moonshot AI, MiniMax, OpenAI đến xAI.

Với FDE, điểm thực tế nhất là Bedrock có nhiều kiểu API: Messages, Responses, Chat Completions, Converse và Invoke. Nhờ vậy bạn có thể giữ nguyên SDK đã quen của Anthropic hay OpenAI, hoặc dùng boto3. Với ứng dụng mới, AWS khuyến nghị dùng endpoint bedrock-runtime.

Trên Azure, Azure OpenAI nay nằm trong Microsoft Foundry. Danh mục mô hình chia làm hai nhóm: mô hình do Azure bán trực tiếp, và mô hình của đối tác hoặc cộng đồng. Ngoài dòng GPT còn có các bộ mô hình của Cohere, DeepSeek, Meta, Mistral AI và xAI.

Microsoft cũng nói thẳng rằng mô hình nào có sẵn còn tùy vùng và loại cloud, và Azure Government có trang tài liệu riêng.

Trên Google Cloud, cái tên bạn hay gặp nhất là Vertex AI. Tài liệu mới của Google gọi nền tảng này là Gemini Enterprise Agent Platform, một bộ công cụ phủ cả vòng đời ML, từ xây dựng, huấn luyện đến quản lý mô hình. Blog cũ ghi “Vertex AI”, tài liệu mới ghi tên kia, nhưng đó vẫn là một nền tảng.

Khía cạnh	AWS	Azure	Google Cloud
Dịch vụ cần tìm	Amazon Bedrock	Azure OpenAI trong Microsoft Foundry	Gemini Enterprise Agent Platform (tên cũ Vertex AI)
Phạm vi dịch vụ	Truy cập hơn 100 foundation model của nhiều hãng	Mô hình Azure bán trực tiếp, cùng mô hình của đối tác và cộng đồng	Bộ công cụ xây dựng, huấn luyện và quản lý mô hình ML
Nên hỏi khách điều gì trước	Có dùng cross-Region inference không?	Mô hình có ở vùng và loại cloud của khách không?	Khách đã duyệt vùng nào để đặt tài nguyên và dữ liệu?

Ví dụ: đưa prototype sang Bedrock của một công ty logistics

Giả sử khách là một công ty logistics chạy toàn bộ hệ thống trên AWS. Họ muốn có một agent đọc email khiếu nại rồi tóm tắt lại cho nhân viên chăm sóc khách hàng. Prototype của bạn hiện đang gọi thẳng API của nhà cung cấp mô hình.

Bước đầu tiên chưa phải là viết code. Thói quen nên có trên bất kỳ cloud nào là mở console trong tài khoản của khách và xem mô hình mình cần có sẵn ở vùng họ dùng hay không. Microsoft ghi rõ điều này với Azure; trên AWS hay Google Cloud, cứ coi đó là giả định an toàn.

Nếu không có, cả kế hoạch phải đổi, và phát hiện càng sớm thì đổi càng rẻ.

Bước thứ hai là cross-Region inference. Bedrock hỗ trợ hai kiểu, Global và Geo, cho thông lượng cao hơn và giá mỗi token thấp hơn. Nghe thì hấp dẫn, nhưng như vậy request có thể được xử lý ngoài vùng gốc, trong khi email khiếu nại chứa tên, số điện thoại và địa chỉ của khách hàng.

Nếu chính sách của khách yêu cầu dữ liệu phải nằm trong một vùng, bạn phải hỏi trước khi bật tính năng này.

Bước thứ ba là quyền truy cập. Đừng nhét access key vào biến môi trường. Hãy cho ứng dụng chạy dưới một IAM role do khách cấp, chỉ được gọi đúng mô hình cần dùng. Bedrock áp dụng tinh thần này khá triệt để: ngay cả công cụ Web Search tích hợp sẵn cũng chỉ lấy dữ liệu từ web bên ngoài khi IAM cho phép rõ ràng.

Cách làm này thuyết phục đội an ninh của khách hơn bất kỳ slide nào.

Đến lúc này mới tới code. Đoạn gọi mô hình bằng boto3 qua API Converse khá ngắn:

import boto3

client = boto3.client("bedrock-runtime", region_name=REGION)  # vùng khách đã duyệt

def generate(prompt: str) -> str:
    resp = client.converse(
        modelId=MODEL_ID,
        messages=[{"role": "user", "content": [{"text": prompt}]}],
    )
    return resp["output"]["message"]["content"][0]["text"]

Chi tiết đáng chú ý là hàm generate(). Phần còn lại của ứng dụng chỉ gọi hàm này và không biết gì về Bedrock. Nếu sau này khách mua lại một công ty chạy trên Azure, bạn chỉ cần viết thêm một adapter cho Foundry, còn logic tóm tắt khiếu nại giữ nguyên.

Adapter mới đó vẫn phải trả lời lại câu hỏi về vùng ngay từ đầu, vì trên Azure mô hình có sẵn hay không còn tùy vùng và loại cloud, kể cả với Azure Government. Đổi cloud chỉ tốn thêm một file adapter, nhưng các câu hỏi kiểm tra thì phải hỏi lại từ đầu.

Thử thêm một tình huống: một chi nhánh của khách lại chạy trên Google Cloud. Việc đầu tiên là tra tài liệu dưới cả hai tên, Vertex AI và Gemini Enterprise Agent Platform, để không bỏ sót hướng dẫn cũ lẫn mới.

Google Cloud có vùng trải từ châu Á, Úc, châu Âu đến châu Phi, Trung Đông và hai châu Mỹ, nên bạn hỏi chi nhánh đã duyệt vùng nào rồi đặt tài nguyên đúng ở đó, sau đó viết adapter thứ ba cho cùng hàm generate().

Bước cuối là hạ tầng. Đừng bấm tay trong console để tạo role và tài nguyên. AWS có CDK, một framework để khai báo hạ tầng bằng code rồi dựng qua CloudFormation. Google Cloud cũng cho phép quản lý tài nguyên qua console, CLI, thư viện client hoặc Terraform; với chi nhánh kia, Terraform là lựa chọn tự nhiên.

Khi hạ tầng nằm trong repo, đội của khách có thể review, dựng lại và tiếp quản nó sau khi bạn rời đi.

Năm câu hỏi cho buổi kickoff

Rút từ ví dụ trên, bạn có một quy trình dùng được cho cả ba đám mây. Câu đầu tiên: khách dùng cloud nào, và vùng nào đã được duyệt? Google Cloud có vùng ở châu Á, Úc, châu Âu, châu Phi, Trung Đông, Bắc Mỹ và Nam Mỹ, nhưng khách thường chỉ cho phép dùng vài vùng.

Câu thứ hai: mô hình bạn cần có trong danh mục ở đúng vùng đó không? Câu thứ ba: ai cấp quyền, và quyền tối thiểu cần xin là gì? Câu thứ tư: dữ liệu nào nhạy cảm, và có được xử lý ngoài vùng hay không?

Câu cuối: khách triển khai bằng công cụ IaC nào? Biết điều này, bạn sẽ viết theo chuẩn của họ chứ không mang chuẩn của mình vào.

Những lỗi khiến tuần đầu trôi mất

Lỗi phổ biến nhất là nghĩ rằng mô hình có mặt ở mọi vùng. Microsoft ghi rõ mô hình có sẵn hay không còn tùy vùng và loại cloud. Một demo chạy được ở vùng Mỹ chẳng đảm bảo gì cho vùng của khách.

Lỗi thứ hai là bật cross-Region inference chỉ vì nó rẻ hơn và nhanh hơn, trong khi chưa hỏi chính sách về nơi lưu và xử lý dữ liệu. Lỗi thứ ba là để credential cá nhân trong code. Code vẫn chạy, nhưng sẽ trượt ngay buổi review an ninh đầu tiên.

Lỗi thứ tư nhỏ nhưng tốn thời gian: tìm “Vertex AI” trong tài liệu mới mà không biết nền tảng đã đổi tên, hoặc ngược lại. Lỗi cuối cùng là dựng mọi thứ bằng tay trong console. Đến ngày bàn giao, không ai dựng lại được môi trường bạn đã làm.

Biến kỹ năng này thành một dòng trong CV

Khi đọc mô tả tuyển FDE, hãy để ý các cụm như “deploy into customer cloud”, “Bedrock”, “Azure OpenAI” hay “IAM”. Thấy chúng là biết công việc sẽ rất giống ví dụ trên.

Trong CV, đừng chỉ ghi “có kinh nghiệm AWS” mà hãy viết cụ thể: chuyển một ứng dụng LLM sang Bedrock trong tài khoản của khách, chạy bằng IAM role với quyền tối thiểu, hạ tầng viết bằng CDK.

Dòng đó cho nhà tuyển dụng thấy bạn biết dựng một ứng dụng chạy ổn trong môi trường của người khác. Ai cũng gọi được mô hình. Ở vị trí FDE, phần đáng tiền là mọi việc phải làm sau đó.