99% 的团队在选 DeepSeek 云部署时，都只看“支持不支持 V4”和“是不是 OpenAI 兼容”，结果踩坑的往往就是这两点。模型同名不代表同一版本，接口兼容也不等于功能一致，更别说数据存储和合规边界。想把 DeepSeek 用在生产环境，你需要先选清楚模型，再选清楚谁在帮你推理，以及推理到底发生在什么地方。

据一些企业用户反馈，同样是叫 DeepSeek 的云端服务，在日志留存、数据出境和工具调用支持上，差异大到足以影响合规审计和上线节奏。

DeepSeek 云部署选型总览

三个关键问题：先想清楚再谈选型

很多人一上来就问“用哪个云最便宜”，其实顺序完全反了。更稳妥的做法是先把三个问题写在白板上：你要的模型版本是什么、谁来运营推理服务、推理可以发生在哪些地理区域。云市场上的 DeepSeek 条目，有的只是打包旧版开源权重，有的才是直连官方托管服务。

一个简单的经验：先锁模型，再锁数据边界，最后才是看价格和生态，否则后面每改一次决策，代码和合规文档都要重写一轮。

一个实用的决策顺序

  1. 锁定模型与功能需求：写清楚模型 ID、上下文长度、输出格式、JSON 严格模式、是否需要工具调用，以及是否涉及图片、多模态。很多团队连“必须支持 JSON 模式”都没写清，就开始比价。
  2. 划定数据边界：能否接受全球或美国多区域处理？是否必须落在某个命名 Region？是否要求在专线或私网内访问而不暴露公网？
  3. 选择运营模式：对比“公共 API”“云厂商托管无服务器模型”“自己运营的专用推理端点”，名字相似，责任完全不同。
  4. 算清总成本：不仅是输入输出 token 价格，还要加上缓存、私网端点、日志、存储、网络流量、GPU 空转成本和运维人力。
  5. 验证“具体这一条”部署：用接近真实的非敏感请求，逐项验证上下文行为、结构化输出、工具调用、流式、延迟、错误处理和日志。不要从“上游模型说明书”推断能力。

我自己在帮团队做选型时，最常见的翻车点，就是大家只测了一个 demo 环境，就默认所有 Region、所有部署类型都一样好用，结果一上生产就发现不支持工具调用或者日志策略完全不同。

Hosted vs 自建：如果你只在这两者之间犹豫

如果你已经确定只在“官方托管 API”与“自建推理”之间做选择，可以先参考更细的对比思路：

  • 业务是否需要完全掌控运行时和数据路径？
  • GPU 利用率是否足够高，值得长期持有算力？
  • 团队是否有能力维护 vLLM/SGLang、Kubernetes、监控与回滚？
  • 合规上是否必须避免第三方运营推理服务？

当这些问题的答案偏向“要强控制、要长期稳定高负载”，自建才开始变得合理，否则官方 API 往往是更快的起步方式。

方案一：官方 DeepSeek API

官方 API 的定位与模型 ID

官方 API 是通往 DeepSeek 自家 V4 服务的最短路径。当前公开文档列出两个模型 ID：deepseek-v4-flash 和 deepseek-v4-pro。OpenAI 兼容接口使用 https://api.deepseek.com，Anthropic 兼容接口则是 https://api.deepseek.com/anthropic。这两个入口都由 DeepSeek 自己运营，功能和更新节奏以官方文档为准。

Official DeepSeek API models and pricing table for V4 Flash and V4 Pro

DeepSeek 已宣布将在 2026-07-24 15:59 UTC 废弃旧别名 deepseek-chat 和 deepseek-reasoner。新项目不要再围绕这些别名搭建，而是直接使用 V4 明确模型 ID，并按最新 API 文档调整请求格式。很多人忽略这一点，等到别名下线才发现监控和告警里压根没记录真实模型 ID。

一个最小化 Node.js 验证请求

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.DEEPSEEK_API_KEY,
  baseURL: "https://api.deepseek.com",
});

const response = await client.chat.completions.create({
  model: "deepseek-v4-flash",
  messages: [
    { role: "user", content: "Reply with exactly: deployment verified" },
  ],
  stream: false,
});

console.log(response.choices[0].message.content);

这个请求只验证了鉴权、Base URL 和模型选择是否正确，并不代表你的生产控制已经就绪。密钥应该放在机密管理服务中，绝不能下发到前端；同时要设置请求超时、记录 token 用量，但避免在日志中存储敏感 Prompt 内容。DeepSeek 官方的首调文档里有多语言示例，可以对照检查。

