本地部署还是云端大模型？隐私、成本与运维决策指南

先给答案：本地部署、云端模型 API 和混合架构没有脱离场景的统一赢家。高敏数据、离线要求和深度定制会提高本地方案的价值；快速试用、弹性流量和持续获得新模型能力通常更适合云端；多数企业最终需要按请求分类的混合路由，而不是把所有数据押在一种部署方式上。

先把四种“部署方式”说清楚

“私有化”不是一个足够精确的采购词。要写清楚权重放在哪里、推理由谁运行、提示词和附件经过哪些组件、日志保存多久、谁能访问、更新怎样进入、是否调用外部检索或工具。站内的模型部署概念页解释了服务化基础；需要快速运行开源模型时，可继续查看Ollama 原理与使用边界和vLLM 词典页。

隐私判断不能只问“数据是否出域”

正确做法是画数据流：用户输入、系统提示词、检索片段、附件、嵌入、输出、反馈、追踪日志、缓存、备份和人工复核样本分别去哪。还要区分“不会用于训练”“不持久保存”“不会被人工查看”“只在指定区域处理”这几个不同承诺。

例如，Microsoft 的 Azure Direct Models 数据隐私文档说明提示词、输出和训练数据默认不会被用于训练基础模型，但也明确列出有状态功能、区域类型和滥用监控的处理差异。Google Cloud 的 Vertex AI 零数据保留说明同样区分训练限制、滥用监控和实现 ZDR 时需要停用或配置的功能。

AWS 当前的 Bedrock 数据保留文档把 none、default 和 provider_data_share 作为不同模式，并提醒模型可用性会受允许模式影响。不能把一个供应商、一个区域或一个功能的条款复制给所有云 API；上线前应冻结产品、模型 ID、区域、API、保留设置、合同版本和子处理方清单。

同一云服务内，不同功能也可能有不同数据路径

不能只问销售“这个平台是否合规”，还要逐项列出在线推理、批处理、上下文缓存、文件上传、微调、RAG、搜索 grounding、Agent 状态、评测和反馈功能。Google Cloud 的 生成式 AI 安全控制表按模型和功能分别列出数据驻留、客户管理密钥、VPC Service Controls 与 Access Transparency 支持情况，这正说明“平台支持某控制”不等于所有功能都支持。

采购验收表应以“服务 + 模型 ID + 区域 + 功能 + 配置”的组合为最小单位。例如，在线推理满足区域要求，并不能自动证明全局批处理、第三方模型或联网工具也在同一边界内。每次增加功能都要重新画数据流，并把控制证据链接、截图日期、配置导出和责任人一起保存。若供应商条款、模型提供方或处理区域变化，应触发变更评审，而不是等年度审计才发现。

零数据保留也不等于零安全风险

即使请求不落盘，提示注入仍可能诱导系统泄露上下文、越权调用工具或把内部数据发送到外部目标。AWS 的 提示攻击说明区分 jailbreak 与 prompt injection，但任何单一过滤器都不应成为唯一控制。更稳妥的做法是限制工具权限和目标域名，对高影响动作进行参数校验与人工批准，将检索内容视为不可信输入，并记录“模型建议了什么”和“系统实际执行了什么”。

NIST 的 AI RMF Core把风险管理组织为 Govern、Map、Measure、Manage，并强调贯穿生命周期；生成式 AI Profile则提供面向生成式系统的配套风险考虑。它们都不能替代适用法律或合同审查，但能防止团队只买一台服务器就宣称完成治理。

中国企业还要判断哪些合规适用范围？

部署位置本身不能决定是否合规。判断顺序应是：谁在处理什么数据、是否向境内公众提供服务、输出是否对外传播、是否属于特定高风险或拟人化场景、数据和接收方是否位于境外。下面是项目立项时的筛查问题，不是法律意见；命中后应由数据保护、法务和业务负责人结合当前法规、行业规则与合同确认。

因此，“本地还是云端”只是架构问题的一部分。云端是否跨境要看实际区域、接收方和访问路径；本地系统也可能因远程运维、日志平台、备份或外部工具产生新的接收方。向公众提供服务、生成内容传播和拟人化交互属于不同适用问题，不应在采购表里合并成一个“已合规”复选框。

成本应该怎样算，而不是猜回本时间？

