1. 核心功能

根据官方 README，Hy4-preview 的核心能力集中在以下几个方面：

• 长上下文文本生成：支持 1M token 上下文，适合处理长文档、大型代码仓库、完整剧本等超长输入。模型以 text-generation 为 pipeline 标签，本质是一个通用的自回归文本生成模型。
• 复杂任务推理：面向软件工程、办公分析、游戏开发和科学研究等任务优化。官方宣称在 203 个工程任务的内部盲评中，模型表现略优于 GLM 5.3 和 Kimi K3。需要注意的是，这是腾讯内部测试结果，并非第三方公开基准。
• 高效推理架构：内置原生 MTP（Multi-Token Prediction）层用于投机解码，同时通过 Gated DSA 稀疏注意力和 IndexCache 机制降低长上下文下的注意力计算开销。
• 多后端部署支持：官方提供 Transformers 快速加载、vLLM 服务化部署、SGLang 高性能推理以及 Docker Model Runner 四种使用路径，覆盖从实验验证到生产部署的完整链路。
• 量化与微调生态：官方发布 FP8 版本权重，并提供微调指南；量化章节提及支持 llama.cpp、Ollama、LM Studio 等工具链的使用，但当前页面未给出具体量化命令。

2. 技术或工作流程

Hy4-preview 的技术架构可以拆解为四个层次：稀疏注意力、混合专家前馈网络、残差连接设计，以及投机解码加速。

在骨干网络层面，模型共有 78 层，其中第一层使用标准稠密 FFN，其余 77 层采用 MoE 结构。每层包含 256 个 routed experts 和 1 个 shared expert，每个 token 激活 top-8 个 routed experts 以及 shared expert。MoE 中间尺寸为 2048，FFN 中间尺寸为 18432，隐藏层维度为 6144，词表大小 120832。这种“大专家池 + 稀疏激活”的设计，使模型在保持 770B 总参数容量的同时，将单 token 推理的计算量控制在 49B 激活参数的规模。

注意力模块采用 Gated DeepSeek Sparse Attention（Gated DSA），官方 README 明确表示这一设计借鉴了 DeepSeek 和 GLM 的思路。其核心是引入 Query 压缩维度 2048、Key-Value 压缩维度 512，并通过 32 个 indexer heads 以 head dimension 128 执行索引筛选，indexer top-k 为 2048。配合 IndexCache 实现跨层稀疏索引复用，避免每一层都从头计算完整的注意力索引，从而在 1M 上下文窗口下控制显存与算力消耗。

残差路径上，模型使用 iHC（identity Hyper-Connections），提供 4 条残差流，用于增强跨层信息流动。官方引用相关论文和知乎专栏，说明这一设计旨在缓解超深网络中的信息衰减问题。此外，模型内置一层原生 MTP 层，用于 speculative decoding，让推理阶段可以一次预测多个 token，理论上能提升解码吞吐。

训练层面，官方强调模型在预训练和后训练阶段都做了规模扩展，并围绕内部专家工作场景构建训练数据。后训练数据涵盖软件工程、办公与分析、游戏开发、科学研究等方向，并且与腾讯产品工具联动。

官方 README 在“Benchmark Appendix”章节放置了一张居中展示的图示，用于补充该附录的视觉呈现；但当前公开页面没有展开图中的具体数值，也未列出详细的任务对标表格。

图：官方 README 基准附录章节图示

根据项目 README 的上下文，该图位于 Benchmark Appendix 标题下，以居中排版展示，没有替代文本，也没有伴随的指标说明。青峰联创认为，当前页面只提供了该附录的视觉入口，具体评测数据仍需等待官方补充，因此不宜将图中内容解读为已完整披露的基准成绩。

3. 适用场景与落地建议

基于官方 README 的“Built for Productivity”描述，Hy4-preview 明确覆盖软件工程、办公与分析、游戏开发和科学研究四个生产力方向。

场景 1：软件工程

场景 2：办公与分析

场景 3：游戏开发

场景 4：科学研究

4. 安装与运行要求

官方 README 提供了四种主要使用方式。最简单的路径是使用 Transformers 的 pipeline：

from transformers import pipeline
pipe = pipeline("text-generation", model="tencent/Hy4-preview")
messages = [{"role": "user", "content": "Who are you?"}]
pipe(messages)

需要更底层控制时，可以直接加载模型：

from transformers import AutoModelForCausalLM
model = AutoModelForCausalLM.from_pretrained("tencent/Hy4-preview", device_map="auto")

对于生产环境，官方推荐使用 vLLM 部署 OpenAI 兼容 API：

pip install vllm
vllm serve "tencent/Hy4-preview"

