正式環境最佳實務

本指南提供一套完整的最佳實務，協助你從原型邁向正式環境。無論你是經驗豐富的機器學習工程師，還是剛入門的愛好者，本指南都能提供所需的方法，協助你在正式環境中成功運用本平台，從確保 API 存取安全，到設計可承受大量流量的穩健架構。你可以參考本指南擬定計畫，讓應用程式部署盡可能順暢且有效率。

如想進一步了解導入正式環境的最佳實務，請觀看我們在 Developer Day 的演講：

設定組織

登入 OpenAI 帳戶後，你可以在組織設定中找到組織名稱和 ID。組織名稱是使用者介面中顯示的組織標籤。組織 ID 則是組織的唯一識別碼，可用於 API 請求。

隸屬多個組織的使用者可以傳入標頭，指定 API 請求使用哪個組織。這些 API 請求的用量會計入指定組織的配額。如果未提供標頭，費用會計入預設組織。你可以在使用者設定中變更預設組織。

你可以從團隊頁面邀請新成員加入組織。成員可以是 讀取者 或 擁有者。

讀取者：

• 可以發出 API 請求。
• 可以查看組織的基本資訊。
• 除非另有註明，否則可以建立、更新及刪除組織中的資源（例如 Assistants）。

擁有者：

• 擁有讀取者的所有權限。
• 可以修改帳務資訊。
• 可以管理組織內的成員。

管理帳務限制

輸入帳務資訊後，OpenAI 會為你的組織設定核准的用量上限。隨著你在平台上的用量增加，並升至更高的用量層級，配額上限也會自動提高。你可以在帳戶設定的限制頁面查看目前的用量上限。

在限制頁面設定支出警示，即可在用量費用超過特定金額時收到通知。如要強制執行每月上限，請設定強制支出上限。當追蹤到的支出達到上限時，強制支出上限會停止受影響的 API 流量，因此在正式環境啟用前，請先閱讀支出上限指南。

API 金鑰

OpenAI API 使用 API 金鑰進行身分驗證。請前往 API 金鑰頁面，取得請求所需的 API 金鑰。

這是一種相對簡單的存取控制方式，但你必須謹慎保護這些金鑰。請避免在程式碼或公開程式碼庫中洩露 API 金鑰，應將金鑰儲存在安全的位置。你應透過環境變數或機密管理服務，讓應用程式取得金鑰，避免將金鑰寫死在程式碼中。詳情請參閱 API 金鑰安全最佳實務。

我們強烈建議你在建立專案 API 金鑰時設定到期日，並建立定期輪替金鑰的流程。在金鑰到期前，請建立新金鑰，更新應用程式以使用新金鑰，並在確認新金鑰運作正常後撤銷舊金鑰。

管理員可以在平台設定中，於組織或專案層級強制設定 API 金鑰的有效期間上限。新金鑰必須在設定的期限內到期，避免金鑰永久有效。專案的有效期間上限不得超過組織的上限。

平台設定中的 API 金鑰治理 區段可讓組織與專案管理員限制可建立的 API 金鑰類型。管理員可以選擇僅允許建立服務帳戶金鑰、僅允許建立使用者擁有的專案金鑰，或禁止建立任何新的 API 金鑰。組織層級的限制一律優先適用：專案設定可以增加限制，但不能放寬組織層級的限制。這些控制措施僅適用於新金鑰的建立；現有的 API 金鑰不受影響。

啟用追蹤後，你可以在用量頁面監控 API 金鑰用量。如果你使用的 API 金鑰是在 2023 年 12 月 20 日之前產生，預設不會啟用追蹤。你可以在 API 金鑰管理儀表板啟用追蹤，以記錄之後的用量。2023 年 12 月 20 日之後產生的所有 API 金鑰都已啟用追蹤。先前未追蹤的用量會在儀表板中顯示為 Untracked。

預備環境專案

