Google: Gemini 3.1 Pro Preview vs google/gemini-pro-latest

Về giá, Google: Gemini 3.1 Pro Preview là lựa chọn rẻ hơn — thấp hơn khoảng 50% so với google/gemini-pro-latest về tokens đầu vào. Với khối lượng công việc nhạy cảm về độ trễ, google/gemini-pro-latest trả về token đầu tiên sớm hơn. Về chất lượng benchmark, Google: Gemini 3.1 Pro Preview dẫn đầu chỉ số tổng hợp. Chọn Google: Gemini 3.1 Pro Preview để giảm thiểu chi phí, hoặc google/gemini-pro-latest khi tốc độ phản hồi quan trọng nhất.

Cả Google: Gemini 3.1 Pro Preview và google/gemini-pro-latest đều có sẵn qua cùng một endpoint OrcaRouter theo giá gốc của nhà cung cấp, không cộng thêm phí token nào, nên chuyển đổi giữa hai bên chỉ là thay đổi một dòng và các con số dưới đây đúng là số tiền bạn thực trả. So sánh này lấy giá thời gian thực, context window được công bố, cùng các số đo latency và throughput của chính OrcaRouter, để bạn có thể cân nhắc chi phí so với hiệu năng cho khối lượng công việc cụ thể của mình thay vì dựa vào benchmark trưng bày của nhà cung cấp. Lựa chọn đúng gần như luôn phụ thuộc vào hình dạng lưu lượng của bạn — độ dài prompt, lượng văn bản bạn sinh ra, người dùng của bạn nhạy cảm với latency đến mức nào, và việc suy luận khó đến đâu — nên các mục dưới đây bóc tách quyết định theo từng chiều một và kết thúc bằng một khuyến nghị cụ thể. Bất cứ khi nào thiếu một chỉ số cho một trong hai mô hình, hàng đó bị bỏ đi thay vì đoán mò, nên mọi khẳng định ở đây đều được hậu thuẫn bằng một con số thực.

Với token đầu vào, Google: Gemini 3.1 Pro Preview tốn $2.00 mỗi 1 triệu so với $4.00 của google/gemini-pro-latest, còn ở đầu ra là $12.00 so với $18.00 mỗi 1 triệu. Hóa đơn thường được quyết định ở token đầu ra: một khối lượng công việc chat hoặc agent sinh ra các completion dài bị chi phối bởi mức giá đầu ra, nên một mô hình trông rẻ hơn ở đầu vào vẫn có thể là lựa chọn đắt hơn khi tính đầu-cuối. Hãy ước lượng tỷ lệ đầu vào-đầu ra thực tế của bạn trước khi chọn chỉ theo giá — một prompt nặng về truy hồi với câu trả lời ngắn và một prompt ngắn với phần sinh dài rơi vào hai đầu đối lập của bảng này. Một cách thực tế để ước lượng quy mô là lấy một mẫu prompt tiêu biểu, đếm số token đầu vào và đầu ra trung bình, rồi nhân mỗi giá trị với mức giá tương ứng của hai mô hình; mô hình có chi phí pha trộn (blended) thấp hơn trên tổ hợp thực tế của bạn chính là mốc cần vượt qua. Hãy nhớ cả hai mức giá ở đây đều là mức giá gốc của nhà cung cấp — OrcaRouter không cộng thêm gì — nên phép so sánh là cùng thước đo và khoản tiết kiệm bạn tính ra đúng là khoản tiết kiệm bạn giữ được.

Latency và throughput quyết định cảm giác của mô hình khi vận hành thực tế. Latency phản hồi trung vị (p50) là thời gian một yêu cầu điển hình chờ trước token đầu tiên; throughput (token mỗi giây) đặt ra tốc độ câu trả lời được truyền ra sau khi bắt đầu. Với chat tương tác và các vòng lặp agent, latency p50 thấp quan trọng nhất vì người dùng đang chờ token đầu tiên; với sinh theo lô và đầu ra dạng dài, throughput chi phối tổng thời gian vì câu trả lời dài. Các biểu đồ xu hướng 7 ngày ở trên cho thấy latency của mỗi mô hình ổn định hay trôi dạt, điều mà một con số nổi bật đơn lẻ che giấu — một mô hình có trung bình tuyệt vời nhưng phần đuôi nhiễu vẫn có thể trượt một SLA p95 nghiêm ngặt. Nếu sản phẩm của bạn có ngân sách latency, hãy đọc cả trung vị lẫn hình dạng của đường cong, và nhớ rằng latency đầu-cuối còn bao gồm bước nhảy mạng của bạn cùng bất kỳ truy hồi hay lời gọi công cụ nào bạn thực hiện quanh mô hình.

Điểm benchmark xấp xỉ năng lực nhưng không thay thế việc kiểm thử trên chính prompt của bạn. Các chỉ số tổng hợp hiển thị ở đây gộp nhiều đánh giá công khai, còn phân vị đánh dấu mỗi mô hình đứng ở đâu so với mọi mô hình tương đương trong danh mục — một tín hiệu chọn lọc hữu ích, không phải bảo đảm cho tác vụ của bạn. Một mô hình dẫn đầu ở chỉ số trí tuệ tổng quát vẫn có thể tụt lại trong lĩnh vực của bạn (lập trình, trích xuất, đa ngôn ngữ, suy luận ngữ cảnh dài), nên hãy dùng benchmark để thu hẹp phạm vi rồi cho cả hai mô hình chạy trên một lát cắt lưu lượng tiêu biểu. Hãy chú ý đến chỉ số cụ thể khớp với trường hợp sử dụng của bạn thay vì con số tổng: một sản phẩm nặng về lập trình nên coi trọng chỉ số lập trình, một trợ lý nghiên cứu thì chỉ số suy luận. Benchmark cũng lỗi thời dần khi các mô hình được cập nhật, nên hãy xem chúng như một giả thuyết khởi đầu mà bạn xác nhận bằng bộ đánh giá của riêng mình.

Nếu chi phí là ràng buộc quyết định, hãy bắt đầu với mô hình rẻ hơn trên tỷ lệ đầu vào-đầu ra thực tế của bạn và chỉ nâng lên khi chất lượng không đạt. Nếu ưu tiên là khả năng phản hồi — chat hướng người dùng, agent, mọi trường hợp có ai đó đang chờ — hãy coi trọng latency p50 và throughput hơn một khoảng chênh giá nhỏ. Nếu bạn đang đẩy các tác vụ suy luận, lập trình hoặc ngữ cảnh dài nặng nhất, hãy để bên thắng về benchmark và context window dẫn dắt và chấp nhận mức giá cao hơn ở nơi nó đáng đồng tiền. Vì cả hai mô hình đều nằm sau cùng một API, nước đi ít rủi ro là định tuyến một phần lưu lượng thực tới mỗi mô hình rồi so sánh chi phí, latency và chất lượng câu trả lời trên chính prompt của bạn trước khi cam kết. Một mẫu hình phổ biến là phân tầng (tier): gửi phần lớn các yêu cầu dễ, khối lượng cao tới mô hình rẻ hơn hoặc nhanh hơn và dành mô hình mạnh hơn cho những yêu cầu thực sự cần đến nó, cách này thu về phần lớn lợi ích chất lượng với một phần nhỏ chi phí. Dù chọn cái nào, hãy giữ cho việc chuyển đổi có thể đảo ngược — chỉ với một dòng thay tên mô hình, bạn có thể chuyển lưu lượng trở lại ngay khi các con số hoặc yêu cầu của bạn thay đổi.

Trong 7 ngày qua, google/gemini-pro-latest giữ độ trễ phản hồi trung vị thấp hơn.