腾讯 Hy4 preview 开源后，API 怎么选：本地部署、兼容接口与中转渠道核验清单

腾讯在 2026 年 8 月 28 日 发布并开源了 Hy4 preview。消息出来后，很多人的第一个问题不是“它的架构是什么”，而是：我今天能不能直接调用？应该自己部署，还是找一个 API 渠道？

答案不能只看“开源”两个字。Hy4 preview 的总参数达到 770B、每个 token 激活 49B，官方模型卡还给出了 1M 上下文、vLLM 和 SGLang 部署路径。对普通开发者而言，真正的选择是四层问题：

有没有拿到可信的模型权重或 API 入口；
自部署的硬件和推理框架是否匹配；
OpenAI 兼容只是请求格式兼容，还是工具调用、推理字段也能工作；
第三方渠道的模型名、价格、限额和实际提供方能不能逐项核验。

本文按这四层拆开。价格和可用性只记录我在 2026 年 8 月 30 日 UTC 看到的页面快照，不把一次页面观察写成长期保证。

先给结论：开源权重与 API 供给是两件事

如果你有大规模 GPU 资源、愿意维护推理服务，并且需要数据留在自己的环境里，Hy4 preview 的开源权重提供了自部署选项。

如果你只是想在代码代理、长上下文分析或工具调用项目中试用，先找一个能公开展示模型标识、计费规则和接口文档的 API 入口，通常比一开始采购整套推理集群更容易验证需求。

但“第三方能调用”仍然不等于“官方直连”。选择渠道时至少要把下面三件事分开记录：

模型事实：腾讯官方和模型卡说明了什么；
部署事实：vLLM、SGLang 实际要求什么硬件和参数；
渠道事实：某个 API 页面当前展示什么价格、提供方和接口行为。

这也是为什么本文不直接给某个渠道贴上“最好”“最稳定”或“官方”的标签。

Hy4 preview 到底开源了什么

腾讯官方公告将 Hy4 preview 描述为面向真实生产力任务的新一代大语言模型，覆盖编码、办公和科研场景，并说明模型已开源，同时可通过腾讯自己的产品访问。Hugging Face 模型卡则给出了更具体的工程信息：

总参数：770B；
激活参数：49B/token；
架构：Mixture-of-Experts（MoE）；
上下文长度：1M；
许可：Apache 2.0；
提供 Hy4-preview 和 Hy4-preview-FP8 两个模型权重入口。

这些信息说明它是一个面向长任务和复杂工具使用的大模型，但不能直接推出“所有 API 渠道都已经支持”“本地电脑可以运行”或“输入输出价格一定很低”。模型权重开放、推理服务开放、第三方 API 聚合，分别是不同的供给状态。

另外，SGLang 文档明确把 Hy4 preview 描述为文本模型，并指出工具调用需要配合相应的 Hunyuan tool-call parser。也就是说，看到一个渠道写着“支持 Hy4”，还要继续问：它支持的是普通文本对话，还是连 reasoning、streaming、tool calling 和结构化输出一起支持。

自部署：为什么不是下载权重就结束

1. 先估算硬件，而不是只看激活参数

MoE 模型的“每 token 激活 49B”并不意味着只需要为 49B 参数准备显存。服务启动时仍要加载完整权重或其量化版本，还要为 KV cache、运行时、并行通信和上下文长度留空间。

vLLM Recipes 给出的 Hy4 preview 部署描述是 16 张 B200 或 8 张 B300，并配合 MTP（multi-token prediction）做推测解码。SGLang 文档同时列出 H200、B200、B300、GB300 等硬件路径，并区分 BF16 与 Blackwell 上的 MXFP8 方案。

这带来一个实际判断：

个人开发机：不适合把“本地部署 Hy4”当作低门槛教程目标；
研究或企业 GPU 集群：可以按 BF16/FP8、tensor parallel、上下文预算和并发量核算；
普通 API 用户：应先验证远程 API 的能力和成本，再决定是否值得自建。

2. 推理框架版本也属于兼容性的一部分

Hugging Face 模型卡给出了 vLLM 和 SGLang 的启动方式，而不是只给一个权重下载地址。官方示例包含了模型名、并行参数、推测解码以及 reasoning/tool-call parser 等配置。

这意味着自部署时至少要固定以下变量：

