聊天補全
相容於 OpenAI 的聊天補全 API，支援串流、圖片、工具呼叫與推理控制。
POST /v1/chat/completions
curl https://api.unquant.io/v1/chat/completions \
-H "Authorization: Bearer $UNQUANT_API_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"glm-5.3-flash",
"messages":[{"role":"user","content":"Hello!"}]}'請求欄位
model字串必填glm-5.3-flash 或 qwen-3.8-flash-next。
messages陣列必填角色可為 system、user、assistant 和 tool。內容可以是字串，或由 text 和 image_url 區塊組成的陣列。
stream布林值透過伺服器傳送事件，以串流方式傳回回覆。
stream_options物件{"include_usage": true} 會在最後新增一個包含 token 計數的區塊。
max_tokens整數回覆長度上限。
max_completion_tokens整數與 max_tokens 相同。
temperature數值取樣的隨機程度。
top_p數值核心取樣。
top_k整數從機率最高的 k 個 token 中取樣。
min_p數值token 的最低相對機率。
seed整數用於重現取樣結果的隨機種子。
stop字串或陣列觸發停止生成的序列。
frequency_penalty數值依 token 出現的次數施加懲罰。
presence_penalty數值對任何曾出現過的 token 施加懲罰。
repetition_penalty數值以乘法方式施加重複懲罰。
tools陣列模型可呼叫的函式，採用 OpenAI 格式。
tool_choice字串或物件可設為 auto、none、required，或依名稱指定函式。
parallel_tool_calls布林值允許在同一回合中呼叫多個工具。
response_format物件JSON 輸出格式。
logprobs布林值傳回 token 的對數機率。
top_logprobs整數每個 token 位置要傳回的候選 token 數量。
n整數必須為 1：每個請求只產生一個補全結果。
reasoning_effort字串兩款模型皆支援 none、low 或 high；GLM-5.3-Flash 另支援 max。
chat_template_kwargs物件範本功能開關，例如 {"enable_thinking": false}。
其他欄位會被忽略。
回應
response.choices[0].message.content傳回的用量統計僅供你自行監控，不會用來計費。
串流
設定 "stream": true 後，回覆會透過伺服器傳送事件，以 OpenAI 區塊格式陸續傳回，並以 data: [DONE] 結束。請從 choices[0].delta.content 讀取文字。
圖片
兩款模型皆接受以 image_url 區塊傳入的圖片，區塊中須包含 base64 資料 URL（data:image/png;base64,...、JPEG 或 WebP）。系統不會擷取圖片 URL 連結的內容，傳入這類連結會收到 400 錯誤。
{"role": "user", "content": [
{"type": "text", "text": "Describe this image."},
{"type": "image_url", "image_url": {"url": "data:image/jpeg;base64,/9j/4AAQ..."}}
]}工具呼叫
請依照 OpenAI API 的格式傳入 tools。模型呼叫工具時，回應會包含 finish_reason: "tool_calls" 和 message.tool_calls；請執行工具，再新增一則 tool 訊息，填入執行結果與對應的 tool_call_id，然後再次呼叫 API。
推理
兩款模型都會先推理再回答，也都支援 reasoning_effort：none 代表直接回答，low 代表簡單推理，high 則適合較困難的問題；GLM-5.3-Flash 另支援 max，預設值為 high。思考內容會透過 reasoning_content 獨立傳回，不會混入 content。你也可以透過 "thinking": {"type": "disabled"} 或 "chat_template_kwargs": {"enable_thinking": false} 關閉推理。
並行處理
你的方案決定所有 API 金鑰合計可同時執行的請求數。超過上限的請求會立即收到 429 回應，不會進入佇列；正在執行的請求則不受影響。