别再白白烧掉您的 AI 预算了：借助工作流导航优化 GPU 使用和模型部署

Uber 在 4 月份就已耗尽 2026 年全年的 AI 工具预算。微软也面临类似危机，由于 Claude Code 表现过于出色、使用过于频繁，他们不得不收回该工具的使用许可。就连 OpenAI 首席执行官（CEO）Sam Altman 也表示，词元成本对企业及其客户而言是“一个巨大的问题”。“Tokenmaxxing”（词元刷满）——即在与业务成果没有明确关联的情况下迅速耗尽词元的现象——已经从内部玩笑演变成了董事会层面的难题。

各企业通过限制外部 AI 预算和收回使用许可来应对这一问题。这无可厚非。但当团队试图通过在自有基础架构上部署模型来规避不断攀升的成本时，他们不过是将按量计费替换成了一种新的隐性开销：基础架构资源浪费。没有人对第二个成本问题加以限制，因为大多数企业组织甚至不知道该如何衡量它。

从词元消耗到基础架构资源浪费

有一点很容易被忽视。过去一年里，单个词元的成本下降了多达 80%。这听起来是好消息，也确实如此，直到您发现总支出不降反升。在代理式工作流中，AI 会循环执行规划、工具调用、验证和纠错，词元消耗速度远超基于聊天的交互方式。根据德勤《2026 年 TMT 预测》报告，推理工作负载目前约占所有 AI 计算量的三分之二，而 2023 年这一比例仅为三分之一左右。词元价格下降并没有让 AI 成本降低，反而让人更容易花更多的钱。

有人选择了一个模型。通常是上个月排行榜上排名第一的模型，或是同事在 Slack 上分享的模型。团队将该模型部署到图形处理单元（GPU）上。模型配置只是凭经验做出的最佳猜测，因为没人有时间对多种不同配置进行基准测试。自动扩展这个环节，要么过于激进，要么过于保守，要么根本未设置。量化设置则直接沿用了最近看到的教程或博客文章中的配置。

然后，GPU 就会开始运行，但效率通常不高。模型可能比任务实际需要的要大得多，或者硬件可能未得到充分利用，因为部署时是按照峰值流量来配置的，而峰值流量从未出现。

这就是基础架构资源浪费。它不像 API 账单那样会明确列在账单中，但只要这些 GPU 为了运行该模型而部署，无论利用率如何，每天都会产生费用。这是部署自托管模型的企业组织中普遍存在的一种模式。

自托管部署的问题出在哪里

大多数浪费源于两个决策。

选错模型

市面上有数千种开放权重模型。默认做法是选择那个规模最大、知名度最高的模型。但对于您的特定任务而言，规模越大并不一定意味着越好。关于模型路由的早期研究（例如 RouteLLM 框架）表明，将任务分配给适当大小的模型——使用较小的模型进行信息提取和分类，并保留较大的模型进行复杂推理——这样可以在保持大部分输出质量的同时，降低总支出。但大多数团队从未进行过此类对比。可能需要花费数天时间来查阅排行榜、基准测试报告和硬件规格表，而且结果每月都在变化。

凭猜测进行部署

一旦选择了模型，就必须有人配置服务运行时、GPU 分配、量化级别和自动扩展参数。如果没有特定于自身硬件和流量模式的性能数据，即便是参考配置也只能靠猜测来调整。配置设得过高会浪费计算资源，而配置设得太低又会造成延迟问题。无论哪种情况，团队都要付出代价——要么是浪费预算，要么是糟糕的用户体验。

真正懂得如何正确做出这两项决策的人实属罕见。大多数团队中都缺少只要看一眼模型、硬件配置文件和流量模式就能给出正确答案的人。

借助工作流导航消除部署时的不确定性

我们专门针对这种情况构建了工作流导航工具。工作流导航是红帽 OpenShift AI 中的自然语言辅助工具，能够捕捉用户意图并将其转化为可执行的工作流。

您只需告诉它您要构建什么。例如：“我需要一个用于检索增强生成应用的模型，支持 20 个并发用户，延迟低于 1.5 秒。”工作流导航会查看您的模型注册表，检查集群中的 GPU 硬件配置，提取与您的用例相关的基准测试数据，并返回按优先级排序的选项。

在模型选择方面，工作流导航会根据您的实际硬件容量进行筛选，并依据对您的任务至关重要的基准测试指标进行排序。假设您的团队需要一个编码助手。人们本能地会部署一个包含 700 亿参数的模型，因为它在排行榜上名列前茅。工作流导航的规划器经过测算后显示：在两个 GPU 上运行的包含 320 亿参数的模型，既能满足您的延迟目标，在代码基准测试中的得分也与包含 700 亿参数的模型相当；而包含 700 亿参数的模型要完成同样的作业，则需要四个 GPU。这意味着只需一半的硬件资源即可获得相当的效果。工作流导航会在您将大量 GPU 时间和算力浪费在错误模型之前，向您展示这一对比结果。

在部署方面，工作流导航会为您选择的模型生成可直接投入生产的 Kubernetes 配置。其容量规划器会估算不同量化级别和张量并行配置下的 GPU 内存需求，随后 GPU 推荐器会在无需实际运行基准测试的情况下，比较不同硬件的性能表现。

部署聊天模型的团队可能会发现，采用 8 位浮点（FP8）量化的 L40 显卡，延迟可控制在服务级别目标（SLO）范围内，而成本仅为运行相同模型且采用 16 位浮点（FP16）量化的 A100 显卡的一小部分。工作流导航会生成 KServe InferenceService YAML、资源请求、自动扩展规则和可观测性配置，所有这些配置均是根据集群实际拥有的资源来确定。您可以权衡利弊，并根据自身关注点（无论是成本还是性能）选择合适的配置。

解决基础架构资源浪费问题，而不仅仅是 API 账单问题

关于 AI 成本的讨论，几乎完全集中在账单中的 API 部分。这是一个切实存在的问题，而 Uber 和微软着手应对这个问题是对的。但是，没有人以同样的紧迫感来谈论基础架构方面的问题。您的模型在真实的 GPU 上运行，实实在在地消耗着电力，但部署时所用的配置却从未针对工作负载进行过测试。这种浪费更难被察觉，因此也无法得到解决。

如果您基于信誉而非适用性来选择模型，并使用默认配置而非经过测试的配置进行部署，则成本差异可能会非常显著。

工作流导航工具并非试图解决 API 成本问题，而是直指基础架构成本问题。当您在自有硬件或 OpenShift AI 上的云上部署模型时，工作流导航可帮助您部署合适的模型，并根据您的使用方式进行配置。

试用

工作流导航现已作为 OpenShift AI 的一部分，以开发者预览版的形式提供。它使用模型上下文协议（MCP），因此可以与 Claude Code、Cursor、Gemini CLI 或您的团队偏好的任何兼容 MCP 的客户端配合使用。

工作流导航由两个开源项目构建而成。rhoai-mcp 服务器提供了 90 多种工具，用于以编程方式管理 OpenShift AI 环境，涵盖从项目设置和工作台管理到模型部署和管道配置等各个方面。llm-d 规划器负责处理智能层、对话式需求收集、SLO 驱动的容量规划、GPU 内存估算，以及多标准部署排序，将“我需要一个用于 X 的模型”这样一句话变成一次正在运行且经过优化的部署。

如果您的团队在挑选模型和调整部署方面花费了过多时间，不妨试一试。我们正在公开构建此工具，非常期待收到您的反馈。

或者，您也可以进一步了解红帽 OpenShift AI。