Gartner 预测，到 2026 年，全球终端用户在 AI 模型与平台上的支出将达到约 640.52 亿美元，较此前一年增长 63.4%。其中，生成式 AI 模型支出预计增长 117%，AI 平台支出则预计增长 36.9%。这些数字说明，企业关注的重点正从“要不要使用 AI”转向“应该购买哪些能力，以及如何持续运营”。
模型增长更快，不代表预算只该投给模型
生成式 AI 模型支出增长 117%，反映出企业对推理、内容生成、代码辅助和智能代理等能力的需求迅速上升。但在真实项目里，模型通常只是整个系统的一部分。
一项可上线的 AI 服务还需要数据接入、权限控制、向量检索、提示词管理、内容审核、调用监控和成本核算。模型费用甚至可能不是最大的支出项：如果企业需要清洗大量内部文档、建设评测集，或者为敏感业务部署隔离环境，平台与工程成本会快速上升。
因此，预算不宜只写成一项笼统的“AI 采购费”。可以按以下对象拆分：
- 模型消费：API token、图像生成、嵌入模型、微调和专用推理实例。
- 平台能力：模型网关、知识库、代理编排、评测、可观测性与安全策略。
- 数据工程：数据清洗、权限同步、索引更新和质量检查。
- 应用交付：业务系统集成、人工复核界面、故障降级和用户支持。
- 风险治理：隐私审查、红队测试、审计记录与供应商退出方案。
这样的分类能回答一个关键问题：成本增长究竟来自业务使用量，还是来自平台复杂度。
平台支出增长，意味着企业开始建设长期能力
AI 平台支出预计增长 36.9%。虽然速度低于生成式 AI 模型，但它往往对应更长期的基础设施投入。
当团队从一个模型扩展到多个供应商时，直接在每个业务应用中调用厂商 API 会形成重复代码。模型名称、鉴权方式、限流规则和错误格式各不相同，迁移时还要逐个修改应用。统一模型网关可以把这些差异收敛到平台层，并集中记录调用量、延迟、失败率和业务归属。
不过，平台建设也容易走向另一个极端：业务尚未稳定，就提前开发庞大的内部 AI 中台。更稳妥的边界是，只有当某项能力被多个项目重复需要时，才将其提升为共享平台能力。例如统一鉴权、成本标签和审计日志通常值得共建，而高度依赖单一业务的提示词流程未必适合过早抽象。
可以这样实践：用配置和脚本建立预算护栏
下面是一个最小化的预算检查示例。它不是 Gartner 提供的工具，而是一种可以改造的内部实践：团队在 YAML 中登记各 AI 项目的模型、平台和工程预算，再由脚本检查总额及模型支出占比。
先创建 ai-budget.yaml，将金额和项目名称替换为企业自己的数据：
currency: USD
annual_budget: 500000
max_model_share: 0.55
projects:
- name: customer-support-copilot
owner: service-team
model: 90000
platform: 45000
data: 30000
delivery: 25000
governance: 10000
- name: developer-assistant
owner: engineering
model: 70000
platform: 35000
data: 15000
delivery: 20000
governance: 8000
安装依赖并创建 check_budget.py：
python -m pip install pyyaml
from pathlib import Path
import sys
import yaml
CATEGORIES = ("model", "platform", "data", "delivery", "governance")
config = yaml.safe_load(Path("ai-budget.yaml").read_text(encoding="utf-8"))
projects = config.get("projects", [])
annual_budget = float(config["annual_budget"])
max_model_share = float(config["max_model_share"])
totals = {category: 0.0 for category in CATEGORIES}
for project in projects:
for category in CATEGORIES:
totals[category] += float(project.get(category, 0))
total_spend = sum(totals.values())
model_share = totals["model"] / total_spend if total_spend else 0
print(f"Planned spend: {total_spend:,.2f} {config['currency']}")
for category, amount in totals.items():
print(f" {category:10s} {amount:,.2f}")
print(f"Model share: {model_share:.1%}")
errors = []
if total_spend > annual_budget:
errors.append(f"budget exceeded by {total_spend - annual_budget:,.2f}")
if model_share > max_model_share:
errors.append(
f"model share {model_share:.1%} exceeds limit {max_model_share:.1%}"
)
if errors:
for error in errors:
print(f"ERROR: {error}", file=sys.stderr)
raise SystemExit(1)
运行检查：
python check_budget.py
在 CI 中执行这个脚本，可以阻止未经审批的预算变更。真实环境还应补充月度调用上限、项目成本中心、数据敏感级别和供应商合同期限。max_model_share 并不存在适用于所有企业的标准值，应根据应用类型、平台成熟度和自建基础设施成本设定。
不只看 token 单价，还要看单位业务产出
模型单价很容易比较，但单价最低的模型不一定带来最低的业务成本。一个准确率不足的模型可能触发更多人工复核；上下文窗口较大的模型可能减少检索流程，却增加每次请求的 token 消耗；自建模型能够降低部分调用费用，但会引入 GPU 利用率、升级和运维成本。
企业可以为每类应用设置更贴近业务的指标：
- 客服助手：每个成功解决工单的 AI 成本、转人工率、错误答复率。
- 开发助手：每个被接受建议的成本、代码审查缺陷率、开发周期变化。
- 文档处理：每份合格文档的处理成本、字段准确率、人工校正时间。
- 智能代理：每个完成任务的成本、工具调用失败率、越权操作次数。
这些指标应与 token、延迟和错误率同时记录。否则，财务部门只能看到模型账单上升，却无法判断增长是否换来了可验证的产出。
采用建议：把高速增长转化为可撤回的决策
面对快速扩张的市场，企业不必一次性锁定单一模型或建设完整平台。更可控的做法是按季度推进：先选择有明确业务指标的场景，设置模型与平台预算上限，再通过网关保留供应商切换能力。
采购和架构评审时，可以检查以下事项：
- 模型、平台、数据和交付费用是否分别核算。
- 每个项目是否定义了单位业务产出的成本指标。
- 敏感数据是否有明确的传输、保留和删除规则。
- 模型升级后是否运行固定评测集与安全测试。
- 供应商涨价、限流或停止服务时是否可以降级或迁移。
- 平台团队是否只建设已经被多个项目验证的共享能力。
640.52 亿美元的预测展现了市场规模，但企业真正需要管理的是自己的单位经济性。模型能力会继续变化，能够持续测量成本、质量与风险的平台和流程，才是更耐用的投入。