OpenCost 1.121.0：Kubernetes 首度能算出每百萬 token 的 GPU 成本
cncf.io · 2026-08-05
背景
Kubernetes 上的 GPU 成本過去只能用「每小時多少錢」粗略估算，無法回答「這個模型的每次推論實際花了多少錢」。OpenCost（CNCF 沙盒下的 Kubernetes 成本監控專案）在 1.121.0 版加入針對 LLM 推論的 token 層級成本追蹤，是目前開源生態中首個做到這件事的工具。此版本與 CNCF 沙盒專案 llm-d 以及 vLLM 整合，直接消費推論伺服器暴露的指標。
核心改動
OpenCost 讀取 vLLM 的 vllm:prompt_tokens_total 與 vllm:generation_tokens_total 兩個計數器，分別對應輸入與輸出 token 數量，並各自套用不同的單位成本換算。新增的兩個 Prometheus 指標是 llm_total_hourly_cost（每個模型每小時總成本）與 llm_cost_per_million_tokens（每百萬 token 成本），後者帶有 model、version、namespace、cost basis、workload type 等標籤，可依模型或命名空間拆分帳單。
成本計算採用兩種互補基準：allocation-based 計入 GPU 閒置時間，回答「這個模型佔用了我們多少資源」；usage-based 只計實際運算中的時間，回答「這次推論實際花了多少錢」。兩者相除即得到使用率，可用來抓出過度佈建的模型部署：
utilization = usage_based_cost_per_million_tokens
/ allocation_based_cost_per_million_tokens影響範圍
此追蹤機制涵蓋 llm-d 架構中的多個元件，包括 Inference Scheduler（EPP）閘道、llm-d 的 gateway proxy、KV cache 儲存層（分層部署下可達 18TB），以及負責自動調度副本數的 Workload Variant Autoscaler。概念驗證已在一個擁有 109 顆 GPU、同時運行 30 個 AI 模型的叢集上完成測試，驗證了指標在多模型混部場景下的可用性。
HCP Terraform 把自己定位為 AI Agent 佈建基礎設施的控制平面
hashicorp.com · 2026-08-05
核心改動
HCP Terraform 在文章中被定位為 AI agent 產生並套用基礎設施設定時的中介控制層，而非讓 agent 直接持有雲端憑證。文章拆成五層防線：來源（provenance）、政策（policy）、身分（identity）、隔離（isolation）、稽核（audit）。來源層要求 agent 只能透過 Terraform MCP Server 存取私有 Registry 內的模組與已核准的 Agent Skills，避免 agent 憑空生成未經驗證的設定。
政策層強制在 plan 與 apply 之間插入 policy-as-code 檢查（Sentinel 或 OPA），agent 產生的任何變更都要先過這一關才能套用。身分層則透過 OIDC 動態憑證核發限定專案範圍、單次 run 即回收的雲端憑證，涵蓋 AWS AssumeRoleWithWebIdentity、Azure federated credentials、GCP workload identity pools 與 Vault JWT/OIDC 四種後端，agent 手上不再有長期存在的 access key。
影響範圍
隔離層讓一個 workspace 對應一個 agent、一個專案圈住一組資源的異動半徑；稽核層則把每次 run 的 plan、政策判定結果與核准紀錄都保留在 run history 中作為證據鏈。Terraform MCP Server 已在 GitHub 開源，官方 Docker image 為 hashicorp/terraform-mcp-server:1.2.0，除了直連 Public Registry 的 provider／module 查詢工具外，也支援 HCP Terraform/Enterprise 的 workspace 建立與管理，可用 stdio 或 streamable-HTTP 兩種傳輸模式接進 Claude Code、Cursor、VS Code Copilot 等常見 agent 用戶端。
Docker：治理若做成審批流程，開發者就會繞道而行
docker.com · 2026-08-05
核心改動
這是 Docker「AI agent 治理」系列第三篇，主張把治理做成平台內建能力，而不是要開發者每次手動申請核准的關卡。對應的產品是 Docker AI Governance，整體架構分成三層防護。
第一層是 Sandbox 政策，針對 agent 執行環境設定網路與檔案系統規則：網路規則依網域、IP 或 CIDR 允許或封鎖對外連線，檔案系統規則決定掛載點是唯讀還是可寫，實際隔離執行靠的是 Docker Sandboxes 的 microVM。第二層是 MCP 工具治理，預設封鎖所有 MCP server，須由管理員在後台逐一核准後才能使用，同一套政策引擎會攔截每一次 MCP 呼叫，也能依團隊分別授權可用的 server 範圍。
第三層是稽核機制：每次政策判定都會產生包含使用者身分、時間戳、session context 與觸發規則的結構化事件，原生串流輸出到 Splunk、Datadog、Grafana 等 SIEM 工具，並集中彙整在 Docker Cloud 供搜尋，不需手動匯出紀錄。
影響範圍
政策的下發路徑是：管理後台設定規則，透過既有 SAML/SCIM IdP，在開發者登入時自動套用到本機 Docker Desktop，最後由 proxy 與 mount 層實際執行，不需要逐台機器手動設定。這個模型對應三種角色的需求：CISO 要的是可稽核與集中核准、平台團隊要的是設定一次全公司套用、開發者則保留在受控邊界內自主操作 agent 的空間。