什么时候优先选官方 API

  • 你明确需要 DeepSeek 自家 V4 模型，而不是云市场里的旧版本权重。
  • 你依赖 DeepSeek 文档中描述的 V4 工具调用、推理字段或 JSON 行为。
  • 业务允许通过公网 HTTPS 访问第三方 API。
  • 负载波动较大，希望按 token 计费，而不是长期持有 GPU。
  • 法务和隐私评审可以接受由 DeepSeek 作为服务运营方。

有用户反馈，在同样的 Prompt 下，官方 V4 的 JSON 严格模式和工具调用稳定性，要明显好于某些云市场打包的旧版模型，这在自动化工作流里差别非常大。

什么时候不要只靠官方 API

如果你的应用必须：

  • 使用云厂商原生的私网端点（如 Azure Private Link、AWS PrivateLink），
  • 严格限制推理只能发生在某个云地理区域或合规边界内，
  • 或者需要把模型运行时完全纳入自家运维和审计体系，

那就需要考虑 Azure、AWS 或自建等其他路径。DeepSeek 公布的隐私政策中提到，其收集的个人数据可能在中国境内处理和存储。企业级部署要以账号条款、合同和数据分级为依据，而不是只看一份面向消费者的隐私摘要。

在评估成本时，可以用官方的 API 成本估算工具先跑一遍，再对照最新价格表确认，避免审批时因为价格更新导致预算不符。

方案二：通过 Microsoft Azure 使用 DeepSeek V4

Azure Foundry 中的 DeepSeek V4 模型

在 Microsoft Foundry 中，DeepSeek-V4-Pro 和 DeepSeek-V4-Flash 被标记为 Direct from Azure 模型。这意味着模型由微软在 Azure 内部托管和运营，请求不会被转发到 DeepSeek 官方 API。这一点会直接影响采购流程、身份认证、网络路径、数据处理责任以及功能对齐程度。

Microsoft Foundry DeepSeek V4 Pro model card showing Direct from Azure, Preview lifecycle, text input and output, one million context, and 128K output limit

据微软公开卡片，当前可依赖的能力包括：

  • DeepSeek-V4-Pro 与 DeepSeek-V4-Flash 的 2026-04-23 版本；
  • 支持文本输入与文本输出的聊天补全；
  • 标称 100 万 token 上下文窗口；
  • 支持文本与 JSON 响应格式；
  • 使用 OpenAI 兼容 v1 接口，但 model 字段填的是 Azure 部署名；
  • 卡片中未记录任何工具/函数调用能力。

微软文档列出了两种 v1 Base URL 模式：https://.openai.azure.com/openai/v1/ 和 https://.services.ai.azure.com/openai/v1/。配置时应以 Foundry 官方端点指南为准，而不是从别的 Azure 资源复制粘贴。生产环境建议优先使用 Entra ID 做鉴权。

Azure 区域与数据区域（Data Zone）

在 2026-07-23 的核查中，V4 提供了 Global Standard 和 US Data Zone 两种形态。Global Standard 允许在模型可用的任意 Azure 区域处理请求，把资源建在某个 Region 并不意味着推理一定发生在同一 Region。Data Zone 则把处理限制在指定地理范围内，但不必然是单一物理 Region。

当时的 Azure 模型可用性矩阵中，没有看到 Europe Data Zone 或“单 Region Standard V4” 的公开条目。也就是说，你在设计阶段就要把“允许的处理地理范围”写进架构文档，再去选 Global Standard、Data Zone Standard 或其他路线，而不是反过来。

Azure 隐私、日志与私网连接

对于 Direct from Azure 模型，微软声明：Prompt 和输出不会提供给 DeepSeek 或其他客户，也不会在未经允许的情况下用于训练基础模型。基础推理是无状态的，但你开启的持久化功能、日志配置以及滥用监控流程，都可能引入额外存储路径。

这话听着有点绕，但关键点是：你打开的每一个“方便调试”的开关，都可能在别处多出一份数据副本，合规评审时要一并算进去。

Azure Private Link 可以关闭公共网络访问，通过私有端点、Private DNS、VPN 或 ExpressRoute 把 Foundry 资源接入 VNet。它只保护网络路径，并不会把 Global Standard 变成“单 Region 推理”。私网配置要按官方指南一步步做，部署类型的选择则是另一条决策线。

Direct from Azure 与 Fireworks 模型的区别

