平台工程2.0：在不重建基础设施的情况下管理AI成本和风险

# 平台工程 2.0：在不重建基础设施的情况下管理 AI 成本与风险 来源: https://platformengineering.com/features/platform-engineering-2-0-manage-ai-costs-and-risks-without-rebuilding-infrastructure/ 跳过内容 (https://platformengineering.com/features/platform-engineering-2-0-manage-ai-costs-and-risks-without-rebuilding-infrastructure/#content) Platform Engineering Logo (https://platformengineering.com/) - 最新 (https://platformengineering.com/latest/) - 网络研讨会 (https://platformengineering.com/webinars/) - 视频 (https://platformengineering.com/features/platform-engineering-2-0-manage-ai-costs-and-risks-without-rebuilding-infrastructure/#) - Platform Engineering Show (https://platformengineering.com/category/the-platform-engineering-show/) - 相关站点 (https://platformengineering.com/features/platform-engineering-2-0-manage-ai-costs-and-risks-without-rebuilding-infrastructure/#) - Techstrong Group (https://techstronggroup.com/) - Cloud Native Now (https://cloudnativenow.com/) - Security Boulevard (https://securityboulevard.com/) - Digital CxO (https://digitalcxo.com/) - Techstrong AI (https://techstrong.ai/) - Techstrong ITSM (https://techstrongitsm.com/) - Techstrong Research (https://techstrongresearch.com/) - DevOps Chat (https://soundcloud.com/devopschat) - DevOps Dozen (https://devopsdozen.com/) - DevOps TV (https://www.youtube.com/channel/UC-zcE077X98oTEDPwKkDQxQ) - Techstrong TV (https://techstrong.tv/) - Techstrong TV Podcast (https://www.techstrongpodcasts.com/) - Techstrong TV Twitch (https://www.twitch.tv/techstrongtv) - 关于我们 (https://platformengineering.com/about/) - 媒体资料包 (https://techstronggroup.com/assets/techstrong-media-kit.pdf) - 自动化与工具 (https://platformengineering.com/category/automation-tooling/) - 最佳实践 (https://platformengineering.com/category/best-practices/) - 云管理 (https://platformengineering.com/category/cloud-management/) - 开发者体验 (https://platformengineering.com/category/developer-experience/) - 开发者门户 (https://platformengineering.com/category/developer-portal/) - 更多 (https://platformengineering.com/features/platform-engineering-2-0-manage-ai-costs-and-risks-without-rebuilding-infrastructure/#) - DevOps 与 SRE (https://platformengineering.com/category/devops-sre/) - 基础设施即代码 (https://platformengineering.com/category/infrastructure-as-code/) - 创新与新兴技术 (https://platformengineering.com/category/innovation-emerging-technologies/) - 领导力战略 (https://platformengineering.com/category/leadership-strategy/) - 可观测性与监控 (https://platformengineering.com/category/observability-monitoring/) - 研究 (https://platformengineering.com/category/research/) - 安全与合规 (https://platformengineering.com/category/security-compliance/) - 培训与认证 (https://platformengineering.com/category/training-certification/) 首页 (https://platformengineering.com/) » 平台工程 2.0：在不重建基础设施的情况下管理 AI 成本与风险 ## 平台工程 2.0：在不重建基础设施的情况下管理 AI 成本与风险 平台工程团队花了大半个世纪的时间来构建一些令人钦佩的东西：标准化的 Kubernetes 集群、CI/CD 流水线、内部开发者平台（IDP）以及自助式基础设施，使开发者能够安全、高效、可重复地交付应用。这个基础一直表现良好 —— 直到 AI 的到来，并改变了其下的每一个假设。 如今，DevOps 与平台工程之间的争论已经显得有些过时了。 一个更具深远影响的挑战已经取而代之：如何在一个从未为承载 AI 工作负载而设计的基础设施上构建、治理、隔离和运行这些工作负载？Broadcom 和 PlatformEngineering.org 表示，答案就在 Broadcom 新推出的平台工程 2.0 框架 (https://www.vmware.com/docs/platform-engineering-2-evolution-for-the-ai-era) 中。Broadcom 表示，在创建该框架时，它汲取了在 AI、软件和私有云基础设施方面的整体企业经验。 平台工程 2.0 同时建立在平台工程 1.0 成功的基础之上，而非取而代之。该框架旨在成为一个自然演进，而非对现有平台投资的背离。 ### AI 暴露出的鸿沟 平台工程 1.0 是为容器化、以开发者为中心、以人类节奏运行的工作流而构建的。AI 以三种截然不同的方式打破了这一模式。 - 首先，AI 引入了提示词和检索内容作为实时、不可预测的输入通道。数据不再仅仅是数据——它是模型输出行为上的可执行影响，使得传统的隔离属性（曾适用于计算和存储）突然变得不可靠。 - 其次，AI 工作负载同时横跨多个执行平面：SaaS API、经过微调的托管模型、本地推理、检索层以及深入现有系统的工具调用代理。平台从未被设计为同时治理所有这些方面。 - 第三，也是最关键的一点，AI 将信任边界从应用本身转移到了模型、工具、数据源、人类以及操控它们的人机代理之间的交互中。这不是一个可以修补的缺口。这是一个结构性问题。除了引入新的安全和治理关切外，AI 还导致了运营碎片化——团队各自独立采用不同的模型、工具、检索方法和可观测性实践。 其后果已开始显现于企业预算中。在六月份的 FinOps X 大会上，Accenture 的 FinOps 全球实践负责人 Mike Eisenstein 转述了一位 CIO 的陈述：Claude API 成本在一个月内从每天 25 万美元飙升到每天 40 万美元。正如 FinOps Foundation 执行董事 J.R. Storment 明确指出的那样：“AI 的变化速度异常快。今天的好政策下周就可能过时。” 这是不可持续的——而且应用层面的修复无法解决这个问题。 ### 为什么应用层面的修复无法规模化 本能的反应是让每个应用团队为自己的 AI 用例包裹上安全防护栏。聊天机器人增加提示词强化，文档工具增加访问检查，代码助手添加单独日志记录。每个团队都在构建自己的边界。 这种反应有其结构性限制。策略解释在各团队之间支离破碎。例如，“禁止将 PII 发送到外部模型”在营销部门与财务部门的含义截然不同。安全负责人无法回答关于哪些模型在运行、运行在哪里以及受哪些策略约束的基本问题，因为答案分散在数十个服务和供应商控制台中。 影子 AI 进一步加剧了这一问题。它比影子 IT 更加危险——不仅仅是因为数据暴露风险，还因为它产生的成本画像。 将 AI 治理局限于文档和应用程序代码是不够的。安全责任必须下沉到平台本身。 其中的两个支柱是基础性的：作为控制平面的模型治理，以及作为结构性保证的工作负载隔离。 ### 作为控制平面的模型治理 如今，大多数企业在多个提供商处运行多个模型。正如 AI 安全公司 Airia (https://airia.com/why-model-agnostic-governance-is-the-only-enterprise-ai-strategy-that-scales/) 所指出的 (https://airia.com/why-model-agnostic-governance-is-the-only-enterprise-ai-strategy-that-scales/)，“特定于模型的治理在大规模下会失效。”它提出了“一个位于模型层之上的控制层——无论底层模型是哪个执行任务，它都能强制执行策略、记录决策并监控行为。” 平台工程 2.0 将该原则转化为一项具体服务：一个中央模型注册表与路由层；统一的身份认证？策略执行统一应用于 OpenAI、Anthropic 或任何本地模型；以及一个用于审计、可观测性和合规性的单一管理界面。开发者通过平台请求模型访问权限；平台将这些请求映射到风险等级和审批工作流。可以将其视为 AI 的基础设施——平台同时扮演规则手册和裁判的角色。 ### 作为结构性保证的工作负载隔离 如果说模型治理定义了 AI 被允许做什么，那么工作负载隔离则定义了它可以在哪里做以及故障能蔓延多远。这意味着跨实验沙箱、内部工作负载和面向客户受监管数据环境的专用隔离域。同时，它还意味着绑定到模型、代理和工具的零信任服务身份——因为提示注入攻击一定会成功，而当它们成功时，横向移动必须在结构上变得困难。 ### 自主智能体前沿 这两个支柱汇聚到了一个更大的议题上。自主 AI 代理正在作为一种新的平台用户类别出现——它们没有可继承的先前用户角色，也没有人类在循环中捕获错误配置的作用域。平台必须同时支持人类开发者和 AI 代理，将它们视为一等消费者。 “平台工程不再仅仅是一个软件交付学科，”平台工程 2.0 白皮书 (https://brcm.tech/PE2WhitePaper) 声明 (https://brcm.tech/PE2WhitePaper)。“它正在成为企业自主智能体未来的运营基础。” ### 平台转型势在必行 平台工程 2.0 是一个演进，而非重置。其基础——平台即产品、黄金路径 (https://platformengineering.com/features/golden-paths-should-let-the-spice-flow/)、自助式 IDP 和左移安全——仍然必不可少。改变的是平台服务谁、它必须做什么以及它需要以多快的速度适应。 掌握这一过渡的团队拥有的不仅仅是交付流水线。他们拥有组织面向 AI 原生未来的基石。那些没有将自主智能体 AI 直接集成到平台控制面板中的组织将严重落后。 实现这一点并不容易。但方向是明确的，而延迟的代价——在安全暴露、运营碎片化和失控的 AI 支出方面——已经清晰可见。平台必须演进，而现在是时候开始了。 #### 分享这个故事 页面加载链接 (https://platformengineering.com/features/platform-engineering-2-0-manage-ai-costs-and-risks-without-rebuilding-infrastructure/#) 返回顶部 (https://platformengineering.com/features/platform-engineering-2-0-manage-ai-costs-and-risks-without-rebuilding-infrastructure/#)