问题描述 #

我有一段Bicep代码用于向Azure Foundry部署AI模型，之前一直正常，但最近在没有修改任何Bicep代码的情况下，部署突然失败，返回错误：

"code":"715-123420","message":"An error occurred. Please reach out to support for additional assistance."

我已经尝试过更换其他模型、移除自定义护栏并使用Microsoft.DefaultV2，但错误信息没有任何变化或消失。另外注意到从2月中旬开始有不少人碰到这个错误，但目前还没看到解决方案，求帮忙！

以下是我的Bicep代码：

// Model deployment for gpt-4o-mini
resource gpt4oMiniDeployment 'Microsoft.CognitiveServices/accounts/deployments@2024-10-01' = {
  parent: azureFoundry
  name: 'gpt-4o-mini'
  sku: {
    name: 'GlobalStandard'
    capacity: 20
  }
  properties: {
    model: {
      format: 'OpenAI'
      name: 'gpt-4o-mini'
      version: '2024-07-18'
    }
    versionUpgradeOption: 'OnceNewDefaultVersionAvailable'
  }
  dependsOn: [
    azureFoundryProject
  ]
}

// Model deployment for gpt-4o
resource gpt4oDeployment 'Microsoft.CognitiveServices/accounts/deployments@2024-10-01' = {
  parent: azureFoundry
  name: 'gpt-4o'
  sku: {
    name: 'GlobalStandard'
    capacity: 20
  }
  properties: {
    model: {
      format: 'OpenAI'
      name: 'gpt-4o'
      version: '2024-08-06'
    }
    versionUpgradeOption: 'OnceNewDefaultVersionAvailable'
  }
  dependsOn: [
    gpt4oMiniDeployment
  ]
}

解决方案建议 #

这问题确实闹心，无代码变更突然故障+内部错误码的组合最让人头疼。结合你的情况，我整理了几个优先级从高到低的排查方向：

1. 先查平台侧的配额与资源限制 #

• 检查配额：登录Azure门户，进入你的Cognitive Services（即代码中的azureFoundry）资源，打开「配额管理」页面，确认GlobalStandard SKU的可用部署容量是否充足，是否触发了区域级的资源限制。
• 回退API版本：你使用的API版本2024-10-01非常新，不排除部分区域对该版本的部署支持存在临时故障。可以尝试回退到稳定的旧版本（比如2024-05-01-preview）重新部署。

2. 验证模型版本的区域可用性 #

你指定的模型版本（gpt-4o-mini:2024-07-18、gpt-4o:2024-08-06）可能在目标区域存在同步延迟，尝试不指定版本号让Azure使用默认版本：

// 修改gpt-4o-mini的模型配置
model: {
  format: 'OpenAI'
  name: 'gpt-4o-mini'
  // 注释版本号，使用区域默认版本
  // version: '2024-07-18'
}

如果部署成功，再通过Azure CLI或门户查询该区域可用的具体模型版本，再填回代码。

3. 排除依赖资源的隐性问题 #

• 确认父资源azureFoundry和azureFoundryProject处于正常运行状态，最近没有权限调整、配置变更或锁定记录。
• 尝试简化dependsOn逻辑，比如先单独部署gpt4oMiniDeployment（去掉dependsOn: [azureFoundryProject]），验证是否是依赖顺序导致的问题。

4. 手动部署区分Bicep/平台问题 #

• 直接在Azure门户手动创建相同配置的部署：进入Azure OpenAI账户→「部署」→手动添加gpt-4o-mini，选择GlobalStandard SKU、容量20。
  • 如果手动部署也报715-123420错误：说明是Azure平台内部问题，立即提交支持工单，附上订阅ID、资源ID、错误时间戳、活动日志详情，同时说明“2月中旬起大量用户遇到相同错误”，推动团队排查共性问题。
  • 如果手动部署成功：问题出在Bicep配置，尝试降低capacity到5（高容量可能触发严格调度限制），或调整API版本后再试。

5. 最后尝试：降低部署容量 #

当前设置的capacity:20属于较高配置，平台可能对这类部署有更严格的资源调度限制。先将容量改为5，部署成功后再通过门户扩容到20，尝试绕开错误。

如果以上方法都无效，提交Azure支持工单是唯一能深入排查的途径——毕竟715-123420是内部错误码，公开渠道无法获取具体原因，只有Azure后台能查到日志。