# 优化预算配置

根据规模、结构和支出目标查找组织预算控制的正确组合。

在优化预算配置之前，请确保了解预算控制的工作原理以及系统如何评估它们。 请参阅“[基于使用情况的计费预算](/zh/copilot/concepts/billing/budgets-for-usage-based-billing)”。

如果尚未设置预算，请从 [预算控制入门](/zh/copilot/tutorials/budgets/getting-started-with-budget-controls) 开始获取基本知识，然后返回本指南以优化配置。

若要使用用户界面或 REST API 在管理成本中心之间做出决定，请参阅 [大规模控制和跟踪成本](/zh/billing/tutorials/control-costs-at-scale)。

## 确定预算规模

用户级预算和其他预算之间的关系是最常见的意外阻止来源。 如果用户级预算合计允许的使用量超过共享池提供的额度，超出的部分将按量计费，因此您的预算额度必须足够高，以覆盖这部分差额。

下面介绍如何估算：

1. 计算用户级预算允许的最大总消耗量。 对于使用通用预算的用户，请将其人数乘以通用 ULB。 加上所有成本中心用户级预算的总额——即每位用户的金额乘以各成本中心中的用户数量。 然后添加任何单个 ULB 替代的总和。
2. 计算您的池值：将您的 Copilot业务 个席位乘以 19 美元，再将您的 Copilot Enterprise 个席位乘以 39 美元，然后将两者相加。
3. 从最大总消耗量中减去池值。 结果是你的预算需要覆盖的最高按量计费费用。

如果还使用成本中心预算，则成本中心预算和企业预算的总和应涵盖差距。 企业预算适用于未分配到成本中心的用户。

