用一個 API Key 存取 GPT、Claude、Gemini 與 DeepSeek

切換到統一端點之前：四個 API Key 散落在你的密碼管理員裡。四個帳單儀表板，各有各的最低儲值金額和晦澀的 rate-limit 面板。新模型一發表——你想試試，於是花 20 分鐘翻找認證資料、10 分鐘掃過上個月才改版的 SDK 文件、再花 5 分鐘瞪著一個解析不出來的 base_url。然後 Claude 告訴你，你的地區不受支援。好不容易拿到回應，已經是禮拜二，而你一行功能程式碼都還沒寫。

切換之後：一個 API Key。一個端點。把 "gpt-5" 改成 "claude-opus-4-5"，一行搞定，你就換了供應商——同一個 client、同一個請求格式、同一套錯誤處理。在一個迴圈裡比較五個模型。OpenAI 一傳回 429，立刻 fallback 到 Gemini。零個新 import。零個新帳號。

差別就在一個統一端點、15 行程式碼設定，以及從零到能呼叫所有主流模型的 5 分鐘。以下是完整程式碼——Python 和 Node.js，可直接貼上。

為什麼需要一個 API Key？

一句話說明白：管理四個供應商帳號，每個月浪費 8–12 個開發者工時在跟程式無關的雜務上——KYC、最低儲值、帳單週期、rate-limit 儀表板、SDK 版本更新——而你把一切整合到單一端點的那一刻，這些全部消失。

想看到完整的論述——包含市場資料、成本比較，以及每月 360 萬次聚合平台造訪背後的可靠性分析——請讀為什麼開發者改用聚合平台。

把它想成 AI API 的萬用轉接器。你的應用程式對單一端點說一種協定——OpenAI Chat Completions。端點背後，平台把你的請求轉譯到 model 參數指定的供應商，正規化回應，再用你程式碼本來就預期的格式送回。以應用程式的角度來看，每個模型都是 OpenAI 模型。供應商之間的差異——認證握手、錯誤格式的怪癖、串流 frame 的不一致——在碰到你的程式碼之前就被吸收掉了。

這是技術面的圖像。財務面同樣有說服力——下面是整合在真實團隊資產負債表上的樣貌。

真實世界的成本比較

一個五位開發者、在打造 AI 原生 SaaS 產品的團隊。以下是他們實際的每月花費——三個月前一次遷移期間記錄下來的。

整合之前——各供應商直連帳號：

OpenAI：最低儲值 $200，實際用於 GPT-5.5 複雜推理任務的是 $180。Anthropic：最低儲值 $200，實際用於 Claude Opus 程式生成的是 $150。Google：最低儲值 $100，實際用於 Gemini 多模態處理的是 $85。DeepSeek：無最低儲值，實際用於大量文字分類的是 $60。各帳號間閒置的未用儲值合計：$185。實際每月支出：$475。

行政負擔每月再為每位開發者加上 2–3 小時——掉進垃圾郵件的 KYC 重新驗證信、拖了一個禮拜的 rate-limit 談判串、永遠對不上的帳單週期日期。五位開發者加總，等於每月 10–15 個團隊工時耗費在 API 行政事務上。以含所有成本的開發者時薪 $75 計算，隱藏的人事成本是每月 $750–1,125。

整合之後——單一聚合端點：

一個帳號。一個預儲餘額。一張帳單。沒有閒置儲值。以量計價的統籌定價，把旗艦模型費率壓到比零售低 15–35%——GPT-5.5 每個 100 萬 token $12.75，而非 $15；Claude Opus 同樣 $12.75，而非 $15。

成本導向路由（下方 Pattern 2）把 60% 的「中等」請求從 Opus 級費率轉到 Sonnet 級費率——在可路由流量上再省 40–60%。加上量價折扣，實際每月支出落在 $285–340。這比直連帳號少了 28–30%。

行政負擔降到每月 15 分鐘——儲值一個餘額、核對一張帳單。你的財務團隊看到的是標示「AI API」的單一項目，而不是四行項目——四個帳單週期、三種付款方式、還有一個只收電匯的供應商。

