Google Cloud: Tối ưu chi phí và hiệu năng cho workload AI tạo sinh | CMC Telecom

Google Cloud: Tối ưu chi phí và hiệu năng cho workload AI tạo sinh

May 29, 2026
-
17 views

Làm thế nào để quản lý chi phí AI tạo sinh (GenAI) một cách hiệu quả mà không phải hy sinh hiệu năng và tính sẵn sàng của ứng dụng? Đây là câu hỏi lớn mà nhiều doanh nghiệp đang đối mặt. Google Cloud cung cấp một loạt các tùy chọn hạ tầng linh hoạt, từ mô hình thanh toán theo mức sử dụng (Pay-as-you-Go) đến các giải pháp chuyên biệt, giúp doanh nghiệp tìm ra điểm cân bằng tối ưu giữa chi phí và hiệu năng.

Nền tảng: Các tùy chọn Pay-as-You-Go (PayGo)

Đối với nhiều workload, các gói PayGo tiêu chuẩn của Google Cloud là một điểm khởi đầu mạnh mẽ và linh hoạt. Để tận dụng tối đa, doanh nghiệp cần hiểu rõ các cơ chế quản lý hiệu năng và tính sẵn sàng.

1. Dynamic Shared Quota (DSQ)

Về cơ bản, môi trường PayGo tiêu chuẩn hoạt động dựa trên một nguyên tắc về sự công bằng và hiệu quả gọi là Dynamic Shared Quota (DSQ). Thay vì áp đặt các giới hạn cứng nhắc cho mỗi khách hàng, DSQ phân phối dung lượng GenAI có sẵn một cách thông minh cho tất cả người dùng.

Sơ đồ hoạt động của Dynamic Shared Quota (DSQ) trên Google Cloud

Cách hoạt động:

  • Làn ưu tiên cao: Tổ chức của bạn có một ngưỡng Tokens Per Second (TPS) mặc định. Bất kỳ request nào nằm trong ngưỡng này đều được ưu tiên cao hơn. Làn này được thiết kế để cung cấp tính sẵn sàng cao, nhắm đến mục tiêu SLO 99.5%.
  • Làn nỗ lực tối đa: Nếu bạn gặp đột biến traffic và vượt ngưỡng TPS, các request dư thừa không bị từ chối ngay lập tức. Thay vào đó, chúng được xử lý với mức độ ưu tiên thấp hơn, nhận được thông lượng khi có dung lượng dự phòng.

2. Usage Tiers: Ghi nhận sự đầu tư của khách hàng

Để cung cấp hiệu năng dễ dự đoán hơn khi việc sử dụng GenAI của bạn tăng lên, Google Cloud tự động xếp tổ chức của bạn vào các Hạng mục sử dụng (Usage Tiers) dựa trên chi tiêu trong 30 ngày gần nhất cho các dịch vụ Vertex AI đủ điều kiện. Hạng càng cao, giới hạn Tokens Per Minute (TPM) được đảm bảo càng lớn.

Tại thời điểm bài viết gốc được công bố, đây là các hạng mục cho các họ mô hình phổ biến của Google Cloud:

Họ Mô hình Hạng Chi tiêu (30 ngày) TPM
Pro Models Tier 1 $10 – $250 500,000
Tier 2 $250 – $2,000 1,000,000
Tier 3 > $2,000 2,000,000
Flash / Flash-Lite Models 4,000,000 / 10,000,000

Lưu ý: Để có thông tin mới nhất về mô hình và ngưỡng, doanh nghiệp nên tham khảo tài liệu chính thức.

Điều quan trọng là nên xem giới hạn theo hạng là mức sàn, không phải mức trần.

Mô hình lưu lượng truy cập quan trọng được bảo vệ bởi giới hạn theo hạng sử dụng
  • Lưu lượng quan trọng: Lưu lượng truy cập trong giới hạn của hạng được bảo vệ. Doanh nghiệp sẽ gặp rất ít hoặc không có lỗi 429 (hết tài nguyên) miễn là duy trì trong mức cơ bản này.
  • Bùng nổ đột xuất (Opportunistic bursting): Khi vượt quá giới hạn, bạn vẫn có thể sử dụng dung lượng hệ thống dự phòng trên cơ sở nỗ lực tối đa.

3. Priority PayGo: “Bảo hiểm” cho những đột biến traffic

Nếu workload của bạn dễ có những đột biến không thể đoán trước và không thể chấp nhận rủi ro lỗi 429, nhưng chưa sẵn sàng cam kết một mô hình dung lượng cố định, Priority PayGo là giải pháp. Nó kết hợp sự linh hoạt của PayGo với tính sẵn sàng cao cần thiết cho traffic quan trọng.

Với một khoản phí bổ sung, bạn có thể gắn thẻ các request API cụ thể để được ưu tiên cao hơn.

Lưu ý: Tính năng Priority PayGo hiện chỉ khả dụng cho endpoint toàn cầu. Việc phát hành trên các endpoint khu vực trong tương lai có thể xảy ra nhưng không được đảm bảo.