Foundry 里还会看到类似 FW-DeepSeek-V4-Pro 这样的模型 ID，那是 Fireworks 提供的 DeepSeek 模型，而不是 Direct from Azure。两者在数据共享、可用性、合规承诺和开通条件上都不同。微软明确说明，Fireworks 路线不在 EU Data Boundary 承诺范围内，也不能用于 Azure Government。

Azure 的价格会随部署类型、协议、区域和货币变化。更稳妥的做法是：

  • 先看 Azure DeepSeek 官方价格页；
  • 再以订阅里实际显示的估算为准；
  • 最后把 Private Link、监控、存储和内容安全等附加成本加进去。

方案三：在 Amazon Bedrock 与 AWS 上使用 DeepSeek

AWS 上的 DeepSeek 模型家族

Amazon Bedrock 把特定版本的 DeepSeek 开源权重打包成 AWS 模型 ID，通过 AWS API、区域路由和 AWS 计费体系对外提供。写代码前一定要先查 AWS DeepSeek 模型目录，因为不同模型、不同端点家族的支持能力差异很大。

目前常见的几条路线：

  • Bedrock Runtime：提供原生 InvokeModel 和 Converse 接口；
  • Bedrock Mantle：为部分模型提供 OpenAI 兼容端点，但 R1 不在 Mantle 中；
  • Bedrock Marketplace / SageMaker JumpStart：把模型容器部署到 SageMaker 托管算力上，本质是“你租算力自己跑”，不是标准 Bedrock 的按 token 无服务器服务。

很多人看到“OpenAI 兼容”就以为有 Responses API、服务端工具调用等新特性，其实并没有。AWS 的端点对比文档里写得很清楚：Runtime 和 Mantle 支持的 API 家族并不完全相同。

AWS 区域与私网访问

DeepSeek V3.2 和 V3.1 的模型卡，列出了在部分美国、欧洲、亚太和南美 Region 的“就地推理”能力。R1 则不同：AWS 为它定义了一个美国地理推理配置，可以在 N. Virginia、Ohio 和 Oregon 之间路由，提供的是“美国边界”，而不是“单 Region 锁定”。

AWS PrivateLink 支持为 Bedrock Runtime 和 Mantle 创建接口端点，让应用在没有公网网关、NAT 或公网 IP 的情况下访问服务。PrivateLink 只控制网络路径，不会改变模型本身的跨 Region 路由策略。配置时要严格使用文档中列出的服务名。

AWS 的数据处理与日志

AWS 声明，Bedrock 的输入输出不会共享给模型提供方，也不会用于训练或改进基础模型；同时在数据保护文档中说明了传输和存储加密策略。

但这不等于“什么都不存”。Bedrock Runtime 的模型调用日志默认关闭，一旦你开启，完整的请求和响应体就可能被写入 CloudWatch Logs 或 S3，并按你的保留策略长期保存。迁移或审计时，要对照模型调用日志文档确认哪些端点会被记录。

什么时候 AWS 是更合适的选择

  • 你的应用已经深度绑定 AWS 的身份、网络、监控和采购体系；
  • 经过评估后，V3.2、V3.1 或 R1 的质量和功能足以满足需求；
  • 你需要 PrivateLink 或某个 Region 内的 V3.2/V3.1 推理端点；
  • 可以接受 Bedrock 的行为、上下文、工具支持和价格与官方 V4 不完全一致。

有团队在 2026 年的内部评估中发现，同样的业务任务上，V3.2 + Bedrock 的网络与合规优势，综合成本反而优于“硬上 V4 自建”，尤其是在 GPU 紧张、配额申请周期长的情况下。

方案四：在 Google Cloud 上使用 DeepSeek

DeepSeek MaaS 的退场时间表

Google 已在官方开放模型退役计划中列出 DeepSeek MaaS 的迁移时间线。2026-07-21 起所有托管 DeepSeek MaaS 模型 ID 进入弃用状态，计划在 2026-10-21 正式下线。现有用户需要在退役前，梳理所有项目、模型 ID、Region、配额、客户端和回退策略。

说实话，这种“时间已经写死”的服务，不适合作为新项目的长期基础设施。你可以短期过渡，但不要指望它撑完整个产品生命周期。

GCP 上可以替代的路径

如果你打算在 GCP 上做一个更长寿的架构，可以重点评估：

  • 使用 Model Garden 自部署；
  • 或者把工作负载迁移到其他托管端点。

