API Decisions của Google trả lời 1.000 câu hỏi và không tính phí đầu ra

Phần rẻ nhất của Gemini Decision 1 chính là phần không hề tồn tại. Google đã đặt mô hình phía sau một Gemini Decisions API mới vào ngày 11 tháng 11 năm 2026, và trang định giá ghi đầu ra là không — không phải rẻ, không phải được giảm giá, mà là không có, bởi vì POST /v1beta/decisions không có văn xuôi nào để tạo. Bạn gửi một khối đầu vào dùng chung cộng với tối đa 1.000 câu hỏi được định kiểu; bạn nhận lại một câu trả lời đã hiệu chỉnh cho mỗi câu hỏi và không có gì khác. Con số trên bảng xếp hạng đã thu hút sự chú ý vào ngày ra mắt. Dòng tính phí mới là thứ thay đổi cách bạn xây dựng, và đáng để tính toán trước khi bạn sao chép sơ đồ kiến trúc của bất kỳ ai.

Mọi quyết định khác về mô hình mà bạn đã đưa ra trong hai năm qua đều được định hình bởi hai loại chi phí kéo theo hai hướng ngược nhau: đầu vào bạn muốn gửi một lần, và đầu ra bạn muốn giữ ngắn. Endpoint này loại bỏ hoàn toàn căng thẳng thứ hai và thay bằng một căng thẳng khác, nằm bên trong một yêu cầu duy nhất. Một khi bạn thấy căng thẳng mới nằm ở đâu, phần còn lại trong thiết kế của API — giới hạn số câu hỏi, ngữ cảnh dùng chung, việc không có bộ nhớ đệm — sẽ không còn trông tùy tiện nữa.

Việc không có token đầu ra ảnh hưởng thế nào đến phép tính số học

Hãy lấy một tác vụ chấm điểm tài liệu thực tế: một chính sách hoặc hợp đồng dài 40.000 token và 1.000 câu hỏi bạn muốn được trả lời về tài liệu đó. Một yêu cầu tới Decisions API chỉ tính phí 40.000 token đầu vào một lần, ở mức 0,10 USD cho mỗi triệu token, tức là bốn phần mười của một xu — 0,004 USD cho cả một nghìn câu trả lời.

Bây giờ hãy đặt cùng 1.000 câu hỏi theo cách bạn hẳn đã đặt chúng một tuần trước, dưới dạng 1.000 lệnh gọi generate-content riêng biệt. Mỗi lệnh gọi phải mang theo tài liệu, vì endpoint chat không có cách nào giữ nó xuyên suốt các lệnh gọi. Đó là 40 triệu token đầu vào, tức $4.00 với cùng mức giá trên mỗi token, và khoảng cách sẽ còn nới rộng khi bạn cộng thêm số token đầu ra mà mỗi lệnh gọi đó lẽ ra sẽ tạo ra. Envelope không phải là một tính năng tiện dụng. Đó là mức chênh lệch chi phí gấp một nghìn lần cho cùng một công việc, và nó xuất phát từ một lựa chọn thiết kế duy nhất: các câu hỏi được đánh giá dựa trên một ngữ cảnh dùng chung trong một lượt, chứ không phải mỗi lượt khứ hồi một câu hỏi.

Phép tính đó cũng cho bạn biết cấu trúc của khối lượng công việc mà mô hình này mong muốn. Nhiều câu hỏi về một đối tượng lớn, được trả lời cùng nhau. Nếu câu hỏi của bạn liên quan đến 1.000 đối tượng khác nhau, bạn sẽ có 1.000 yêu cầu và không tiết kiệm được gì.

Hạn mức: 262.144 token, dùng chung và giới hạn ở 1.000 câu hỏi

Cửa sổ ngữ cảnh bao trùm đầu vào dùng chung và mọi câu hỏi trong yêu cầu cùng một lúc, ở mức 262.144 token. Trong ngân sách đó, bạn có thể đặt từ 1 đến 1.000 câu hỏi. Con số quan trọng là giới hạn trên: 1.000 câu hỏi trong một lần gọi không thuộc địa hạt của bộ phân loại, mà là lượng phán đoán tương đương cả một bộ máy quy tắc bị nén vào một lượt. Một phiếu hỗ trợ có thể được đối chiếu với bốn mươi điều khoản chính sách; một hồ sơ khoản vay có thể được kiểm tra với mọi quy tắc thẩm định cùng một lúc.