随后通过标准 curl 调用 /v1/chat/completions 接口。SGLang 的部署方式同样在官方文档中给出，既支持 pip 安装后启动，也支持 Docker 镜像运行。SGLang 的 Docker 命令中设置了 --shm-size 32g，说明长上下文推理对共享内存有明确需求。

此外，官方还提供了 Docker Model Runner 的极简启动方式：

docker model run hf.co/tencent/Hy4-preview

对于量化部署，官方提到可在 llama.cpp、Ollama、LM Studio 中使用量化版本，但当前 README 页面没有给出具体的量化命令或工具链参数，需要等待补充或参考社区方案。

5. 环境、硬件或依赖

Hy4-preview 的模型权重托管于 Hugging Face，同时提供 ModelScope、GitCode 和 CNB 镜像入口。模型以 Transformers 为基准库，pipeline 类型为文本生成。

官方 README 并没有给出明确的最低硬件配置清单。从权重规模推断，770B 总参数即使以 FP8 存储，完整加载也需要数百 GB 显存，单张消费级显卡无法承载。49B 激活参数则意味着单次前向计算对显存带宽和算力都有较高要求。青峰联创认为，实际部署至少需要多卡高端 GPU 服务器，且 1M 上下文的推理还会显著放大 KV Cache 显存占用；具体卡型、卡数和吞吐表现，应以官方后续说明或社区实测为准。

依赖方面，vLLM 和 SGLang 均需要 Linux 环境与 CUDA 环境支持，Docker 部署时还需注意共享内存设置。官方未提供 CPU 推理建议，也未说明 Windows 原生支持情况。

6. 已知限制

官方 README 的“Known Limitations”章节明确指出，Hy4-preview 是 Hy4 的早期版本，预训练和后训练都留有提升空间。已知问题包括：

• 在复杂任务上会花费比实际需要更长的时间进行推理；
• 倾向于过度验证自己的工作，即输出中可能包含多余的自我检查或重复确认步骤。

官方表示会继续快速迭代，并援引 Hy3 preview 的经验：提前发布、收集社区反馈、针对问题快速改进，是上一代模型显著提升的关键路径。

此外，当前 Hugging Face 页面虽然列出了 Benchmark Appendix、News、Finetuning、Quantization 等章节标题，但正文中尚未展开详细基准数据、微调命令和量化命令。这意味着除架构参数和部分使用说明外，模型的性能证据、微调细节和量化方式仍需进一步公开。

7. 青峰联创分析

以下内容为青峰联创基于公开物料的分析，不代表官方承诺。

Hy4-preview 在开源模型竞赛中选择了“超大 MoE + 生产力导向”的差异化路线。770B 总参数、49B 激活参数的规模直接对标当前开源社区第一梯队，而 1M 上下文窗口则试图在长文档和复杂任务场景建立体验优势。Apache-2.0 许可进一步放大了其吸引力——企业无需担心商用授权风险，这是推动开源大模型落地的重要筹码。

从架构设计看，Gated DSA 稀疏注意力与 IndexCache 的组合，反映出长上下文推理的成本控制正在从“减少注意力计算”走向“跨层复用索引”的新阶段。官方承认借鉴了 DeepSeek 和 GLM 的思路，说明头部开源团队在稀疏架构上已经形成一定的技术共识。iHC 残差连接和原生 MTP 层则是腾讯混元的差异化尝试，前者解决深层网络信息流动问题，后者直接服务于推理加速。这些设计表明，模型不是简单复刻已有 MoE 结构，而是围绕实际部署成本做了针对性优化。

内部盲评中“略优于 GLM 5.3 和 Kimi K3”的说法值得关注，但必须保持审慎。内部盲评与第三方公开基准之间存在方法论差异，测试集构成、评判标准和评分方式都未披露。真正有说服力的验证，需要等社区在公开 benchmark 上完成独立复现。与此同时，官方坦承的“推理时间过长”和“过度验证”两个问题，也可能影响复杂任务下的使用体验。对于生产环境而言，这些都是必须实测的关键指标。

从生态角度看，Hy4-preview 与 CodeBuddy、WorkBuddy 的协同设计，显示出腾讯混元正在走“开源权重 + 产品联动”的路线。开源版本提供基础能力，商业产品在模型之上封装工具链和场景体验。这种策略既能为研究社区提供完全开放的模型权重，又能为内部产品积累真实反馈，形成数据与能力的闭环。

综合来看，Hy4-preview 是一个架构指标领先、开源策略激进、但尚未被第三方充分验证的模型。它在长上下文和生产力场景的定位足够清晰，技术选型也紧跟前沿；具体任务表现是否真如官方所述，则需要等待更完整的基准公开和社区实测。对于有算力条件、希望在开源模型上做深度定制的团队，这是一个值得纳入评估清单的候选项目。

8. 信息来源

• 官方项目仓库《Hy4-preview》