GitLab 扩展了 GitLab Duo Self-Hosted，以支持通过 Microsoft Foundry 托管的模型，允许组织针对其所选 Azure 环境中托管的模型运行 GitLab 的 AI 开发功能。该集成支持包括 OpenAI GPT、Anthropic Claude、Meta Llama 和 Mistral 在内的模型系列，为企业在模型提供商、部署位置和数据路径方面提供了更多选择。
这一举措对于需要数据驻留、主权、监管或网络隔离的组织尤其重要。 GitLab Duo Self-Hosted 可以使用 AI 网关并部署组织的模型，而不是将 AI 请求发送到 GitLab 管理的模型基础设施。这使管理员能够更好地控制请求和响应的处理位置以及底层模型的部署方式。
该架构由三个主要组件组成：自我管理的 GitLab 实例、GitLab AI 网关以及通过 Microsoft Foundry 部署的一个或多个模型端点。该网关充当 GitLab Duo 和选定模型之间的中介，而不是将各个 Duo 功能直接连接到特定模型提供商。
集成的一个重要方面是特征级别模型的选择。组织可以针对不同的 GitLab Duo 功能使用不同的模型，例如，用于代码提交的以代码为中心的模型、用于机构工作负载的另一种模型以及用于大批量任务的较小模型。模型的放置也可以更改，而无需对 GitLab 工作流程进行任何重大更改。
这种方法还强调了与自主人工智能的重要权衡。让组织控制模型和基础设施可以提供更大的灵活性，但也给工程和平台团队带来了更多的责任。除了 GitLab 环境本身之外，他们还必须管理模型部署、可用性、网络、可靠性、可用性和模型生命周期。
这也意味着模型可用性并不自动等同于 GitLab Duo 兼容性。 Microsoft Foundry 目录的变化速度比 GitLab 支持的模型矩阵更快，因此组织应在选择模型之前检查两个平台上的兼容性。
亚搏体育appGitLab的方法遵循更广泛的趋势，不再将人工智能开发工具和基础模型视为集成服务。 Microsoft Foundry 本身提供对多个供应商模型的访问，而 GitLab 则提供围绕它们的开发和 DevSecOps 层。
与其他企业开发平台有相似之处。例如，GitHub Copilot 支持越来越多的核心模型，但其标准体验与 GitHub 的托管服务紧密集成。 GitLab 的自我管理模型方法反而更侧重于控制 AI 基础设施和网络路径。与此同时，Amazon Bedrock 和 Microsoft Foundry 等平台本身提供了多模型基础设施，但不能替代 GitLab 等集成 DevSecOps 平台。
这使得开发环境越来越像一个与模型无关的管理层：GitLab 管理开发人员工作流程和 AI 功能，而组织可以确定哪些模型位于它们之下。
因此，该公告的重要性超出了另一个模型的集成。随着人工智能深入软件工程，企业不仅需要做出决策，不仅要决定开发人员使用哪些人工智能功能，还要决定模型在哪里运行、源代码和激励措施在哪里、谁控制信任数据以及哪些司法管辖区处理数据。
Microsoft Foundry 的 GitLab 集成允许 AI 模型层位于组织选择的 Azure 环境中，部分解决了这个问题。企业人工智能工具正在朝着模型选择、部署控制和数据所有权的方向发展，而不是假设开发最佳实践需要单一、集中的人工智能提供商。
