腾讯混元 Hy4 preview 上手测评：770B 与 1M 上下文实际表现、长文档 vs RAG 怎么选、preview 版已知问题避坑清单

Hy4 preview 开源没几天，规格表上的 770B 总参和 1M 上下文确实抓眼球。但如果你正打算为一个 8 卡集群排期，真正要回答的问题其实是三个：厂商的性能说法能信几分、自己的长文档场景该直接塞进 1M 窗口还是继续走 RAG、preview 版的坑会不会在生产链路里爆。这篇测评把三件事放在一起讲，先给结论：规格和限制以官方模型卡为准，“略优于 GLM 5.3 和 Kimi K3”目前只是腾讯内部盲测口径，未经独立第三方复现；1M 上下文解决的是“装得下”，不自动解决“找得到”；官方自己承认 preview 版存在长思考和过度自我验证倾向，但有参数级的缓解手段。建议先走 API 或免费体验渠道跑完文末的自测清单，数据说话之后再决定是否上集群。

Hy4 preview 是什么规格？这几个数字别误读

先快速过一遍官方模型卡和 GitHub 仓库确认过的事实：Hy4 preview 于 2026 年 8 月 28 日发布并开源，总参数 770B，激活参数 49B，MoE 架构，上下文窗口 1M，Apache 2.0 协议，权重提供 BF16 和 FP8 两个版本，在 HuggingFace、ModelScope、GitCode、CNB 四个渠道免申请下载。

MoE 即混合专家架构，每次推理只激活总参数中的一小部分专家网络，Hy4 的“49B 激活”就是这个含义：模型容量按 770B 存，单次推理的计算量按 49B 量级走。这也是它能同时做到大容量和可控推理成本的原因。

三个容易误读的地方需要提前说清。

第一，770B 是 backbone 口径。HuggingFace 页面显示的 780B 是把内置的 MTP 投机解码层（约 10B 总参）算进去的口径，两个数字说的是同一件事，别在选型文档里混用。

第二，“1M 窗口 / 960K 最大输入 / 64K 最大输出”是三个不同的数字，不可互换。腾讯云产品页明确标注：1M 是上下文窗口总长，实际单次最大输入是 960K，最大输出是 64K。这个 64K 输出上限是后文输出截断风险的规范依据，先在这里记下。

第三，49B 激活不等于 49B 显存。社区技术分析对 FP8 权重的显存测算在 770 到 800GB 量级，BF16 约为两倍，这个体量适合云端集群而不是本地单机。部署基线一句话带过：官方 recipe 为 8 卡节点 TP=8，推荐 FP8 权重，且必须用官方 vLLM/SGLang 镜像，因为 Hy4 用的是 Gated DSA 稀疏注意力而非标准稠密注意力，通用安装跑不起来。具体部署步骤属于另一篇教程的范围，这里只需要知道：这不是一张卡就能试的模型，评估期走 API 更划算。

“略优于 GLM 5.3 和 Kimi K3”这个说法，可信度怎么校准？

腾讯在发布材料中称，内部组织了 163 名内部专家、203 个工程任务的盲测，Hy4 preview 均分 2.99，GLM 5.3 为 2.92（胜率 46.8%、平 12.8%、负 40.4%），Kimi K3 为 2.94（胜率 51.2%、平 7.9%、负 40.9%）。注意，这是腾讯内部盲测结果，未经独立第三方复现，不能当作行业共识来引用。

怎么校准这个说法？三个视角。

看分差量级。0.05 到 0.07 的均分差在 4 分制下非常小，社区技术分析对此的评价是“样本小、主场测试、分差接近噪声”，这个评价本身也是社区观点，但至少提醒你：这不是一代人的差距。

看第三方现状。目前初步出现的第三方数据（如基准聚合平台、社区维护的评测）口径各异，与内部盲测的口径并不一致，彭博转述的第三方基准里，Hy4 的表现与官方说法就“有所不同”。这些数据同样初步且口径不一，既不能用来证实也不能用来证伪官方说法，只能说明一件事：内外口径目前对不上，独立复现还没出现。

