北京
企业想用AI写代码，又不想把源代码和提示词送到别人的服务器上，这个矛盾一直卡着很多团队的落地节奏。GitLab给出的解法是：把模型层交还给企业自己部署。
GitLab Duo自托管版本完成了一次扩展，支持通过微软Foundry部署的模型。企业可以在自己选定的Azure环境中运行GitLab的AI开发能力，覆盖的模型系列包括OpenAI GPT、Anthropic Claude、Meta Llama和Mistral。模型厂商、部署位置、数据路径，这三件事的选择权都回到了企业手里。
谁最需要这套方案
有数据驻留、数据主权、合规监管或网络隔离要求的组织，是这次更新最直接的受益方。AI请求不必再发送到由GitLab管理的模型基础设施，GitLab Duo自托管版本可以直接调用企业自身的AI网关与模型部署资源。管理员能控制请求和响应在哪里处理，也能控制底层模型怎么部署。
架构上由三个组件构成：自管理的GitLab实例、自托管的GitLab AI Gateway，以及一个或多个通过微软Foundry托管的模型端点。网关是GitLab Duo与所选模型之间的中间层，它的存在意味着Duo的各项功能不会被强行绑定到某一家模型厂商身上。
功能级别选模型，是这套方案的关键差异
企业可以为GitLab Duo的不同功能分配不同模型。面向代码的模型负责代码建议，另一套模型处理智能体任务，吞吐量要求更高的任务则可以用更小的模型。模型部署更换时，GitLab的开发工作流程不需要根本性改动。
代价同样明确。企业拿到了模型与基础设施的灵活性，也接过了更多运维责任。工程和平台团队除了维护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厂商的前提，正在被松动。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