省下來的錢會複利成長。每個新模型發表，都不增加新帳號、不增加新儲值、不增加新的帳務關係。DeepSeek V4 發表時，團隊只是改一個 model 字串就切換完成——不用註冊流程、不用新的驗證、不用等待。

全部 10 家供應商、每個等級的逐模型定價，見模型定價總覽。

5 分鐘設定：你的第一個多模型呼叫

需要帶螢幕截圖的逐步教學嗎？官方快速入門指南帶你完成帳號設定、API Key 產生，以及五分鐘內發出第一個請求。

Python——15 行程式碼。

from openai import OpenAI

# One client. One base_url. One API key.
client = OpenAI(
    base_url="https://api.tokspan.com/v1",
    api_key="ts-your-key-here"
)

# GPT-5.5
gpt_response = client.chat.completions.create(
    model="gpt-5.5",
    messages=[{"role": "user", "content": "Explain quantum computing in one sentence."}]
)
print(f"GPT-5.5: {gpt_response.choices[0].message.content}")

# Claude Opus 4.8 —same client, different model string
claude_response = client.chat.completions.create(
    model="claude-opus-4-8",
    messages=[{"role": "user", "content": "Explain quantum computing in one sentence."}]
)
print(f"Claude: {claude_response.choices[0].message.content}")

Node.js——同一套寫法。

import OpenAI from 'openai';

const client = new OpenAI({
    baseURL: "https://api.tokspan.com/v1",
    apiKey: "ts-your-key-here"
});

// Switch models by changing one string
const models = ["gpt-5.5", "claude-opus-4-8", "gemini-3.1-pro", "deepseek-v4-pro"];

for (const model of models) {
    const response = await client.chat.completions.create({
        model,
        messages: [{ role: "user", content: "Explain quantum computing in one sentence." }]
    });
    console.log(`${model}: ${response.choices[0].message.content}`);
}

就是這樣。換模型等於改 model 參數的字串——OpenAI Python SDK 會處理其他一切。不用換 SDK。不用改 base_url。不用新的認證流程。

生產環境模式：超越快速入門

快速入門適合探索。生產環境要的是韌性。下面三個模式，把能跑的 prototype 變成可靠的應用程式。

Pattern 1：模型 fallback 鏈。

單一供應商故障不該拖垮你的應用程式。這條 fallback 鏈會先試你偏好的模型、再試備援、再試省錢的備案——全程對使用者透明。

import logging
from openai import OpenAI

client = OpenAI(
    base_url="https://api.tokspan.com/v1",
    api_key="ts-your-key-here"
)

FALLBACK_CHAIN = [
    "gpt-5.5",               # Primary: strongest agent reliability
    "gemini-3.1-pro",        # First fallback: multimodality and long-context
    "deepseek-v4-pro"        # Cost-efficient safety net for text-only tasks
]

def chat_with_fallback(messages, model_chain=FALLBACK_CHAIN):
    last_error = None
    for model in model_chain:
        try:
            response = client.chat.completions.create(
                model=model,
                messages=messages,
                timeout=30
            )
            return response.choices[0].message.content
        except Exception as e:
            last_error = e
            logging.warning(f"Model {model} failed: {e}. Trying next.")
            continue

    raise RuntimeError(
        f"All models in chain failed. Last error: {last_error}"
    )

三行 fallback 邏輯。這就是「聊天機器人掛了」和「使用者根本沒注意到」之間的差別。你的使用者不在乎是哪個模型回應了他們的請求。他們在乎的是回應有到。

Pattern 2：成本導向路由。

不是每個請求都需要旗艦模型。這個分類器把簡單查詢導到最便宜又能勝任的模型，只在必要時才升級。

ROUTING_RULES = {
    "simple": "deepseek-v4-flash",      # $0.14/$0.28 —classification, extraction, simple Q&A
    "medium": "claude-sonnet-4-6",       # $3/$15 —coding, analysis, moderately complex tasks
    "complex": "claude-opus-4-8"         # $5/$25 —architectural decisions, debugging, legal analysis
}

