摘要
- 串流回應需要強大的 SSE 解析，以處理不完整的區塊和最終的權杖使用資料。
- 當模型生成超出嚴格 JSON schema 的尾隨文字時，JSON 模式會失效。
- 100k 上下文視窗在提示詞與完成之間共享，因此長輸出會減少可用的輸入空間。
- 成本估算必須考慮輸出 token 比輸入 token 更高的單價。
為何您的串流回應掛起
當客戶端未能讀取包含 Token 使用量資料的最後一個伺服器發送事件（SSE）片段時，串流回應會掛起。我們的 API 隨生成串流傳輸 Token，但連線僅在最後一個片段到達後才完全關閉。如果您的客戶端程式碼提前斷開連線或忽略最後一個片段，您將失去用於計費驗證的精確 Token 計數。
讀取每個區塊直到串流結束。不要假設最後一個區塊只包含最終 token。我們 SSE 串流中的最後一個區塊包含 usage 包含輸入與輸出 token 總計的欄位。若遺失此資料，將無法準確追蹤預付信用的消耗情況。
常見陷阱
- 忽略最後一個 SSE 事件。
- 超時時間設定過低，無法處理長時間的補全。
- 串流模式下未處理部分 JSON。
始終消耗整個串流，以確保伺服器知道客戶端已接收完整回應。這可防止我們端的資源洩漏，並確保您擁有自己的日誌所需的資料。
處理生產環境中的 JSON 模式錯誤
JSON 模式錯誤發生是因為模型可能在閉合大括號後生成文字，違反了嚴格的 JSON 解析規則。當您設定 response_format 以 {"type": "json_object", 模型會嘗試輸出有效的 JSON，但通常會在閉合括號後加上如「Here is the data:」之類的對話式填充文字。您的解析器會因額外文字而崩潰。
刪除最後一個有效閉合大括號後的尾隨文本。不要依賴模型在 JSON 結構的末尾精確停止。您必須實施後處理步驟來找到最後一個 '}' 或 ']' 並丟棄其後的內容。在解析數組或嵌套對象時這至關重要。
最佳實踐
- 使用正則表達式提取最後一個有效的 JSON 區塊。
- 使用 JSON 解析器驗證擷取的字串。
- 如果輸出混亂，請以較低的 temperature 重試。
此方法確保即使模型決定話多，您的生產管線仍保持穩定。無審查模型限制較少，因此它們在格式上可能感覺更具「創意」。
理解上下文視窗限制
上下文窗口限制為提示詞與補全內容合計 100,000 個 token。這意味著如果您的輸入為 50,000 個 token，您最多只能生成 50,000 個 token 就會達到限制。限制不僅限於輸入；它是整個請求的共享預算。
透過從 100,000 中減去輸入 token 數量來計算您的可用輸出空間。如果您發送大型系統提示或長歷史消息，您的可用輸出空間會相應減少。這對於維護長對話歷史的應用程式至關重要。
計算範例
- 總視窗：100,000 個詞元。
- 輸入 Tokens：20,000 個 token。
- 最大輸出：80,000 個 Token。
如果您超過此限制，API 將返回錯誤。請密切監控您的 token 使用量，以避免模型回應被意外截斷。模型不會自動截斷；如果總量超過視窗，它僅會拒絕請求。
Token 計數與成本估算
成本估算必須考慮輸入與輸出 token 的價格差異。輸入 token 每 1M 個價格為 $0.15，而輸出 token 每 1M 個價格為 $0.50。輸出 token 顯著更貴，因此生成長回應會比發送長提示詞更快推高您的成本。
透過將預期的 token 數量乘以相應的價格來估算您的成本。例如，10,000 個輸入 token 和 5,000 個輸出 token 的成本為：(10,000/1,000,000 * $0.15) + (5,000/1,000,000 * $0.50)。這等於每次請求 $0.0015 + $0.0025 = $0.004。
定價表
| Token 類型 | 每 1M Tokens 的價格 |
|---|---|
| 輸入 | $0.15 |
| 輸出 | $0.50 |
透過最終的 SSE 區塊或 API 回應追蹤您的使用情況。這確保您可以為高流量應用程式準確預算。預付信用額度永不過期，因此您可以隨時間規劃支出，無需每月費用。
速率限制：300 RPM 說明
速率限制將您的請求上限設為每分鐘每 API 金鑰 300 次。此限制適用於所有請求，無論有效載荷大小或 token 數量為何。若超過此限制，API 將返回 429 錯誤。您必須實作指數退避（exponential backoff）以優雅地處理這些錯誤。
監控您的請求速率並相應調整並行數量。如果您使用多個執行緒或程序，請確保它們共用相同的 API 金鑰，並且總請求量保持在每分鐘 300 次以下。超過此限制將導致暫時性錯誤，直到速率視窗重置。
處理 429 錯誤
- 實作指數退避。
- 記錄失敗的請求以供分析。
- 如果頻繁遇到限制，請降低併發數。
我們的 API 專為高用量使用設計，但速率限制確保了所有客戶端的公平使用。如果您需要更高的限制，可以產生新的 API 金鑰，但請注意，每個帳戶同時僅限一個有效金鑰。
排除函數呼叫失敗
當模型的工具定義與預期結構描述不符，或模型未能為工具參數輸出有效的 JSON 時，就會發生函式呼叫失敗。確保您的工具定義精確並包含所有必要參數。含糊的結構描述會導致格式錯誤的工具呼叫。
在執行函式之前驗證工具參數。模型可能會產生缺少必要欄位或包含錯誤類型資料的參數。您的客戶端程式碼應透過使用更清晰的提示或調整工具定義來重試，以處理這些錯誤。
除錯步驟
- 檢查工具定義語法。
- 驗證參數類型與值。
- 審查模型輸出是否缺少欄位。
函式呼叫是一個強大的功能，但需要仔細設計結構描述。與經過過濾的模型相比，非審查模型在工具定義方面可能較不一致，因此嚴格的驗證至關重要。
為什麼「uncensored」並非完全無限制
「無審查」標籤意味著模型不會拒絕合法的成人、虛構或爭議性主題，但它對涉及未成年人的性內容仍有硬性限制。這是唯一始終適用的硬性內容限制。包含此類內容的請求將被拒絕，即使提示的其餘部分完全有效。
其他拒絕情況可能仍會發生，原因可能是技術錯誤或速率限制。該模型並非萬能；如果輸入過於複雜或超出上下文視窗，它仍可能無法生成回應。請理解「uncensored」指的是內容政策，而非技術可靠性。
內容限制
- 不允許涉及未成年人的性內容。
- 允許合法成人內容。
- 技術錯誤仍可能導致拒絕。
這種區別對於需要處理廣泛主題的應用程式很重要。了解具體限制有助於你正確設計過濾邏輯。
除錯 400 與 429 錯誤
400 錯誤表示請求本身有問題，例如無效的 JSON、缺少必要欄位或超過 8 MB 的有效負載限制。429 錯誤表示您已超過每分鐘 300 次請求的速率限制。區分這些錯誤有助於您快速修正正確的問題。
對於 400 錯誤，請檢查請求載荷與結構定義。對於 429 錯誤，請實作退避機制並降低併發量。如果收到關於請求主體大小的 400 錯誤訊息，請確保未在單一請求中發送過多資料。8 MB 的限制是嚴格的。
錯誤代碼
| 錯誤代碼 | 含義 |
|---|---|
| 400 | 錯誤請求 |
| 429 | 超過速率限制 |
記錄這些錯誤及其上下文（負載、時間戳記）可使除錯變得更容易。使用這些數據來優化您的整合並避免重複失敗。
異端 LLM 優化下一步
最佳化始於監控您的令牌使用量與錯誤率。使用最終 SSE 區塊中的令牌數據來追蹤您的實際消耗量。將此數據與您的預估成本進行比較，以確保準確性。根據您觀察到的使用模式調整併發性與速率限制策略。
考慮使用較低的溫度值以獲得更一致的 JSON 輸出或函式呼叫。如果您需要更具創意的回應，可以提高溫度，但請準備好應對更多的解析錯誤。嘗試不同的參數，以找到適合您使用場景的最佳平衡點。
最佳化建議
- 仔細監控 token 用量。
- 調整溫度以取得一致性與創造力的平衡。
- 實作強大的錯誤處理。
以免費試用開始測試您的整合。這是低風險的方式，可在承諾預付額度之前，驗證您的客戶端程式碼是否能正確處理串流、JSON 模式和速率限制。