自部署 Vertex AI 端点可以把专用推理资源放在你的项目里，并在支持的情况下使用 Private Service Connect 和 VPC Service Controls 等控制手段。但这也意味着：GPU 配额、端点可用性、自动扩缩、模型权重、容器、推理软件、更新、可观测性和空闲成本，都要你自己负责。

Google 的自定义权重支持表中列出了 DeepSeek-R1、V3 和 V3.1，而退役计划则单独给出了 V3.2 和 OCR 的 Model Garden 自部署替代方案。V4 没有出现在这些官方部署参考里。更稳妥的做法是：对照 Google 提供的模板来部署具体模型，而不是看到 Hugging Face 上有某个名字，就假定 GCP 里也有“一键部署”。

迁移期的数据位置与日志策略

正在退役的 DeepSeek MaaS 卡片标注了“美国多区域处理”。Google 的全球端点无法满足“必须在某个指定 Region 内处理”的要求，因为你无法精确选择推理发生的 Region。对于更宽泛的“美国多区域”要求，需要结合 Google 的位置文档来评估，其中区分了端点名称、静态数据位置和 ML 处理位置。

Google 文档中提到，相关开放模型服务的 Prompt 日志和请求-响应日志默认关闭。一旦开启，请求-响应日志可能写入 BigQuery。如果你要实现 Zero Data Retention，就必须保持这些日志功能关闭，并在周边应用中避免额外存储。不要想当然地认为“默认配置”就覆盖了所有组件。

迁移期的 MaaS 价格只是过渡期价格，自部署的成本需要用云计费器单独估算 VM、GPU、存储、网络和端点资源。

方案五：自建 DeepSeek 推理服务

自建的含义与 V4 模型规模

自建并不只是“在一台笔记本上跑个小模型”这么简单，而是你要自己决定：使用哪份权重、哪种推理引擎、什么算力规格、网络拓扑、存储策略、日志路径、扩缩容策略以及更新流程。运行环境可以是自家机房，也可以是 AWS、Azure、GCP 或其他云上的 GPU 实例。

DeepSeek 官方 V4 模型卡中提到：V4-Flash 是 284B 参数的 MoE 模型，V4-Pro 则是 1.6T 参数模型，两者都支持 100 万 token 上下文。官方的 DeepSeek-V4-Flash 模型卡给出了 vLLM、SGLang 和 Docker 示例，并标注权重为 MIT 许可证。生产容量会受到精度、量化方式、上下文长度、并发数、输出长度、推理引擎和加速器拓扑等多因素影响。

什么时候自建是好选择

  • 你必须完全掌控模型运行时以及周边存储、日志路径；
  • 需要在指定网络和 Region 内提供专用私有端点；
  • 需要锁定特定权重版本、量化配置或推理引擎；
  • 负载高且稳定，足以摊薄长期持有算力的成本；
  • 团队能持续监控延迟、内存、队列、失败率、质量回退和安全更新。

有一位金融行业用户分享过经验：在严格合规要求下，自建 V4-Flash 集群虽然前期投入大，但在高并发报表生成场景中，单任务成本比托管 API 低了约 30%，同时审计和数据出境证明也更容易通过。

什么时候自建会成为负担

  • 业务量很小或极度突发，GPU 大部分时间都在空转；
  • 无法长期预留足够的加速器配额；
  • 没有明确的团队负责补丁、扩缩容、评估、应急响应和成本控制；
  • 你需要快速获得一个可用的 V4 托管 API，并且可以接受公网依赖。

我也不太确定这个说法对不对，但从我看到的案例来看，很多团队是“为了技术情怀”上了自建，半年后发现监控、告警、回滚和安全更新都跟不上，最后又退回托管服务，等于多走了一圈弯路。

功能与数据驻留：如何真正看懂“在本地处理”

Residency 不只是“资源建在哪个 Region”

如果数据驻留是你决策的关键因素，不能只看“资源 Region”这一项。更准确的做法是拆成几个维度：

  • 资源位置（Resource Location）；
  • 端点暴露位置（Endpoint Location）；
  • 实际推理发生的地理范围（Processing Geography）；
  • 日志与备份的存储位置；
  • 第三方服务（监控、网关、安全扫描）的数据路径。

很多云厂商会在文档里写“US multi-region”或“Global Standard”，这往往意味着推理可以在多个 Region 之间动态调度。对某些合规场景来说，这没问题；但对“必须锁定单一 Region”的要求来说，就完全不合格。

