距離上篇在 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 DevOps 在 CICD 時提供了由微軟維護的 Microsoft-hosted agents，與自架機器方案的 Self-hosted Agents，前者的環境中有非常完整的套件與其嚴格的生命週期管理，基本上已經滿足了大部分的開發需求；而選擇後者的原因除了可以突破六小時的 Pipeline 超時限制，在有資安要求的企業環境中也能確保在內網執行佈署流程，讓佈署目標僅需要允許少數，甚至不必允許任何外部來源。
在下方的連結中，初步介紹了使用 VMSS 搭建 Self-hosted Agents 的流程，建議有興趣的朋友可以從前篇看起，在文章最後也簡單描述了 Self-hosted Agents 在軟體版本維護上的困難點，所以在本篇中想藉由直接使用 Microsoft-hosted agents 的原始 VM 映像來啟動 VMSS，希望以此來解決在 Self-hosted Agents 上永無止盡的軟體安裝需求。
相關連結：【Azure DevOps】使用 VMSS 建立 Self-hosted Agents 的一些細節
Runner-Images
GitHub Actions runner images 是一個由 GitHub 官方維護的庫，在 GitHub 中執行 CICD 的機器稱為 GitHub-hosted runners，其中使用的 VM 映像就是使用這個庫的腳本建構出來的，當然 Microsoft-hosted agents 的 VM 映像也是由這個庫的腳本產生，兩者只差在一些棄用原則的不同。
值得注意的是官方開源的是 VM 映像的建構腳本，而不是直接公開 VM 映像本身，所以使用上還是沒有這麼便利，主要的原因是映像所涵蓋的上百個軟體中有一些存在授權問題。
準備腳本執行環境
現在我們對於 Self-hosted Agents 已經有了大致的方向，也就是使用 runner-images 上所維護的腳本來建構要使用的 VM 映像，但在這之前我們還需要準備一台用來執行腳本的機器。
最快的方式當然就是直接使用 Azure VM 來搭建腳本執行環境，這個環境並不限於 Linux 或 Windows，所以以下我們在一個獨立的資源群組中，建立了一個規格為 Standard D2ds v5 的 windows 11 機器。
 |
| 建立 Azure VM 做為腳本執行環境 |
再來根據 runner-images 的文檔，我們需要在 VM 中安裝以下五項軟體：
Chocolatey
Windows 的套件管理器，這項不算是必備，但 Chocolatey 可以加快後續的軟體安裝，所以建議還是可以裝一下，在 CMD 中執行以下指令即可：
Packer
整個 runner-images 就是使用 Packer 來打包 VM 映像的，在 Windows 中可以很方便的使用 Chocolatey 來安裝，在 CMD 中執行以下指令：
Git
Git 會用來 clone runner-images，一樣使用 Chocolatey 在 CMD 中執行以下指令：
Powershell
Windows 中已經內建了，我們這邊就直接跳過。
Azure CLI
腳本中包含了 az 指令，所以我們需要預先安裝 Azure CLI，在 Powershell 中執行以下指令：
到此，我們已經準備好了腳本執行的環境，在網路沒有任何限制的情況下，安裝這些也就幾行指令，大約 5 分鐘左右可以完成。
建構 VM 映像
一切準備完成，我們可以開始執行腳本來建構 VM 映像了，新開一個 Powershell 來執行以下 git clone 指令，將 runner-images 的程式碼下載到 VM 中。
接著使用以下指令匯入腳本並開始執行：
開始執行時會需要填入一些基本資訊，如圖與以下說明填入就可以了。
- SubscriptionID：訂用帳戶 ID，可以從 Azure Portal 取得。
- ResourceGroupName：資源群組名稱，用來存放過程中臨時建立的所有資源。
- ImageType：欲建構的 VM 映像類型，runner-images 提供了最簡單的 UbuntuMinimal 方便進行測試，一般情況共有 Windows2019、Windows2022、Ubuntu2004 與 Ubuntu2204 可以選擇。
- AzureLocation：建立相關資源的地區，這邊使用 Sourtheast Asia，根據自己需求選擇就好。
 |
| 開始建構 VM 映像 |
UbuntuMinimal 大於需要 15 分鐘的建構時間， 完成後回到 Azure Portal 中會看到 temp-rg，其中就包括由腳本生成名為 Runner-Image-UbuntuMinimal 的 VM 映像。
 |
| 建構完成 |
使用自定義 VM 映像建立 VMSS
現在我們已經有打包完成的 VM 映像，我們將使用它來做為 VMSS 的基底映像，使用以下 az 指令：
關於指令的一些細節可以參考前一篇文章，連結在下方。
使用 VMSS 建立 Self-hosted Agents
到這邊後的動作就與前一篇文章相同了，如果不知道如何將 VMSS 用在 Self-hosted Agents，可以參考以下連結，這邊就直接跳到測試階段囉！
相關連結：【Azure DevOps】使用 VMSS 建立 Self-hosted Agents 的一些細節
測試
Self-hosted Agents 建立完成後，一個簡單的測試方式，我們將執行一個有安裝在 UbuntuMinimal 但不包含在原生 Ubuntu 20.04 的指令，如果該指令執行成功就代表我們確實使用了 runner-images 建構出的 VM 映像來啟動 VMSS。
我們所選擇的指令是 GitHub CLI，使用 gh -h 來確認是否有安裝成功，而測試的執行方式是如下寫一段 CICD 的 YML 檔，其中指定我們搭建好的 Self-hosted Agents。
完成後就等待 Pipeline 執行了，執行結果如下：
 |
| Pipeline 執行成功 |
GitHub CLI 指令確定有存在於 VMSS 中，成功！
總結
此篇文章中，我們使用由 GitHub 維護的 runner-images 來搭建 Self-hosted Agents，解決掉了煩人的軟體版本維護難題，並且得到了 Self-hosted Agents 的無限執行時間與符合企業資安要求的 CICD 環境，提供給有相同需求的朋友😎
留言
張貼留言