LLM API 開發者指南：從 Chat Completions 開始

AI2026-09-22TryQuickToolBox

你對某個 AI 功能有個很棒的點子，但當你開始閱讀 API 文件時，卻撞上一堵術語高牆：tokens、temperature、streaming、system prompts。感覺要拿第二個學位才能送出一個訊息。好消息是，核心概念很簡單：你送出一串訊息，模型回覆一則訊息。其他都只是調校。本文將帶你走過將 LLM chat completion API 整合至應用程式的實用步驟，並附上你今天就能套用的程式碼。

什麼是 Chat Completion API？

本質上，chat completion API 以對話歷史作為輸入，並回傳對話中的下一則訊息。歷史紀錄是一組訊息物件陣列，每個物件包含 role 與 content。角色通常是 system、user 與 assistant。system 訊息設定助理的行為，user 訊息是使用者輸入的內容，assistant 訊息則是模型先前的回覆。透過送出整段歷史，你提供模型生成連貫回應所需的上下文。

大多數供應商（OpenAI、Anthropic、Google 以及開源替代方案）都遵循類似的模式，雖然實際的 endpoint 與 payload 可能不同。一旦你理解其中一種，就能快速適應其他供應商。

逐步教學：你的第一個 API 呼叫

讓我們用 Python 與 OpenAI SDK 走過一個最小範例。你可以用 pip install openai 安裝。將 API key 設為環境變數，避免寫在程式碼中。

import os
from openai import OpenAI

client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])

response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user", "content": "Explain what an API is in one sentence."}
    ]
)

print(response.choices[0].message.content)

就是這樣。回應物件包含一個 choices 清單；通常你取第一個。message content 就是模型的回覆。你也可以存取 usage 統計資料來追蹤 token 消耗量。

你應該調整的關鍵參數

除了 messages 之外，有幾個參數控制模型的輸出：

model：要使用哪個模型。較小的模型更便宜、更快速；較大的模型能力更強。
temperature：控制隨機性。0 是確定性的，1 是有創意的。事實性任務請使用低數值；腦力激盪則使用較高數值。
max_tokens：限制回覆長度。設定此值可避免意外過長（且所費不貲）的回應。
top_p：控制多樣性的另一種方式，可替代 temperature。通常你調整其中一個，而非兩者都調。
stream：設為 true 時，API 會在生成回應的同時送出部分內容，改善使用者感知的延遲。

串流回應以提升使用者體驗

等待完整回應可能感覺很慢，尤其是長答案。串流讓你可以在文字到達時就顯示出來。以下是在 Python 中處理串流的方式：

stream = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "Tell me a story."}],
    stream=True
)

for chunk in stream:
    delta = chunk.choices[0].delta.content
    if delta:
        print(delta, end="", flush=True)

每個 chunk 包含一個 delta，內含回應的一小部分。你累積這些片段來組成完整訊息。在網頁應用中，你可以使用 Server-Sent Events (SSE) 或 WebSockets 將這些 chunk 轉發到瀏覽器。

處理錯誤與速率限制

API 會失敗。網路會出狀況。速率限制會觸發。你的整合應該優雅地處理這些情況。常見錯誤包括：

401 Unauthorized：無效的 API key。檢查你的環境變數。
429 Too Many Requests：你已觸發速率限制。實作指數退避並重試。
500 Internal Server Error：供應商端的問題。延遲後重試。

一律將 API 呼叫包在 try/except 區塊中並記錄失敗。在正式環境中，可考慮使用像 tenacity 這樣的函式庫來處理重試。

管理成本與 Tokens

Tokens 是 LLM API 的貨幣。輸入與輸出的 tokens 都會計入你的帳單。若要讓成本可預測：

簡單任務使用較小的模型。
不需要完整上下文時，將對話歷史裁剪至最後幾則訊息。
設定 max_tokens 來限制輸出長度。
若使用情境允許，快取頻繁出現的回應。

透過供應商的 dashboard 監控用量，或記錄每次回應的 token 數量。

安全性與隱私考量

當你將使用者資料傳送給 LLM API 時，你是在將這些資料託付給第三方。請檢視供應商的資料保留政策。避免傳送密碼或個人識別資訊等敏感資料。若必須傳送，可考慮自架模型或提供強大隱私保證的供應商。此外，絕不要在用戶端程式碼中暴露你的 API key；一律透過後端代理請求。

常見問題

chat completion 與一般 completion 有何不同？

Chat completions 是為對話式介面設計的。它們接受帶有角色的訊息清單，讓模型能維持上下文。一般 completions 接受單一 prompt 字串，較不適合多輪對話。

我該如何選擇正確的模型？

從較小、較便宜的模型開始做原型。如果需要更好的推理能力或更長的上下文，再改用較大的模型。在你的特定任務上測試兩者，找出最佳的成本效能權衡。

我可以在同一個應用中使用多個 LLM 供應商嗎？

可以。許多開發者將 API 呼叫抽象化到介面之後，並根據成本、延遲或功能來切換供應商。像 LiteLLM 或 LangChain 這類函式庫可以協助統一不同的 API。

後續步驟

現在你可以進行基本呼叫了，試著用 system prompts 來引導模型的行為。嘗試串流以改善使用者體驗。並隨時留意 token 用量。在開發過程中，你可能需要格式化模型回傳的 JSON 回應以便後續處理。為此，JSON formatter 可以協助你快速驗證並美化輸出。