本地、VPC 和开放式托管

收益：

• 能够评估托管 API、VPC 和本地托管之间的权衡
• 能够根据数据主权、数据量和运营能力决定托管
• 能够计算完整项目的总拥有成本 (TCO) 并设计混合架构

对于某些组织来说，“将数据发送给提供商”——无论多么安全——都是不可接受的。在国防工业、公共、银行和一些健康场景中，数据永远不应该超出机构的边界。此时，托管您自己的模型就显得尤为重要：开放权重模型，在您自己的云网络 (VPC) 或您自己的服务器（本地）上运行。在本单元中，我们将学习托管 API 和自托管之间的权衡（当有意义时）以及总拥有成本 (TCO)。

概念

• 托管API：在模型提供商的基础设施上运行；您发送请求并获得响应。运营开销很小，但数据会发送给提供商。
• 开放权重模型：模型参数（权重）可下载；您可以在自己的硬件上运行它。它不一定与“开源”相同（许可证可能不同）。
• VPC托管（虚拟私有云）：在您自己的隔离云网络中运行模型；数据保留在您的网络边界，但基础设施仍在云中。
• On-prem（本地）：完全在自己数据中心的硬件上运行模型；最高控制，最高运行负载。

注意：“自己的托管总是更安全”是一个误解。安全性较少取决于您保存数据的位置，而更多取决于您管理数据的程度。未修补、配置不当的本地服务器比成熟的托管 API 风险更大。

决策轴：哪个时间？

三个问题指导决策：

1. 数据主权：法律或合同是否禁止数据离开机构/国家？如果是，您将被推向 VPC/on-Prem。
2. 数量和成本：使用率是否非常高且可预测？大量的自托管可以降低单位成本；以低/不稳定的数量管理的 API 几乎总是便宜的。
3. 运营能力：您是否有团队来维护 GPU 基础设施、模型更新、扩展和安全修补？否则，您自己的托管是一项隐性成本。

权衡表

尺寸

托管API

专有网络

本地（开放重量）

数据主权

信任提供商

高（在您的网络限制下）

最高（永不上升）

运行负荷

太低

中等

高

初始成本

低（现收现付）

中等

高（硬件）

缩放比例

自动

托管

你的责任

模型质量/货币

最新的，自动的

视情况而定

你更新

控制

低

高

满

一步一步：托管决策

1. 确定数据类别。数据将以何种保密级别进行处理？
2. 验证法律约束。数据能出去吗？ （KVKK，部门监管，合同。）
3. 估计体积。每月请求/代币数量和增长曲线。
4. 计算总拥有成本。不仅仅是 GPU；能源、维护、团队、安全、冗余。
5. 想想混合动力。处理本地/VPC 中的敏感数据和托管 API 中的非敏感数据的混合模型通常是最稳定的。

四个可复制模板

托管决策提示：

决定托管用于以下用途：{{ 场景 }}问题：- 要处理的数据的隐私类别是什么？ （公开/内部/机密/绝密）- 法律/合同是否允许数据流出组织之外？- 每月数量预测和可预测性？- 是否有运营/GPU 团队能力？建议：“托管 API/VPC/本地/混合”+ 理由。

TCO 项目列表（用于自托管）：

通过以下方式计算总拥有成本： - 硬件 (GPU) 购买/租赁 - 能源和冷却 - 人力：MLOps + 安全团队时间 - 模型更新和测试人员 - 冗余/灾难恢复 - 安全修补和监控 将其与 12-24 个月内托管 API 的每月账单进行比较。

混合路由规则：

根据数据类路由每个请求：-“秘密/绝密”数据->本地/VPC模型-“公共/内部”数据->托管API（更强大/更便宜）将转发决策和数据类写入审核日志。

开启重量安全检查提示：

评估我们的自托管模型：- 许可证是否允许商业使用以及在我们的场景中？- 来自可信来源的模型权重、完整性（哈希）经过验证吗？- 是否安装了服务器修补、网络隔离、访问控制？- 监控和日志记录是否与托管 API 一样成熟？将任何缺失的项目标记为“ON”。

弱提示/强提示

糟糕的方法

强硬的做法

“本地部署更安全，请始终使用它”

基于数据主权+体量+容量的决策

只看GPU成本

完整的 TCO（能源、人员、更新、安全）

被锁定在单一托管模型中

混合：按数据类路由

在不降低开放重量并验证的情况下运行

许可证+完整性+补丁+跟踪控制

三个迷你箱

案例 1 — 本地授权是正确的决定。一家国防承包商要处理高度机密的文件；该合同禁止将数据带出国。托管 API 从一开始就被淘汰了。 On-Prem开放权重模型建立；成本很高，但这是唯一兼容的选择。

案例 2 — 机密 TCO 推翻了决定。一家初创公司计划转向自托管，因为“API 很昂贵”。在 TCO 计算中，不仅包括 GPU，还包括 GPU。添加 2 名全职 MLOps 工程师、更新负载和冗余，24 个月的总时间是托管 API 的两倍。它们仍保留在 API 中，因为它们的数量很少且零散。

案例 3 — 混合动力给出了最好的结果。一家银行的呼叫中心助理正在处理两种类型的数据：一般产品问题和客户特定的帐户数据。帐户数据定向到 VPC 内的模型，一般问题定向到强大的托管 API。敏感数据永远不会泄露，最强模型的质量用于一般问题；成本和适合度一起优化。

提示：决策不必是二元的（全有或全无）。混合架构（按类别路由数据）同时解决了大多数企业场景中的合规性和成本问题。

常见错误

• 假设“自己的托管自动更安全”；而安全取决于管理的质量。
• 认为 TCO 只是 GPU 成本；团队、精力、更新和忘记安全。
• 切换到低/不规则容量的自托管并增加单位成本。
• 使用开放权重模型而不验证许可证和完整性（哈希）。
• 没有在本地服务器上安装像托管 API 一样成熟的监控/日志记录。
• 做出二元决策，根本不考虑混合选项。

总之

• 托管 API 操作起来最简单，但数据会流向提供商； VPC/本地部署将数据保留在您的边界。
• 三个问题推动着这一决策：数据主权、数量/成本可预测性和运营能力。
• “自托管更安全”是一个误解；安全性并不取决于您保存数据的位置，而是取决于您管理数据的程度。
• 计算准确的 TCO：能源、团队、更新、冗余和安全性以及 GPU。
• 混合架构（按类路由数据）在大多数企业场景中同时平衡合规性和成本。

应用任务

选择 AI 用途并将要处理的数据分为隐私类别。使用托管决策提示生成建议。然后填写您自己的托管的 TCO 项目列表，并将 24 个月的总计与托管 API 账单进行比较。最后，编写混合路由规则草案：什么数据去哪里？

清单

• [ ] 我已确定要处理的数据的机密级别和法律限制。
• [ ] 我根据主权+数量+容量做出托管决定。
• [ ] 我计算了完整项目（包括非 GPU）的 TCO。
• [ ] 我检查了自托管的许可证、完整性、补丁和监控。
• [ ] 我考虑了混合路由选项。
• [ ] 我记录了该决定及其推理。