SiliconFlow Hy4 Preview 将 770B 开放模型接入熟悉的 API

SiliconFlow 已将腾讯的 7700 亿参数开放模型 Hy4 preview 加入其平台，并宣称支持 100 万 token 的上下文窗口。SiliconFlow 的 Hy4 preview 页面将这一规模罕见的开放权重模型发布，转化为可供使用成熟编程与智能体工具的开发者调用的 API 选项。

这一可用性之所以重要，是因为 Hy4 preview 很难独立部署。其公开权重占用超过 1TB 存储空间，而腾讯的部署方案假设采用八张 GPU 配置来运行压缩后的 FP8 版本。SiliconFlow 实际上提供了访问能力，使各团队无需自行搭建这套基础设施。

这一结果让开放权重与托管专有模型之间形成了直接检验。Claude、Codex 及其他托管系统，将模型能力与严格管控的基础设施结合在一起。Hy4 preview 提供可审查的权重和更广泛的部署权利，但其在真实场景中的可靠性尚未得到同等程度的验证。

SiliconFlow Hy4 Preview 消除了首个部署门槛

SiliconFlow 将 Hy4 preview 从可下载的研究产物，转变为普通 API 客户可在既有工作流中评估的模型。

该公司通过其 Hy4 平台帖子宣布了这一新增服务。根据该帖子，客户可以将该模型连接到 Claude Code、Codex、Cursor 以及其他接受兼容模型端点的工具。

这一集成路径比又一张基准测试图表更重要。多数开发者不会通过搭建推理集群来开始模型评估；他们会先在已熟悉的工作流中替换一个端点。

编程团队可以将范围明确的代码仓库任务路由至 Hy4 preview，并将其补丁与现有模型进行比较。分析师可以测试更大的上下文是否能在报告、电子表格和支持文档之间保持连贯。研究团队则可以检验其在大量论文与笔记中的推理表现。

模型本身来自腾讯的 Hy 团队，而非 SiliconFlow。腾讯以 Apache 2.0 协议发布了权重，并将 Hy4 preview 描述为一款面向生产力场景的旗舰模型。SiliconFlow 提供托管推理服务，以及客户使用该模型所需的接口。

这一区分很重要。腾讯负责模型设计、训练声明、权重和官方文档；SiliconFlow 则负责托管服务体验，包括可用性、吞吐量、缓存、限制和运行行为。

因此，该公告验证的是平台可用性，而不是所有可能的性能声明。SiliconFlow 的帖子并不能证明该托管模型在真实生产工作负载中可与专有系统全面匹敌，也不会独立验证腾讯的内部评估结果。

不过，托管访问移除了最大的初始障碍。腾讯的模型仓库包含部署说明，但这些说明面向拥有大量加速器资源和推理专业能力的团队。

完整模型包含 7700 亿个主干参数。其混合专家架构每个 token 仅激活 490 亿个参数，相比激活整个模型可降低计算量。但这一设计并不会消除存储或服务要求。

腾讯还发布了 FP8 版本，它以较低数值精度存储模型数值。FP8 可降低内存使用并提高吞吐量，不过部署结果取决于硬件、内核、批处理和工作负载形态。

托管路径让开发者能在承担这些工程成本前先审视输出结果。即使最终希望自行托管模型的组织，SiliconFlow Hy4 preview 也因此具有参考价值。

API 评估可以先回答实际问题。团队可以衡量指令遵循能力、工具调用、代码质量、延迟和故障恢复表现，随后再决定对权重的控制权是否足以证明更高部署要求的合理性。

SiliconFlow 还将该模型置于不断扩大的可互换推理提供商市场中。在这个市场里，模型访问不再与单一应用绑定。开发者可以保留原有接口，同时替换其背后的系统。

这种可移植性也有局限。不同模型对推理控制、工具模式、token 计数和错误条件的处理方式各不相同。端点兼容性可减少迁移工作，但并不保证应用行为完全一致。

因此，眼下的变化范围有限，却意义重大。Hy4 preview 不再只面向准备管理超大模型的团队，而是可以进入常规的模型路由实验。

为什么 770B 参数不等于每个 Token 使用 770B 参数

Hy4 preview 利用规模存储知识和实现专业化，同时限制每个生成 token 所使用的网络部分。

