Lỗi timeout: cần làm gì khi gọi gpt-4.1 thất bại

Hết thời gian chờ nghĩa là client bỏ cuộc trước khi phản hồi tới. Yêu cầu streaming tới LLM hay gặp nhất, vì mô hình phải suy nghĩ trước token đầu tiên và giai đoạn đó không tạo ra byte nào.

timeout không phải là mã trạng thái HTTP mà là giới hạn chờ phía client. Request thường đã đến gateway và được chuyển tiếp lên upstream, nhưng model không tạo ra kết quả trong thời gian bạn đặt. Ba nguyên nhân phổ biến nhất là context dài, output dài và gọi không dùng streaming.

gpt-4.1 được OpenAI 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à: Đặt thời gian chờ phía client quá ngắn. Hành động đầu tiên nên làm là: Tăng thời gian chờ phía client lên 300 giây trở lên.

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

  • Đặt thời gian chờ phía client quá ngắn
  • Prompt hoặc ngữ cảnh dài làm độ trễ token đầu tăng
  • Mô hình đang xử lý tác vụ suy luận dài
  • Mạng chập chờn

Cách khắc phục

  • Tăng thời gian chờ phía client lên 300 giây trở lên
  • Bật streaming để không phải chờ toàn bộ câu trả lời
  • Rút ngắn ngữ cảnh hoặc dùng mô hình nhanh hơn
  • Giảm max_tokens

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

Đoạn mã dưới sẽ thử lại khi gpt-4.1 trả về timeout, 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 = 'gpt-4.1'


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

Điểm cuối APIhttps://api.airai.cc/v1
Tương thích OpenAIOpenAI-compatible
Nhà cung cấpOpenAI
Ngữ cảnh1M
Khả năngTools, Files, Vision
Định dạng APIopenai, openai-response, openai-response-compact, anthropic, gemini, openai-alpha-search
Công thức tính phíp * 2 + cr * 0.5 + c * 8

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

Khi báo lỗi nên cung cấp thông tin gì cho hỗ trợ?

Gom lỗi theo thời gian và theo node trước; quy luật thường rất rõ. 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. Mô hình này do OpenAI 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.

Khi gpt-4.1 trả timeout, gateway hay upstream có khả năng là nguyên nhân hơn?

Đa số là lỗi tạm thời và tự phục hồi. Thẻ năng lực của model này là Tools, Files, Vision. Xác định trước là cấp tài khoản hay cấp mô hình; hai trường hợp xử lý hoàn toàn khác nhau.

Nên dùng exponential backoff hay khoảng cố định?

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 * 2 + cr * 0.5 + c * 8, các request thất bại không được tính vào mức sử dụng. Đặt giới hạn thử lại ở 3–5 lần và thêm jitter. 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.

Chuyển sang streaming có giảm timeout không?

Cần đổi tham số request, chỉ thử lại sẽ không giúp được. Đây là lỗi cấu hình phía client, phía server không cần đổi. Nhãn năng lực là Tools, Files, Vision, và giới hạn tham số bắt nguồn từ tập năng lực đó. Cửa sổ ngữ cảnh 1M quyết định đầu vào tối đa mỗi request; vượt quá sẽ bị từ chối ngay. Với lỗi tham số, hãy thất bại nhanh thay vì lãng phí lần thử 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 08:15

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