一个可复用的成本估算框架

不要只比较“输入 token 单价”。用同一份工作负载和质量目标，对每个候选方案都算一遍：

托管服务月度成本 ≈
  缓存未命中输入 token
  + 缓存命中输入 token
  + 输出与推理 token
  + 预留吞吐（如有）
  + 私网端点与网络费用
  + 日志、追踪、存储与检索
  + 数据传输
  + 安全、评估与网关服务

自建月度成本 ≈
  GPU/加速器小时 × 副本数
  + CPU、内存、存储与网络
  + 空闲与故障转移容量
  + 监控与备份
  + 工程与值班运维

模型质量本身也是成本的一部分。单价更低的模型，如果需要更长的 Prompt、更多重试、更大的输出或额外验证，最终“每个成功任务”的成本可能更高。更靠谱的做法是：对同一批任务做基准测试，算“成功任务成本”，并把托管与自建的估算分开记录。

生产部署检查清单

上线前必查的 12 个维度

  • 模型身份：记录清楚提供方、模型 ID、版本、生命周期状态和退役日期。
  • 能力范围：实际测试文本、JSON、结构化输出、流式、推理字段、工具调用、上下文和输出上限。
  • 处理位置：区分资源 Region 与真实推理地理范围。
  • 网络路径：明确是否允许公网 HTTPS，还是必须使用 Private Link、PrivateLink 或 Private Service Connect。
  • 认证方式：优先使用工作负载身份或短期凭证，绝不在浏览器或移动端下发 API Key。
  • 数据最小化：在推理前尽量脱敏，避免传入不必要的个人、财务、健康、凭证和机密信息。
  • 日志策略：逐一确认请求、响应、追踪、错误、缓存、网关和分析的落地位置。
  • 保留周期：为日志、数据库、对象存储和备份设置删除周期，并在合规文档中写明。
  • 可靠性：配置超时、带退避的重试、必要时的幂等、熔断、配额和降级回退路径。
  • 评估机制：在更换提供方、模型版本、量化、上下文或系统 Prompt 前，跑一遍固定回归集。
  • 预算控制：对 token 量、输出长度、缓存命中率、端点在线时间和空闲 GPU 容量设置告警。
  • 退出计划：写清楚当提供方退役模型或调整限制时，应用如何迁移。

有用户在 2026 年的一个真实事故中，因为没有“退出计划”，在某云宣布模型退役后，被迫在两周内紧急迁移，结果业务连续性和合规审计都受到影响。这类风险，完全可以在设计阶段就写进文档。

场景推荐：不同需求下的优先路线

场景一：要用最新 V4 功能，又不想自己管 GPU

  • 优先考虑：官方 DeepSeek API。
  • 适合需求：追求最新 V4 能力（如特定推理行为、工具调用），负载波动大，对公网依赖可接受。
  • 风险点：数据可能在中国境内处理，需要法务与合规单独评估；价格调整要持续关注。

场景二：企业已经全面上云 Azure，需要统一治理

  • 优先考虑：Azure Foundry Direct from Azure DeepSeek V4。
  • 适合需求：统一使用 Azure 身份、网络、日志和私网连接，且能接受卡片上记录的功能范围（目前不含工具调用）。
  • 风险点：Global Standard 与 Data Zone 的处理地理范围不同，文档中公开信息有时存在不一致，需要在订阅内实测确认。

场景三：AWS 为主云，V3.x 或 R1 质量已验证可用

  • 优先考虑：Amazon Bedrock DeepSeek V3.2 / V3.1 / R1。
  • 适合需求：深度绑定 AWS 生态，需要 PrivateLink 和 Region 内推理，且业务对 V4 的依赖不强。
  • 风险点：不要在 Bedrock 中使用 V4 的模型 ID；Mantle 与 Runtime 的能力差异要提前验证。

场景四：GCP 为主，但不想被退役时间卡死

  • 优先考虑：Vertex AI 自部署 DeepSeek 模型 或迁移到其他托管服务。
  • 适合需求：必须留在 GCP 账单与网络体系内，又能接受自建带来的运维责任。
  • 风险点：MaaS 已进入退役窗口，新项目不要再依赖；自部署成本和配额申请要预留足够缓冲。

场景五：强合规、强控制、长期高负载

  • 优先考虑：自建 DeepSeek V4 推理服务。
  • 适合需求：对数据路径和模型版本有极强控制需求，负载高且稳定，有专门团队负责运维与评估。
  • 风险点：前期投入大，运维复杂度高，一旦团队变动或预算收紧，容易出现“没人敢动”的技术债。