腾讯将 Hy4 preview 描述为混合专家模型，通常简称为 MoE。MoE 系统包含许多专门化的前馈组件，而路由机制会在推理期间选择其中较小的一部分。

官方模型卡列出了 7700 亿个主干参数，以及每个 token 激活的 490 亿个参数。它包含 78 个主干层，多数层具有 256 个路由专家和一个共享专家。

对于每个 token，路由器会在共享专家之外再选择八个路由专家。这种安排试图在模型容量与推理成本之间取得平衡。整个网络可以存储已学习的行为，而每个 token 只使用较小的计算路径。

这一区分避免了一种常见误解。总参数量描述的是整个网络，而非每个 token 所需的确切计算量。对于估算 MoE 模型的推理工作量而言，激活参数量是更有用的起点。

不过，激活参数量并不是完整的成本指标。服务仍需访问规模大得多的权重集合。在内存与计算设备之间传输数据可能成为主要瓶颈。

专家路由也会带来运行层面的挑战。请求在专家之间的分布可能并不均匀，尤其是在工作负载多变时。提供商必须管理内存放置、并行化、批处理、通信开销和专用内核。

Hy4 preview 增加了一层原生多 token 预测层，用于推测式解码。这项技术会在主解码过程验证前提出多个未来 token。当这些提议被接受时，系统可通过更少的串行步骤生成输出。

腾讯表示，这一附加层共包含 100 亿参数，其中激活 7 亿参数。这些数字不包含在已发布的 7700 亿参数主干规格内。

该模型还采用了受与 DeepSeek 和 GLM 相关研究启发的稀疏注意力设计。稀疏注意力会减少每一步直接审视的早期 token 数量。当提示接近极长上下文上限时，这一点尤为重要。

密集注意力会将每个相关 token 与其他所有 token 比较，随着输入增长会带来陡增的计算和内存需求。稀疏方法会选择更窄的一组位置，旨在以更少工作量保留有用信息。

腾讯将其实现称为带有 IndexCache 的 Gated DeepSeek Sparse Attention。该公司表示，IndexCache 会在各层之间复用稀疏索引。这些选择旨在使长输入更易于处理。

100 万 token 的上下文窗口是该模型最醒目的规格。上下文窗口指模型在支持条件下可处理的最大输入与生成序列总量。

这一上限并不意味着每个回答都能准确利用 100 万 token。最大可接受量、有效检索、推理一致性、延迟和成本是不同属性。模型可以接受很长的提示，却忽略其中关键细节。

这一规格仍带来了有用的可能性。开发者或许可以在一次会话中提供大型代码仓库、问题历史、架构文档和测试日志；分析师则可以合并多年的文件记录与内部研究。

知识工作者面临着相关挑战：他们的信息常分散在文档、会议、笔记和本地文件中。个人知识库可在模型接收材料前先对其进行组织。

组织工作仍不可或缺，因为不加筛选地堆叠上下文可能损害结果。重复文档、过时决策、无关日志和相互冲突的指令都会增加模型负担。更大的窗口扩展了容量，但不能替代信息筛选。

在腾讯发布的配置中，Hy4 preview 默认采用高推理模式。当不需要扩展推理时，开发者可以请求直接响应模式。这一选择会影响响应速度，也使按工作负载进行测试变得不可或缺。

因此，Hy4 preview 背后的机制比其标题式参数量更值得关注。腾讯结合大量专家、稀疏注意力和推测式解码，试图让一个规模巨大的开放模型具备可用性。

SiliconFlow 的角色，是决定这种架构通过 API 是否具备实际可用感。对客户而言，单位时间内的输出质量比底层设计的优雅性更重要。

开放权重挑战托管模型捆绑方案

主要竞争并非 Hy4 preview 与某一具名模型之间的较量，而是开放部署权利与垂直管控 AI 服务之间的竞争。

专有模型提供商销售的不只是模型智能，还包括优化服务、安全系统、可观测性、支持、稳定接口和集成能力。它们的优势往往来自完整的捆绑方案。

开放权重发布通过将模型与其原始运营方分离，对这种捆绑方案提出挑战。客户可以检查文件，通过其他提供商运行它们，对其进行微调，或在自己的边界内进行部署。

Hy4 preview 通过采用 Apache 2.0 协议强化了这一选择。该模型的 Hugging Face 发布页标明了该协议，并公开了模型文件和支持配置。

