腾讯开源 Hy4 Preview：770B 总参数、49B 激活参数、百万级 token 上下文的编码与研究大模型

2026 年 8 月 28 日，腾讯正式发布并开源了 Hy4 preview——一款总参数 770B、激活参数 49B 的混合专家模型，上下文窗口超过一百万 token。它不像以往那样只强调跑分，而是直接瞄准「真实生产力任务」：软件工程、办公分析与金融、游戏开发、科学研究。对开发者来说，最值得关注的三个信号是：开源权重可在 Hugging Face 直接下载、百万级上下文让「整仓级」编码任务第一次有了可行的开源选择、API 定价把长上下文任务的成本压到了可计算的范围。

1. 这次发布的是什么

Hy4 preview 采用 MoE 架构，770B 总参数中每次请求只激活约 49B。官方渠道包括 CodeBuddy、WorkBuddy、元宝与 ima，开发者也可以经腾讯云 TokenHub 与 OpenRouter 调用 API。发布时 WorkBuddy 与 CodeBuddy 提供两周免费体验，Hy3 的免费访问则延长到 9 月 30 日。在腾讯内部 163 位专家对 203 项工程任务的盲评中，Hy4 preview 均分 2.99/4.00，略高于 GLM-5.3（2.92）与 Kimi K3（2.94）——注意这是厂商内部评测，正式对比仍需第三方复现。

# Download the open weights from Hugging Face.
# Hy4 preview ships alongside Hy3, so pin the repo revision.
pip install -U huggingface_hub
huggingface-cli download tencent/Hy4-preview --local-dir ./hy4-weights
# A quantized variant is the usual first stop for local testing:
huggingface-cli download tencent/Hy4-preview-FP8 --local-dir ./hy4-fp8

2. 为什么「49B 激活」比「770B 总参数」更值得看

MoE 的意义在于：单次请求的算力开销由激活参数决定，而不是总参数。49B 激活意味着推理成本接近中小型稠密模型，同时 770B 总参数提供了巨大的知识容量；而超过 1M 的上下文窗口才是这次最大的工程变量——它让模型可以一次性读完一个大型代码仓库的关键文件、跨文档的财报材料，再开始多步推理。对「长程软件开发」而言，上下文长度往往比单项基准分数更能决定任务成败。

// Before spending on GPU hours, estimate the real cost of your
// workload: active params matter more than total params for MoE.
function estimateMoECost(tokens, opts) {
  const activeB = opts.activeBillion || 49;
  const totalB = opts.totalBillion || 770;
  // MoE routes each token through the active subset, so the flops
  // per token scale with active parameters, not the full count.
  const flopsPerToken = 6 * activeB * 1e9;
  const totalFlops = tokens * flopsPerToken;
  return {
    activeShare: (activeB / totalB * 100).toFixed(1) + '%',
    totalFlops: (totalFlops / 1e18).toFixed(2) + ' EFLOPS',
    note: 'context length dominates memory, not compute'
  };
}

3. 编码与生产力能力定位

腾讯把 Hy4 preview 定位为生产力模型而非纯代码补全器。软件工程方向上，它强调长上下文任务的理解、规划、调试与验证能力，并改善了前端开发的视觉质量与交互体验；办公与金融分析方向上，支持跨文档协作与「从信息处理到产出文档/表格/演示文稿」的完整链路；游戏方向可以从一句自然语言生成可玩的游戏原型。对团队而言，这意味着它更适合当「分析型代理」而不是「自动补全插件」。

// Hy4 preview API pricing (per million tokens), USD.
const HY4_PRICE = {
  input: 0.834,
  output: 2.501,
  cacheHit: 0.042, // cache reads are dramatically cheaper
};

function costPerTurn(inputTokens, outputTokens, cacheHits) {
  return (
    cacheHits * HY4_PRICE.cacheHit / 1e6 +
    (inputTokens - cacheHits) * HY4_PRICE.input / 1e6 +
    outputTokens * HY4_PRICE.output / 1e6
  ).toFixed(4);
}

// A 60k-token agent loop with 50k cached reads:
console.log(costPerTurn(60000, 4000, 50000)); // ~0.0218 USD

4. 成本画像：长上下文首次变得可负担

API 定价为每百万输入 token 0.834 美元、每百万输出 2.501 美元、缓存命中每百万仅 0.042 美元。缓存价格是输入价格的 1/20，对代理循环是决定性的：每轮重复读取同一上下文时，命中缓存的 token 几乎不花钱。以一个 6 万 token 的代理回合为例，若 5 万 token 命中缓存，单回合成本约 0.022 美元。把路由策略写清楚——简单任务走 Hy3、长程任务走 Hy4 preview——比无脑升级模型更能控制账单。

5. 自我改进与推理优化：31.8% 吞吐提升

Hy4 preview 首次参与了自身研发流程：它被用来自动优化训练方法、数据策略、评测框架与底层算子，形成早期「递归自我改进」闭环；同时自主分析推理系统瓶颈，对算子融合与通信优化进行多轮改进，端到端吞吐相比基线提升 31.8%，且在不同上下文长度与并发下保持一致。对架构师来说，这暗示未来开源模型的发布节奏会更快——模型自己也在帮厂商调优部署栈。

// Route tasks to the cheapest model tier that can finish them.
// Tencent ships Hy3 and Hy4 preview side by side, so route by
// difficulty instead of using one default for everything.
function pickModel(task) {
  if (task.ctxTokens > 900000 || task.depth === 'multi_repo') {
    return 'hy4-preview';   // million-token context, long-horizon work
  }
  if (task.kind === 'research' || task.kind === 'finance') {
    return 'hy4-preview';
  }
  return 'hy3';             // cheaper for everyday coding
}

6. 现在该做什么

第一，先跑你自己的评测：用真实仓库与任务回放对比 Hy4 preview 与现有默认模型，公共跑分只能当参考。第二，把路由策略写进代码：按上下文长度与任务难度在 Hy3 与 Hy4 preview 之间切换。第三，用成本公式（激活参数 + 缓存命中）估算每回合开销，而不是拍脑袋。最后，注意百万级上下文的记忆体占用——长上下文在显存上的成本与算力同样重要。

// Run your own blind eval before adopting any open model.
// Public claims are directional; your tasks are the contract.
const evalTasks = [
  { id: 'fix-crash', prompt: 'Root-cause this intermittent failure', ctx: 820000 },
  { id: 'refactor-module', prompt: 'Refactor legacy module with tests', ctx: 150000 },
  { id: 'finance-report', prompt: 'Summarize this earnings call', ctx: 40000 },
];

async function runEval(model) {
  const results = [];
  for (const t of evalTasks) {
    const ok = await executeTask(model, t);   // your harness
    results.push({ task: t.id, passed: ok, cost: costPerTurn(t.ctx, 4000, 0) });
  }
  return results;
}