所以决策建议很简单：把“略优于 GLM 5.3 和 Kimi K3”当作一个待验证的厂商说法，而不是选型依据。如果你的场景里 GLM 5.3 或 Kimi K3 已经跑得不错，Hy4 preview 值得纳入对比测试，但对比要在你自己的语料和任务上做，方法见文末自测清单。

1M 上下文该直接用还是继续走 RAG？按任务类型分三条路

这是全文的重点。先立一个核心判断：“装得下”不等于“找得到”。1M 窗口解决的是输入容量问题，它不自动解决三个别的问题：长输入里的检索准确性、单次调用的延迟、以及 token 成本。社区技术分析对长上下文生产化的一个通用判断是，模型对位于上下文中间位置的信息存在明显的性能下降，也就是所谓“迷失在中间”现象，降幅可达 20 个百分点以上。需要说明，这个判断来自发布于 Hy4 之前的通用长上下文技术分析，不是 Hy4 的官方基准，但它是你做选型时必须纳入测试的变量。

Hy4 支撑 1M 上下文的技术路线，社区技术分析解读为 Gated DSA 稀疏注意力加 IndexCache 分层检索缓存。这套机制解释了为什么 1M 窗口在工程上可行，但同样不保证每个位置的信息都被同等对待。按三类任务分别看。

场景一：单次通读长文档。 合同全文审查、年报分析、代码库整体理解、全局摘要这类任务，一次输入、要求模型通读后给出全局性结论，是最接近 1M 上下文设计场景的用法，可以试直接塞入。有一个正面样例：ZAKER 在一次实测中把约 93 万 token 的文本（三部小说加一份年报）一次性输入，约 9 分钟后返回，准确列出了 8 处目标段落的位置。注意这是单次媒体实测观察，不是普遍结论，但它至少说明“装得下且大体找得到”在这个量级上是可能成立的。两个前提仍要自己验证：一是上下文长度受部署环境 KV cache 显存约束，vLLM 的 Ascend 教程给出的实例是单节点仅能开到约 1K、双节点约 96K，也就是说“1M 窗口”不是任意环境自动可用的，自部署时你的实际可用长度取决于硬件配置；二是长输入的往返延迟和 token 成本要按自己的 SLO 评估，9 分钟级别的响应在离线分析场景可接受，在交互式产品里就是事故。

场景二：多轮检索问答。 同一批文档反复问、不同用户问不同问题、问答次数多的场景，直接塞入和 RAG 的取舍要看几个因素。社区技术分析给出的通用决策框架是五因素：语料规模是否超窗口、单次问题相关的语料占比（低于约两成时检索的价值开始显现）、延迟 SLO 是否紧、数据是否频繁更新、查询量是否大。这些因素里只要有两三个倾向 RAG，直接塞入的方案在成本和延迟上就会吃亏。同时提醒一点：即使你决定直接塞入，“迷失在中间”意味着你仍然要做位置敏感的测试，把关键证据分别放在上下文早、中、晚三个位置各测一轮（做法见文末），否则上线后会出现“有时答得很好有时完全找不到”的不稳定表现，而你不知道原因。

场景三：海量知识库。 语料远超 1M、持续更新、多团队共享的场景，直接塞入在数学上就不成立，RAG 仍是主线。1M 长上下文在这个场景里的正确位置是补充而非替代：比如对 RAG 检索回来的片段做局部通读复核，或者处理“检索召回的上下文加上原始问题本身就很长”的链路。任何“1M 完全替代 RAG”的说法都不成立，至少在成本、延迟和数据新鲜度这三个维度上不成立。

三类任务放在一起对照：

给一个简化的判断口诀：单次通读、静态语料、要全局理解，试长上下文；反复问答、延迟敏感、查询量大，倾向 RAG；语料超窗、持续更新，RAG 为主、长上下文做补充。边界场景（比如 50 万 token 的语料、中等查询量）没有通用答案，跑一轮自测再定。

preview 版有哪些已知问题？官方承认的和社区观察的要分开看

