距離上篇在 Early Access Playground 試用 o1 模型後又過了兩週，今天終於等到 API 開放使用啦！本篇將紀錄如何使用 Python SDK 存取 o1 模型。 系列文章 【Azure OpenAI】快速試用 o1 模型 模型佈署 在先前開放的 Early Access Playground 中使用 o1 是不需要另外佈署模型的，不過回到使用 API 來存取 o1 模型，就需要像之前的模型一樣先進行佈署才能使用，相信大家都很熟悉了。 使用 Python SDK 一樣使用熟悉的 openai 套件： 2024-09-01-preview 初始化的方式與先前模型都一樣，需要注意的是 o1 模型目前只能使用最新的 API 版本 2024-09-01-preview 來訪問。 Chat Completions 將 model 填入 o1-preview ，或是你的模型佈署名稱， messages 也一樣是歷史對話堆疊的 List。 回應如下： 查看 Token 使用量 內建 Chain of Thought 的 o1 比起過往的模型會消耗較多的 Token，因此我們特別把 Token 使用量拉出來看。 回應如下： 其中 prompt_tokens 、 completion_tokens 、 total_tokens 在先前的 API 就已經存在了，分別代表Token 的 Input、Output 與總使用量，而在新的 completion_tokens_details 中可以看到 reasoning_tokens 使用了 320 個 Tokens，居然佔了總輸出 Token 的 80% 以上！ 控制 Token 成本 已往我們可以使用 max_tokens 參數來控制 Token 的用量，但在 o1 模型中棄用了 max_tokens ，取而代之的是使用 max_completion_tokens 參數，來看看這段程式碼： 回應如下： 沒東西？那再看一次 Token 量。 回應如下： Token 居然是有被使用的！ 這表示 max_completion_tokens 並不像過往使用 max_tokens 這麼簡單，先前在回應遇到...
在 Azure 中提供了各式各樣的 API 讓我們可以在不同的場景中隨意組合使用，對於服務的 API 一般會在建立完成時分配一個專用的 Key，雖然這可能不是最佳作法，但直接使用 Key 來呼叫 API 的作法非常方便直觀。然而其他非服務類或管理層面的 API 就會遵循 OAuth 2.0 標準來設計，這對於初次使用且不太熟悉 OAuth 2.0 流程的人來說就不是很好上手。
這篇文章就來記錄一下如何在 Service Principal 中使用 OAuth 2.0 四個基礎流程之一的 Client Credentials 來呼叫 Azure API，並且盡量跳過那些繁雜的 OAuth 2.0 理論。
建立 Service Principal
首先建立要用來呼叫 API 的 Service Principal，使用以下 Azure CLI 指令：
指令在建立時會順便指派權限給 Service Principal，以這邊為例，我們將 Service Principal 指派在資源群組範圍 "/subscriptions/<SUBSCRIPTION-ID>/resourceGroups/charlie-test" 上的 Reader。
建立成功後會得到以下回應：
其中 appId、password 與 tenant 會在下一步中使用，記得要先記錄下來。
另外在 Portal 中的 Microsoft Entra ID 也可以搜尋得到建立完成的 Service Principal。
取得 Access Token
在上一步中我們得到了類似密碼或 Key 的 password，但這並不能直接作為呼叫 API 的驗證，我們必須要先用這個 password 來換取 Access Token。
至於為什麼需要多這一步驟，就與最一開始提到 OAuth 2.0 的 Client Credentials 有關，我們將理論的部分留給有興趣的讀者，現在我們只要把他當成固定流程就好。
取得 Access Token 的方式是一個 HTTP Post，以下我們選擇可以直接在 Azure Cloud Shell 中執行的 curl 指令作為範例。
其中 <TENANT-ID>、<APP-ID> 與 <PASSWORD> 使用上一步紀錄下來的資訊填入即可。
執行成功後會得到以下類似回應：
其中的 access_token 就可以作為呼叫 API 的驗證了。
呼叫 API
我們使用資源群組的 List API 作為範例，規格文件請查看以下連結。
不要忘記將 <ACCESS-TOKEN> 替換為上一步得到的 access_token。
執行成功後會得到以下類似回應：
因為在最一開始建立 Service Principal 時，我們只賦予了 charlie-test 這個資源群組的 Reader 權限，所以這個範例只列出一個資源群組是正確的👍
總結
使用 Service Principal 搭配 Client Credentials 適合使用在不需要用戶交互的應用程式中，算是 OAuth 2.0 中相對簡單的流程，像我自己就常使用在一些背景執行的監控管理排程上。
另外本篇文章也盡量去除掉理論，只留下實作流程，也推薦給只想快速測一下 API 的讀者 😄
留言
張貼留言