Hai đặc điểm của cấu trúc yêu cầu rất dễ bị bỏ sót và rất tốn kém nếu phát hiện muộn. Các câu hỏi được đánh giá độc lập — câu trả lời của một câu hỏi không làm điều kiện cho câu tiếp theo, vì vậy bạn không thể xâu chuỗi lập luận bằng cách đặt một câu hỏi tiếp theo phụ thuộc vào câu trả lời trước đó. Và mô hình không bao giờ nhìn thấy khóa câu hỏi của bạn, chỉ thấy văn bản hướng dẫn bạn viết, nên các khóa chỉ để bạn tự ghi chép nội bộ và phần hướng dẫn phải tự đứng vững.

Ba dạng câu hỏi, và cái bẫy nằm trong mỗi dạng

• Có/không — loại noul trả về xác suất từ 0.01 đến 0.99 cùng điểm tin cậy. Giới hạn bị kẹp ở cả hai đầu, nên ngưỡng định tuyến đặt ở 0.995 sẽ không bao giờ kích hoạt, dù mô hình có chắc chắn đến đâu. Hãy chọn ngưỡng nằm trong phạm vi API thực sự có thể trả về.

• Lựa chọn — từ hai đến 255 tùy chọn được đặt tên, trả về tùy chọn thắng cuộc, xác suất cho mỗi tùy chọn có tổng bằng một và độ tin cậy. Trước khi chấm điểm, API sắp xếp các khóa tùy chọn của bạn theo thứ tự bảng chữ cái theo thứ tự byte UTF-8, nghĩa là thứ tự khóa JSON không quan trọng và một trận hòa chính xác sẽ được giải quyết theo khóa nào sắp xếp trước. Hướng dẫn của Google xuất phát từ đó: hãy đặt tên tùy chọn bắt tất cả của bạn là other, vì một tên như none_of_the_above sắp trước hầu hết các danh mục thực và sẽ thắng những trận hòa mà lẽ ra nó nên thua.

• Điểm — từ hai đến 255 mức rubric có thứ tự, khuyến nghị từ hai đến mười. Giá trị trả về là một mức kỳ vọng có trọng số theo xác suất, và vì giá trị kỳ vọng lấy trung bình các chỉ số mảng thay vì các nhãn, nên một thang đo được viết là 1/10/100/1000 sẽ tạo ra một con số không nằm trên thang đo của bạn. Hãy giữ rubric cách đều nhau theo chỉ số, hoặc tự chuyển chỉ số kỳ vọng trở lại thành nhãn.

Những gì tài liệu liệt kê là không khả dụng

Các thiếu hụt đều cùng một hướng: đây là một endpoint chỉ gọi một lần, không có gì bao bọc xung quanh. Không có bộ nhớ đệm ngữ cảnh, nên một tài liệu chính sách được tái sử dụng qua các yêu cầu sẽ bị tính phí lại toàn bộ mỗi lần. Không có Batch API, điều này khiến không thể thực hiện một đợt xử lý hàng loạt qua đêm với giá bằng nửa đối với các ticket của năm ngoái. Không có hạng Flex hay Priority. Mô hình chỉ có trên Gemini Developer API, ở phiên bản v1beta, và không có mục niêm yết Vertex AI trong tài liệu mà Google phát hành — một chi tiết quan trọng với bất kỳ ai có quy trình mua sắm đi qua hợp đồng đám mây thay vì khóa API.

Media rộng một cách bất thường và đồng thời bị giới hạn một cách bất thường. Văn bản, hình ảnh, video, âm thanh và PDF đều đi trong một yêu cầu. Các giới hạn là 100 MB base64 nội tuyến, 50 MB cho một PDF và 15 MB cho mỗi URL HTTPS bên ngoài. Liên kết YouTube không được chấp nhận và URI gs:// cũng vậy; bạn truyền tham chiếu tệp đã tải lên, URL đã ký hoặc byte.

Giới hạn tốc độ bắt đầu ở 200 yêu cầu và 50.000 token mỗi phút trên gói miễn phí, tăng lên 1.500 và một triệu ở Bậc 1, và đạt 5.000 yêu cầu và bốn triệu token mỗi phút ở Bậc 2 mà không có giới hạn yêu cầu hàng ngày. Gói miễn phí không mất phí nhưng được ghi nhận là được dùng để cải thiện sản phẩm của Google, điều này khiến nó không phù hợp cho bất kỳ thứ gì thuộc điều khoản bảo mật.