变量	为什么要记录
权重版本	`Hy4-preview` 与 `Hy4-preview-FP8` 的显存和精度取舍不同
推理框架与镜像	模型代码、稀疏注意力和 parser 可能依赖特定版本
并行方式	GPU 数量、通信拓扑和 tensor parallel 会影响能否启动及吞吐
上下文上限	1M 是模型能力上限，不等于你的服务会为每个请求分配 1M KV cache
parser 配置	reasoning 与 tool calling 不配置时，返回格式可能和客户端预期不同

不要把公开模型卡里的“1M context”直接当成 API 套餐里的“每次请求免费使用 1M”。服务商可能另设上下文上限、最大输出、并发、速率或计费规则。

OpenAI 兼容：能发请求，不代表能跑代码代理

Hy4 preview 模型卡提供了一个 OpenAI SDK 风格的示例，通过修改 base_url、api_key 和 model 发起 Chat Completions 请求。这对已有 OpenAI 客户端的开发者很方便，但兼容性要分三层测试。

第一层：基础文本请求

先用最小请求验证：

GET 模型列表是否可用，或者服务文档是否明确模型名；
Chat Completions 路径是否存在；
普通文本请求是否返回合法 JSON；
流式响应是否按客户端能识别的 SSE 格式返回；
输入、输出 token 是否能在响应中统计。

一个只返回普通文本的接口，可以说明“基础对话能通”，不能说明它适合 Claude Code、Codex、Cursor 或 MCP 工具链。

第二层：推理与流式字段

Hy4 preview 默认 reasoning mode 为 high，模型卡还给出了 no_think 的调用方式。不同服务商可能会：

把思考内容放在自定义字段；
直接剥离思考内容，只返回最终答案；
在流式响应中使用不同的 chunk 字段；
对 reasoning_effort 或额外 body 参数做转换或忽略。

因此，接入代码代理前不要只测试“你好”。应使用一个短代码修复任务，检查最终答案、增量事件、usage 字段和错误信息是否符合客户端预期。

第三层：工具调用与结构化输出

SGLang 文档专门提供了 Hy4 preview 的 tool-call parser 说明：模型生成的工具调用需要经过解析，才能重组为 OpenAI 风格的 message.tool_calls，并兼顾流式与非流式请求。

这对 Agent 尤其重要。若渠道只做了文本字段映射，却没有正确处理工具调用，常见表现包括：

模型说“我准备执行命令”，但客户端收不到 tool_calls；
参数 JSON 被截断或变成普通文本；
流式和非流式返回结构不一致；
代码代理反复重试，最终把 token 和费用一起放大。

所以“OpenAI 兼容”在选 API 时应写成测试清单，而不是一句宣传语。

第三方 API 渠道：2026 年 8 月 30 日应核对什么

我在 2026 年 8 月 30 日 UTC 打开 OpenRouter 的 Hy4 preview 页面时，页面显示：模型于 2026 年 8 月 28 日发布；输入价格为 $0.834 / 1M tokens，输出价格为 $2.501 / 1M tokens，上下文标为 1M，并显示当时只有一个提供方。

这段信息有三个限制：

这是公开页面的动态快照，不是长期价格承诺；
“一个提供方”意味着替代路径可能有限，不能自动推出高可用；
页面标价是该页面的渠道价格，不等于腾讯官方价格，也不等于所有中转站的最终价格。

如果你在其他中转站看到 Hy4 preview，建议按下面的表格逐项记录，而不是只看倍率或首屏宣传：

核验项	需要确认的证据	不能直接相信的说法
模型名	控制台模型列表、接口文档、实际响应中的 model 字段	“已接入 Hy4”但没有可调用模型名
上游来源	服务商对提供方的说明、可复现实测和错误信息	“官方直连”但没有一手证明
输入/输出价格	当前价目页、计费单位、缓存和折扣规则	只写“低至某倍率”
上下文限制	API 文档中的 max input、max output 和套餐限制	直接照搬模型卡的 1M
工具调用	schema、streaming、tool_calls 的实测响应	只展示聊天截图
限流与余额	RPM/TPM、并发、最低充值、余额扣费规则	只承诺“高并发”
失败处理	401、403、429、5xx、超时和重试说明	一次成功请求就称“稳定”
数据与日志	隐私政策、日志保留和敏感信息处理说明	没有说明却声称“安全”