投入资源前，这份清单建议逐条过一遍。每条的来源属性不同，处理优先级也不同。

长思考倾向。 这是官方承认的问题，发布公告的原文口径是“复杂任务的长思考和过度自我验证倾向”，官方同时自述“预训练和后训练均仍有较大提升空间”。具体表现可以看 ZAKER 那次实测里的另一个案例：一个快速排序复杂度分析任务，模型反复思考约半小时，期间三次说出“让我再确认一下”。单次观察，不是普遍结论，但它给了你一个体感：在默认思考档位下，简单任务如果忘关思考，延迟和 token 成本都会白白上升。

过度自我验证循环。 官方承认的是“倾向”，社区观察到的具体表现更严重一些：有实测反馈称模型有时会困在自我验证循环里，只有人工打断、明确推进才能继续完成任务。前者是官方口径，后者是社区单次观察，两者分开记。对 Agent 场景来说这条最要命：无人值守的长链路任务里，一个验证循环可能烧掉大量 token 而不产出任何结果。

token 膨胀。 社区观察。长思考直接推高输出 token，而输出计价通常是输入的数倍。Hy4 的 API 发布时定价为输入 6 元每百万 token、输出 18 元每百万、缓存命中 0.3 元，这是发布时口径，后续可能变动。思考 token 花的是输出的钱，这是成本核算时最容易漏算的一项。

输出截断风险。 这条要写成组合推导而不是官方定论：官方 64K 最大输出是硬限制；第三方网关文档显示思考 token 计入这个输出上限；叠加长思考倾向，长任务存在“思考还没结束、输出额度先耗尽”的截断风险。官方没有专门说明截断的触发条件，所以处理方式是预防而非修复：为输出预留预算，对返回内容做完整性校验，JSON 解析失败或代码明显不完整就视为截断，触发重试而不是把半截结果传给下游。

无视觉输入。 能力缺口。官方模型卡没有列出任何多模态能力，社区观察也交叉印证这是纯文本模型。模型卡里出现的“visual taste”字样指的是前端代码生成中的视觉品味，不是视觉输入能力，别误读。如果你的链路里有图片或视频输入需求，Hy4 preview 当前覆盖不了，这是硬边界。

这些问题怎么缓解？参数、任务设计、人工干预三层手段

决定用的话，三层手段从前往后递进。

参数层：把思考档位管起来。 Hy4 的 reasoning_effort 只有两档：high（默认，深度思考）和 no_think（关思考）。调用写法是官方 Quickstart 给出的：

extra_body={"chat_template_kwargs": {"reasoning_effort": "no_think"}}

两个易错点：一是上一代 Hy3 曾有 high/low/no_think 三档，Hy4 砍掉了中间档，网上旧文档的三档写法不适用，别混用；二是简单任务（分类、抽取、格式转换）显式传 no_think，复杂任务才用默认 high，按任务分级控制是 token 成本管理的主要抓手。官方推荐采样参数为 temperature 0.9、top_p 1.0。

任务设计层：拆解加预算。 复杂任务拆成子任务，每个子任务有明确的输出目标长度，避免单次调用要求模型产出超长内容。给指令、工具结果和引用预留输出预算，也就是输入别顶到 960K，给输出留出 64K 里的足够份额。所有结构化输出（JSON、代码、报告）在下游使用前做完整性校验，校验失败按截断处理。

人工干预层：给循环设停止条件。 Agent 场景必须为自我验证循环设计停止条件：单步最大思考时间、单任务最大调用次数、连续无产出即告警并转人工。另外有一个容易踩的部署坑：Hy4 的工具调用语义依赖服务端的 hy_v4 解析器，社区技术分析提醒，通用 OpenAI 兼容端点可能接收请求成功但丢失工具语义，所以工具调用任务和纯文本任务要分开测试，别用纯文本测试的通过去推断 Agent 能力可用。

没有第三方数据？这套自测清单把验证权拿回来

