\n\n组织不应通过单一模型标准化 AI。由于软件生命周期需求多样，企业应根据任务的性能、质量和成本，灵活编排多模型策略，并引入 FinOps 进行科学的支出管理。
译自：Why enterprise AI needs customization
作者：Bryan Ross
大多数组织在采用 AI 时，采取的方式与当年购买企业软件时如出一辙：选择一个供应商，统一一个模型，然后在全公司推广。
这种做法基于一个假设，即一个模型可以解决所有问题。但一个擅长代码生成的模型可能在安全分析方面表现挣扎，而一个非常适合原型的尖端模型可能无法满足你的数据驻留要求。
“一个擅长代码生成的模型可能在安全分析方面表现挣扎，而一个非常适合原型的尖端模型可能无法满足你的数据驻留要求。”
解决这种错位需要灵活部署 AI 模型。有些团队需要大规模模型进行高级推理，而其他团队则需要专用模型进行特定领域的工作。关键在于，你需要根据手头的任务进行灵活组合。
AI 悖论：优化整个软件开发流程
目前的 AI 采用几乎完全集中在加速代码生成上。但编写代码仅占开发人员实际工作的一小部分。根据 GitLab 2025 全球 DevSecOps 调查报告，开发人员仅花费约 15% 的时间编写代码。其余时间用于规划、代码审查、测试、调试、管理依赖关系、与队友协作以及应对合规性要求。
这产生了一个 AI 悖论：AI 正在加速编码，但脱节的工具链和手动协调降低了整体生产力，导致每位开发人员每周损失近一个完整的工作日。
要打破这一悖论，AI 需要贯穿整个开发生命周期，而不不仅仅是代码生成。软件生命周期中的不同活动具有截然不同的性能要求：
- 速度关键型任务：如在活动开发期间自动补全代码或建议修复，需要亚秒级的响应时间，这可能更适合较小的本地托管模型。
- 质量关键型任务：如架构规划或安全分析，值得使用推理能力更强的尖端模型。
- 成本敏感型任务：在大规模运行时，例如在数百个存储库中运行测试或更新依赖项，需要具有成本效益的选择。
这就是多模型定制化至关重要的原因。软件生命周期中的任务价值各不相同。在单一模型上进行标准化可能会导致为某些功能支付过高费用，或对其他功能支持不足。
做得好的组织会构建足够灵活的系统，将每个任务路由到与其性能、质量和成本概况最匹配的模型。
优先考虑溢价模型的使用
务实的做法是将模型成本与任务价值相匹配。
对于高容量、常规性工作（如编写提交信息、总结日志文件或编写测试用例），团队倾向于选择更便宜、更快的方案，包括在可行的情况下使用开源模型。对于需要复杂推理的任务，团队愿意为更强大的能力付费。对于更具确定性的专用模型，团队可能愿意为生成基础设施即代码或高精度数据转换支付溢价。
能够根据任务在不同模型之间进行选择，可以规避性能差异、价格波动以及供应商可能停产产品或完全退出市场的现实风险。
这种灵活性来自三个来源，每个来源都有其权衡：
- 来自 Anthropic、OpenAI 和 Google 的商业尖端模型性能强劲且持续改进，但会产生对供应商路线图和定价的依赖。
- **自托管商业模型或开源模型**让你能够控制数据驻留、成本和可用性，但需要基础设施管理，且就开源模型而言，目前仍无法处理代理工作流。
- 你训练的特定领域模型在具有独特数据和明确成功标准的狭窄、高风险任务上，表现可以超越通用模型。尽管如此，它们需要专业知识，且运营成本昂贵。
每种方法都涉及权衡。关键是构建能让你战略性地使用这三种模型的系统。
像管理云支出一样管理 AI 支出
只有当你能够管理模型背后的经济效益时，模型灵活性才能创造价值。模型之间的价格差距是巨大的。复杂推理模型的单次请求成本可能比处理常规任务的通用模型高出 500%。
“复杂推理模型的单次请求成本可能比处理常规任务的通用模型高出 500%。”
在这里，模型路由（定义哪些任务使用哪些模型的能力）变得至关重要。代码审查可能会路由到尖端模型，而提交信息生成则使用更快、更便宜的选择。
但仅有路由是不够的。企业需要应用与云基础设施相同的财务控制，包括防止超支的配额、强化预算纪律的限制，以及将成本分配给消费 AI 资源的部门的分摊模型。如果没有这些护栏，大规模采用 AI 将变得难以证明其合理性。
这就是为什么 FinOps 实践 正在扩展到 AI 领域。IDC 预测 到 2027 年，组织将低估其 AI 基础设施成本 30%，将生成式 AI 与 FinOps 流程相结合对于管理这种复杂性至关重要。那些像对待云支出一样对待 AI 支出，并具备可见性、问责制和治理能力的组织，将能够成功扩展 AI。
定制化对投资回报率（ROI）至关重要
模型灵活性也取决于上下文。AI 需要分布在各个系统中的信息，而这些系统默认情况下并非协同工作的。正在调试问题的开发人员可能需要引用待办事项、提取最近的 Slack 讨论，并在 Grafana 中查看应用性能指标。如果每个系统都有自己的 AI 体验且互不相连，AI 就会产生摩擦而不是消除摩擦。
幸运的是，最近的开源进展，如 Model Context Protocol (MCP)，通过使工具能够在单个工作区内共享相关的上下文和操作，解决了这个问题。
这种共享基础实现了有意义的定制化，而最有效的定制化是分层工作的，每一层都编码了你的组织执行工作的方式。
大多数开发人员依赖预构建的代理和工作流，使 AI 可用于常见任务而无需专业知识。高级用户通过详细的提示词来塑造模型的运作方式，本质上是教它遵循组织的运行手册。专家则将多个代理连接到受管控的流程中，镜像人类交付工作的方式，并设有严格的审查协议。
当组织设计 AI 在定义的上下文和问责结构内运行，且团队可以根据其需求（无论是尖端商业模型、用于数据驻留的自托管实例，还是为特定领域工作训练的专业模型）连接不同模型时，其投资回报率最强。
实施编排，而非标准化
当企业 AI 产生的输出能够在真实的系统、真实的约束下经受住考验时，它才是成功的。
领先的组织在保持严格治理的同时，为模型多样性而构建。他们像管理云支出一样管理 AI 支出，利用模型路由、配额和费用分摊。他们投资于编排，使 AI 自然地融入日常工作流，并让相关上下文在工具之间流动。
严谨的选择过程至关重要。优秀的平台使用子代理针对每种操作类型评估模型的质量、性能和成本，并将这些评估结果展示给用户，以便团队理解为什么给定模型处理给定任务。这种透明度建立了信任。当团队有不同于默认设置的要求时，他们应该能够覆盖模型选择或完全引入自己的模型。
这使组织能够根据需要在性能至关重要处使用尖端模型、在需要数据驻留处使用自托管模型、在领域专业知识发挥作用处使用专业模型，所有这些都由一个控制平面管理，无论模型来源如何，都能保持一致的可靠性和安全性标准。
企业 AI 并不是在寻找一个完美的模型。它的核心工作是构建能将正确的模型连接到正确的任务，并有治理体系提供支持。全 工智能
