距離上篇在 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 這麼簡單，先前在回應遇到...
在這個年代，靠這行吃飯的勢必都需要學幾項 IaC 工具，最近遇到的專案剛好有機會可以練習，考量到公司內部幾乎是純 Azure 的環境，就直接選擇 Azure 專用的 Bicep 了，趁這次也將過程記錄下來。
本文不打算深入探討 Bicep 的語法細節，因為這些都可以在官方文檔中找到，反之，重點會放在如何利用 VSCode 上的 Bicep 擴充模組來簡化開發，所有工具將打包在 Devcontainer 中搭配 GitHub Codespaces 搭建乾淨的開發環境，整合 GitHub Action 在每次推送時建構 ARM 模板，最終會生成一個美觀又功能強大的一鍵佈署按鈕：Deploy to Azure。
以上這些已經在我的 GitHub 上整理成一個範例，歡迎使用以下連結。
相關連結：https://github.com/charliewei0716/azure-bicep-codespaces-sample
系列文章
開啟 GitHub Codespaces
使用 GitHub Codespaces 的方式非常簡單，先進到下方 GitHub 連結，在登入 GitHub 後點擊 README.md 中的「Open in GitHub Codespaces 」。
相關連結：https://github.com/charliewei0716/python-fastapi-azure-cosmos-db-todo-list
 |
| Open in GitHub Codespaces |
進入 Codespaces 時不用做任何動作，它會在啟動時自動安裝 Bicep 擴充模組與 Azure CLI 工具，直到在瀏覽器中看到 VSCode 的畫面就代表成功。
使用 Bicep 擴充模組開發
VSCode 上的 Bicep 擴充模組是官方在開發 Bicep 的首推工具，同時也已經安裝在我們剛剛開啟的 Codespaces 中了。
首先我們試著定義一個儲存體帳戶，但我們不打算背一堆 Bicep 寫法，或是又要跳到哪篇文檔中複製出來修改，現在只需要要輸入代表儲存體帳戶的前幾碼英文字母「sto」，就能從清單中看到 「res-storage」。
接著按下「TAB」或「ENTER」就能直接套用模板，現在 VSCode 中應該會包含以下這些程式碼：
如果是以這種方式產生的模板，它將會自動包含所有必要參數，終於不會再東缺西漏了。
接著我們想要定義兩個參數 storageAccountName 與 storageAccountLocation，分別代表儲存體帳戶的名稱與位置，一樣使用工具來做，這次輸入「par」並選擇清單中的「param-defaults」。
稍加修改後，我們讓儲存體帳戶來參考這兩個變數。
如果有建立過儲存體帳戶，應該就會知道帳戶名稱是有長度限制的，為了預防到時候在佈署時有異常，我們希望在參數這邊就加上限制，還是一樣的方式，這次輸入「@」並選擇清單中的「minLength」與「maxLength」。
我們完成的程式碼最終如下：
最後我們可以點擊右上角來查看所有資源的視覺化呈現。
當專案中使用到多個資源時，我們就能明確看出資源間的關聯性，算是一個挺酷的功能。
佈署 Bicep
我們的 Codespaces 中已經安裝了 Azure CLI 工具，所以可以直接使用以下 az 指令：
接著回到 Portal，就能看到佈署好的儲存體帳戶了。
「Deploy to Azure」按鈕
如果常逛 GitHub 上的 Azure 架構，應該都對這個藍色按鈕不陌生，在分享架構上還蠻方便的，讓人真的有一鍵佈署的感覺。
實際上「Deploy to Azure」按鈕只支援 ARM 模板，並不直接支援 Bicep 檔案。幸運的是我們能透過以下這個指令快速的從 Bicep 檔案生成 ARM 模板：
但感覺好像又不是那麼的自動...😢
所以延伸這個做法，我們可以在每次推送新的 Bicep 檔案時，在 CICD 中執行這個指令，如此一來，就能每次都根據最新的 Bicep 檔案生成 ARM 模板。以下直接提供 YAML：
相關連結：https://github.com/charliewei0716/azure-bicep-codespaces-sample/blob/main/.github/workflows/ARM.yml
最終，我們完成了一個一鍵佈署按鈕，並且確保按鈕背後指向的 ARM 模板與 GitHub 中的 Bicep 檔案始終保持一致。
總結
對我來說，學習一項新工具或新語言這件事本身並不難，麻煩的始終都是開發環境與實際走過一次完整流程，藉這次機會把這些整理到 GitHub 上，希望未來在開發 Bicep 上都能輕鬆點😀
相關連結：https://github.com/charliewei0716/azure-bicep-codespaces-sample
留言
張貼留言