如果您希望每个成本中心都控制在其自身的 AI credits 许可证预算范围内，请对此成本中心应用内含使用控制。 这会自动为团队从共享池中可使用的额度设定上限，因此某个团队的大量使用不会在开始应用按量计费预算之前先耗尽其他团队的份额。 请参阅“[基于使用情况的计费预算](/zh/copilot/concepts/billing/budgets-for-usage-based-billing#included-usage-controls-for-cost-centers)”。

> \[!TIP]
> 每当提高用户级预算时，请重新检查此计算。 提高 ULB 而不提高企业预算，可能会导致企业预算在用户达到其个人预算前就先行阻断用户。

## 选择范围

对于大多数企业，我们建议**直接向用户分配成本中心预算**。 将用户直接分配到成本中心时，费用始终遵循用户，因此无论许可证的结构如何，强制实施都是可预测的。

| Scope  | 何时使用                                     | 谁可以设置它     |
| ------ | ---------------------------------------- | ---------- |
| 成本中心预算 | 你希望以企业管理员身份进行可预测的组织级支出控制。                | 企业所有者、计费经理 |
| 组织预算   | 组织所有者需要设置自己的支出限制，而无需企业管理员参与。             | 组织所有者      |
| 企业预算   | 你需要一个兜底机制，为所有未被范围更窄的预算覆盖的用户的总按量计费费用设定上限。 | 企业所有者、计费经理 |

如果你企业中的用户拥有来自多个组织的 Copilot 许可证，那么仅包含组织（不包含用户）的组织预算和成本中心将产生不可预测的强制效果。 每个周期都会随机选择计费组织，因此支出可能会计入从月到月的不同预算。 将用户直接分配到成本中心可避免此问题。

### 从组织预算迁移到成本中心

如果企业已有组织预算，它们将继续工作。 但是，如果你有通过多个组织分配 Copilot 许可证的用户，迁移到采用直接用户分配的成本中心会带来更可预测的强制效果。

1. 创建成本中心并直接分配用户（而不仅仅是组织）。
2. 设置与所需支出上限匹配的成本中心预算。
3. 一旦成本中心预算到位，就删除组织预算。

## 常见场景

以下方案显示了不同企业结构的常见预算配置。

### 负责任地管理共享使用情况

**情况：** 你希望防止任何单个用户占用资源池中过高比例的资源，同时仍为使用量较大的用户保留一定的灵活性。

**配置：**

* 将 **全局用户级预算** 设置为高于单个许可证的值，以使池化生效。
* 为需要更高限额的已知高级用户设置**单独的用户级预算覆盖**。
* 将 **企业预算** 设置为按流量计费的安全网。
* 在企业预算上启用 **“在达到预算限制时停止使用** ”。

对于大多数企业来说，这是最简单的配置和良好的起点。

### 按业务部门预算

**情况：** 你有多个业务部门或组织，并希望每个业务部门负责自己的按流量计费的支出。

**配置：**

* 为每个组织创建**成本中心**。 请参阅“[使用成本中心将成本分配给业务部门](/zh/billing/how-tos/products/use-cost-centers)”。
* 将**包含量使用控制**应用于每个成本中心，以便业务部门不能从共享池中使用超过其自身许可证所提供的包含量AI credits，并可选择在达到上限时阻止或允许付费超额使用。
* 为每个业务部门设置 **成本中心预算** 。
* 将**企业预算**设置为安全网，覆盖所有未分配到成本中心的用户。
* 在所有预算上启用 **“在达到预算限制时停止使用”。**

使用此配置，每个业务部门都有自己的按流量计费的支出上限。 当某个成本中心的预算耗尽时，仅该成本中心内的用户被阻断，其他业务单元不受影响。 企业预算涵盖所有未分配到成本中心的用户。

如果希望业务部门独立于企业预算运行，请考虑启用 **成本中心排除** 。 这允许成本中心用户保留支出，即使企业预算达到 0 美元，但这意味着其按流量计费的费用只能由自己的成本中心预算限制。

### 按团队区分每位用户的限制

**情况：** 不同部门需要不同的每位用户限额。例如，工程部门每位开发人员所需的容量要高于市场部门，但你又不想管理成千上万个单独的预算。

**配置：**

* 为每个部门创建 **成本中心** 并直接分配用户。 请参阅“[使用成本中心将成本分配给业务部门](/zh/billing/how-tos/products/use-cost-centers)”。
* 为每个部门设置 **成本中心用户级预算** ，为该成本中心的每个成员提供相同的每个用户限制。
* 为需要与部门默认值不同的限制的任何特定用户设置 **单个用户级预算替代** 。
* 将**企业预算**设置为按量计费费用的保障措施。
* 在企业预算上启用 **“在达到预算限制时停止使用** ”。

成本中心用户级预算设置一个每个用户的金额，该金额适用于成本中心的每个当前成员和将来成员，因此你可以在一个位置调整部门限制，而不是按用户编辑预算。 优先顺序按具体程度从高到低排列：单个预算优先于成本中心用户级预算，而后者又优先于全局预算。

### 业务部门中的高级用户

**情况：** 你需要按团队负责，并且需要在业务部门中为特定开发人员提供更高的限制。

**配置：**

* 为每个组织创建**成本中心**。
* 设置 **通用用户级预算** 以限制大多数用户。
* 为需要更大容量的高级用户设置**单独的用户级预算覆盖**。
* 为每个业务部门设置 **成本中心预算** 。
* 将**企业预算**设为一项保险措施。
* 在所有预算上启用 **“在达到预算限制时停止使用”。**

这是最精细的配置。 它结合了针对每位用户的控制（谁可以使用多少）、团队层面的控制（各业务部门可产生多少按量计费的支出），以及覆盖整个企业的安全保障机制。 如果跨团队混合使用模式，并且需要精细的治理，请使用此功能。

### 将控制权委派给组织所有者

**情况：** 组织所有者需要设置自己的支出防护措施，而不涉及企业管理员。

**配置：**

* 每个组织所有者为其 **组织设置组织预算** 。
* 企业管理员将 **企业预算** 设置为安全网。
* 在所有预算上启用 **“在达到预算限制时停止使用”。**

组织预算是组织所有者唯一可用的预算选项。 组织预算只能进一步限制企业管理员设置的任何预算以下的使用情况。它不能替代更高级别的预算。

如果贵企业中的用户通过多个组织被分配了 Copilot 许可证，则组织预算可能无法针对这些用户按预期生效。 在这种情况下， GitHub 在每个计费周期随机选取一个组织来计费席位。 这意味着，用户的支出每个月都可能计入不同组织的预算，从而使执行情况变得难以预测。 若要避免这种情况，请确保每个用户通过一个组织拥有单个许可证，或者将成本中心预算用于直接用户分配。

## 使用历史数据调整预算大小

AI 使用情况仪表板和使用情况导出 CSV 是调整预算大小的最佳工具。 查看：

* **按用户消耗：** 确定信用额度如何分布在用户之间。 如果消耗量集中在小部分群体中，采用单独覆盖的用户级预算将比单一的高通用 ULB 更有效。
* **模型使用模式：** 不同的模型消耗积分的速度不同。 如果少数用户通过高级模型推动高支出，请考虑模型策略（限制哪些模型可用）是否比收紧预算更有效。
* **每月趋势：** 查看消耗量是平稳还是波动较大。 峰值可能只是暂时的（例如迁移项目或入职冲刺期），而不是新的基线。 根据稳态调整预算大小，并使用单独覆盖来处理临时例外情况。