Tóm tắt
- Các phản hồi dạng stream yêu cầu phân tích cú pháp SSE mạnh mẽ để xử lý các phần dữ liệu không đầy đủ và dữ liệu sử dụng token cuối cùng.
- Lỗi chế độ JSON thường bắt nguồn từ việc mô hình tạo ra văn bản thừa bên ngoài lược đồ JSON nghiêm ngặt.
- Cửa sổ ngữ cảnh 100k được chia sẻ giữa lời nhắc và phần hoàn thành, vì vậy các đầu ra dài làm giảm không gian đầu vào có sẵn.
- Ước tính chi phí phải tính đến mức giá cao hơn của token đầu ra so với token đầu vào.
Tại sao phản hồi streaming của bạn bị treo
Phản ứng streaming bị treo khi máy khách không đọc được chunk Server-Sent Events (SSE) cuối cùng chứa dữ liệu sử dụng token. API của chúng tôi truyền token khi chúng được tạo, nhưng kết nối chỉ đóng hoàn toàn sau khi chunk cuối cùng đến. Nếu mã máy khách của bạn ngắt kết nối sớm hoặc bỏ qua chunk cuối cùng, bạn sẽ mất số đếm token chính xác cần thiết để xác minh tính phí.
Đọc mọi đoạn dữ liệu cho đến khi luồng kết thúc. Đừng giả định rằng đoạn dữ liệu cuối cùng chỉ chứa token cuối cùng. Đoạn dữ liệu cuối cùng trong luồng SSE của chúng tôi bao gồm usage trường chứa tổng số token đầu vào và đầu ra. Nếu bạn loại bỏ dữ liệu này, bạn không thể theo dõi chính xác mức tiêu thụ tín dụng trả trước của mình.
Những Cạm Bẫy Thường Gặp
- Bỏ qua sự kiện SSE cuối cùng.
- Thời gian chờ được đặt quá thấp cho các phần hoàn thành dài.
- Không xử lý JSON một phần ở chế độ phát trực tiếp.
Luôn đọc hết luồng dữ liệu để đảm bảo máy chủ biết rằng máy khách đã nhận được phản hồi đầy đủ. Điều này ngăn ngừa rò rỉ tài nguyên phía máy chủ và đảm bảo bạn có dữ liệu cần thiết cho nhật ký của riêng mình.
Xử lý Lỗi Chế độ JSON trong Sản xuất
Các lỗi chế độ JSON xảy ra vì mô hình có thể tạo văn bản sau dấu ngoặc nhọn đóng, vi phạm các quy tắc phân tích cú pháp JSON nghiêm ngặt. Khi bạn đặt response_format để {"type": "json_object", mô hình cố gắng xuất ra JSON hợp lệ, nhưng nó thường thêm phần văn bản hội thoại như 'Đây là dữ liệu:' sau dấu ngoặc đóng. Trình phân tích cú pháp của bạn sau đó bị lỗi do văn bản thừa.
Loại bỏ văn bản thừa sau dấu ngoặc nhọn đóng hợp lệ cuối cùng. Đừng dựa vào mô hình để dừng chính xác ở cuối cấu trúc JSON. Bạn phải triển khai một bước xử lý sau để tìm dấu '}' hoặc ']' cuối cùng và loại bỏ mọi thứ sau đó. Điều này rất quan trọng khi phân tích cú pháp các mảng hoặc đối tượng lồng nhau.
Thực tiễn tốt nhất
- Sử dụng biểu thức chính quy (regex) để trích xuất khối JSON hợp lệ cuối cùng.
- Xác nhận chuỗi đã trích xuất bằng trình phân tích cú pháp JSON.
- Thử lại với nhiệt độ thấp hơn nếu đầu ra hỗn loạn.
Cách tiếp cận này đảm bảo quy trình sản xuất của bạn vẫn ổn định ngay cả khi mô hình quyết định nói nhiều. Các mô hình không kiểm duyệt ít bị ràng buộc hơn, vì vậy chúng có thể cảm thấy 'sáng tạo' hơn với cách trình bày của chúng.
Hiểu giới hạn cửa sổ ngữ cảnh
Giới hạn cửa sổ ngữ cảnh là 100.000 token cho lời nhắc và phần hoàn thành kết hợp. Điều này có nghĩa là nếu đầu vào của bạn là 50.000 token, bạn chỉ có thể tạo tối đa 50.000 token trước khi chạm giới hạn. Giới hạn không chỉ dành cho đầu vào; đó là ngân sách chia sẻ cho toàn bộ yêu cầu.
Tính không gian đầu ra khả dụng của bạn bằng cách trừ số lượng token đầu vào khỏi 100.000. Nếu bạn gửi một prompt hệ thống lớn hoặc một lịch sử tin nhắn dài, không gian đầu ra khả dụng của bạn sẽ thu hẹp tương ứng. Điều này rất quan trọng đối với các ứng dụng duy trì lịch sử hội thoại dài.
Ví dụ về tính toán
- Tổng cửa sổ: 100,000 token.
- Số token đầu vào: 20.000 token.
- Đầu ra tối đa: 80.000 token.
Nếu bạn vượt quá giới hạn này, API sẽ trả về lỗi. Hãy theo dõi chặt chẽ mức độ sử dụng token của bạn để tránh việc cắt ngắn không mong muốn trong phản hồi của mô hình. Mô hình không tự động cắt ngắn; nó chỉ từ chối yêu cầu nếu tổng vượt quá cửa sổ ngữ cảnh.
Đếm Token và ước tính chi phí
Ước tính chi phí phải tính đến sự chênh lệch giá giữa token đầu vào và token đầu ra. Token đầu vào có giá $0.15 cho mỗi 1M token, trong khi token đầu ra có giá $0.50 cho mỗi 1M token. Token đầu ra đắt hơn đáng kể, vì vậy việc tạo ra các phản hồi dài sẽ làm tăng chi phí nhanh hơn so với việc gửi các lệnh gọi dài.
Ước tính chi phí của bạn bằng cách nhân số lượng token dự kiến với giá tương ứng. Ví dụ: 10.000 token đầu vào và 5.000 token đầu ra sẽ tốn: (10.000/1.000.000 * $0,15) + (5.000/1.000.000 * $0,50). Điều này bằng $0,0015 + $0,0025 = $0,004 cho mỗi yêu cầu.
Bảng giá
| Loại Token | Giá mỗi 1M Token |
|---|---|
| Đầu vào | $0.15 |
| Đầu ra | $0.50 |
Theo dõi mức sử dụng thông qua chunk SSE cuối cùng hoặc phản hồi API. Điều này đảm bảo bạn có thể lập ngân sách chính xác cho các ứng dụng có khối lượng lớn. Tín dụng trả trước không bao giờ hết hạn, vì vậy bạn có thể lên kế hoạch chi tiêu của mình theo thời gian mà không có phí hàng tháng.
Giải thích giới hạn tốc độ 300 RPM
Giới hạn tốc độ giới hạn yêu cầu của bạn ở mức 300 mỗi phút cho mỗi khóa API. Giới hạn này áp dụng cho tất cả các yêu cầu, bất kể kích thước tải trọng hoặc số lượng token. Nếu bạn vượt quá giới hạn này, API sẽ trả về lỗi 429. Bạn phải triển khai cơ chế backoff theo cấp số nhân để xử lý các lỗi này một cách duyên dáng.
Theo dõi tốc độ yêu cầu và điều chỉnh độ đồng thời của bạn cho phù hợp. Nếu bạn đang sử dụng nhiều luồng hoặc quy trình, hãy đảm bảo chúng chia sẻ cùng một khóa API và cùng nhau duy trì dưới giới hạn 300 RPM. Vượt quá giới hạn này sẽ dẫn đến các lỗi tạm thời cho đến khi tốc độ được đặt lại.
Xử lý Lỗi 429
- Triển khai cơ chế tăng dần thời gian chờ (exponential backoff).
- Ghi lại các yêu cầu thất bại để phân tích.
- Giảm độ đồng thời nếu các giới hạn xảy ra thường xuyên.
API của chúng tôi được thiết kế cho các tác vụ khối lượng lớn, nhưng giới hạn tốc độ đảm bảo sử dụng công bằng cho tất cả khách hàng. Nếu bạn cần giới hạn cao hơn, bạn có thể tạo khóa API mới, nhưng lưu ý rằng mỗi tài khoản chỉ được giới hạn một khóa hoạt động tại một thời điểm.
Khắc phục Lỗi Gọi Hàm
Lỗi gọi hàm xảy ra khi định nghĩa công cụ của mô hình không khớp với lược đồ dự kiến hoặc khi mô hình không xuất ra JSON hợp lệ cho các đối số công cụ. Đảm bảo các định nghĩa công cụ của bạn chính xác và bao gồm tất cả các tham số bắt buộc. Các lược đồ mơ hồ dẫn đến các lệnh gọi công cụ bị lỗi.
Xác nhận các đối số công cụ trước khi thực thi hàm. Mô hình có thể tạo ra các đối số thiếu các trường bắt buộc hoặc chứa các kiểu không chính xác. Mã máy khách của bạn nên xử lý các lỗi này bằng cách thử lại với một gợi ý rõ ràng hơn hoặc điều chỉnh định nghĩa công cụ.
Các Bước Gỡ lỗi
- Kiểm tra cú pháp định nghĩa công cụ.
- Xác thực các loại và giá trị đối số.
- Xem lại kết quả của mô hình xem có thiếu trường nào không.
Gọi hàm là một tính năng mạnh mẽ, nhưng nó yêu cầu thiết kế lược đồ cẩn thận. Các mô hình không kiểm duyệt có thể kém nhất quán hơn với các định nghĩa công cụ so với các đối tác có kiểm duyệt của chúng, vì vậy việc xác thực nghiêm ngặt là rất cần thiết.
Tại sao 'không kiểm duyệt' không hoàn toàn là không giới hạn
Nhãn 'không kiểm duyệt' có nghĩa là mô hình không từ chối các chủ đề người trưởng thành, hư cấu hoặc gây tranh cãi hợp pháp, nhưng nó vẫn có giới hạn cứng về nội dung tình dục liên quan đến trẻ vị thành niên. Đây là giới hạn nội dung cứng duy nhất luôn được áp dụng. Các yêu cầu chứa nội dung như vậy sẽ bị từ chối, ngay cả khi phần còn lại của lời nhắc hoàn toàn hợp lệ.
Các từ chối khác vẫn có thể xảy ra do lỗi kỹ thuật hoặc giới hạn tốc độ. Mô hình không phải là phép màu; nó vẫn có thể không tạo được phản hồi nếu đầu vào quá phức tạp hoặc cửa sổ ngữ cảnh bị vượt quá. Hãy hiểu rằng 'không kiểm duyệt' đề cập đến chính sách nội dung, không phải độ tin cậy kỹ thuật.
Giới hạn nội dung
- Không có nội dung tình dục liên quan đến trẻ vị thành niên.
- Nội dung người lớn hợp pháp được cho phép.
- Lỗi kỹ thuật vẫn có thể gây ra từ chối.
Sự khác biệt này rất quan trọng đối với các ứng dụng cần xử lý nhiều chủ đề khác nhau. Biết giới hạn cụ thể giúp bạn thiết kế logic lọc của mình đúng cách.
Gỡ lỗi Lỗi 400 và 429
Lỗi 400 cho thấy vấn đề với chính yêu cầu, chẳng hạn như JSON không hợp lệ, thiếu trường bắt buộc hoặc vượt quá giới hạn thân yêu cầu 8 MB. Lỗi 429 cho thấy bạn đã vượt quá giới hạn tốc độ 300 yêu cầu mỗi phút. Phân biệt giữa các lỗi này giúp bạn khắc phục đúng vấn đề một cách nhanh chóng.
Đối với lỗi 400, hãy kiểm tra tải trọng yêu cầu và lược đồ của bạn. Đối với lỗi 429, hãy triển khai cơ chế backoff và giảm độ đồng thời. Nếu bạn nhận được lỗi 400 với thông báo về kích thước thân yêu cầu, hãy đảm bảo bạn không gửi quá nhiều dữ liệu trong một yêu cầu. Giới hạn 8 MB là nghiêm ngặt.
Mã lỗi
| Mã lỗi | Ý nghĩa |
|---|---|
| 400 | Yêu cầu không hợp lệ |
| 429 | Vượt quá giới hạn tốc độ |
Việc ghi lại các lỗi này cùng với ngữ cảnh của chúng (tải trọng, dấu thời gian) giúp việc gỡ lỗi trở nên dễ dàng hơn. Sử dụng dữ liệu này để tối ưu hóa tích hợp của bạn và tránh các lỗi lặp lại.
Các bước tiếp theo cho Tối ưu hóa Heretic LLM
Tối ưu hóa bắt đầu bằng cách theo dõi việc sử dụng token và tỷ lệ lỗi. Sử dụng dữ liệu token từ chunk SSE cuối cùng để theo dõi mức tiêu thụ thực tế của bạn. So sánh điều này với chi phí ước tính của bạn để đảm bảo độ chính xác. Điều chỉnh chiến lược đồng thời và giới hạn tốc độ dựa trên các mẫu sử dụng quan sát được của bạn.
Hãy xem xét việc sử dụng nhiệt độ thấp hơn để có đầu ra JSON hoặc gọi hàm nhất quán hơn. Nếu bạn cần các phản hồi sáng tạo hơn, hãy tăng nhiệt độ nhưng hãy chuẩn bị cho nhiều lỗi phân tích cú pháp hơn. Hãy thử nghiệm với các tham số khác nhau để tìm sự cân bằng phù hợp cho trường hợp sử dụng của bạn.
Mẹo tối ưu hóa
- Theo dõi sát việc sử dụng token.
- Điều chỉnh nhiệt độ cho tính nhất quán so với sáng tạo.
- Triển khai xử lý lỗi mạnh mẽ.
Bắt đầu với bản dùng thử miễn phí để kiểm tra tích hợp của bạn. Đây là một cách ít rủi ro để xác minh rằng mã khách của bạn xử lý phát trực tiếp, chế độ JSON và giới hạn tốc độ đúng cách trước khi cam kết tín dụng nạp trước.
