GitLab 扩展了自托管的 GitLab Duo，以支持通过 Microsoft Foundry 部署的模型，允许组织针对自己选择的 Azure 环境中托管的模型运行 GitLab 的 AI 开发功能。该集成支持包括 OpenAI GPT、Anthropic Claude、Meta Llama 和 Mistral 在内的模型系列，为组织提供了在模型提供商、部署位置和数据路径方面的更多选择。
该措施特别适用于具有数据驻留、主权、控制或网络隔离要求的组织。 GitLab Duo 可以使用自托管组织自己的 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 功能，但组织可以识别哪些模型位于它们之下。
因此，广告的重要性超出了另一种模式的整合。随着人工智能越来越深入地嵌入到软件工程中，组织不仅必须做出决策，不仅要决定开发人员使用哪些人工智能功能，还要决定模型在哪里运行、源代码和提示在哪里传输、谁控制凭证以及哪些司法管辖区处理数据。
GitLab 的 Microsoft Foundry 集成允许 AI 模型层位于组织选择的 Azure 环境中，部分解决了该问题。企业人工智能工具越来越倾向于模型选择、部署控制和数据主权，而不是假设需要单一的、集中管理的人工智能提供商来获得最佳的开发体验。
Leave a Reply