私有 AI 成本：衡量被接受的任務，而不僅是代幣

MLPerf 根據測試條件和質量要求區分推理工作負載。[1] 私有 AI 的購買決策也需同樣嚴謹：在比較成本前先定義什麼算是有用的工作。我們的立場是，每個被接受任務的成本比單純的代幣價格更能反映試點成效。

這個衡量方法很直接。將分配給試點的成本（包括審核和修正）相加，然後除以通過約定接受檢查的輸出數量。這是建議的評估方法，並非 Software Tailor 客戶已實現的節省聲明。

命名完成的工作

文件摘要並非模型產生段落即算完成。試點團隊可能要求摘要明確決策、保留所有截止日期，並提供返回相關原文段落的路徑。錯過截止日期的輸出需修正後才算被接受。

在測試前寫下這些條件。使用一小組允許的文件，涵蓋不同長度和版面。包含一個棘手範例：掃描頁面、日期衝突或依賴腳註解釋的表格。每個候選配置保持相同輸入集，避免工作變化被誤認為模型改進。

我們的 AI PDF Reader 是文件工作流程的一個可能起點。評估仍應同時考量實際來源與答案。引用的存在有助於審核，但其存在本身並非接受決定。

記錄被拒絕的輸出與被接受的輸出。否則報告只描述最佳案例，而團隊卻為整個隊列付費。

對於本地部署，分攤設備成本於指定評估期間。若有顯著，加入測量的電力成本、適用於所選配置的軟件費用，以及設置或維護服務所花時間。結果旁標明假設。現有有閒置容量的工作站與新購專用伺服器屬不同採購情況。

對於託管模型，記錄試點實際請求的費用，包括重試。也計入本地情況中的相同審核與整合工作。對一方使用完整成本模型，另一方用狹隘模型，會導致無法支持決策的比較。

審核時間需明確估價。合理報告經過分鐘數及估計勞動成本，前提是標明估計。除非組織有可信方式實現，否則不要將員工回收的分鐘數當作現金節省。任務縮短即使不改變薪資，也有價值。

將例外設置工作與經常性運營分開。團隊才能判斷令人失望的第一週是安裝工作所致，還是工作流程持續存在問題。

Hugging Face 的模型卡格式支援關於預期用途、限制及評估的資訊。[2] 將該文件視為候選記錄的起點。加入所用的精確模型版本、本地檔案或變體、運行時版本，以及執行測試的機器。僅有模型名稱不足以重現購買評估。

同樣原則適用於效能證據。MLCommons 描述基準測試結果與提交系統及軟件的關係，並區分比較範疇。[1] 已發佈的基準測試可協助構建問題框架，但不會提供未測試辦公工作流程的測量結果。

分別測試冷啟動及已運行服務。記錄達到有用回應的時間及完成時間。如兩人將共同使用系統，應測試該情況，而非從單一請求推斷。這些是試點設計選擇，並非聲稱每次部署均有相同瓶頸。

「 AI Server 產品頁面」描述了共享推理的伺服器路由。當共享服務適合擬議工作時，請使用該路由；切勿僅為使試點類似未來全組織部署而新增伺服器。

最終記錄應顯示輸入集、接受規則、接受數量、審核時間及成本假設。包含最具影響力的失敗案例，並適當編輯其來源資料。審核者應能理解團隊為何偏好某配置，而無需依賴作者的熱忱。

若質量不可接受，廉價結果無法挽救。若質量可接受但運營工作量過大，請縮小工作流程或更改配置，並重新執行相同測試。我們的配套文章「關於關鍵基礎設施中私有 AI 的證據」將此習慣應用於不同的決策界限。

從 Software Tailor 產品目錄中選擇一項可用任務，定義其接受檢查，並保持首份成本表足夠小以便審核。有效數字是可用工作的成本。