Apache 2.0 赋予使用、修改和分发获授权材料的广泛权利。组织在作出合规决策前，仍必须审阅完整协议、模型文档、适用法律及其预期部署方式。

这些权重也带来一种实际的供应商选择。团队可以先测试 SiliconFlow，之后评估另一家兼容托管服务商，或研究自行托管。这与核心模型只能通过获准服务访问的专有 API 路径不同。

但开放权重不会自动形成开放的运行环境。托管端点仍要求用户信任提供商对提示、输出、日志、访问控制和服务连续性的处理方式。

评估 SiliconFlow Hy4 preview 的组织需要进行两项独立审查：一项针对模型及其行为，另一项针对处理公司数据的托管平台。

这种区别对编程智能体而言至关重要。这类工具可能接收源文件、终端输出、日志中意外记录的凭证，以及内部架构细节。强大的模型并不能解决围绕这些信息的治理问题。

与 Claude Code、Codex 或 Cursor 的兼容性也应谨慎解读。它意味着用户可以将受支持的客户端指向该模型端点，但并不意味着 Hy4 preview 等同于与这些产品相关联的原生模型。

编程智能体依赖的不只是原始生成能力。它们还需要可靠的工具选择、结构化参数、状态跟踪、错误解读和适当克制。一个能够写出高质量独立函数的模型，仍可能在漫长的智能体循环中表现吃力。

Tencent 表示，Hy4 preview 围绕编程、办公分析、游戏开发和科学研究构建。该公司与内部专家合作，围绕这些领域设计训练任务。

其模型卡报告了一项盲测内部比较，涉及 163 名专家和 203 项工程任务。Tencent 表示，Hy4 preview 在与 GLM 5.3 和 Kimi K3 的比较中获得了 2.99 的平均评分。

Tencent 报告称，对阵 GLM 5.3 时，Hy4 preview 的胜率为 46.8%，平局率为 12.8%，败率为 40.4%。对阵 Kimi K3 时，其胜率为 51.2%，平局率为 7.9%，败率为 40.9%。

这些数字具有参考价值，但仍属于公司自行产出的结果。受评任务来自 Tencent 的内部环境，评估流程也由该公司定义。在将这一排名视为定论之前，仍需独立复现。

这些比较也不能直接回答 Hy4 preview 相对于所有专有编程系统的表现。不同智能体采用不同的脚手架、提示词、工具协议和重试策略。模型分数无法单独衡量完整的产品体验。

Hy4 preview 在开放性方面的主张强于那些以限制性自定义条款发布的模型。其权重已公开，Tencent 还提供了适用于 vLLM 和 SGLang 的部署路径。

这种开放性会以特定方式向专有服务提供商施压。它们必须通过更好的可靠性、延迟、安全性、集成能力或整体结果，来证明封闭访问的价值。当替代方案能够在不同主机之间迁移时，模型质量本身会成为较不持久的差异化因素。

与此同时，Hy4 preview 也会向较小的开放模型开发者施压。其规模反映了大型科技公司可获得的资源。独立团队可能难以训练、分发和支持同等规模的系统。

SiliconFlow 将这些竞争压力转化为一项可轻松参与的实验。客户不必在抽象层面接受开放与封闭之争，而是可以将受控工作负载分别路由到两种方案并衡量结果。

这项实验应聚焦于完整任务。对于编程而言，有意义的单位是经过测试的变更，而非看似合理的代码片段。对于分析而言，则是具有可追溯证据、经得起推敲的结论。

对于研究而言，有价值的结果不只是流畅的文献综述。模型必须区分已确立的发现、存在争议的主张、缺失的证据和缺乏支撑的推断。

当输出不理想时，开放权重提供了更多选择。团队可以更改系统提示词、服务设置、量化方式、微调策略或服务提供商。专有服务通常只开放这一技术栈中较少的层级。

更多选择也意味着责任转移。客户必须决定哪种配置有效、哪些风险可以接受，以及哪些变更会使此前测试失效。控制权带来灵活性的同时，也带来了运营工作。

Hy4 Preview 的主张仍无法证明什么

Hy4 preview 提供了异常详细的规格说明，但规格和内部评估无法证明其生产环境可靠性。

