如何使用 LLM API：Token、費用、金鑰，以及你的第一個 AI 功能

LLM API 是一種網路服務，讓你的應用程式把文字送給大型語言模型（例如 OpenAI 的 GPT 模型、Anthropic 的 Claude 或 Google 的 Gemini），並在程式中取回它的回覆。你向供應商註冊，建立一個 API 金鑰，接著你的應用程式伺服器就會用這把金鑰發送請求；你會依進出的 Token（文字片段）數量，為每次請求付費。通常所謂「在應用程式中加入 AI」，指的就是：從你的伺服器安全地向別人的模型發出一個寫得好的請求。

為什麼用 AI 建置時這很重要

AI 建置的應用程式中有兩種不同的 AI，很容易搞混：

1. 建置你應用程式的 AI：應用程式建置工具自己的代理程式，負責撰寫程式碼。
2. 應用程式內部的 AI：使用者會用到的功能，例如聊天助理、「摘要這段內容」按鈕或自動標記。

第二種會用你的金鑰呼叫 LLM API，並由你的供應商帳戶付費。理解 Token、上下文和計費方式，能讓你設計出一個能正常運作、不會洩漏金鑰、也不會讓帳單出乎意料的功能。

日常比喻：一位能力很強、按字數計費的自由工作者

可以把 LLM API 想成一位很厲害的自由撰稿人：你透過電子郵件聯絡他，並按字數付費，不論是你寄給他的字數，還是他寫回來的字數都要算錢（而且他寫回來的字比較貴）。

• 他在信件之間沒有記憶。如果你想延續對話，就必須在每封新郵件裡貼上先前的訊息。
• 他一次能讀的內容有限，這個上限就是上下文視窗。
• 你的指示越清楚，答案就越好、越短，而這也比較省錢。

核心概念

Token

模型以 Token 為單位讀寫文字。Anthropic 的定價文件估計，截至 2026 年 9 月，每個 Token 約為 4 個字元，或大約 0.75 個英文單字。不同模型與語言的 Token 切分方式不同，所以請把它當成粗略的參考。所有內容都會計算：你的指示、使用者的訊息、你附上的任何文件、先前的對話，以及回覆本身。

輸入與輸出

輸入 Token 是你送出的內容。輸出 Token 是模型寫出的內容。根據 OpenAI、Anthropic 與 Google 截至 2026 年 9 月的定價頁面，同一個模型的輸出 Token 費用通常是輸入 Token 的數倍。Google 的 Gemini 定價也註明，模型內部的「思考」過程會計為輸出。

上下文視窗

模型在單次請求中可接受的 Token 總數上限，包括回覆在內。現代模型可以接受非常長的輸入，例如 Anthropic 的部分現行模型最多可接受一百萬個 Token。但輸入越長，費用越高，耗時也越久，所以只送任務真正需要的內容。

無狀態的請求

對大多數聊天式 API 而言，預設每個請求都是獨立的。若要讓聊天「記得」先前的內容，你的應用程式必須在每則新訊息中重新送出先前的訊息。這就是為什麼長對話的每則訊息都比短對話更貴。

系統提示

在每次請求中設定模型角色與規則的指示，例如：「你會把客服工單摘要成三個重點。絕對不要包含客戶的電子郵件地址。」使用者看不到它，但它會影響每一次回覆。

串流

API 不必等到完整答案產生完才回傳，而是可以邊產生邊送出文字，讓使用者立刻看到字詞一個個出現。這會讓聊天介面感覺快很多。

計費方式

以下為截至 2026 年 9 月，依各供應商自己的定價頁面所整理：

部分供應商也提供先試後付的方式：Anthropic 會給新使用者少量免費額度；Google 的 Gemini API 在部分模型上有免費方案，但請注意，在免費方案中送出的內容可能會被用來改善 Google 的產品。

小型、快速模型與最大型模型之間的價格差異很大，而且價格經常變動，所以這裡不列出具體數字。估算任何功能的一個簡單方法是：（輸入 Token × 輸入價格 + 輸出 Token × 輸出價格）× 每月請求次數。之後再預留一些餘裕，並在供應商的後台設定每月支出上限。

實例：「摘要這份工單」按鈕

一支小型客服團隊想要一個按鈕，把冗長的客戶郵件往來串成三個重點，並附上建議的回覆。