如果你正在做一个会活很多年的核心系统，这套判断方法值得反复拿出来对照几次，甚至可以直接贴进团队 Wiki，当作架构评审的必备清单。

常见问题

Q：DeepSeek V4 在 Amazon Bedrock 上能用吗？

A：目前不能。根据 2026-07-23 的 AWS 目录，Bedrock 只列出了 DeepSeek V3.2、V3.1 和 R1，没有任何 V4 条目。原因在于 Bedrock 采用的是特定版本的开源权重打包，而不是自动跟随官方最新 V4 服务更新。如果你在 Bedrock 代码里直接填入 DeepSeek 或 Azure 文档中的 V4 模型 ID，请求会失败或被路由到错误的模型。建议在写代码前对照 AWS 官方 DeepSeek 模型卡，按其列出的模型 ID 与端点家族来适配，并在评估阶段确认 V3.x 或 R1 是否满足质量需求。

Q：DeepSeek V4 能通过 Microsoft Azure 使用吗？

A：可以。Microsoft Foundry 中列出了 DeepSeek-V4-Pro 和 DeepSeek-V4-Flash，并标记为 Direct from Azure 模型。公开卡片显示支持文本输入输出、JSON 响应和 100 万 token 上下文，但没有记录工具调用能力。原因在于 Azure 是以自家托管的方式提供这些模型，功能范围以 Azure 文档为准，而不是完全复制官方 API。实际使用前，应在订阅中核实模型生命周期、输出上限、部署类型（Global Standard 或 Data Zone）以及价格，并用一组固定测试用例验证行为是否符合预期，避免因为文档版本不一致导致误判。

Q：现在还能在 Google Cloud 上新建 DeepSeek MaaS 部署吗？

A：不建议这么做。Google 已在 2026-07-21 将所有托管 DeepSeek MaaS 模型标记为弃用，并计划在 2026-10-21 正式退役。原因是 Google 正在调整开放模型策略，鼓励用户改用 Model Garden 自部署或迁移到其他托管服务。如果你现在再新建 MaaS 端点，很快就要面对一次强制迁移，既增加工程成本，也会给合规和运维带来额外压力。更稳妥的做法是直接评估自部署 Vertex AI 端点或其他云上的长期可用方案。

Q：使用 Private Link / PrivateLink 就一定能保证数据驻留吗？

A：不能。私网端点的作用是保护网络路径，让请求不经过公网，而不是决定推理在哪个 Region 执行。真正决定数据驻留的是服务的部署类型、推理路由配置和云厂商的处理位置规则。例如 Azure 的 Global Standard 可能在多个 Region 之间调度，AWS 的 R1 US geo profile 也会在几个美国 Region 间路由。配置时应同时查看模型卡、区域说明和数据处理文档，并在合规设计中明确写出“允许的处理地理范围”，而不是只勾选“启用私网访问”。

Q：不同云都说“OpenAI 兼容”，功能是不是就完全一样？

A：不是。所谓 OpenAI 兼容，通常只指请求和响应的大致格式相似，比如 messages 数组和 model 字段，但在模型 ID 命名、鉴权方式、工具调用字段、推理参数、结构化输出、上下文上限、流式行为和错误码等方面，都可能存在差异。有的云只支持基础的 chat completions，有的则扩展了自家特有字段。实际接入时，应以各云的官方文档为准，逐项验证你依赖的功能，而不是假定“能跑 OpenAI SDK 就说明一切都一样”。

Q：自建 DeepSeek 推理是不是天然就更私密？

A：并不一定。隐私取决于整个运行时环境，而不仅仅是“模型在自己机器上”。网络拓扑、API 网关、日志系统、分布式追踪、缓存、数据库、对象存储、备份策略、插件系统、访问控制和运维习惯，都会影响数据暴露风险。如果你在自建环境中把完整请求写入明文日志，或者把调试数据长期存放在无加密的对象存储里，实际隐私风险可能比合规良好的托管服务更高。自建前要先设计一套端到端的数据最小化和访问控制方案，并定期做安全审计和演练。

在真正落地 DeepSeek 部署时，你会发现这不是一次性决策，而是一套会随模型版本、云策略和合规要求不断演化的长期工程。如果你正站在选型的十字路口，希望这份指南能成为你反复翻看的那份“底稿”，比随手问几个人的经验更系统，也多一点安全边界感。