def classify_complexity(user_message: str) -> str:
    """Use a cheap model to classify task complexity before routing."""
    response = client.chat.completions.create(
        model="deepseek-v4-flash",
        messages=[{
            "role": "system",
            "content": "Classify this request as 'simple', 'medium', or 'complex'. Reply with one word."
        }, {
            "role": "user",
            "content": user_message
        }],
        max_tokens=3
    )
    return response.choices[0].message.content.strip().lower()

這個分類器每次請求成本 $0.000004。正確路由省下的：通常是你的 API 帳單 70–80%。這種不對稱性，值得那三行多出來的程式。

Pattern 3：統一串流。

串流讓感受上的延遲從 3 秒以上降到 0.3 秒。這個 handler 不管哪個模型在線，運作方式都一模一樣。

def stream_response(model: str, messages: list):
    stream = client.chat.completions.create(
        model=model,
        messages=messages,
        stream=True
    )
    for chunk in stream:
        if chunk.choices[0].delta.content:
            yield chunk.choices[0].delta.content

GPT-5.5、Claude、Gemini、DeepSeek 都用同一個迴圈——不需要供應商特定的串流邏輯。聚合端點會正規化串流格式。

Pattern 4：指數退避重試。

暫時性故障——429 rate limit、503 服務不可用、連線重置——在所有供應商身上以 0.5–2% 的頻率發生。無視它們，等於你的應用程式每 50 到 200 個請求就會失敗一次。三行的重試包裝就能把它降到趨近於零。

import time
import random

def chat_with_retry(model, messages, max_retries=3, base_delay=1.0):
    last_exception = None
    for attempt in range(max_retries + 1):
        try:
            response = client.chat.completions.create(
                model=model,
                messages=messages,
                timeout=30
            )
            return response.choices[0].message.content
        except Exception as e:
            last_exception = e
            if attempt == max_retries:
                break
            # Exponential backoff: 1s -> 2s -> 4s with 0-25% jitter
            delay = base_delay * (2 ** attempt) + random.uniform(0, 0.25 * base_delay)
            time.sleep(delay)
    raise RuntimeError(f"Request failed after {max_retries + 1} attempts: {last_exception}")

生產環境有三個細節很重要。第一，一定要加 jitter——沒有它，重試中的 client 會同步觸發「驚群效應」，把 rate limit 弄得更糟。第二，要區分可重試錯誤（429、5xx）與不可重試錯誤（400、401、403）——把一個錯誤的 API Key 重試六次，是浪費所有人的時間。第三，為所有重試次數設定一個總逾時預算（例如 60 秒），這樣效能劣化的供應商才不會綁架你的請求管線。

把這個跟 Pattern 1（fallback 鏈）結合，你就有縱深防禦：偏好模型最多重試 3 次，然後 fallback 到鏈上的下一個模型、再重試 3 次，依此類推。實務上，這個組合能處理 99.7% 的暫時性故障，而且使用者毫無感覺。

常見的遷移陷阱

從直連供應商 API 搬到統一端點時，這四件事會壞掉。每一件我都是用最痛的方式學到的——星期五晚上 11 點看著測試失敗。

陷阱 1：寫死的供應商特定錯誤碼。

你那支檢查 Anthropic context_length_exceeded 錯誤類型的 error handler，會漏掉聚合層的正規化格式。解法：改抓 HTTP 狀態碼。400 涵蓋所有供應商的 context-length 與無效請求錯誤。429 到哪裡都是 rate limit。5xx 代表供應商今天狀況不好。寫一支依狀態碼分支的 error handler，而不是四支依供應商特定錯誤類型字串分支的 handler。

陷阱 2：對回應 header 的假設。

如果你的追蹤程式碼從 OpenAI 的回應 header 讀 x-request-id，聚合端點很可能用不同的 header——通常是 x-trace-id 或 x-platform-request-id。x-ratelimit-remaining-tokens 這類 rate-limit header 在不同供應商間也不一樣。可靠的做法：讀回應 body 裡的 id 欄位（每個 OpenAI 相容端點都有），並把 rate-limit 監控交給聚合平台的儀表板，而不是在執行期去解析 header。

陷阱 3：用 tiktoken 算 token。

