企业官网建设流程全解析

作者：张文浩

随着企业将大模型能力从试点验证逐步接入客服、办公、研发、营销等真实业务场景，AI 调用成本开始从“少量实验费用”变成需要持续治理的运营成本。不同团队、应用或外部客户会以不同频率调用不同模型，而各模型的输入、输出、缓存 Token 单价和计量口径又不完全一致。如果只依赖供应商账单或离线报表进行事后核算，管理员往往只能在成本已经发生后再追查来源，难以及时发现异常消耗、控制预算超支，或为不同消费者建立清晰的使用边界。

在这种背景下，阿里云 AI 网关作为 AI 流量的统一入口，不仅需要完成转发、认证和路由，还需要把成本治理前置到请求链路中：在消费者维度持续计量调用量与消耗强度，并在达到预设阈值时实时拦截请求。这样，平台团队可以在业务上线前明确各消费者的预算上限，在运行过程中阻断突增流量或超额调用，业务团队也可以基于统一口径规划模型使用，避免“先失控、后对账”的被动治理模式。

因此，产品提供消费者配额能力，并支持 Token 与 Credits 两种限额单位、自然周期与自定义周期等配置方式。Token 适合直接控制调用规模，Credits 适合在跨模型场景下归一化衡量消耗强度；配额触达后由网关实时执行硬约束，帮助用户建立“事前定规则、事中控风险、事后可复盘”的 AI FinOps 治理闭环。

本文面向 AI 网关使用者，帮助您建立一套完善的消费者 AI FinOps 治理体系。

整体能力概览

AI 网关 FinOps 能力围绕“消费者配额”展开，核心解决三个问题：

• 问题 1：用什么尺子量？—— 支持 Token 和 Credits 两种限额单位。Token 直观，适合控制调用量；Credits 通过模型单价归一化，适合跨模型对比消耗强度。
• 问题 2：按什么节奏量？—— 支持自然周期（自然日/自然周/自然月）和自定义周期（每 x 天），覆盖不同业务场景的结算节奏。
• 问题 3：量完以后怎么控？—— 消费者在任意一条配额规则达到限额时，网关直接返回绝请求，实现实时硬约束。

前置准备：模型元信息与供应商

如果你计划使用 Credits 维度的配额（而非纯 Token），需要先完成以下准备工作。如果只用 Token 配额，可跳过本节。

2.1 创建供应商

路径：AI 网关实例 > 模型元信息管理 > 供应商 > 创建供应商。

供应商是服务的归属维度。创建时需要填写：

注意事项：

• 标识一旦创建就无法修改，请提前规划好命名规范。
• 被模型元信息或服务引用的供应商不允许删除，需先解除关联。

2.2 创建模型元信息

路径：AI 网关实例 > 模型元信息管理 > 模型元信息 > 创建模型元信息。

模型元信息承载了 Credits 计量所需的单价信息。创建时包含四组字段：

基础信息（必填）：

• 供应商：下拉选择已创建的供应商。
• 名称：模型名称，如 qwen-max、gpt-4o。

Credits 信息（选填但推荐填写）：

• 输入 Token 消耗：单位 Credits / 1M tokens，最多两位小数。
• 输出 Token 消耗：单位 Credits / 1M tokens，最多两位小数。
• 缓存 Token 消耗：单位 Credits / 1M tokens，最多两位小数。

能力与性能（选填）：最大输入/输出 Token、总 Token 上限、输入输出模态、15 项能力特性开关。

可用路径（选填）：请求路径（如 /v1/chat/completions）及协议类型（OpenAI Compatible / Anthropic Compatible / Custom）。

注意事项：

• Credits 三个单价字段如果不填，该模型的 Credits 消耗按 0 计入，不会拦截请求。
• 建议在接入新模型时就把 Credits 单价填完整，避免后续统计出现缺口。
• 同一供应商下模型名称建议保持唯一。

2.3 配置服务与供应商的绑定关系

路径：服务 > 创建/编辑服务 > 关联供应商。

在服务设置中选择供应商，建立服务与供应商之间的绑定关系。

注意事项：