Tencent 明确将此次发布标注为预览版。其文档承认存在已知问题，包括在困难任务上推理过长，以及过度积极地验证自身工作。

这一披露很重要，因为这两种行为都会影响智能体的成本效益和可用性。延长推理会增加响应时间和 token 消耗。过度验证也可能使使用工具的智能体陷入重复检查。

编程助手可能在生成正确补丁后反复检查文件。分析智能体可能重新审视已经确定的证据，却无法改善结论。即使最终答案可靠，这些行为也可能降低吞吐量。

对一百万 token 上下文的主张同样需要压力测试。团队不应仅通过确认端点能接受超大请求来评估它，而应测试模型能否从不同位置恢复相关证据。

一项有用的评估会将决定性事实放在受控文档集的开头、中间和结尾。随后，审阅者可以衡量检索能力、矛盾处理、引用准确性和最终推理。

长上下文测试还应纳入干扰材料。真实的代码库和文档集合包含重复内容、废弃计划、过时代码和未解决的评论。干净的基准提示词很少能反映这种混乱。

模型规模带来了另一项不确定性。SiliconFlow 必须将复杂架构转化为可接受的服务延迟和可用性。公开权重并不会披露服务提供商的具体硬件、批处理策略或容量规划。

性能可能因提示词长度、生成长度、推理模式和并发需求而变化。简短的代码解释或许响应迅速，但代码库规模的智能体任务可能表现截然不同。

缓存可以通过复用已处理的提示词材料，改善重复上下文工作负载。当大量请求共享稳定前缀，例如代码库快照或政策文档集时，它会有所帮助。当每项请求都包含无关材料时，其帮助则较小。

开发者还应区分模型错误与集成错误。格式错误的工具调用可能反映模型问题、模式转换层问题或客户端问题。一次失败的智能体运行可能涉及权限、沙箱行为或错误命令。

受控比较需要一致的任务和验收标准。每个模型都应获得等效的上下文、工具权限和时间预算。人工审阅者应同时检查任务完成情况和非预期变更。

安全性值得单独设立测试轨道。长上下文系统可能摄入包含隐藏指令的不可信文档。除非周边应用能有效将数据与命令分离，否则智能体可能遵循这些指令。

开放权重允许进行更深入的安全研究，但访问本身并不能保证安全。服务提供商仍必须保护其服务，客户也必须限制工具权限并验证模型操作。

发布文档并未说明 SiliconFlow 针对该特定模型如何处理数据保留、区域处理、事件响应或企业控制。买家在发送敏感信息前应查阅当前的平台条款。

目前也没有大量独立的生产环境证据。Hy4 preview 发布不久，早期社区测试自然会偏向引人注目的成功或失败案例。两类轶事都无法提供具有代表性的可靠性估计。

Tencent 的发布声明将该模型描述为一次重大的代际提升。这一表述来自开发者，应继续归因于该公司。

独立评估应考察常见的失败模式，而不仅是排行榜任务。其中包括虚构的 API、破坏性代码编辑、错误的电子表格公式、缺乏支持的科学主张，以及长时间会话中的指令漂移。

它们还应衡量恢复能力。现实中的智能体会遇到缺失文件、测试失败、需求模糊和工具不可用等情况。有用的系统能够识别这些状态并进行调整，而不是虚构成功。

自行托管者面临额外的验证缺口。量化版本的行为可能与原始发布版本不同，尤其是在高难度推理或工具调用任务上。每种压缩格式都需要各自的验收测试。

FP8 版本相较于更高精度权重降低了内存负担，但它仍是一项大型部署。Tencent 公布的方案采用跨八张 GPU 的张量并行，将模型计算分摊到多个设备上。

该方案证明的是技术可用性，而非普遍的实用性。硬件型号、互连、驱动版本和服务软件都会影响可实现的吞吐量。

SiliconFlow 为 API 用户吸收了其中大部分复杂性。作为交换，客户对服务技术栈的可见性更低。他们必须通过监控和合同信息，而非直接的基础设施控制来推断质量。

合理的结论既不是自动信任，也不是一概否定。Hy4 preview 提供了可信的技术要素和可验证的开放权重。其托管性能仍需要独立、针对具体工作负载的证据。

三个信号将决定 Hy4 Preview 是否重要