tiktoken 是寫死綁定 OpenAI tokenizer 的。把請求透過統一端點路由到 Claude 或 Gemini，你的事前 token 估算會錯 10–20%。解法：用回應 body 裡的 usage 物件——response.usage.total_tokens 永遠回報實際的 token 數，不管是哪家供應商、哪個模型回應的。遇到必須估算的事前評估，就用 cl100k_base，並為非 OpenAI 模型加上 15% 的安全緩衝。

陷阱 4：串流 chunk 的可空性。

OpenAI 把 delta.content 以字串串流。有些供應商在連線建立與拆除時，偶爾會發出 None 的 delta 或空 chunk。聚合端點正規化了大部分情況，但一支在 yield 前檢查 if chunk.choices[0].delta.content is not None 的防禦性程式碼，能避免供應商送出異常 frame 時出現靜默的 AttributeError。這單一個 guard 子句，已經救過我三次凌晨兩點的除錯地獄。

跨過這四個陷阱，遷移不到一小時就完成。通過之後，下面就是藏在單一 API Key 後面的完整模型陣容。

你可以存取哪些模型？

透過統一的聚合端點，你拿到橫跨所有主要供應商的 30 多個生產級模型——不用分開的帳號、不用分開的帳單、沒有地理限制。

供應商	可用模型	定價	最適合
OpenAI	GPT-5.5, GPT-5.4, GPT-5.4 Mini, GPT-5.4 Nano, o4-mini	官方費率	Agent、生態系廣度
Anthropic	Claude Opus 4.8, Sonnet 4.6, Haiku 4.5	官方費率	寫程式、複雜推理
Google	Gemini 3.1 Pro, 3.1 Flash, 2.5 Flash	官方費率	多模態、長上下文
DeepSeek	V4 Pro, V4 Flash, R1	量價費率	成本高效的寫程式、文字處理
Qwen	Qwen3.7 Max, Qwen3-32B	官方費率	多語言（亞洲語言）
GLM	GLM-5.2, GLM-4.7 Flash	官方費率	預算任務、開源對等
MiniMax	M3	官方費率	最佳價值寫程式（80.5% SWE-bench）
Kimi	K2.6	官方費率	長上下文推理
Mistral	Large 3, Small 4	官方費率	歐盟資料落地
Meta	Llama 4 Scout, Llama 3.3 70B	官方費率	自架、隱私

模型的可用性完全透明——平台會透過全球基礎設施路由請求，並回傳標準回應，不會漏出供應商特有的錯誤訊息。

開發者體驗：之前 vs. 之後

統一端點之前：四個供應商帳號、四套不同的註冊流程，各有各的驗證步驟與地區要求。你花在管理存取上的時間，比開發功能還多。

每當有新模型發表，你又得跳一遍註冊之舞。每個隊友都得應付不同的帳號、帳務關係與存取要求。你為了一張「哪個 API Key 配哪裡」的對照表，還得維護一個 Notion 頁面。

之後：一個帳號。一個預儲餘額。一個 SDK。一個帳務關係。新模型發表？它出現在模型清單裡——不用新帳號、不用新的註冊流程、不用新的付款方式。

你在世界各地的同事，跟你用同一個端點。Notion 頁面變成一行：「API Key：見 1Password。」

常見問題

這能用 OpenAI Python SDK 嗎？

可以。把 base_url 改成你的聚合端點就好。所有 client.chat.completions.create() 呼叫都不變地照常運作——串流、function calling、結構化輸出，全部。

Claude Code 和 Cursor 呢？

可以。把 ANTHROPIC_BASE_URL 設成你的聚合端點、ANTHROPIC_AUTH_TOKEN 設成你的 API Key。Claude Code 會透過平台使用 Anthropic 原生協定。Cursor 用 OpenAI 相容端點。兩者都適用於支援原生協定的聚合平台。在把 Claude Code 工作流程依賴上去之前，先確認你的平台支援 Anthropic 原生協定。

跟直連 API 比起來，我會損失哪些功能？

多數聚合平台支援完整的 Chat Completions API——串流、function calling、JSON 模式、結構化輸出都能用。Anthropic 原生功能（extended thinking、computer use）與 Google 特定功能（search grounding、automatic function calling）需要具備原生協定支援的平台。請查閱你平台的協定支援矩陣。就認證與 Key 管理而言，聚合模式比直連更安全——見我們的資安實務頁面。