Tỷ số, tóm gọn

Trên Artificial Analysis Decision Index v2.1, mô hình đạt 66 — 65,98 khi chưa làm tròn — đứng thứ chín trong số mười tám mô hình ra quyết định mà hội đồng xếp hạng. Nó đứng đầu tuyệt đối ở hai trong sáu thành phần, AA-Omniscience-Decision v1.1 và HLE-MultiChoice v1.1, cả hai đều có trọng số 15%, và ở giữa bảng ở AA-Paperclip với trọng số 30%, thành phần quyết định phần lớn điểm tổng hợp. Chi phí đo được là 345 USD cho một triệu tác vụ và độ trễ 211 mili giây mỗi tác vụ, so với mức trung vị của nhóm là 209. Google không công bố bảng đánh giá chuẩn nào của riêng mình cùng bản phát hành; mọi con số hiệu năng ở đây đều của hội đồng độc lập, trên bộ khung kiểm thử của chính họ. Phép tính đằng sau con số 66 là một câu hỏi riêng và một bài viết riêng.

Đưa nó vào một pipeline mà bạn đã định tuyến sẵn

OrcaRouter không cung cấp gemini-decision-1, và lý do mang tính cấu trúc chứ không phải thương mại: một endpoint chỉ trả xác suất không phải là đích chat-completions, nên không có gì để một router theo hình dạng của chúng tôi đặt phía sau một khóa. Nửa pipeline mà chúng tôi hướng tới là nửa còn lại. Một dịch vụ ra quyết định hầu như luôn gồm hai lời gọi — một thứ phác thảo câu trả lời ứng viên, bộ tiêu chí hoặc danh sách rút gọn, và một thứ chấm điểm nó — và lời gọi phác thảo chính là nơi lựa chọn mô hình thực sự bị tranh cãi.

Lệnh gọi đó có thể chạy qua hơn 200 mô hình trên một endpoint, với giá niêm yết của nhà cung cấp được chuyển nguyên với mức cộng thêm 0%, vì vậy khi một nhà cung cấp giảm giá, con số mới sẽ có hiệu lực ở phía chúng tôi ngay trong ngày thay vì vào chu kỳ thanh toán tiếp theo. Model fusion có chỗ đứng ở đây theo cách mà nó không có trong giao diện trò chuyện: hai mô hình soạn nháp tạo ra những câu trả lời ứng viên cạnh tranh, và Decisions API chấm điểm cả hai theo cùng một bộ tiêu chí trong một yêu cầu duy nhất, điều này biến một bài kiểm tra A/B thành quyết định cho từng bản ghi.

Failover cũng đáng để nói chính xác. Failover tự động bảo vệ lệnh gọi sinh — nếu nhà cung cấp đứng sau mô hình soạn thảo của bạn trả về lỗi, yêu cầu sẽ được định tuyến lại và pipeline vẫn tiếp tục chạy. Nó không thể bảo vệ lệnh gọi chấm điểm, vì chỉ có đúng một nơi để gửi yêu cầu đó. Nếu endpoint quyết định bị ngừng hoạt động, pipeline của bạn cũng ngừng hoạt động, và không lượng định tuyến nào thay đổi được điều đó. Hãy thiết kế phần soạn thảo cho có khả năng phục hồi và chấp nhận rằng phần chấm điểm là một phụ thuộc.

Điểm mấu chốt

Decisions API đáng để áp dụng vì một lý do, và đó không phải vị trí trên bảng xếp hạng: nó thu gọn một nghìn lượt khứ hồi thành một đầu vào được tính phí, và điều đó thay đổi những câu hỏi nào trở nên rẻ để hỏi. Hãy xây dựng dựa trên nó nếu vấn đề của bạn trông giống nhiều phán đoán trên một đối tượng lớn — một hợp đồng, một hồ sơ yêu cầu bồi thường, một giờ video — và hãy kỳ vọng giữ các prompt của bạn trong một yêu cầu, vì mọi thứ khiến nó rẻ đều diễn ra giữa token đầu tiên và token cuối cùng của một lần gọi duy nhất. Nếu vấn đề của bạn trông giống một câu hỏi trên một nghìn đối tượng nhỏ, phần bao chẳng mang lại gì cho bạn và giá đầu vào đơn giản là gấp ba lần mức một mô hình ra quyết định rẻ hơn tính.