前面反复说“内部盲测未经复现”“社区观察非官方基准”，那你自己怎么验证？三类任务，只给设计和观察指标，结果你自己跑出来。调用方式用 OpenAI 兼容接口即可，curl 或 Python SDK 都行，自建服务和第三方 API 网关两条路都通。

任务一：长文档问答，带位置埋点。 准备一份你自己业务里的长文档语料，转成纯文本。把关键证据分别埋在上下文的早、中、晚三个位置，各测一轮同样的问题。观察指标：三个位置的回答准确率差异（这就是“迷失在中间”在你语料上的表现）、单次往返延迟、输入输出 token 消耗。如果中间位置准确率明显掉，你的场景要么调整输入组织方式，要么回到 RAG。

任务二：needle 与多跳检索。 在长文本中插入特定事实，做单针检索和多跳检索，在不同上下文长度档位（比如 100K、500K、900K）下各跑一组，观察命中率随长度的变化。提醒一点：公开的大海捞针类测试有已知的误导性，社区技术分析认为其变体测试更接近真实场景，用自己业务语料做的变体最有参考价值。

任务三：Agent 任务，工具与纯文本分开测。 设计一个需要多步工具调用的任务，观察任务完成率、自我验证循环出现频率、人工打断次数、总 token 消耗。工具调用链路单独测，原因见上一节的解析器问题。

跑自测的入口：不想自部署的话，腾讯云 TokenHub、OpenRouter 都提供 API，WorkBuddy 等产品端在发布时口径下有限时免费期，截止到 2026 年 9 月 10 日、每天有额度上限，具体以官方页面实时信息为准，足够把三类任务各跑几轮。腾讯云的技术文档也给出了一套生产评估门槛，包括回归基线、限制测法、延迟成本、监控回滚等八项，可以作为自测清单的补充框架。

常见问题快答

Hy4 preview 和 GLM 5.3、Kimi K3 比怎么样？ 目前只有腾讯内部盲测口径显示略优，未经独立第三方复现。建议用上面的自测清单在自己场景里对比，别拿厂商口径做决策。

1M 上下文是不是就不用 RAG 了？ 不是。单次通读可试直接塞入，多轮检索问答和海量知识库场景 RAG 仍是主线，长上下文做补充。

为什么输出经常不完整？ 64K 最大输出是官方硬限制，第三方网关文档显示思考 token 计入该上限，长思考场景需预留预算并做完整性校验。

自部署后 1M 上下文自动可用吗？ 不是。受 KV cache 显存约束，实际可用长度取决于硬件配置，Ascend 教程实例显示单节点与双节点差距很大，部署前先确认你的环境能开到多长。

支持图片或视频输入吗？ 官方模型卡未列任何多模态能力，社区观察确认为纯文本模型。多模态需求是当前的能力缺口。

API 多少钱？ 发布时国内定价为输入 6 元每百万 token、输出 18 元每百万、缓存命中 0.3 元，属发布时口径、可能变动，成本测算建议按自己任务的实测 token 消耗来。

评估期不想自部署，哪里能先体验？ 腾讯云 TokenHub、OpenRouter 提供 API，WorkBuddy、CodeBuddy、元宝、ima 等产品端也可体验，WorkBuddy 限时免费期以官方页面实时信息为准。

谁该现在动手，谁该再等等

适合现在投入评估的：有 8 卡集群或云端预算、核心场景是长文档处理或长链路 Agent 的团队，以及 GLM 5.3 / Kimi K3 已在用、想找备选或对照的技术决策者。路径是先走 API 或免费期把三类自测任务跑完，用自己语料的数据做判断。

建议先观望的：多模态是刚需的团队（当前能力缺口）、延迟敏感的交互式产品（长思考倾向下默认档位的表现需要先验证）、以及没有独立测试条件只能依赖厂商口径做决策的场景。preview 这个版本名本身就说明官方还会迭代，观望成本不高。

下一步：自测数据支持继续推进的，可以进入部署环节，站内有一篇 Hy4 preview 的 vLLM/SGLang 完整部署教程和常见报错排查，覆盖 8 卡基线配置；数据不支持的场景，RAG 路线的现有方案不必急着动。