• 一个服务在同一时刻只能归属一个供应商。
• 一个供应商可以关联多个服务。
• 此处选择的“供应商”与同一页面的“供应商配置模版”是两个独立概念，互不关联——前者是资源归属，后者是对接协议。

配额周期规划

3.1 两种周期大类

3.2 选型建议

场景 A：按自然月做总量控制

推荐：自然月。每月 1 日自动清零重新计量，与业务侧的月度 Review 节奏一致。

场景 B：在月度大配额的基础上再加一层“日峰值保护”

推荐：自然月 + 自然日同时配置。自然周期内不同小类可以共存，比如同一个消费者可以同时持有“自然月 100000 credits + 自然日 5000 credits”。

场景 C：给短期项目设置一个固定窗口的配额

推荐：自定义周期。比如“每 14 天”，从创建时刻开始精确计 14×24 小时，首周期就是完整的。

3.3 关键约束

• 大类互斥：同一消费者只能用一种大类。已有自然周期的消费者不能再加自定义周期，反之亦然。
• 自然周期小类可共存：自然日 + 自然周 + 自然月最多各一条，互不冲突。
• 自定义周期不可重复：同一消费者最多只有一条自定义周期规则。
• 冲突校验只看周期，不看单位：已有“自然日 + Token”的消费者，不能再建“自然日 + Credits”—— 因为它们统计的是同一份流量。

3.4 首周期行为差异

比如在周三 14:00 创建“自然周”配额，首周期只有周三 14:00 到周日 23:59:59 约 4.4 天，但配额量与后续完整 7 天周期一样，不做按比例折算。

限额单位选择：Token vs Credits

4.1 什么时候用 Token

• 你的消费者都固定使用同一个模型（不存在跨模型对比的需求）。
• 你希望规则简单直接，不依赖模型元信息的 Credits 单价配置。
• 你更关注“调用量”而非“消耗强度”。

4.2 什么时候用 Credits

• 消费者会混合调用多个模型（轻量模型 + 大模型），你需要一个统一的度量刻度来约束总消耗。
• 你希望“同样的配额额度，便宜模型能多用、贵模型自然少用”这种弹性效果。
• 你已经在模型元信息中维护了完整的 Credits 单价。

4.3 Credits 折算逻辑

每次请求完成后，网关按以下公式计算本次 Credits 消耗：

输入 Credits = 输入 Token 数 / 1,000,000 × 模型元信息.输入单价 输出 Credits = 输出 Token 数 / 1,000,000 × 模型元信息.输出单价 缓存 Credits = 缓存 Token 数 / 1,000,000 × 模型元信息.缓存单价 本次总消耗 = 输入 Credits + 输出 Credits + 缓存 Credits

关键规则：

• 单价取请求发生时的模型元信息字段值，不做事后回溯。
• 任一单价字段为空时，对应分项按 0 处理，该请求不会被 Credits 配额拦截。
• 不同厂商对 input_tokens 与 cache_tokens 的关系存在口径差异（有的包含、有的互斥），网关后端会自行归一化处理，配额规则不感知。

4.4 单位相关的约束

• 创建后不可改：限额单位一旦选定，编辑和重置都不允许修改。如需切换单位，唯一的办法是删除原规则后重新创建。
• 冲突校验不看单位：同一消费者同一周期只能有一条规则，无论单位是 Token 还是 Credits。
• 冲突提示不会暴露单位信息，避免误导用户以为“换个单位就能绕过”。

配额规则的创建与管理

5.1 创建配额规则

路径：消费者配额 > 创建配额规则。

创建表单字段：

创建成功后规则立即生效，消费者的下一次请求就会受到该配额规则约束。

5.2 编辑 vs 重置

配额规则创建后支持两种修改方式，选错了可能导致非预期的行为：

常见误区：

• 编辑后余量可以为负。比如配额 100 已消耗 80，编辑为 50，余量 = 50 − 80 = −30。此时消费者无法继续调用，直到进入下一周期或再次编辑调高。
• 重置允许跨大类切换周期类型（如从自定义周期切到自然月），但切换时仍需通过冲突校验。

