Tổng quan
Streaming chuyển đầu ra theo từng phần. Dùng Responses streaming khi mô hình công bố hợp đồng Responses gốc và có tuyến upstream cùng giao thức; nếu không, dùng Chat Completions hoặc giao thức gốc mà mô hình công bố.Khuyến nghị: Responses Streaming
Ranh giới Streaming Responses và Gemini
Với Responses SSE, TokenLab giữ nguyên tên, thứ tự và trường sự kiện upstream, đồng thời đọc usage và trạng thái kết thúc ngoài luồng mà không đổi wire. Sau sự kiện đầu tiên đã gửi, không thử channel hoặc credential khác. Responses WebSocket chỉ nhận sự kiện chính thứcresponse.create. Stream là ngầm định; background và response.cancel không được cung cấp trên transport này, còn background chỉ chạy qua HTTP. Mỗi kết nối xử lý tuần tự, không multiplexing và giới hạn 60 phút.
Gemini SSE giữ nguyên chunk gốc. Sự kiện chỉ có metadata, chunk trung gian không có finishReason và EOF tự nhiên đều hợp lệ; TokenLab không thêm dấu Chat [DONE].
Phát trực tuyến Chat Completions
Nếu framework của bạn vẫn yêu cầu các chunk SSE từ/v1/chat/completions, cách này cũng hoạt động:
Điều kiện kết thúc stream
Các điều kiện hoàn tất điển hình:response.completedcho các stream của Responses APIfinish_reason: "stop"cho các stream Chat Completionsfinish_reason: "length"khi chạm đến giới hạn token- các sự kiện gọi tool/function khi model muốn sử dụng tools
Mẫu cho ứng dụng web
Thực tiễn tốt nhất
Ưu tiên Responses streaming cho các bản dựng mới
Ưu tiên Responses streaming cho các bản dựng mới
Sử dụng
/v1/responses nếu SDK hoặc ứng dụng của bạn đã hỗ trợ. Giữ lại streaming /v1/chat/completions cho các tích hợp cần tương thích.Flush đầu ra tăng dần
Flush đầu ra tăng dần
Nối các chunk delta vào UI hoặc terminal ngay khi chúng đến thay vì chờ toàn bộ phản hồi hoàn tất.
Xử lý ngắt kết nối và thử lại
Xử lý ngắt kết nối và thử lại
Xem việc rớt mạng và ngắt kết nối từ upstream là các chế độ lỗi bình thường, và kết nối lại một cách cẩn thận cho các phiên chạy dài.