共享推論成本研究公開 H100 測試，計量方式改變租戶分攤比例

獨立研究者 Timothy Urista 於 9 月 21 日提交研究，檢視多租戶推論服務如何分攤 GPU 與模型 API 支出。論文搭配開源工具 unalloc，把 Kubernetes 資源費用、模型閘道紀錄及供應商帳單接到同一份帳本；核心發現是，帳目即使加總正確，成本歸屬仍會隨計量規則與標籤處理大幅改變。[論文摘要](https://arxiv.org/abs/2609.24991)

工具將 OpenCost、LiteLLM 等來源轉成統一的 `CostRow`，金額使用十進位數值，並正規化不同系統的團隊、專案與成本中心欄位。報表除了列出無法歸屬的金額，也把依備援欄位分配的支出單獨標示，避免「找到任意名稱」就被誤認為找到負責團隊。[公開儲存庫](https://github.com/timurista/unalloc)

研究的硬體驗證使用單張 H100 80GB、vLLM 0.29.0 與 BF16 的 Qwen2.5-7B-Instruct，開啟前綴快取，重播合成多租戶流量。四種負載各執行兩分鐘；按 token 數分攤時，檢索型租戶占總費用 16.5%–18.9%，若每 50 毫秒把時間平均分給尚未完成的請求，占比則為 4.7%–5.3%，差距約 12–14 個百分點。[實驗方法與結果](https://arxiv.org/pdf/2609.24991)

這類差異涉及成本定義。OpenCost 今年七月的技術文件已區分兩種口徑：配置成本包含讓模型隨時可用的預留資源與共用設施；使用成本只計實際推論消耗，並考慮快取命中。兩者之差可能來自維持低延遲所需的閒置容量，不能只靠 token 單價判斷部署效率。[OpenCost 成本模型](https://opencost.io/blog/opencost-llmd-inference-cost/)

帳本整合也有獨立陷阱：儲存庫提醒，同時讀取閘道與供應商支出，可能把同一筆模型呼叫計算兩次，必須明確選定來源。它提供發票對帳、依金額排序的缺漏標籤清單，以及可接入持續整合流程的未歸屬比例門檻；這些機制能把分攤規則變成可檢查的工程流程。[工具使用與資料路徑](https://github.com/timurista/unalloc)

兩種分攤算法都不是成本的唯一正解，時間均分本身也是近似規則。硬體證據限於單一模型、單張 GPU，以及每個負載的一次短測，沒有跨次重跑的不確定性估計。據此，工程團隊仍須用自身的提示長度、快取命中與多輪流量重測，再決定內部分攤政策。[論文限制與重現說明](https://arxiv.org/pdf/2609.24991)