隨著規模擴大，你可以考慮為預備環境和正式環境分別建立專案。你可以在儀表板中建立這些專案，將開發和測試工作隔離，避免意外干擾已上線的應用程式。你也可以限制使用者對正式環境專案的存取權，並為各個專案設定自訂的速率限制及支出上限。

擴充解決方案架構

在設計使用我們 API 的正式環境應用程式或服務時，務必考量如何擴充以滿足流量需求。無論選擇哪家雲端服務供應商，你都需要考量以下幾個重點：

• 水平擴充：你可以考慮水平擴充應用程式，以處理來自多個來源的請求。這可能需要部署額外的伺服器或容器來分散負載。如果選擇這種擴充方式，請確保架構設計能支援多個節點，並具備在節點之間平衡負載的機制。
• 垂直擴充：另一種選擇是垂直擴充應用程式，也就是增加單一節點可用的資源。這需要提升伺服器的能力，以處理額外的負載。如果選擇這種擴充方式，請確保應用程式的設計能善用這些新增資源。
• 快取：儲存經常存取的資料，可以縮短回應時間，無須重複呼叫我們的 API。應用程式的設計應盡可能使用快取資料，並在新增資訊時使快取失效。例如，你可以根據應用程式的需求，選擇將資料儲存在資料庫、檔案系統或記憶體快取中。
• 負載平衡：最後，請考慮使用負載平衡技術，確保請求平均分配到可用的伺服器。你可以在伺服器前端使用負載平衡器，或採用 DNS 輪詢。平衡負載有助於提升效能並減少瓶頸。

管理速率限制

使用我們的 API 時，務必了解速率限制並據此規劃。

降低延遲

延遲是指處理請求並傳回回應所需的時間。本節將說明影響文字生成模型延遲的一些因素，並提供降低延遲的建議。

補全請求的延遲主要受兩個因素影響：模型和生成的 Token 數量。補全請求的生命週期如下：

大部分延遲通常來自 Token 生成步驟。

直觀理解：提示詞 Token 對文字生成呼叫增加的延遲很少。生成回應 Token 所需的時間則長得多，因為 Token 是逐一生成的。生成的內容越長，每個 Token 所需的生成時間就會累積成越長的延遲。

影響延遲的常見因素及可能的改善方法

了解延遲的基本概念後，接下來看看影響延遲的各種因素，大致依影響程度由大到小排列。

模型

我們的 API 提供多種模型，複雜程度和通用性各有不同。能力最強的模型，例如 gpt-6-astra，可以生成更複雜、更多樣的補全內容，但處理查詢也需要更長的時間。 gpt-5.6-terra 和 gpt-5.6-luna 等模型能以更快的速度和更低的成本生成回應；如果你希望模型有更充裕的能力來應對複雜任務，gpt-6-astra 則是能力更強的預設選擇。你可以根據使用情境，以及速度、成本和品質之間的取捨，選擇最合適的模型。

補全 Token 數量

要求生成包含大量 Token 的補全內容，可能會增加延遲：

• 降低 Token 數量上限：對於生成 Token 數量相近的請求，max_tokens 參數較低的請求，延遲也較低。
• 加入停止序列：加入停止序列可避免生成不必要的 Token。例如，你可以使用停止序列，生成項目數量固定的清單。在這種情況下，將 11. 設為停止序列，就可以生成只有 10 個項目的清單，因為補全內容生成到 11. 時就會停止。請閱讀我們關於停止序列的說明文章，進一步了解做法。
• 減少補全結果數量：盡可能降低 n 和 best_of 的值。其中，n 指定每個提示詞要生成多少個補全結果，best_of 則用於選出每個 Token 的對數機率最高的結果。

如果 n 和 best_of 都等於 1（預設值），生成的 Token 數量最多為 max_tokens。

如果 n（傳回的補全結果數量）或 best_of（生成以供挑選的補全結果數量）設為 > 1，每個請求都會產生多個輸出。此時，你可以將生成的 Token 數量視為 [ max_tokens * max (n, best_of) ]

串流

