Đã đăng vào khoảng 2 giờ trước 4 phút đọc

Gọi LLM Trung Quốc từ bên ngoài Trung Quốc: checklist về độ trễ và độ ổn định

Nếu server của bạn ở ngoài Trung Quốc còn model đặt ở trong Trung Quốc, chắc bạn đã gặp cảnh này: token đầu tiên lâu mới tới, vài request treo không rõ lý do, buổi tối thì tệ hơn. Thường thì model không có vấn đề gì. Vấn đề nằm ở tuyến xuyên giới quá dài. Đường truyền quốc tế có hạn và hay nghẽn vào giờ cao điểm. Mất gói thì TCP phải truyền lại, còn mỗi lần bắt tay TLS mới lại tốn thêm vài lượt khứ hồi. Dưới đây là những gì đã giúp được tôi. Không phụ thuộc nhà cung cấp nào, dùng được với mọi endpoint tương thích OpenAI.

1. Đo từ môi trường production, đừng đo từ laptop. Ghi lại TTFB, thời gian tới token đầu tiên (TTFT) và tổng thời gian qua nhiều lần chạy, rồi so p50 với p90. Khoảng cách giữa hai số này cho biết tuyến ổn định tới đâu. Muốn xem chi phí của một kết nối mới thì curl là đủ:

curl -sS -N -o /dev/null -H "Authorization: Bearer $LLM_API_KEY" -H "Content-Type: application/json" \
  -d '{"model":"MODEL_ID","stream":true,"max_tokens":32,"messages":[{"role":"user","content":"hi"}]}' \
  -w 'connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' \
  "$LLM_BASE_URL/chat/completions"

2. Dùng streaming. Model không sinh nhanh hơn, nhưng người dùng thấy chữ ngay từ lúc TTFT. Hãy đọc stream tới EOF thay vì break khi gặp [DONE]. Nếu không, thư viện HTTP có thể đóng kết nối thay vì dùng lại.

3. Tách riêng các timeout. Connect để ngắn. Với streaming, read là khoảng im lặng dài nhất chấp nhận được giữa hai chunk. Thêm một hạn chót tổng cho ma��i lần gọi. Giá trị mặc định của SDK có khi rất "kiên nhẫn": README của OpenAI Python SDK ghi là 10 phút.

4. Chỉ retry với 429, 5xx, timeout và lỗi kết nối, dùng exponential backoff kèm full jitter và tuân theo Retry-After. Đừng bao giờ âm thầm retry sau khi đã trả token cho người dùng, và đừng chồng retry của mình lên retry của SDK.

def backoff(attempt, base=0.5, cap=8.0):
    return random.uniform(0, min(cap, base * 2 ** attempt))

5. Mỗi process chỉ dùng một client. Nhờ keep-alive, từ request thứ hai trở đi không phải bắt tay lại. Trong bái test với mock server của tôi, bốn lần gọi qua một client dùng chung chỉ tốn một kết nối TCP. Tạo client mới cho ma��i lần gọi thì lần nào cũng mở kết nối mới.

6. Chọn tuyến có chủ đích. Đi thẳng qua internet công cộng là đơn giản nhất. Cách còn lại là dùng một gateway ở gần, gateway đó chuyển traffic về Trung Quốc qua đường truyền do nó quản lý. Bắt tay nhanh hơn và chặng dài ổn định hơn, nhưng thêm một hop và thêm một bên thứ ba (nhớ kiểm tra chính sách lưu log). Đo cả hai từ region của bạn trong vài ngày và giữ tuyến kia làm dự phòng.

7. Fallback + circuit breaker + health check chạy nền (GET /models). Chỉ chuyển endpoint khi gặp lỗi đáng retry, không chuyển với 400/422.

8. Gửi ít đi. Cắt bớt lịch sử hội thoại và đặt max_tokens.

9. Tự ghi p50/p90/p99 theo từng endpoint, theo từng giờ.

Toàn bộ script (đo TTFT, client chịu lỗi, mock server, test): https://apigotonotes.wordpress.com/2026/10/20/calling-chinese-llms-from-outside-china-measure-first-then-fix-latency-and-stability/. Kết quả phụ thuộc vào mạng của bạn, nên hãy tự đo.

Công khai: tôi làm việc trong team APIGOTO; chúng tôi độc lập với OpenAI, Anthropic và Google. Thứ chúng tôi làm là một gateway tương thích OpenAI thuộc loại thứ hai ở trên, trả theo mức dùng. Các server gateway ở nước ngoài nối với data center tại Trung Quốc qua mạng doanh nghiệp chuyên dụng. Log request chỉ được lưu khi bạn tự bật logging trong phần cài đặt. Muốn so với tuyến đang dùng, chỉ cần thêm https://api.china-aiapi.com/v1 làm base URL trong script.

Mục lục