云端月成本可近似拆为输入 token、输出 token、缓存、微调/批处理、存储、检索、网络、日志和支持费用；自建月均成本则包括服务器或租赁折旧、GPU/CPU/内存、机房、电力、网络、备件、软件支持、监控、值班、升级、安全测试和闲置容量。统一口径可以写成：

单位有效任务成本 = 周期内全部拥有成本 ÷ 通过质量与时延验收的有效任务数。

“有效任务”很重要：失败、重试、超时、人工返工和被安全策略拦截的请求都会消耗资源。只用 GPU 采购价除以 API 单价，会遗漏利用率、并发形态、输出长度、维护人力和资金占用；只看 API 标价，也会漏掉检索、日志、网络和高峰预留。

性能比较要使用真实请求分布

平均延迟不足以做决策。至少记录首 token 延迟（TTFT）、每输出 token 时间（TPOT）、端到端 p50/p95/p99、吞吐、排队长度、并发、输入/输出长度、超时和错误率。vLLM 的 指标设计文档明确区分服务级与请求级指标，并列出 TTFT、TPOT、运行/等待请求等生产观测项；数据并行部署文档还提醒 API server 本身可能成为大规模 DP 的瓶颈。

本地部署也不能用“单人聊天很快”外推多人生产。长上下文会扩大 KV cache，流式输出与批处理负载不同，工具调用和 RAG 还会增加外部等待。需要压缩权重时，可先阅读站内模型量化说明；量化带来的显存、速度和质量变化必须在目标硬件、模型与任务集上重新测量。

模型能力变化怎样纳入决策？

云端模型可能更快获得新能力，也可能出现版本退役、配额变化、输出风格改变或区域暂不可用；本地权重可以冻结，却需要团队自行评估新版本、修复推理引擎和迁移量化制品。两者的核心差异不是“会不会变化”，而是变化由谁发起、谁验证、谁承担失败。

因此，模型注册表至少要记录提供方、模型 ID、权重或服务版本、上下文上限、许可、区域、发布日期、批准用途和回退版本。固定回归集应包含事实问答、中文长文、结构化输出、拒答、引用、工具参数、注入攻击和业务难例。升级前后使用相同解码参数盲测；若供应商不提供固定版本，也要在网关记录实际返回的模型标识和变更日期。没有版本证据的“体验变好了”不能进入采购报告。

质量指标也不能只用一个平均分。高影响任务应分别统计严重事实错误、越权动作、敏感信息泄露和无法回退的失败；低影响写作可以更多关注人工编辑时间。只有把错误按影响分层，团队才能决定某类请求可以自动化、需要人工复核，还是必须禁用。

本地部署承担的运维责任有哪些？

自建推理至少涉及权重与许可证、镜像和依赖、GPU 驱动、容量规划、鉴权、密钥、传输加密、日志、备份、漏洞响应、模型评测、升级与回滚。Kubernetes 的 资源管理文档解释 requests/limits 如何参与调度和资源约束；探针文档则区分 startup、readiness 和 liveness，并警告错误探针可能造成级联故障。安装成功远远不等于生产可用。

自建系统的应用安全最低线

生产服务不应直接把推理端口暴露给所有内网用户。入口要有身份认证、租户隔离、限流、请求大小与并发上限；模型进程只获得完成任务所需的文件、网络和工具权限。镜像使用固定摘要，权重记录来源与哈希，密钥不得写进镜像或提示词，管理面与推理面分离。Kubernetes 的 应用安全清单覆盖 service account、网络策略、安全上下文、镜像和 Secrets 等基础控制，可作为容器平台检查入口，但仍需结合模型网关和业务工具权限补充。

至少演练四类事故：模型节点耗尽显存、检索库返回越权文档、工具调用试图执行未批准动作、日志管道意外写入完整敏感提示词。演练输出应包括发现时间、受影响请求、自动隔离、人工通知、证据保全、恢复和后续删除。没有演练的“完全内网闭环”只是架构图，不是已验证的安全能力。

谁拥有最终决策和持续复核责任？

部署方式涉及业务负责人、数据所有者、安全、法务/合规、平台工程、模型评测和采购。NIST 的 AI RMF Playbook提供 Govern、Map、Measure、Manage 的建议行动，可帮助团队把一次选型会议变成持续治理。每个用例都应有可暂停服务的责任人、可接受风险批准人和复核周期；不能把“厂商负责平台”误解成组织无需对使用后果负责。