在請求中設定 stream: true，模型就會在 Token 生成後立即開始傳回，而無須等到整個 Token 序列生成完畢。這不會改變取得所有 Token 所需的時間，但如果應用程式需要顯示部分進度，或會中途停止生成，串流可以縮短取得第一個 Token 的時間。這有助於改善使用者體驗，因此值得嘗試。

批次處理

視使用情境而定，批次處理可能有所幫助。如果你要向同一個端點傳送多個請求，可以將提示詞合併成批次，在同一個請求中傳送。這能減少所需的請求數量。prompt 參數最多可包含 20 個不同的提示詞。我們建議你測試這種方法，確認是否有效。在某些情況下，這反而可能增加生成的 Token 數量，延長回應時間。

管理成本

如要監控成本，你可以在帳戶中設定通知門檻，在超過特定用量門檻時收到電子郵件警示。使用用量追蹤儀表板，即可監控目前及過往帳單週期的 Token 用量。

文字生成

將原型導入正式環境的挑戰之一，是為應用程式的執行成本編列預算。OpenAI 採用隨用隨付的定價模式，以每 1,000 個 Token（約相當於 750 個單字）為計價單位。如要估算成本，你需要預估 Token 用量。請考量流量、使用者與應用程式互動的頻率，以及將處理的資料量等因素。

思考如何降低成本時，一個實用的框架是將成本視為由 Token 數量和每個 Token 的成本共同決定。 依照這個框架，你可以從兩個方向降低成本。首先，可以將部分任務改用較小的模型，降低每個 Token 的成本，進而減少整體成本。另一個方向是減少所需的 Token 數量。做法包括使用較短的提示詞、微調模型，或快取常見的使用者查詢，避免重複處理。

你可以試用我們的互動式 Token 分詞工具來協助估算成本。API 和 Playground 也會在回應中傳回 Token 數量。使用我們能力最強的模型讓應用程式正常運作後，你可以測試其他模型是否能以更低的延遲和成本達到相同結果。詳情請參閱 Token 用量說明文章。

MLOps 策略

將原型導入正式環境時，你可以考慮制定 MLOps 策略。MLOps（機器學習營運）是指管理機器學習模型完整生命週期的流程，涵蓋的模型也包括你可能使用我們的 API 進行微調的模型。制定 MLOps 策略時，請考量以下面向：

• 資料與模型管理：管理用於訓練或微調模型的資料，並追蹤版本與變更。
• 模型監控：持續追蹤模型的表現，並偵測任何潛在問題或效能下降的情況。
• 模型重新訓練：確保模型能因應資料變化或不斷演進的需求，並視需要重新訓練或微調。
• 模型部署：將模型及相關產物部署至正式環境的流程自動化。

仔細思考應用程式的這些面向，有助於確保模型長期符合需求並維持良好表現。

安全性與合規

將原型移至正式環境時，你需要評估並滿足應用程式可能適用的安全性與合規要求。這包括檢視你處理的資料、瞭解我們的 API 如何處理資料，以及確定必須遵守哪些法規。我們的安全性實務與信任與合規入口網站提供最完整且最新的文件。你也可以參閱我們的隱私權政策與使用條款。

你需要考量的常見面向包括資料儲存、資料傳輸及資料保留。你可能也需要採取資料隱私保護措施，例如在可行的情況下進行加密或匿名化。此外，你應遵循安全程式設計的最佳實務，例如清理輸入資料及妥善處理錯誤。

安全最佳實務

使用我們的 API 建立應用程式時，請參考我們的安全最佳實務，以確保應用程式安全且成功。這些建議強調全面測試產品、主動處理潛在問題，以及減少遭到濫用的機會有多重要。

業務考量

當使用 AI 的專案從原型邁向正式環境時，務必思考如何運用 AI 打造出色的產品，以及產品如何與核心業務連結。我們當然無法解答所有問題，不過，你可以先觀看我們在 Developer Day 與幾位客戶深入探討這個主題的演講：