只有当开发者采用它、独立测试支持其主张，并且服务能在高要求工作负载下保持可靠时，Hy4 preview 才会产生重要影响。

第一个信号是其在编程智能体中的持续使用。最初的好奇心可能带来高请求量，但重复使用才能说明该模型是否足够可靠地完成工作，从而保留在路由策略中。

应关注衡量代码库级完成情况、测试通过率、工具调用准确性和回归率的公开评估。与带有客观检查的多步骤任务相比，孤立的编程提示词对智能体模型的揭示更少。

团队可以迅速生成自己的证据。选择一组固定的维护问题，要求测试通过，并记录人工修正时间。在相同权限下，将 Hy4 preview 与现有模型进行比较。

如果 Hy4 能完成更多被接受的任务且不增加审阅工作量，开放权重路线就会获得可信度。如果团队反复回到专有模型，便捷的 API 访问也无法弥补可靠性差距。

第二个信号是独立的长上下文验证。一百万 token 的上限很吸引眼球，但有用的上下文取决于能否在完整序列中检索证据并进行推理。

评估者应公布多个输入长度下的结果，而不是只进行一次最大长度测试。他们应披露提示词构建方式、文档顺序、检索标准、推理设置以及重复运行的方差。

在混乱的代码库和文档集合中取得强劲结果，将支持 Tencent 的架构选择。随着上下文增长而出现明显退化，则会削弱此次发布最具特色的部分。

第三个信号是 SiliconFlow 和其他托管平台的运营表现。开发者需要可预测的延迟、错误率、速率限制和输出行为。只能在低负载时正常工作的模型，无法支撑重要工作流。

服务提供商之间的竞争可在此发挥作用。由于 Hy4 preview 采用开放权重，多项服务可以对同一模型进行优化。客户无需完全放弃底层模型，即可比较不同主机。

自行托管方面的发展同样重要。改进的内核、更低比特的量化和更好的专家并行机制，能够随着时间推移降低部署门槛。这些改进将把模型的应用范围扩展到专业推理服务提供商之外。

不过，激进压缩必须保留模型行为。如果工具调用、推理或指令遵循能力恶化，更小的文件和更低的内存使用价值有限。效率主张应附带可复现的质量测量。

腾讯的下一次模型更新将提供又一个重要的数据点。预览标签意味着训练和后训练工作尚未完全完成。对推理行为的调整，或许能改善其已承认的速度偏慢、过度验证倾向。

该公司还应澄清基准测试方法，并发布更广泛的评估材料。更透明的任务设置将使独立团队能够复现与 GLM、Kimi 及专有系统的比较结果。

对于企业采购方而言，治理方面的证据将与模型评分同样重要。他们应关注是否有更清晰的文档，涵盖数据处理、保留期限、区域可用性、访问控制和服务承诺。

开发者眼下可以采取更简单的行动：将 SiliconFlow Hy4 preview 置于模型路由器之后，为其分配结果可衡量且边界明确的任务。不要一开始就授予其不受限制的代码仓库访问权限，或提供敏感文档。

可以从代码审查、测试生成、文档整合或研究分类开始。记录延迟、修正次数、工具故障和最终验收结果。每项任务都应重复执行，因为单次出色的结果可能具有误导性。

随后再逐步扩大上下文范围。加入代码仓库历史、规格说明、问题讨论和测试输出。观察额外信息是否改善决策，还是仅仅拉长了推理过程。

这一过程检验的是 SiliconFlow Hy4 preview 背后的实际命题。这个命题并不是 7700 亿参数会自动胜过所有闭源模型，而是开放权重模型可以无需部署项目便融入既有工作流程。

如果独立结果与腾讯的说法一致，专有模型提供商将面临更严峻的可移植性挑战。客户将拥有另一款能够在托管服务与私有基础设施之间迁移的强大模型。

如果结果仍不稳定，Hy4 preview 作为一次工程发布依然具有意义。它将展示稀疏注意力、专家路由和推测解码如何支撑超大规模开放模型。

决定性证据将来自已完成的工作，而不是参数数量。该模型能否完成一个代码仓库任务、保持约束条件、引用正确证据，并从失败中恢复？

SiliconFlow 让这个问题变得更容易测试。开发者现在应进行受控对比、发布可复现的发现，并判断开放部署权是否能转化为更好的日常使用效果。