1. 取得金鑰。 向一家供應商建立帳戶，並產生 API 金鑰。設定一個較低的每月支出上限。
2. 把金鑰存成伺服器上的機密。 例如命名為 ANTHROPIC_API_KEY 或 OPENAI_API_KEY，絕對不要放在頁面程式碼中。請參閱環境變數與機密。
3. 新增一個伺服器路由，POST /api/summarise，它會：
   • 檢查使用者是否已登入，且屬於客服團隊；
   • 從資料庫載入工單；
   • 把系統提示（「用三個重點摘要，然後草擬一段禮貌的回覆；不要編造訂單編號」）與工單內容一起送給供應商；
   • 用最大輸出 Token 的設定限制回覆長度；
   • 回傳結果，並記錄本次使用了多少 Token。
4. 按鈕呼叫你的路由，而不是直接呼叫供應商，並在摘要產生時串流顯示。
5. 處理失敗。 如果供應商回應很慢或回傳錯誤，就顯示「目前無法摘要」，並讓工單仍然可以正常使用。
6. 衡量。 一週後查看 Token 記錄。如果大部分費用來自很長的郵件往來，就在送出前先精簡引用的歷史內容。

注意這裡沒有的東西：沒有模型訓練，也沒有特別的基礎設施。一把金鑰、一個伺服器路由、一個寫得好的提示。

關鍵名詞

• API 金鑰： 向供應商識別你帳戶的機密。任何擁有它的人都可以花你的錢。
• 模型： 你呼叫的特定 LLM。供應商會提供多種大小的模型，價格與速度各不相同。
• Temperature（溫度）： 控制回覆多樣性的設定。數值越低，結果越可預測。
• Max tokens（最大 Token 數）： 回覆長度的上限，也同時限制了費用。
• 速率限制（Rate limit）： 你的帳戶每分鐘可以使用的請求數或 Token 數。
• Embeddings（嵌入向量）： 代表文字語意的數字，用於搜尋你自己的文件。
• RAG（檢索增強生成）： 從你自己的資料中找出相關段落，並放進提示中，讓模型根據你的內容回答。
• 工具使用／函式呼叫（Tool use／function calling）： 讓模型要求你的應用程式執行特定函式，例如「查詢訂單狀態」。

常見錯誤與誤解

• 把金鑰放在前端程式碼中。 這是最昂貴的錯誤。瀏覽器程式碼是公開的。請一律從伺服器呼叫。AI 建置應用程式的安全檢查清單會把這點與其他上線前的檢查一起說明。
• 沒有支出上限或每位使用者的限制。 一個錯誤、一個無限迴圈或一位濫用的使用者，都可能很快讓費用暴增。請在供應商端設定上限，並在你的應用程式中限制每位使用者的請求數。
• 每次都送出所有內容。 整份文件和完整的聊天紀錄會成倍增加輸入 Token。請精簡、摘要較早的訊息，或只取回相關的部分。
• 盲目相信輸出。 模型可能會很有把握地說出錯誤的內容。對於事實、價格，或任何法律或醫療相關的內容，請以你自己的資料為依據並附上來源，或由人工確認。
• 讓使用者的輸入覆蓋你的規則。 使用者可能會輸入「忽略你的指示」。權限與敏感操作應該留在你的伺服器程式碼中，而不是只寫在提示裡。
• 一開始就用最大的模型。 先試用較小、較便宜的模型；只有在品質需要時才換用更大的模型。
• 不經思考就送出個人資料。 請檢查供應商的資料使用條款，特別是免費方案，並且只送出功能真正需要的內容。

向你的 AI 建置工具要求什麼

在工單頁面新增一個「摘要」按鈕。它會呼叫一個伺服器路由，使用機密 OPENAI_API_KEY（絕對不會暴露給瀏覽器），檢查使用者是否已登入，並用這段系統提示送出工單內容：[…]，把回覆限制在 300 個 Token 以內，將答案串流到頁面，若呼叫失敗則顯示友善的錯誤訊息。每次請求都記錄使用的 Token，並限制每位使用者每小時最多 30 次摘要。

如果你想要完整的聊天體驗，請參閱如何建置 AI 聊天機器人應用程式；如果想看其他點子，請參閱如何在應用程式中加入 AI 功能。如果你對 API 這個概念還不熟悉，可以先從什麼是 API開始。

在 Mythex 建置的應用程式中使用 LLM API

使用 Mythex 建置時，應用程式內的 AI 會使用你自己的供應商金鑰。你可以把它加入為專案機密，或透過 Mythex 在聊天中需要時顯示的機密卡片加入，然後請代理程式在伺服器上進行呼叫。供應商的用量會計入你的供應商帳戶，而不是 Mythex 的建置點數。Mythex 不會為你應用程式的使用者提供 Token，也不包含內建的知識庫產品；速率限制與費用控管由你自行設計與測試。文件中的食譜使用自己的 API 金鑰為應用程式加入 AI 功能提供了起始提示，而 AI 應用程式建置工具頁面則說明從哪裡開始。

常見問題