距離上篇在 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 這麼簡單，先前在回應遇到...
平常搭配 CICD 使用的 ACR 在缺乏管理的情況下，非常容易變成一個燒錢的大型回收桶，除了不斷疊代產生的大量舊版 image 外，最容易被忽略的就是沒有上 Tag 的孤兒 Manifest。
本篇將透過一個簡單的實驗來了解在 ACR 上 Manifest 與 Tag 的關係，並說明如何移除這些無用的 Manifest 以降低 ACR 的儲存成本。
系列文章
建立 ACR
首先我們需要先建立一個測試用的 ACR ，如果在 Portal 中用中文搜尋的話，記得要輸入「容器登錄」，翻譯成中文就覺得好怪 😕
建立時在價格方案選擇最低的「基本」，其他設定保持預設值，直接建立就可以了。
 |
| 建立容器登錄 |
第一個 Image
再來我們要在建立好的 ACR 中放入第一個 image，先使用以下指令建立 Dockerfile：
使用 az acr build 指令對 Dockerfile 建構並推送 image 到 ACR 中。
接著我們介紹以下兩個指令，第一個 az acr show-usage 可以確認整個 ACR 中的使用量。
輸出結果如下：
可以看到我們剛剛推送的 hello-world image 佔用了 3564 Bytes 的儲存體，而 value[0].limit 顯示的 10737418240 Bytes 也就是 10 GB 即是 ACR 基本 SKU 內包含的儲存體，超過這個量就會有額外的儲存體費用。
因為 ACR 的成本在一般的使用情況下就是看儲存體的使用量，但 Portal 只會顯示一個很概略的值，所以這個指令我還蠻常使用的。
而第二個 az acr manifest list-metadata 指令可以看到各別儲存庫的使用情況。
輸出結果如下：
這兩個指令在後續會重複出現，可以先記下來備用。
回到 ACR，我們應該可以看到如下畫面：
我們可以看到推送上來的 hello-world image 帶有 v1 的 tag 與一個 SHA 值，同時右上角顯示了標籤 (Tag) 計數與資訊清單 (Manifest) 計數，接著我們就要來了解他們之間的關係。
Tag & Manifest
Tag 與 Manifest 之間會存在以下三種關係。
一對一對應
Tag 與 Manifest 兩兩對應是最普遍的情況，目前我們的 hello-world image 也是這個狀態，在這個情況下沒有任何需要注意的地方，一切都很完美。
多個 Tag 對應到相同 Manifest
這種情況常出現在對程式做了一些與 image 無關的更動後，又在推送時自動觸發了 CICD，導致兩次產生了相同的 image 並標上了不同的 Tag。
我們可以透過再次執行 az acr build 指令模擬這種狀態：
回到 Portal 確認多個 Tag 對應到了相同 Manifest。
接著我們使用剛剛提到的兩個指令看一下儲存庫現在的狀況，首先使用 az acr manifest list-metadata：
輸出結果如下：
這邊可以看到與第一次推送時相同的 SHA 值與相同的 image 大小，但不同的是這次有兩個 Tag 同時引用了這個 image。這樣到底是存了幾份呢？我們用下一個指令確認：
輸出結果如下：
一樣的 3564 Bytes，所以這種情況雖然沒有一對一對應來的單純，但至少在 ACR 中不會重複保存兩份 image，因為我們最關心的肯定就是 💲💲
現在我們先使用指令移除 v2 tag 的引用，再繼續第三種情況。
相同 Tag 對應到多個 Manifest
最後一種就是最麻煩的情況了，一樣很常會出現在 CICD 的情境，因為就是有人會習慣一直使用 latest 做為 Tag 來不斷更新 image。
我們可以透過以下步驟來重現這個狀態，首先先對 Dockerfile 做出一些會動到 image 的更動：
現在 Dockerfile 會如下：
接著再次執行 az acr build，記得我們要繼續使用 v1 這個 Tag。
這時確認 Portal 畫面：
我們成功更改了 SHA 值並做出了 1 個標籤計數與 2 個資訊清單計數，但卻只有一筆紀錄？沒關係，一樣的方式我們先來確認一下狀態。
輸出結果如下：
使用指令可以正常看到兩筆紀錄，而舊的 SHA 值沒有 Tag 的引用所以顯示了 null，但 2459 Bytes 顯示了兩次肯定不是件好事。
輸出結果如下：
正如我們想的，ACR 的使用量提高到了 5686 Bytes，而最糟糕是這種情況居然不會顯示在 Portal 上 😫
清除孤兒 Manifest
直接使用以下指令就可以清除儲存庫中沒有被 Tag 引用的孤兒 Manifest 了。
最後回到 Portal 確認標籤計數與資訊清單計數都是 1。
總結
到此我們弄清楚了 Manifest 與 Tag 的關係，而在相同 Tag 對應到多個 Manifest 的情況下相當於儲存了多份 image 在 ACR 內，這些舊的 image 高機率就會變成不再使用的垃圾，而且你在 Portal 上不會看到這些 image 😠
留言
張貼留言