Lỗi 500: cần làm gì khi gọi gemini-3.1-flash-lite-preview thất bại

Mã 500 nghĩa là máy chủ gặp lỗi nội bộ ngoài dự kiến khi xử lý yêu cầu. Thường không phải vấn đề định dạng yêu cầu mà là sự cố tạm thời ở phía máy chủ hoặc mô hình thượng nguồn.

500 Internal Server Error là lỗi nội bộ không mong muốn phía server. Đa số lỗi 500 là sự cố node tạm thời và sẽ thành công khi thử lại với exponential backoff. Nếu vẫn tiếp diễn, có khả năng một tổ hợp tham số cụ thể đang chạm vào trường hợp ngoại lệ chưa được xử lý.

gemini-3.1-flash-lite-preview được Google cung cấp. Mọi nội dung trên trang này — nguyên nhân, cách xử lý và dữ liệu đo được — đều tổng hợp từ hoạt động thực tế của mô hình này tại lớp gateway.

Tại gateway này, nguyên nhân thường gặp nhất là: Sự cố tạm thời ở dịch vụ mô hình thượng nguồn. Hành động đầu tiên nên làm là: Thử lại sau một lúc (hầu hết lỗi 500 là tạm thời).

Nguyên nhân thường gặp

  • Sự cố tạm thời ở dịch vụ mô hình thượng nguồn
  • Yêu cầu rơi vào nút đang khởi động lại
  • Phần thân yêu cầu gây ra trường hợp biên chưa được xử lý
  • Tải tăng vọt tức thời

Cách khắc phục

  • Thử lại sau một lúc (hầu hết lỗi 500 là tạm thời)
  • Thử một mô hình khác cùng nhà cung cấp để xem có phải lỗi riêng mô hình
  • Đơn giản hóa phần thân yêu cầu (bỏ tham số ít dùng) rồi thử lại
  • Nếu vẫn tiếp diễn, liên hệ chúng tôi kèm thời điểm yêu cầu

Ví dụ thử lại với backoff luỹ thừa

Đoạn mã dưới sẽ thử lại khi gemini-3.1-flash-lite-preview trả về 500, tối đa 5 lần, thời gian chờ tăng dần kèm jitter ngẫu nhiên để các request đồng thời không retry cùng lúc. Hãy đọc base URL và API key từ biến môi trường, đừng hardcode vào code.

import os, time, random
import requests

BASE  = os.getenv("OPENAI_BASE_URL")   # e.g. https://<your-gateway>/v1
KEY   = os.getenv("OPENAI_API_KEY")
MODEL = 'gemini-3.1-flash-lite-preview'


def chat(messages, retries=5):
    """Retry with exponential backoff + jitter."""
    for i in range(retries):
        try:
            r = requests.post(
                BASE + "/chat/completions",
                headers={"Authorization": "Bearer " + KEY},
                json={"model": MODEL, "messages": messages, "stream": True},
                timeout=60,
            )
            if r.status_code == 429 or r.status_code >= 500:
                time.sleep(min(2 ** i + random.uniform(0, 1), 30))
                continue
            r.raise_for_status()
            return r.json()
        except requests.exceptions.Timeout:
            time.sleep(min(2 ** i + random.uniform(0, 1), 30))
    raise RuntimeError("gave up after " + str(retries) + " retries")


print(chat([{"role": "user", "content": "hello"}]))

Dữ liệu chính của mô hình này

TPS437.37
Độ trễ trung bình1194 ms
Tỷ lệ thành công100%
Điểm cuối APIhttps://api.airai.cc/v1
Tương thích OpenAIOpenAI-compatible
Nhà cung cấpGoogle
Ngữ cảnh1M
Khả năngReasoning, Tools, Files, Vision, Audio
Định dạng APIopenai, openai-response, openai-response-compact, anthropic, gemini, openai-alpha-search
Công thức tính phíp * 0.25 + cr * 0.025 + ai * 0.5 + c * 1.5

Câu hỏi thường gặp

500 trên gemini-3.1-flash-lite-preview có phụ thuộc khu vực hay node không?

Nếu chỉ xảy ra ở môi trường production, thường là khác biệt môi trường chứ không phải mô hình. Tỷ lệ thành công 100% được tính trung bình theo node, nên một node yếu sẽ kéo số tổng thể xuống. Mô hình này do Google cung cấp, vì vậy trạng thái upstream theo thông báo của nhà cung cấp. Ghi lại request ID mỗi lần thất bại — hữu dụng hơn status code. Tái hiện trước trong môi trường thử nghiệm với cùng request body.

500 có liên quan cách tính phí của gemini-3.1-flash-lite-preview không?

Không bị tính phí, chỉ output thực sự được tạo mới tính vào sử dụng. Chỉ phần đầu ra đã tạo mới bị tính phí, phần thất bại thì không. Cách tính phí theo p * 0.25 + cr * 0.025 + ai * 0.5 + c * 1.5, không có output thì không tính phí. Kiểm tra số dư và giới hạn tốc độ trong console trước, rồi mới xem code.

Chuyển sang model tương đương của hãng khác có giải quyết 500 không?

Nên chuẩn bị sẵn một model dự phòng. Có phương án dự phòng ở cấp kiến trúc thì đáng tin hơn là vá từng lỗi một. Model này của Google có nhiều node upstream để gateway chuyển đổi. Chuẩn bị sẵn một mô hình dự phòng nhẹ hơn để luồng chính không bị gián đoạn. Đưa tên mô hình vào config, đổi upstream sẽ không cần sửa code.

Mã nào đáng để thử lại, mã nào thử lại cũng vô ích?

Thường không cần sửa code nghiệp vụ, chỉ cần điều chỉnh nhịp gọi. Thử lại là bước đầu tiên hiệu quả nhất. Với cách tính phí p * 0.25 + cr * 0.025 + ai * 0.5 + c * 1.5, các request thất bại không được tính vào mức sử dụng. Dùng exponential backoff cho lỗi có thể thử lại, và trả lỗi ngay cho các lỗi còn lại.

Lỗi khác của mô hình này

Các mô hình khác gặp cùng lỗi

Dữ liệu cập nhật: 2026-10-10 18:35

Hỗ trợ kỹ thuậtHỗ trợ trực tuyến
Về đầu trang