1.5TB 压到 214GB，长上下文模型到底是不是刚需？

上周腾讯开源了 Hy4 preview，770B 的 MoE 模型，1M token 上下文，Apache 2.0 协议。这个规模的权重接近 1.5TB，单卡肯定跑不了，8 卡 B300 起步。

但三天后，腾讯又丢了个更狠的——轻量版。1.5TB 压到了 214GB。用的是 Sherry 稀疏三值量化，把路由专家的权重压到平均 1.25 比特，还搞了个混合精度策略，敏感层保留 2 比特，不敏感层直接压到 1.31 比特。

压缩比 7:1，长文理解几乎没掉分。

这个事让我想到一个问题：1M token 的上下文，到底有多少人真的需要？

长上下文，谁在用、用来干嘛

先看几个数据。

Google Gemini 1.5 Pro 最早把上下文推到 1M token，那是 2024 年的事。两年过去了，我观察到的实际使用场景大概只有三类：

第一类，代码库分析。 把整个代码库塞进上下文，让模型理解项目结构、找 bug、做重构。这个场景确实需要长上下文——一个中等规模的项目，光是源码就能吃掉几十万 token。

第二类，长文档处理。 金融研报、法律合同、学术论文——几百页的文档一次性读完，然后提取关键信息。这个场景需要上下文够长，但实际需求是"能一次读完"，不是"越长越好"。

第三类，Agent 记忆。 这是 2026 年才真正跑起来的场景——Agent 在执行长周期任务时需要记住上下文，对话轮次一多，上下文窗口很容易被打满。Claude Fable 5.1 的 Agent 能力能连续跑几个小时，上下文管理就成了瓶颈。

但问题来了：绝大多数用户，日常根本用不到 100 万 token。

我自己的使用习惯是，70% 的请求在 8K token 以内，20% 在 32K 以内，超过 100K 的不到 5%。这不是我一个人这样——很多做 AI 工具的朋友反馈差不多。真正需要用满 1M token 的场景，要么是测试，要么是特定领域的深度分析。

那为什么每家都在卷长度？因为 1M 是个标杆数字。你做到了，别人没做到，你就能在 PR 里写一行。但用户拿到手之后，这个能力的实际使用率，恐怕没多少厂商愿意公开。

MoE 架构的价值，不在参数总量

聊回 Hy4 本身。

770B 总参数，49B 激活，这个比例大概 15:1。MoE 的优势在于，你有一支"专家团队"，但每次只叫其中几个人干活。所以 770B 听起来吓人，实际推理的计算量只相当于一个 49B 的密集模型。

但 MoE 真正的挑战在部署。

Hy4 权重 1.5TB，哪怕激活参数只有 49B，你得先把它装进显存。8 卡 B300 每卡 192GB，总共 1.5TB，刚好卡在边界上。这意味着你要么用 8 卡集群跑推理，要么想办法压缩。

腾讯轻量版的思路挺有意思。他们没有用传统的 4-bit 或 8-bit 量化，而是搞了个"稀疏三值"——权重不是 0 就是 1 或者 -1，乘法变成了加法。这个思路在学术圈不新鲜，但落地到 1M 上下文的 MoE 模型上，能保持长文理解不掉分，确实有点东西。

214GB 什么概念？一块 H100 80GB 跑不了，但 4 块 H100 就可以了。或者一块 B200 就够了。部署门槛从"8 卡集群"降到了"单卡 B200 或者 4 卡 H100"，这对很多中小团队来说是质的变化。

不过坦白说，我还没看到有人真正把 Hy4 轻量版部署到生产环境跑长上下文任务。量化模型在长上下文场景下，注意力机制的精度会不会受影响，这是一个需要实际验证的问题。官方说"几乎持平"，但"几乎"这两个字，在工程上往往意味着"你最好自己测一遍"。

长上下文 vs 检索增强，不应该是二选一

我经常看到一种争论：长上下文会取代 RAG。

持这个观点的人说，既然模型能一次读完 100 万 token，那就不需要分块检索了。直接全量塞进去，让它自己找。

但实际用过的都知道，这不太现实。

第一，成本。Hy4 preview 的 API 定价是输入 0.834 美元、输出 2.501 美元每百万 token。如果每次请求都塞 100 万 token，一次对话就将近一美元。对于大多数应用场景，这个成本扛不住。

第二，召回精度。长上下文模型的注意力分布是稀疏的——模型确实能"看到"所有 token，但真正关注到的可能只有其中一小部分。RAG 的精髓在于，它用检索器把最相关的片段先筛出来，再喂给模型。这个过程不仅省 token，而且精度更高。

第三，迭代。长内容是静态的，而 RAG 的检索源可以动态更新。你今天向量库里加了新文档，明天检索结果就变了。长上下文不行，你每次得重新构造输入。

所以我更倾向于另一个判断：长上下文和 RAG 是互补的，不是替代的。 长上下文适合"一次性读完"的场景——比如 review 一个完整的代码库、分析一份几百页的合同。RAG 适合"持续更新"的场景——比如客服知识库、企业文档检索。两者各有各的位置。

这次 Hy4 能同时做到 1M 上下文和 49B 激活，说明 MoE 模型在长上下文方向上确实有潜力。但真正的价值释放，可能不在那个"1M"的数字上，而在 214GB 轻量版带来的部署灵活性上——你能在本地跑一个 770B 的模型，哪怕只是局部精度，也意味着很多以前需要云端 API 才能做的事，现在可以在本地完成了。

几个值得关注的方向

顺着这个事，我梳理了几个接下来值得关注的技术方向。

第一，MoE + 量化的组合拳会成为标配。 纯 MoE 模型部署成本高，纯量化模型精度有损失，但两者结合之后，确实能在成本和精度之间找到一个不错的平衡点。Hy4 轻量版只是一个开始，接下来会有更多团队在这个方向上探索。

第二，长上下文的评估标准需要重新定义。 现在的评测基准大多是"多长能记住"——比如大海捞针测试。但实际应用中，关键是"在长上下文里能不能准确找到并利用信息"，而不是"能不能记住"。这两个指标差挺远的。

第三，开源模型的"价值锚点"在变。 以前大家比参数量、比基准分。但现在，Apache 2.0 协议 + 实际部署门槛 + 场景适配度，正在成为新的评判维度。Hy4 的权重是 Apache 2.0 的，没有 MAU 限制，没有自定义协议——这比很多"开源但限制商用"的模型，对开发者来说友好得多。而且 770B 的 MoE 模型能被量化到 214GB 在本地跑，这本身就是一个信号：开源模型正在从"云端演示"走向"本地可用"。

你觉得长上下文是刚需还是噱头？你平时用 32K 以上的上下文窗口做过什么实际的事吗？欢迎评论区聊聊。