5.3 自动续期

每个周期结束后，系统自动：

1. 将已消耗量清零。

2. 限额恢复为规则设定值（最近一次编辑/重置后的值）。

3. 进入下一周期。

这个过程持续循环，无需人工干预，直到规则被删除。

实操示例

示例 1：给消费者设置“每月 50000 Credits”的配额

前提：已创建供应商和模型元信息并填写了 Credits 单价。

步骤：

1. 进入消费者配额 > 创建配额规则

2. 选择消费者

3. 限额单位选择 credits

4. 限额值填写 50000

5. 周期类型选择“自然月”

6. 时区选 UTC+8

7. 保存

效果：该消费者每月 1 日 00:00 自动清零重新计量。每次调用完成后按模型单价折算 Credits 并累加，累计达到 50000 credits 后，后续请求返回 429。

示例 2：给消费者设置"Token 日限 + Credits 月限"双重保护

步骤：

1. 创建第一条规则：限额单位 token，限额值 10000000（1000 万），周期类型“自然日”。

2. 创建第二条规则：限额单位 credits，限额值 100000，周期类型“自然月”。

效果：

• 日维度：单日 Token 消耗不超过 1000 万，防止单日异常暴涨。
• 月维度：月度 Credits 消耗不超过 10 万，控制整体消耗强度。
• 任一规则触达即拦截。

注意：这里能同时建两条规则，是因为自然日和自然月属于自然周期大类下的不同小类，可以共存。如果尝试建“自然日 + Token”和“自然日 + Credits”两条规则，会被冲突校验拦截。

示例 3：临时调高配额应对业务高峰

场景：大促期间某消费者月度 Credits 配额不够用，需要临时调高。

步骤：

1. 找到对应配额规则 > 编辑

2. 将限额值从 50000 调高到 80000

3. 保存

效果：已消耗的数据保留不变，余量立即增加 30000 credits。大促结束后可以再编辑回 50000。

如果想直接重新开始计量（不保留历史消耗）：

1. 找到对应配额规则 > 重置

2. 限额值填写 80000

3. 保存

效果：已消耗清零，余量 = 80000 credits，相当于从头开始。

故障排查

7.1 消费者被限额但管理员认为不应被限制

排查步骤：

1. 查看该消费者的配额规则列表，确认当前周期的已用量是否确实达到限额。

2. 如果是 Credits 配额，确认相关模型元信息的 Credits 单价是否合理（单价过高会导致快速消耗）。

3. 确认是否存在多条配额规则（如日限 + 月限），可能是某一条较低限额的规则先触达。

临时解决：编辑对应规则调高限额值，或删除该规则。

7.2 Credits 消耗为 0 但有实际调用

可能原因：该模型的模型元信息中 Credits 单价字段未填写（三个字段全为空或为 0）。

解决：进入模型元信息管理 > 模型元信息，找到对应模型，补充 Credits 单价。补充后，后续请求会按新单价计量，历史请求不会回溯。

7.3 想切换限额单位（Token → Credits 或反向）

限额单位创建后不可修改。需要：

1. 删除原有配额规则。

2. 重新创建一条新规则，选择目标单位。

注意：删除原规则后当前周期的历史消耗数据会丢失。建议在周期交界点（如月初）执行切换，影响最小。

7.4 创建规则时提示“冲突”

冲突校验只看周期，不看单位。常见冲突原因：

• 已有自然日规则，又尝试建一条自然日规则（无论单位是否相同）。
• 已有自定义周期规则，又尝试建自然周期规则（大类互斥）。

解决：先删除或重置（改周期）已有规则，再创建新规则。

配置检查清单

在正式上线配额管控前，建议逐项确认：

• 已创建供应商，标识命名规范统一。
• 已创建模型元信息，Credits 三个单价字段已填写完整。
• 服务中已绑定正确的供应商。
• 配额规则的限额单位已确定（Token 还是 Credits），创建后不可改。
• 配额规则的周期类型已规划好（是否需要日+月双层保护）。
• 已确认目标消费者不存在冲突的已有配额规则。