一家中国人工智能企业发布开放模型之后，海外开发者能够使用这些模型，是否就意味着企业已经在当地建立了商业业务？
DeepSeek提供了一个值得研究的案例。
这些活动表明，模型开发者的技术成果可以通过海外云平台进入当地数字服务体系。
但模型被部署、开发者调用模型，以及云服务商向客户收费，并不等于DeepSeek直接取得相应客户合同或当地营业收入。
本案例关注的问题是：开放模型如何经过海外云平台的部署、计费、数据处理和应用集成，转化为企业及开发者能够实际使用的服务？技术提供者与云服务商分别创造什么价值，又承担哪些不同的经营责任？
一、从DeepSeek模型到海外云服务：研究对象是什么？
1. DeepSeek提供的核心资产是什么？
DeepSeek的核心研究对象是人工智能模型及相关技术成果。
其官方DeepSeek-R1仓库区分R1、R1-Zero，以及基于Qwen和Llama等基础模型形成的六个蒸馏模型。5
仓库对代码、模型权重及不同蒸馏模型的许可来源分别作出说明。
从作者分析看，开放模型的意义在于为第三方部署、适配和集成提供技术条件，使模型不必完全依赖开发者自行经营的应用或接口才能传播。
不过，不同模型版本及其许可条件不能简单合并，开放许可也不等于所有云平台服务均免费使用。
2. 为什么不能把AWS和OVHcloud视为DeepSeek的海外分公司？
AWS与OVHcloud是独立云服务提供商，负责各自平台上的模型部署、计算资源及相关客户服务。
AWS于2025年1月介绍，通过Bedrock Marketplace、SageMaker JumpStart及其他基础设施路径提供DeepSeek-R1相关部署方式。4
OVHcloud则在2025年4月宣布，将DeepSeek-R1的Llama蒸馏版本纳入AI Endpoints服务，并使用法国Gravelines数据中心提供部署基础。3
这些资料证明第三方平台建立了具体的模型服务入口，但不能据此将其数据中心、客户关系及平台服务收入归属于DeepSeek。
模型技术的国际传播与开发者自身的海外经营，是两个需要分别判断的问题。
3. 模型版本为什么影响经营判断？
DeepSeek-R1完整模型、R1蒸馏模型及DeepSeek 3.1属于不同的技术对象。
AWS当前R1模型卡对应特定托管模型版本，并已将其生命周期标示为Legacy，列出2027年3月30日的预定终止日期。1
因此，不能将不同版本的部署记录合并为同一项产品表现，也不能以2025年模型发布消息判断2026年的主推服务状态。
二、从美国托管到法国应用集成：如何比较两种平台机制？
1. 为什么选择美国与法国？
两者均有具体技术服务记录，而不只是模型可供全球下载的声明。
但美国资料更侧重模型托管与基础设施分发，法国资料同时展示平台服务和应用集成。
这种差异决定了两地适合比较服务组织方式，而不能直接比较DeepSeek的单国商业成果。
2. 模型如何转化为可消费服务？
本案例从三个层次观察。
第一是技术供给。 DeepSeek提供模型权重及相应许可，使第三方有条件开展部署。
第二是云平台服务。 AWS和OVHcloud分别组织计算资源、调用入口、使用计费及数据处理安排。
第三是应用集成。 企业可进一步将模型接入具体任务，例如OVHcloud在ALPHA助手中使用DeepSeek 3.1处理检索增强生成结果。2
从作者分析看，三个层次可能形成从模型发布到实际应用的服务路径，但各层的客户关系、收费与运营责任并不自动归属于同一主体。
3. 如何判断这一国际化路径的实际价值？
美国与法国案例说明，海外平台可以将DeepSeek模型转化为自身提供的数字服务。
但现有资料尚不足以确认DeepSeek在美国或法国直接签署了哪些客户合同、获得多少当地收入，或建立了怎样的直营团队。
因此，本案例研究的是中国人工智能模型经由海外云平台实现技术服务化的组织机制，而非DeepSeek已经完成美国与法国双市场直营商业化的证明。
真正值得进一步观察的，是模型技术、平台基础设施及应用服务如何协作，以及这种协作最终能否为技术开发者形成可持续、可识别的商业回报。
三、美国AWS：DeepSeek-R1如何通过云平台转化为模型服务？
DeepSeek-R1进入美国AWS服务体系，体现了模型开发者与云平台之间的技术供给和服务运营分工。
1. AWS如何组织模型部署？
2025年1月30日，AWS宣布通过Amazon Bedrock Marketplace和SageMaker JumpStart提供DeepSeek-R1相关部署方式，涉及美国俄亥俄、俄勒冈区域，并介绍蒸馏模型导入及EC2部署等其他路径。4
从作者分析看，云平台的作用，是将模型转化为能够在其计算基础设施上部署、运行和调用的技术服务。
模型开发者提供技术成果，平台负责组织相应计算资源及服务入口。开发者可以选择平台支持的部署方式，而不必自行建立完整的底层计算环境。
但不同部署路径具有不同的服务安排，不能简单视为同一种产品。
2. 模型调用与收费如何区分？
AWS历史部署公告说明，Bedrock Marketplace、SageMaker JumpStart及EC2相关路径，涉及所选推理实例的基础设施费用。4
而Amazon Bedrock现行DeepSeek-R1模型卡列出模型标识deepseek.r1-v1:0，其标准服务采用按Token使用量计费的方式。1
这说明，第三方使用DeepSeek技术时，实际面对的可能是不同的计算资源和计费结构。
从作者分析看，平台将模型能力转化为收费服务，并不意味着模型开发者直接向每个终端使用者收费。
AWS相关收费信息不能直接推导DeepSeek从美国客户取得的授权收入或服务收入。
3. 区域部署与数据处理意味着什么？
AWS现行R1模型卡列有美国跨区域推理标识，相关来源及目标区域涉及北弗吉尼亚、俄亥俄和俄勒冈，未列出该模型的全球跨区域推理方式。1
这些是模型服务的计算区域安排，不代表客户所在地，也不是DeepSeek在美国设立办公室的证明。
AWS在2025年公告中还表示，其Bedrock及SageMaker相关客户数据不会共享给模型提供方，也不会用于改进模型。4
这是AWS对相应服务的数据处理说明，不能据此推断DeepSeek直接取得AWS客户数据。
4. 为什么必须关注模型生命周期？
截至2026年10月22日，AWS的DeepSeek-R1模型卡将该版本标示为Legacy，并列出2027年3月30日为预定生命周期终止日期。1
从作者分析看，云平台部署并不意味着某一模型版本会永久维持相同服务状态。
企业使用托管模型时，需要考虑版本生命周期及后续应用维护条件。
美国案例说明，海外云平台可以为开放模型提供部署、调用、计费和数据处理机制，但这些服务能力属于具体平台安排，不能直接等同DeepSeek在美国的直营商业能力。
四、法国OVHcloud：从模型部署到AI应用集成
与AWS侧重多种模型部署路径不同，法国OVHcloud的公开资料同时展示了模型接口服务和具体应用集成。
其AI Endpoints服务与ALPHA助手涉及不同的DeepSeek模型版本，需要分别观察。
1. OVHcloud如何提供模型服务？
2025年4月29日，OVHcloud宣布推出AI Endpoints服务，其中包括DeepSeek-R1的Llama蒸馏版本。3
公告将法国Gravelines数据中心列为相关服务部署地点，并说明采用按使用量计费方式。
OVHcloud还介绍，开发者可以先通过沙盒测试模型，再将其用于应用开发和部署。
从作者分析看，这种服务方式降低了开发者直接管理模型推理基础设施的需求，使模型调用能够成为应用开发流程的一部分。
但公告仅说明采用R1的Llama蒸馏版本，不能将其写为R1完整模型，也不能自行指定模型参数规模。
2. 法国部署涉及哪些数据服务安排？
OVHcloud表示，AI Endpoints相关数据托管于欧洲，并将这一安排与其数据主权和安全服务主张联系起来。3
这属于云服务商公开介绍的服务条件。
从经营机制看，模型应用除了计算能力，还涉及数据存放地点、调用方式及平台服务责任。
但法国数据中心部署，不意味着所有使用该服务的客户均位于法国，也不能仅依据供应商声明认定其满足所有适用法律要求。
3. ALPHA助手如何进一步使用DeepSeek模型？
OVHcloud Labs介绍，其ALPHA助手首先索引公司网站内容并执行检索，再使用DeepSeek 3.1处理检索增强生成（RAG）的结果。2
同一应用流程还使用Llama及Mistral模型。
这一案例与AI Endpoints发布中的R1蒸馏Llama版本不同，不能将两者描述为同一模型的完整应用路径。
从作者分析看，ALPHA体现了模型作为第三方应用技术组件的另一层价值：模型不再只是独立调用对象，而是参与检索、信息处理和回答生成的应用流程。
不过，这属于OVHcloud对自身集成方式的说明，并非独立性能验证，也不代表全部用户请求均调用DeepSeek 3.1。
法国案例展示了从模型接口到实际应用集成的服务路径，但平台应用的存在，尚不足以证明DeepSeek与OVHcloud之间存在特定付费合同或可量化的商业回报。
五、从模型技术到终端应用：海外平台承担了哪些交接责任？
DeepSeek提供模型技术及相应许可条件，为第三方部署与集成创造基础。其官方仓库分别说明模型权重、代码及派生模型涉及的许可来源。5 从作者分析看，技术提供者首先需要使模型身份和使用条件清晰，但开放许可本身并不规定第三方云平台的全部服务责任。
当模型进一步进入具体应用，应用提供者还需要承担任务设计、模型组合及终端服务交付。OVHcloud对ALPHA助手的介绍，展示了将DeepSeek 3.1用于检索增强生成流程的集成方式，但这一应用安排属于平台方披露，并未独立证明服务效果。2 从作者分析看，开放模型服务化的关键交接关系是：技术提供者明确模型与许可，云平台承担基础设施及调用服务，应用方组织具体任务和用户交付。三者只有在各自责任清晰的条件下，才能构成可持续的服务链。
六、从开放模型到服务接口：企业应当如何选择部署方式？
开放模型能够被第三方部署，并不意味着不同平台提供的是完全相同的服务。企业真正需要选择的，不只是模型名称，还包括具体版本、部署路径、调用接口与后续维护条件。
1. 模型选择为什么需要落实到具体版本？
DeepSeek官方仓库区分R1、R1-Zero及不同基础模型形成的蒸馏版本，并分别说明相关许可来源。5
从作者分析看，企业选择模型时，应当先确认实际部署的技术对象，再判断相应许可、推理资源及应用适配要求。
例如，如果企业需要使用R1完整模型，就不能仅依据某个平台提供R1蒸馏模型的公告，认定两者具有相同的技术能力和使用条件。
如果企业计划采用DeepSeek 3.1，也不能直接援引R1的部署记录来证明该版本在相同平台上具有一致的服务安排。
作者建议，模型选型至少应同时明确版本身份、服务提供方和使用条件，避免以品牌名称代替具体产品决策。
2. 自行部署与托管调用应当如何选择？
从经营机制看，选择部署路径需要考虑企业愿意承担多少基础设施管理工作，以及应用是否需要持续、稳定地调用模型。
如果企业具备相应技术运维能力，并需要较高的部署控制程度，可以评估基础设施型方案；如果主要目标是通过平台接口获得模型能力，则应重点评估托管服务条件。
但具体选择仍取决于部署成本、应用需求和可获得的服务，而不能仅凭开放模型属性决定。
3. 多模型集成意味着什么？
OVHcloud对ALPHA助手的介绍显示，DeepSeek 3.1参与检索增强生成流程，同时还有Llama及Mistral模型承担其他环节。2
从作者分析看，这类结构意味着应用开发者可以按具体任务选择模型，而不必将整个应用绑定于单一模型。
如果不同模型的适用任务、接口及运行要求存在差异，应用方就需要明确各环节的输入输出关系，并考虑替换其中某一模型时对整体流程的影响。
这是一种有条件的应用架构启发，并不意味着ALPHA已经采用特定的自动切换、备份或性能优化制度。
七、从Token计费到数据处理：服务价值与经营责任如何分配？
模型成为云服务之后，用户面对的不只是技术能力，还包括计费方式、计算资源与数据处理条件。
这些因素决定企业如何评价模型使用成本，以及由谁承担实际服务运营责任。
1. 不同计费方式如何影响经营选择？
OVHcloud在2025年4月发布AI Endpoints时，也介绍了按使用量计费的服务模式。3
从作者分析看，企业若采用按调用量计费的方案，应关注实际请求规模及单位使用成本；若采用需要配置计算实例的方案，则还需要考虑资源利用率与持续运行成本。
如果业务使用量尚不稳定，按使用量付费可能有助于控制初期投入；如果调用需求长期稳定，基础设施型部署是否具有成本优势，则需要结合实际资源使用情况测算。
两种方案不存在脱离业务规模的普遍优劣。
尤其需要区分：云平台的使用费用，是平台向其客户提供计算或模型服务的收费安排，并不能直接作为DeepSeek取得授权收入的证据。
2. 数据处理责任应当怎样划分？
AWS在2025年部署公告中表示，相关Bedrock及SageMaker客户数据不会与模型提供方共享，也不会用于改进模型。4
OVHcloud在AI Endpoints发布时，则强调数据托管于欧洲及相关数据主权服务主张。3
这些分别属于云服务商对自身服务的数据处理说明。
从作者分析看，企业选择模型平台时，应当将数据存放位置、数据使用规则和服务提供方责任作为独立条件考察。
如果业务涉及特定地域的数据处理要求，就需要进一步确认选定服务的实际部署区域与适用条款，而不能仅依据模型来源地判断。
同样，数据在欧洲托管不自动构成所有法规要求均已满足的证明。
3. 谁应当对终端服务负责？
在第三方云平台模式下，DeepSeek提供模型技术，AWS或OVHcloud组织相应云服务，应用开发者则可能进一步面向自身用户提供产品。
从作者分析看，技术提供、基础设施运营和终端应用交付可以形成相互依赖但责任不同的关系。
如果服务发生中断、计费条件变化或模型版本调整，企业需要首先识别问题发生在哪个环节，再根据实际服务关系确定处理路径。
作者建议，将模型权利、云服务责任和终端应用责任分别纳入服务选择，而不是因为采用同一模型就推定各方承担相同义务。
八、从模型上线到生命周期管理：开放模型服务如何保持持续可用？
模型被海外平台采用，并不是一个只有起点、没有变化的过程。
第三方平台可以调整产品状态、服务区域及版本安排，应用开发者也需要根据这些变化重新评价模型的持续适用性。
1. AWS的Legacy状态提出什么经营问题？
截至2026年10月22日，AWS Bedrock的deepseek.r1-v1:0模型卡已将生命周期标示为Legacy，并列出2027年3月30日为预定终止日期。1
这意味着，2025年AWS宣布提供R1相关服务，与2026年该具体托管版本的生命周期状态，是两个不同时间的事实。
从作者分析看，对于依赖这一版本的企业，重要问题不再只是能否调用模型，还包括现有应用如何面对未来可能发生的服务终止。
如果模型属于业务关键环节，企业可以提前评估替代版本、接口兼容性、数据处理安排及迁移成本。
但现有资料并不证明AWS或具体客户已经采取某项迁移措施，也不能把预定终止日期描述为已经发生的事件。
2. 法国平台服务需要怎样的持续评价？
OVHcloud于2025年4月宣布AI Endpoints及R1蒸馏Llama版本的部署，是明确的历史服务发布记录。3
其ALPHA助手页面则介绍了DeepSeek 3.1在具体应用中的集成方式。2
从作者分析看，平台发布与应用集成是两个不同层次的证据。
评价长期经营能力时，应进一步关注某一模型版本是否持续提供服务、实际应用是否保持使用，以及服务条件变化是否影响原有集成方案。
因此，不能仅凭2025年的服务公告，判断相关模型在2026年仍保持相同的销售状态，也不能将ALPHA的集成介绍延伸为全部用户流量和商业效果。
3. 如何分阶段判断开放模型的海外价值？
从作者分析看，可以将模型国际化的观察划分为三个层次。
第一层是技术可获得性。 模型权重、许可和部署条件使第三方具备采用技术的可能。
第二层是平台服务化。 云服务商将模型与计算资源、调用入口、计费和数据处理安排结合，形成可供使用的服务。
第三层是可验证的经营价值。 需要进一步观察模型开发者是否建立直接客户关系、取得可识别的商业收入，或者通过明确合作机制获得持续回报。
美国AWS与法国OVHcloud的资料，能够支持前两个层次的具体观察，并提供部分实际应用集成线索，但尚不足以证实DeepSeek在两国实现了第三层意义上的直接经营成果。
4. 平台分发模式有哪些可迁移的管理启发？
对于希望通过开放模型进入国际市场的人工智能企业，作者认为有三项选择值得考虑。
首先，在开放扩散与商业服务之间建立清晰的产品区分，使模型版本及适用许可能够对应具体部署方式。
其次，将云平台视为承担独立运营责任的合作生态参与者，分别理解平台计费、数据处理及客户服务安排。
最后，重视模型版本的生命周期管理。技术被平台采用之后，仍需要考虑更新、兼容和长期维护条件。
这些属于从DeepSeek案例提炼的条件性经营建议，并非已经证实的DeepSeek内部管理制度。
本阶段最重要的启示是：开放模型的海外传播能力，取决于技术能否被不同平台持续部署与集成；而模型开发者的商业全球化能力，则需要进一步建立可识别、可持续的价值回收机制。两者相互关联，但不能直接等同。
九、从平台采用到经营选择：开放模型企业如何建立可持续的国际化路径？
DeepSeek在美国AWS和法国OVHcloud的案例表明，开放模型可以借助第三方平台进入不同的技术服务体系。但模型获得分发渠道之后，开发者仍需面对一个更重要的问题：如何在技术扩散、平台合作与商业价值回收之间作出选择？
1. 何时适合优先扩大模型分发？
从作者分析看，如果企业的阶段性目标是扩大技术采用范围、增加开发者接触机会，那么允许不同云平台部署模型，可以成为一种可考虑的国际化路径。
但这一选择需要具备两个条件：模型及其衍生版本的许可关系足够清晰，第三方平台能够独立承担相应的推理资源及服务运营责任。
作者建议，评价开放模型分发时，不仅关注平台数量，更应关注具体模型版本是否获得持续支持，以及平台是否形成明确的调用和应用入口。
2. 何时需要考虑商业价值回收？
如果模型开发者希望将海外技术采用进一步转化为经营成果，就需要判断平台分发之外是否存在可持续的商业关系。
可能需要回答的问题包括：模型开发者通过什么机制获得经济回报？该机制是否与平台调用量、服务授权或其他合作安排相关？相关收入能否按产品及市场识别？
这些是作者提出的商业模式分析问题，不代表DeepSeek已经与AWS或OVHcloud建立了某种特定分成或收费协议。
从经营选择看，如果企业优先追求技术生态扩散，平台采用本身便具有一定的阶段价值；如果目标转向商业收益，则需要进一步建立能够识别收入来源及责任主体的安排。
技术传播范围与价值回收能力可以相互促进，但需要分别设计、分别评价。
3. 如何选择值得长期投入的平台合作？
AWS现行R1托管版本已标示为Legacy，并预告2027年3月30日结束生命周期。1
这一事实提示，模型开发者不能把第三方平台某一版本的上线视为永久性的渠道资产。
从作者分析看，选择长期合作平台时，值得关注三个条件：平台是否能够持续支持模型更新，应用开发者是否能够管理版本迁移，以及模型开发者能否了解其技术在平台生态中的实际采用情况。
如果某个平台无法持续支持关键版本，企业就需要重新评估该渠道对技术传播及服务连续性的价值。
这种评价方法是作者的条件性建议，并非DeepSeek已经实施的伙伴管理制度。
十、从技术可见度到商业全球化：如何评价两国案例的实际进展？
1. 美国与法国应当采用相同的评价标准吗？
从作者分析看，两国可以采用共同的分析框架，但不能忽略各自的证据特征。
美国AWS资料更适合评价模型部署方式、计费责任、数据处理安排与版本生命周期。
如果要进一步评价法国服务的商业成熟度，则需要掌握2025年发布之后的持续运营情况，不能直接把历史发布视为2026年仍保持相同销售状态。
因此，两国共同证明的是海外平台采用机制的存在，而非已经取得相同阶段的商业经营成果。
2. 下一阶段最值得回答哪些经营问题？
作者认为，有三个问题比进一步统计模型出现在哪些平台上更有研究价值。
首先是持续采用：具体版本是否仍被平台支持，是否进入稳定应用流程，以及版本变化如何影响既有使用者。
其次是经济关系：模型开发者与平台之间是否存在可确认的商业协议，相关费用由谁收取，开发者能够获得什么形式的回报。
最后是市场组织：开发者是否拥有美国或法国的直接客户合同、可辨识的分国收入，以及承担当地经营职责的团队。
其中，OVHcloud对ALPHA助手的介绍可以支持存在具体集成方式的判断，但不能替代实际采用规模、客户成效或经济关系的证据。2
这些问题的答案将决定DeepSeek的海外技术扩散，能否进一步被评价为具有独立经济贡献的国际业务。
3. 对其他中国人工智能企业有什么可迁移的启发？
从作者分析看，开放模型企业可以考虑采用递进式的国际化策略。
第一阶段，确保模型许可、版本身份及技术分发条件明确，使第三方能够合法、有效地部署模型。
第二阶段，选择具有相应计算、数据处理及服务能力的平台合作生态，使模型进入实际应用场景。
第三阶段，在已有技术采用基础上，探索可持续的商业关系，并建立能够识别实际经济贡献的经营信息。
三个阶段不必严格先后发生，也不要求企业必须建立海外直营团队。但如果研究目标是判断某一国家的实际商业经营能力，就不能省略相应的客户、收入或组织证据。
这是一种有条件的经营路径建议，而不是DeepSeek已经公布的国际化路线图。
结语：开放模型全球化的价值，在于从技术传播走向可持续服务
DeepSeek案例展示了中国人工智能技术通过海外云平台实现服务化的可能路径。
这一案例最有价值的启示，是模型全球化不必完全依靠开发者自建海外运营体系，但第三方平台采用与开发者商业成果之间，仍需要可识别的经济关系和持续经营证据连接。
对于DeepSeek，目前能够观察到的是海外技术采用和平台服务机制。其美国与法国直接经营能力、商业回报及市场组织仍有待进一步证实。
对于中国开放模型企业，长期竞争力不仅来自模型被多少平台采用，也来自技术能否持续融入实际应用，以及企业能否据此形成适合自身战略的价值回收方式。
主要来源与研究依据
1. DeepSeek-R1 — Amazon Bedrock model card
发布者：Amazon Web Services（AWS）
发布日期：未标明
更新日期：未标明
首次查阅日期：2026年10月21日
复查日期：2026年10月22日
相关时点：复查时所见Amazon Bedrock模型版本及生命周期状态
主要依据：模型标识deepseek.r1-v1:0、美国跨区域推理安排、标准Token计费，以及具体模型生命周期。
适用限制：所列来源及目标区域涉及美国北弗吉尼亚、俄亥俄和俄勒冈；该模型未列全球跨区域推理方式，不能将AWS其他产品的区域范围直接套用。
2026年10月22日复查时，页面将该版本标示为Legacy，并列出2027年3月30日为预定生命周期终止日期。该日期尚未发生，不能将2025年的模型上线公告解释为该版本2026年仍处于最新主推状态。
服务区域不代表客户所在地、DeepSeek办公室或分国收入。该模型卡也不能证明所有DeepSeek版本具有相同生命周期。
2. OVHcloud Assistant
发布者：OVHcloud Labs
发布日期：未标明
更新日期：未标明
相关时点：查阅时所见ALPHA助手服务说明
查阅日期：2026年10月21日
主要依据：OVHcloud对ALPHA助手实际集成方式的公开介绍，包括网站索引、检索、使用DeepSeek 3.1处理RAG结果，以及在同一流程中使用Llama和Mistral模型。
适用限制：这是OVHcloud的应用集成自述，不属于独立性能测试；不能推断全部请求均使用DeepSeek 3.1，也不能据此确定客户满意度、实际应用效果或商业成熟度。
ALPHA使用的是DeepSeek 3.1，不能混同于完整R1或R1的Llama蒸馏版本。该资料未证明OVHcloud与DeepSeek之间存在具体付费合同或收入分配关系。
3. OVHcloud Launches AI Endpoints to Simplify and Democratize Access to AI Models
发布者：OVHcloud
发布日期：2025年4月29日
更新日期：未标明
相关事件：2025年4月AI Endpoints服务发布
查阅日期：2026年10月21日
定位：PDF第1–2页
主要依据：2025年AI Endpoints发布时列入DeepSeek-R1的Llama蒸馏版本；相关服务从法国Gravelines数据中心部署，采用按使用量计费方式，并提供开发者沙盒测试及应用部署路径。
适用限制：公告仅标明distilled Llama，未明确具体参数规模，不得擅自指定8B或70B，也不得等同完整R1。
Gravelines是所披露的法国部署地点。服务可供欧洲、加拿大及亚太地区使用，不证明上述地区分别设有该模型的数据中心。
欧洲数据托管、数据主权及安全属于OVHcloud的供应商声明，不能直接转化为独立法律合规结论。
这是2025年4月的历史服务发布资料，不能单凭该公告确认2026年相关模型仍保持相同的销售状态、调用规模或商业收入。
4. DeepSeek-R1 models now available on AWS
发布者：Amazon Web Services（AWS）
首次发布日期：2025年1月30日
中间更新日期：2025年2月5日
最后标示更新日期：2025年3月10日
相关事件：2025年AWS发布DeepSeek-R1相关模型部署路径
查阅日期：2026年10月21日
主要依据：AWS于2025年通过Amazon Bedrock Marketplace、SageMaker JumpStart等方式提供R1相关部署，涉及美国俄亥俄和俄勒冈区域；同时分别介绍蒸馏模型导入及EC2部署路径。
适用限制：Marketplace、JumpStart及EC2相关部署涉及所选推理实例的基础设施费用，不能与参考资料1现行特定Bedrock托管模型的Token计费方式混同。
AWS表示，相关Bedrock及SageMaker客户数据不会与模型提供方共享，也不会用于改进模型。这是AWS对自身服务的数据处理说明，不证明DeepSeek取得AWS客户数据。
AWS平台收费及模型部署不能直接证明DeepSeek获得模型授权费、美国直接客户合同或当地营业收入。
该资料属于2025年的历史部署公告，不能取代2026年10月22日模型卡记录的Legacy状态及预定终止日期。
5. DeepSeek-R1 — official repository
发布者：DeepSeek，官方GitHub仓库
发布日期：未标明
更新日期：未标明
相关时期：2025年DeepSeek-R1系列模型文档
查阅日期：2026年10月21日
主要依据：R1、R1-Zero及六个蒸馏模型的区别；代码、模型权重及相关许可说明。
适用限制：仓库标示MIT许可，同时说明蒸馏模型涉及Qwen的Apache 2.0许可及Llama 3.1、3.3原始许可。不能将全部派生模型视为无条件采用同一许可，也不能将模型开放许可等同于第三方API服务条款。仓库不提供DeepSeek美国或法国直接客户、收入及盈利证据。