建议每季度复核模型与服务状态、数据流、权限、价格、利用率、质量难例和退出路径；发生模型退役、地区政策变化、重大漏洞、任务用途扩大或接入新数据源时立即复核。复核不必每次重新采购，但必须能说明上次结论是否仍成立。

什么时候适合混合架构？

混合架构不是把两个系统随意拼接，而是把路由规则显式化。例如：公开资料摘要走云端高能力模型；含客户标识的请求先脱敏；受限代码或不能出域的文档走本地；低置信度或高影响决策转人工。RAG 数据是否出域取决于检索片段最终进入哪个模型，不能因为向量库在本地就默认安全。相关原理见站内RAG 指南。

六步试点：用证据替代“终极对比”

1. 定义任务与红线：列出用户、数据等级、允许区域、禁止外发字段、人工审批和不可接受输出。
2. 冻结测试集：从真实工作中抽取并脱敏，覆盖常见任务、长尾难例、攻击输入、拒答和工具故障；保存版本和批准记录。
3. 建立三条可比路径：至少一个云端候选、一个本地候选和明确的人工/规则回退；不要同时改变提示词与知识库。
4. 压测真实分布：按请求长度和并发分桶，记录 TTFT、TPOT、p95/p99、吞吐、错误、资源和每个有效任务成本。
5. 验证控制：检查数据流、权限、保留、日志脱敏、故障路由、限额、升级回归与删除传播，并留下证据。
6. 小流量上线并设退出条件：先灰度，定义质量、成本和故障阈值；任何路径都必须能停止、回滚或切换。

如果用户主要在断网设备或边缘节点运行，还应结合站内边缘 AI 说明评估功耗、内存、散热和升级渠道。桌面工具的易用性比较则属于另一意图，可查看本地大模型工具对比，不要把个人体验页当成企业架构证据。

常见问题

数据不出内网就一定安全吗？

不是。内网仍有账号越权、恶意内部人员、未修复漏洞、模型与镜像供应链、日志明文、备份外泄和错误工具调用等风险。本地把更多控制权交给组织，也把更多责任交给组织。

云端 API 会不会用企业数据训练模型？

不能一概而论，也不能只看营销摘要。应以具体供应商、服务、模型、区域、API、保留模式、功能和合同版本为准，分别核对训练限制、持久化、人工复核、滥用监控和子处理方。

怎样计算本地部署多久回本？

先运行代表性试点，得到并发、token、利用率、质量返工和运维工时，再用统一周期比较单位有效任务成本。没有真实负载就不存在可靠回本月数；采购价与 API 标价的简单相除会系统性漏项。

模型越小，本地成本一定越低吗？

单次推理资源可能降低，但若质量下降导致更多重试、人工复核或无法完成任务，单位有效任务成本反而可能上升。应把质量门槛放在成本分母中。

上线验收清单

• 每类数据和请求都有允许路径、禁止路径、负责人和审计证据；
• 供应商条款或本地组件版本、模型哈希、许可证和区域均已冻结；
• 真实负载的质量、TTFT、TPOT、p95/p99、吞吐、错误和成本已测量；
• 鉴权、最小权限、密钥、日志脱敏、保留、删除、备份和漏洞响应已演练；
• 模型/引擎升级必须经过固定测试集回归，旧制品可以回滚；
• 云端限流、本地节点故障、网络断开和错误路由均有安全回退；
• 季度复核数据流、价格、模型退役、合同和利用率，不沿用过期结论。

编辑复核记录：本文于 2026 年 7 月 16 日依据 Microsoft、Google Cloud、AWS、vLLM、Kubernetes、NIST 及中国人大网/国家网信办现行公开资料复核；新增中国企业适用范围筛查，不把部署位置直接等同于隐私、跨境、备案、标识或拟人化服务的法律结论。价格、云功能、区域、模型、条款和法规均需在实际采购或上线时重新确认。

结论：真正专业的选择不是“本地更安全”或“云端更便宜”，而是把数据、能力、负载、责任和退出路径逐项变成可验证条件。能明确哪些请求去哪里、为什么、成本多少、失败后如何回退，并能在模型、条款和业务变化后重新验证的架构，才是可运营、可审计的大模型部署方案。