這比直連 API 便宜還是貴？

這篇文章開頭那張真實世界比較表已經說明一切：五位開發者從每月實際 API 支出 $475、加上凍結在閒置儲值的 $185，降到整合後每月 $285–340。光是整合就省下 28–30%——一張帳單、沒有閒置現金、以量計費的每 token 定價。再加上這篇文章的 Pattern 2（成本導向路由），原本會打到 $30/M 模型的流量，有 60–80% 的比例改用 $0.28/M 或 $3/M 的模型解決。整合加路由加起來，團隊穩定落在沒做優化、直連旗艦模型帳號時期支出的 30–50% 以下。零售價上每個模型的標價不是重點——每月帳單總額才是。

我可以設定每個使用者的支出上限嗎？

可以。多數聚合平台支援虛擬 API Key——為每位團隊成員、每個應用程式或環境建立各自的 Key。設定每把 Key 的預算上限、rate limit 與模型白名單。有人離職時，撤銷他的 Key——供應商 Key 從來沒有暴露給他。這是直連 API 存取在你自己蓋一層 proxy 之前做不到的安全模式。

如果供應商在請求進行到一半時掛掉呢？

聚合端點在基礎設施層級處理 failover。如果你的請求到達端點，而供應商傳回 5xx 錯誤，平台會依你的路由設定在替代模型或供應商上重試。沒有設定明確的 fallback 時，請求會以明確的錯誤失敗——而不是 15 秒的 TCP 逾時。聚合平台上多數供應商端的故障，都會透過自動重試到健康模型，在 2 秒內解決。

在應用程式程式碼裡設定 Pattern 1（fallback 鏈）來做縱深防禦——平台處理基礎設施層級的 failover，你的程式碼處理應用層級的模型偏好。兩者加起來，既涵蓋供應商故障，也涵蓋平台層級的路由決策。實務上，這個多層做法代表：就算某家大型供應商完全劣化 30 分鐘以上，你的使用者還是看得到回應。

延遲跟直連 API 比起來如何？

聚合端點每次請求增加 50–150ms 的路由與正規化負擔。對 first-token 時間 300–2000ms 的串流請求，這點負擔幾乎感覺不到。對完成時間 2–5 秒的非串流請求，50–150ms 佔總延遲的 2–7%。取捨很清楚：你拿每次請求的 50–150ms，換取供應商劣化時能省下 15–30 秒停機時間的自動 failover。

如果你的應用程式需要低於 50ms 的負擔——高頻交易、即時遊戲 AI、低於 100ms 回應的 SLA——直連 API 是比較好的選擇。對其餘 95% 的使用案例，這點延遲差異比同一個模型兩次相同請求之間的自然變異還小。

可以用這個做微調（fine-tuning）嗎？

不行——聚合端點只做推論。微調需要直連供應商，因為訓練基礎設施（資料集上傳、訓練任務管理、模型產物儲存）是供應商特定的，並未透過 OpenAI 相容的 chat completions API 暴露。實務工作流程：所有推論流量用你的聚合 Key，另外留一把直連供應商 Key 專門跑微調任務，訓練完成後再把產出的模型 ID 加進你的聚合路由設定。一把直連 Key 負責訓練，一把聚合 Key 負責其他所有事。

打開你目前的專案。找到初始化 OpenAI client 的那一行。把 base_url 改成你的聚合端點。把 api_key 改成你的聚合 Key。跑你的測試套件。這就是遷移——兩行、五分鐘、零行為改變。然後做一件舊設定永遠不讓你做的事：改一個字串，就能在同一個提示詞上對 Claude Opus 和 GPT-5.5 做 A/B 測試。你已經想跑那個 benchmark 好幾個月了。今天就做。

上述兩行遷移——改 base_url、改 api_key——適用於任何 OpenAI 相容的聚合端點。這篇文章的所有程式碼都用 TokSpan 作為那個端點。你可以先用免費級模型驗證設定，等需要付費級吞吐量、或要存取 Claude Opus 與 GPT-5.5 時，再加值預儲額度。