尤其要把官方模型定价、渠道标价、倍率、充值门槛和最终成本分开。比如一次请求可能还受到输入输出比例、缓存命中、最低计费单位、失败重试和上下文长度影响。只拿一个倍率乘上官方价格，很容易得到一个看似精确但并不适用的数字。

一套 15 分钟的 Hy4 API 验证流程

第一步：确认模型身份

记录完整的模型字符串，例如 tencent/Hy4-preview、hy4-preview 或渠道自定义名称。不要只在前端下拉框里看中文别名，要把实际发送的 model 和返回的 model 一起保存。

第二步：跑最小文本请求

固定同一段短提示词，分别测试非流式和流式。记录 HTTP 状态码、首 token 时间、总耗时、输入输出 usage 和完整错误体。单次结果只能用于发现明显故障，不能用来宣称长期延迟或成功率。

第三步：跑一个短代码任务

让模型完成一个可验证的小任务，例如解释一个函数并给出单元测试。这样能同时观察长输出、代码块、reasoning 开关和 token 统计。

第四步：跑工具调用

使用一个无副作用的本地工具，例如读取固定 JSON 或计算表达式。检查客户端收到的是否是结构化 tool_calls，参数是否可解析，工具结果回传后模型能否继续对话。

第五步：做一次失败测试

主动使用错误模型名或无效 Key，确认 API 返回 401/404/模型不存在时是否给出可读错误。再按文档设置一个较低的并发或速率，观察 429 是否带有重试提示。

第六步：把价格换算成自己的请求成本

用自己的输入输出比例估算，而不是套用“每百万 token”的单一数字：

单次成本 = 输入 token ÷ 1,000,000 × 输入单价
         + 输出 token ÷ 1,000,000 × 输出单价
         + 缓存、工具调用、重试或其他附加费用

如果服务商按倍率、分组或余额扣费，先把这些规则写成单独的变量。测试时保留请求时间、模型、endpoint、样本数量和环境，否则过几天再看账单时很难解释差异。

哪种选择更适合你

适合先找 API 渠道的情况

你想快速试用 Hy4 preview 的长上下文、编码或工具调用；
没有足够 GPU，或者不想维护推理框架；
你能接受先做协议、价格、限流和数据处理核验；
你的应用可以容忍单一提供方或临时不可用，并且准备备用模型。

适合评估自部署的情况

你已经有匹配的 GPU 集群和运维能力；
需要更明确的数据边界和内部日志策略；
能根据真实上下文长度、并发和输出比例做容量测试；
愿意跟进 vLLM/SGLang 镜像、模型权重和 parser 的变化。

不适合马上下结论的情况

只看到一个“支持 Hy4”的宣传页，没有实际模型名和文档；
只比较倍率，没有输入输出价格与最低计费规则；
只测通一次，就把渠道写成长期稳定；
把模型卡的开源许可误认为 API 服务也无需付费；
需要工具调用，却没有做结构化返回测试。

最后：把“能不能用”拆成四个问题

Hy4 preview 的开源价值很明确：研究者和服务商可以获得权重、部署参考和推理框架支持。但对 API 用户来说，真正要问的是：

模型是否真实存在于这个渠道的模型列表中？
基础对话、流式输出、reasoning 和 tool calling 是否分别可用？
当前价格、上下文上限、限流和余额规则是否写清楚？
单一提供方不可用时，是否有可验证的替代路径？

如果你只是试用，先用小额、低风险请求完成上面的验证，再决定是否迁移代码代理或生产流量。需要寻找其他模型或 API 渠道时，可以从 RouterHub 的平台目录开始，进入具体站点后仍要以其当前文档、价目页和实际响应为准。

参考来源

腾讯官方：Tencent Releases and Open-Sources Tencent Hy4 preview（发布日期：2026-08-28，核验：2026-08-30）
Hugging Face：Tencent Hy4-preview 模型卡（模型规格、OpenAI SDK 示例、vLLM/SGLang 入口，核验：2026-08-30）
vLLM Recipes：Tencent Hy4-preview（部署硬件与推理配置说明，核验：2026-08-30）
SGLang Cookbook：Tencent Hy4 preview（reasoning、tool calling 与部署说明，核验：2026-08-30）
OpenRouter：Tencent Hy4 preview（公开 API 页面动态价格、提供方与可用性快照，核验：2026-08-30）