OpenCost 1.121.0：首创的Kubernetes推理成本追踪
内容提要
OpenCost与llm-d集成，为Kubernetes上的LLM推理提供成本可见性。通过vLLM指标计算每模型和每token成本，区分分配成本（含闲置GPU）与使用成本（仅活跃推理），帮助平台团队评估自建与SaaS成本、优化GPU利用率。支持按命名空间和团队计费，已发布OpenCost 1.121.0。
延伸解读
两种成本指标，避免决策陷阱
文章强调，平台团队需要区分“分配成本”和“使用成本”。分配成本包含闲置GPU和基础设施开销，反映模型“可用”的真实代价；使用成本仅计算活跃推理，适合对比模型效率。若误用使用成本做自建与SaaS的对比，可能低估实际支出。例如，25%利用率下，使用成本$1/百万token，但分配成本高达$4，此时外部API $2反而更划算。理解两者差异，才能做出明智的构建或购买决策。
利用率是成本优化的关键杠杆
文章指出，分配成本与使用成本的比值直接反映GPU利用率。低利用率模型（如95%时间空闲）会推高分配成本，因为固定开销分摊到少量token上。通过智能路由、模型共享或流量整合提升利用率，可降低每token分配成本，使自建更具竞争力。例如，利用率从25%提升至50%以上，自建成本可能低于外部API。这为平台团队提供了明确的优化目标。
成本矩阵：四象限诊断模型健康
文章提出用分配成本与使用成本的组合诊断模型状态：高分配+低使用意味着利用率问题，可考虑整合流量；高分配+高使用则需评估模型选型；低分配+低使用表示部署合理；低分配+高使用提示模型或硬件不匹配。这种矩阵帮助团队快速定位成本异常，并指导优化方向，如调整模型大小、量化或硬件配置。
Q&A
OpenCost 1.121.0 新增了哪些功能？
OpenCost 1.121.0 新增了 Kubernetes 上 LLM 推理成本追踪功能，通过与 llm-d 集成，利用 vLLM 指标计算每模型和每 token 成本，区分分配成本（含闲置 GPU）与使用成本（仅活跃推理），并支持按命名空间和团队计费。
OpenCost 如何计算 LLM 推理成本？
OpenCost 通过集成 llm-d，从 vLLM 获取 token 吞吐量指标（如 prompt_tokens_total 和 generation_tokens_total），结合 OpenCost 现有的 GPU 成本分配引擎，以及处理时间指标，分别计算输入和输出 token 的成本，并考虑 KV 缓存命中带来的节省。
分配成本和使用成本有什么区别？
分配成本（allocation-based cost）包括运行模型的所有成本，如 GPU 内存预留、活跃推理消耗的计算资源，以及共享基础设施（如网关和 KV 缓存存储）的分摊，反映模型可用的成本。使用成本（usage-based cost）仅包括活跃推理期间消耗的 GPU 和其他基础设施成本，并考虑 KV 缓存命中的节省，反映模型实际工作的成本。
如何利用 OpenCost 判断自建 LLM 与使用 SaaS API 哪个更划算？
应使用分配成本（而非使用成本）与外部 API 价格比较。例如，若使用成本为 $1.00/百万 token，但分配成本为 $4.00/百万 token，而 API 价格为 $2.00，则当前利用率下 API 更便宜。自建在利用率约 50% 以上时才具有竞争力。
OpenCost 的推理成本指标包括哪些？
OpenCost 发布的新指标包括 llm_total_hourly_cost（每模型每小时成本）和 llm_cost_per_million_tokens（每百万 token 混合成本），并带有 model_name、model_version、namespace、cost_basis（usage 或 allocation）和 workload_type 等标签。输入和输出 token 成本分开报告。
OpenCost 如何处理 llm-d 的共享基础设施成本？
llm-d 的共享组件（如推理调度器、网关代理、KV 缓存存储、Workload Variant Autoscaler）通过 OpenCost 的 SharedLabels 机制进行成本分摊。这些组件在部署时打上标签，OpenCost 根据共享成本分配逻辑将其归入分配成本，但不计入使用成本。
如何利用成本矩阵诊断模型部署的健康状况？
通过分配成本和使用成本的组合可以诊断：高分配成本低使用成本表示利用率低，应考虑模型共享或流量整合；高分配成本高使用成本表示模型昂贵，需评估是否适合；低分配成本低使用成本表示部署良好；低分配成本高使用成本表示推理成本高，需评估模型大小、量化或硬件。