Để sử dụng Priority PayGo, chỉ cần thêm một header vào lệnh gọi API. Doanh nghiệp cần lưu ý đến giới hạn tăng tốc (ramp limit). Như các hình ảnh dưới đây minh họa, việc tăng các request ưu tiên quá nhanh có thể khiến một số request bị hạ cấp xuống mức ưu tiên tiêu chuẩn nếu dung lượng bị hạn chế.

Biểu đồ minh họa việc tăng nhanh request ưu tiên có thể bị hạ cấp
Biểu đồ minh họa việc tăng chậm request ưu tiên để đảm bảo trải nghiệm tốt

Dành cho workload quan trọng: Provisioned Throughput (PT)

Khi workload GenAI của bạn mang tính sống còn đối với hoạt động kinh doanh và cần một cam kết rõ ràng về tính sẵn sàng, đã đến lúc xem xét Provisioned Throughput (PT). Với PT, bạn đặt trước một lượng dung lượng xử lý mô hình cụ thể với chi phí cố định hàng tháng. Đây là cách duy nhất để nhận được cam kết chất lượng dịch vụ về tính sẵn sàng (availability SLA).

Trong khi mô hình PayGo tiêu chuẩn có uptime SLA (mô hình đang hoạt động), PT cung cấp availability SLA (request của bạn sẽ được xử lý). Đối với PT tiêu chuẩn, khi bạn sử dụng ít hơn lượng đã mua, các lỗi mà lẽ ra là 429 (hết tài nguyên) sẽ được trả về dưới dạng 5XX và được tính vào tỷ lệ lỗi của SLA. Điều này làm cho PT trở thành lựa chọn lý tưởng cho:

  • Các workload sản xuất lớn, có thể dự đoán được.
  • Các ứng dụng có yêu cầu hiệu năng nghiêm ngặt, không chấp nhận việc bị điều tiết (throttling).

Kiểm soát chi tiết các request PT

Mặc định, mọi mức sử dụng vượt quá đơn hàng PT của bạn sẽ tự động chuyển sang PayGo. Tuy nhiên, bạn có thể kiểm soát hành vi này ở cấp độ request bằng cách sử dụng các HTTP header:

  • Ngăn chặn vượt mức: Để đảm bảo không bao giờ vượt quá cam kết PT, hãy thêm header dedicated.
  • Bỏ qua PT theo yêu cầu: Để cố ý gửi một request ưu tiên thấp hơn đến nhóm PayGo, hãy sử dụng header shared.

Giám sát hiệu quả đầu tư

Bạn có thể giám sát chặt chẽ việc sử dụng Provisioned Throughput bằng các chỉ số Cloud Monitoring trên tài nguyên aiplatform.googleapis.com/PublisherModel.

Xây dựng chiến lược tối ưu: Kết hợp các tùy chọn

Hãy xem xét một workload có mức tải cơ bản hàng ngày có thể dự đoán, các đỉnh dự kiến và các đột biến bất ngờ. Chiến lược tối ưu sẽ là:

  1. Provisioned Throughput (PT): Dành cho mức tải cơ bản, quan trọng.
  2. Priority PayGo: Xử lý các đỉnh dự kiến vượt quá cam kết PT hoặc cho traffic quan trọng nhưng không thường xuyên.
  3. Standard PayGo (trong giới hạn hạng): Nền tảng cho traffic chung, không quan trọng.
  4. Standard PayGo (bursting): Dành cho các công việc không nhạy cảm về độ trễ (như xử lý hàng loạt).

Các tùy chọn bổ sung: Batch API và Flex PayGo

Không phải mọi request LLM đều cần thời gian phản hồi dưới một giây. Đây là lúc Gemini Batch API trở nên hữu ích. Khách hàng có thể gộp một lượng lớn request vào một tệp duy nhất và gửi đi một cách bất đồng bộ. Bằng cách đánh đổi việc thực thi ngay lập tức để lấy xử lý bất đồng bộ, bạn sẽ được giảm giá 50% so với chi phí token tiêu chuẩn.

Trong khi đó, Flex PayGo cung cấp một cách truy cập các mô hình Gemini hiệu quả về chi phí, giảm giá 50% so với Standard PayGo. Nó được tối ưu hóa cho các workload không quan trọng có thể chấp nhận thời gian phản hồi lên đến 30 phút. Các trường hợp sử dụng lý tưởng bao gồm:

  • Phân tích ngoại tuyến văn bản và tệp đa phương thức.
  • Đánh giá và đo lường chất lượng mô hình.
  • Chú thích và gán nhãn dữ liệu.

Bắt đầu

Để tìm hiểu sâu hơn, doanh nghiệp có thể:

Tin liên quan

CMC Telecom cam kết hỗ trợ doanh nghiệp của bạn kịp thời

Hãy gửi phản hồi và câu hỏi của bạn cho chúng tôi để được giải đáp

    Hi! Bạn đang cần tư vấn về dịch vụ của Google?