GitLab针对其自托管版本推出扩展方案，借助微软Foundry支持OpenAI、Claude、Llama及Mistral等模型部署，使企业在自主选择的安全环境（如Azure）中运行AI开发能力。该方案整合自管理实例、AI网关及Foundry托管模型端点三组件，实现模型厂商与部署资源的灵活分配，尤其契合数据驻留、主权及合规监管需求，规避GitLab管理的模型基础设施。其核心价值在于打破单一厂商绑定，赋予企业按功能定制模型的能力，同时强调AI基础设施与开发者流程的自主掌控。不过，此方案将运维责任重心转移至工程团队，需兼顾模型部署、容量、安全等全链路管理，并强调模型兼容性验证的必要性。当前，随着AI深度嵌入工程，企业决策范围拓展至模型部署、数据流向、合规控制等环节，GitLab与微软Foundry的集成正是提供模型层自主可控的解决方案，推动AI工具向模型自由选择、部署精准管控及数据主权保障的方向演进，实现从单一托管服务向综合控制层升级。
--91likeyou---
该集成的一大亮点是功能级别的模型选择能力。企业能够为 GitLab Duo 的不同功能分配不同模型：例如，选用面向代码的模型提供代码建议能力，用另一套模型处理智能体任务，为更高吞吐量的任务使用更小的模型。模型部署也可以在不根本改变 GitLab 开发工作流程的情况下进行更换。
但这套自托管 AI 方案也存在关键取舍。虽然企业获得了模型与基础设施的高度灵活性，但也将更多运维责任转移给工程和平台团队。团队除维护 GitLab 环境之外，还需要管理模型部署、容量、网络、凭证、可用性以及模型全生命周期。
这也意味着模型可用并不代表一定与 GitLab Duo 兼容。微软 Foundry 目录的变化速度可能会快过 GitLab 支持模型矩阵的变化速度，因此组织需要在选择模型之前验证两个平台之间的兼容性。
GitLab 的做法顺应了一种更广泛的行业趋势：不再将 AI 开发工具和基础模型视为单一的捆绑服务。微软 Foundry 本身就提供了来自多个厂商的模型，而 GitLab 则在之上提供了开发和 DevSecOps 层。
它与其他企业开发平台有相似之处。例如，GitHub Copilot 也越来越多地支持多种底层模型，但其标准体验仍与 GitHub 的托管服务紧密集成。GitLab 的自托管模型则更加强调对 AI 基础设施和网络路径的控制。而像 Amazon Bedrock 和微软 Foundry 这类平台，虽然提供了多模型基础设施，但它们本身并不能替代 GitLab 这种集成 DevSecOps 平台。
这使得开发环境越来越像一个与模型无关的控制层：GitLab 管理开发者工作流程和 AI 功能，而组织可以决定底层使用哪些模型。
因此，本次发布的意义不仅仅在于又增加了一项模型集成。随着 AI 更深入地嵌入到软件工程中，企业需要做的决策不再局限于开发者使用哪些 AI 功能，还包括模型在哪里运行、源代码和提示词流向何处、谁控制凭据，以及哪些司法管辖区处理数据。
GitLab 与微软 Foundry 的集成为此提供部分解决方案：把 AI 模型层部署在企业自主选择的 Azure 环境中。企业级 AI 工具正在向着模型可选择、部署可管控、保障数据主权的方向演进，不再默认最优开发体验必须依赖单一集中托管式 AI 厂商。
查看英文原文：
🔥 热词：#gitlab有免费托管仓库的地址吗