企业官网建设流程全解析

看到腾讯混元这次把 Hy4 Preview 带出来的时候，我对榜单上的跑分反而没什么兴趣，真正让我停下来多看了几秒的是另一行字：295B 到 770B。如果你整天只接 API，可能觉得这不过是一句“哦，变大了”；但如果你跑过大型模型，就会知道这个数字背后牵扯的东西极多——模型权重落盘体积、显卡显存规划、路由负载均衡策略、并行度设计，甚至业务侧的调用成本模型，全部都要重新盘一遍。

这篇文章不打算复述新闻，也不打算重复官方通稿。我更想从一个在业务里长期接大模型 API、也折腾过私有化推理的工程师角度，聊一聊：295B 到 770B 这种参数规模跃迁，底层架构为什么必须跟着变；对整个开发链条上的调用、迁移、评测和最终“生产力落地”到底意味着什么。适合正在做技术选型、拿不准要不要切换到新版本的人，也适合想理解“模型变大不等于简单放大”的读者。

1. 先别急着聊架构：295B 和 770B 到底意味着什么

1.1 总参数和激活参数不是一回事

很多人看到 770B 的第一反应是“能力大概是 295B 的 770/295 倍”。这个理解有两个问题。

一方面，模型能力和参数量不是线性关系。参数增加，确实能提高知识容量和复杂模式的拟合能力，但对很多任务来说，边际收益会递减。从 70B 到 700B 的体感差异，远比 7B 到 70B 模糊得多，因为到一定体量后，天花板会变成训练数据的质量、对齐水平、推理能力，而不是“参数到底装了多少事”。

另一方面，平时说的“总参数”指的是权重文件里所有可训练参数，不代表每一步推理都会把每个参数都算一遍。尤其参数量到了 295B、770B 这个级别，基本不会再用一个完全稠密的 Transformer 直接塞进显存硬推理，而是会走 MoE（Mixture of Experts，混合专家）这类稀疏结构：总参数量可以很大，但单个 token 只会激活其中一小部分专家。

Hy3 的 295B、Hy4 Preview 的 770B，这里很难从标题直接判断到底是“稠密总参”还是“MoE 总参”。但从行业通用做法和推理成本反推，更合理的猜测是：它大概率是稀疏 MoE 架构下的总参数规模。你要比较“变强了多少”，更应该看激活参数——也就是每个 token 实际参与计算的那部分参数——而不是眼睛盯着墙上的 770B。

提醒一下：我见过不少同学直接用参数量估算推理速度，得出“旧版能跑 20 token/s，新版参数大 2.6 倍，所以大概只剩 8 token/s”这种结论。这个估算在稠密模型之间大体能站住脚，遇到 MoE 就完全失真。

1.2 显存和成本：先算一笔最容易算错的账

假设我们不考虑任何稀疏结构，只按权重体积来算：BF16 精度下，1B 参数差不多占 2GB 显存。实际部署还得算上 embedding、layer norm、位置编码等额外量，但先按这个粗略公式盘：

• 295B 参数的 BF16 权重，约 590GB；
• 770B 参数的 BF16 权重，约 1.54TB。

也就是说，即便底层架构不变、不做任何量化，单从权重加载看，你就不能再用以前“8 张 A100/H100 就能跑”的预算去规划。8 张 80GB 显卡一共才 640GB 显存，连 770B 的 BF16 权重都塞不下，更不用说推理时还要给激活值、KV Cache、通信缓冲留空间。

所以到 770B 这个规模，现实方案基本只有几条：

• 量化：把权重压到 INT8/FP8，存储和带宽压力减半，但需要实测精度回退是否可接受；
• 多机分布式推理：把参数切到几十张卡甚至更多，网络带宽和调度复杂度立刻上一个台阶；
• 走服务方 API：把部署痛苦转移出去，按 token 计费，但需要评估延迟、限流和数据边界。

这也是我为什么总说“架构跃迁”不是模型团队内部的事，它会顺着部署方式一路传导到你的预算表。770B 听起来是一次性能升级，落地时先砸过来的往往是成本重估。如果你正准备为 Hy4 Preview 扩容，第一步不是训练技巧，而是先把“卡有多少、带宽够不够、评测能跑多并发”算清楚。

我个人经验：评估这种体量模型的部署成本，别只盯着权重文件。KV Cache 的开销常比预想更大，尤其上下文一长，后半段推理延迟会逐步上涨。建议按“模型权重 + KV Cache + 20% 通信/显存冗余”来规划显存，不要卡着 90% 容量去接流量，否则一个高并发峰值就能把节点打挂。

1.3 规模变大，训练和推理的复杂度会换“品种”

参数量从 295B 到 770B，除了显存总量，还有两个隐蔽变化。

第一是训练并行策略更复杂。稠密模型相对好办，张量并行、流水线并行、数据并行按层切就行。但 MoE 会多一个“专家并行”维度。每个 token 要路由到不同专家，如果某个专家被路由到的请求特别多，负载一不均衡，就会出现部分 GPU 忙不过来、另一部分在摸鱼的现象。看网上的“架构跃迁”讨论，很少人提这一点，但它才是训练稳定性的关键。

第二是长上下文的代价。上下文窗口越长，注意力计算复杂度越高，KV Cache 也越大。770B 模型如果支持长上下文，对显存管理、调度器、缓存策略的要求会比 295B 高一整个档次。推理框架通常需要配合 PagedAttention、Prefix Caching、KV Cache 量化等手段，否则并发一上来，显存很快会被长请求填满。

所以，“从 295B 到 770B 是架构跃迁”这句话，我理解是在说：它不能只把 Transformer 每一层等比例加宽，而是必须动骨架。Transformer 依然是底座，但里面的注意力机制、专家路由、层级分布、训练目标都可能调整。这些藏在底层的变化，最终会表现为模型输出质量、稳定性、指令遵循能力的变化。

2. 架构跃迁到底藏在哪里：从 MoE 到长上下文能力

2.1 为什么这个量级几乎必然会走向 MoE

如果真把参数量拉到 770B，同时又不能让推理成本线性上涨，那最现实的技术路径就是 MoE。这个架构经常被误认为是“好几个模型商量着回答”，其实更贴切的比喻是：一家大公司里坐着几千个领域的专家，但每个来咨询的人不会把所有人都喊来开会，而是由一个前台判断“你现在这个问题，应该找哪几位专家聊”。

整套结构里有两个关键角色：

• Router（路由）：对输入 token 打分，选出最合适的 k 个专家；
• Expert（专家）：通常是 FFN 层的多个副本或变体，各自学习不同模式。

于是总参数量可以做很大，但每次推理只激活一部分专家和注意力层。一个 770B 总参数的模型，完全可能把激活参数控制在几百亿以下，远端看起来像是另一个规模的模型。最终效果由专家分工的细致程度、路由的准确度、被激活参数的表达能力共同决定。

这也是为什么这种结构对扩容友好：想变强，就往专家池里加人，不需要把原有每层推倒重来。但反过来，它对训练框架非常不友好：路由一旦学偏，会出现一批专家忙死、一批专家饿死，训练效率和稳定性都会很难看。网上能看到的各种跳票、Preview、渐进式开放，很多都和这类稳定性问题有关，不只是市场策略。

2.2 路由稳定性是那只看不见的手

做算法的人看模型，喜欢丢几个测试题。做训练和部署的人，却会长期盯两个指标：专家负载均衡程度、路由的重复度。如果某个专家收到的 token 太少，它的参数等于白训；如果某几个专家收到特别多，又会造成单卡显存和算力瓶颈。

到 770B 量级，负载均衡通常要依靠更复杂的辅助 loss、专家容量限制、随机丢弃等手段，强迫模型把请求尽量分散开。普通用户看不到这一层，却能间接体验到：如果训练时负载不均衡严重，模型会出现一种“某些领域特别聪明，某些领域明显偏科”的观感。换个角度说，评测集里如果不覆盖多个子领域，很容易被模型在某个偏科方向上的惊艳表现误导。

MoE 还有一个工程特点：专家在分布式环境间传递中间结果，通信量远大于普通稠密模型。跨机带宽一旦不够，延迟会被通信拖住，模型再“聪明”也快不起来。这也是为什么很多团队跑大 MoE 时，宁可用 NVLink 或高速 RDMA 网络，也不愿意让专家在普通以太网上散开。

2.3 长上下文能力不会只靠“塞更多 token”长出来

讨论架构跃迁时，很多人会漏掉上下文窗口，但我觉得这反而是影响生产力最直接的维度。

参数变大，模型能容纳更多复杂知识，但如果上下文窗口很短，生产场景照样转不起来——你丢一份几十页合同进去就爆了，模型再“聪明”也没用。长上下文能力需要在很多层面做配套：

• 用稀疏注意力或注意力压缩，降低长文本计算量；
• 用更好的位置编码方案，让模型理解超过训练长度的相对位置；
• 在推理侧做 KV Cache 量化、Prefix Caching 等优化，让服务端不被长请求拖垮。

这些能力很少出现在跑分海报上，却决定你是不是真的能把模型放进“读完整个项目仓库再给建议”“通篇审阅一份厚合同再审阅细节条款”这些真实任务里。从 Hy3 到 Hy4 Preview 的生产力跃迁，我认为很大一部分不是“更会答题”，而是“更能把上下文装下去，并且真的会用起来”。

3. 真正值得尝鲜的生产力场景：我比较看好的三个方向

3.1 多轮长对话与复杂文档：终于不再频繁“失忆”

我以前在项目里用小参数模型做会议纪要，最痛的问题是总结到一半丢信息。让它分析一份 50 页材料，经常只抓到开头结尾，中间细节全丢掉。参数规模增大之后，最直观的变化是长期依赖能力：它能更稳地记住前文出现过的实体、约束条件、数字，并把它们应用到后文判断中。

这里还得强调一个区别：“上下文能装下”不等于“会自动找答案”。哪怕技术上支持 128K 上下文，模型如果不会在 128K 里定位关键信息，给它 256K 也白搭。770B 带来的更可能是注意力模式更细致，能从密集信息中捞到真正需要的内容。如果你的工作流里有长文档问答、跨章节总结、多轮需求澄清，换到 Hy4 Preview 后，第一个建议测试的方向就是这个。不用一上来就挑战高难度推理，先把自己最痛的长文本材料丢进去，看看模型能不能找出你人为埋下的几个细节。

3.2 Agent 里的工具调用与路径规划：不再“一错到底”

这两年只要聊 AI 应用，几乎绕不开 Agent。Agent 的本质是让模型当一个调度中心，决定先调用哪个工具、观察结果再走下一步。这对模型要求特别高，因为中间一旦误判，后面所有步骤都可能跟着跑偏。

更大的模型在 Agent 场景里通常有几个优势：

• 指令遵循更稳：能在 system prompt 里同时遵守格式、顺序、安全规则，而不是只记得最后一句；
• 工具选择更准：能分辨“搜天气”和“定闹钟”这类边界模糊的语义；
• 错误恢复更好：工具返回异常时，能把错误信息当作普通文本重新规划，而不是直接崩溃或原地循环。

如果你以前用 295B 级别的模型调 Agent 时，总觉得“能力有，但不够听话”，那 770B 级别的新版本值得用同一套 Prompt 重新跑一轮。我的经验是先别比复杂任务，先比“当工具返回 500 错误时，模型能不能正确识别并改用备选工具”。这个 case 最能看出版本间的架构级进步。

3.3 结构化输出与数据清洗：最容易被低估的提效点

很多团队最容易忽略的场景其实是结构化输出。比如把一堆非结构化合同文本，抽取出“付款条件、违约金比例、甲方乙方名称”并输出 JSON。

这类任务不算高深，但对格式遵从和细粒度实体识别要求很高。小模型常犯的毛病是：输出路径对了，可 JSON 字段值漏几个，或者甲方名称和乙方名称搞混。参数量提升后，这种细粒度消歧能力通常会有明显进步。

如果你们公司有大量“脏数据清洗、半结构化文本转 JSON、客服工单分类”需求，换大模型可能是成本收益最直接的一项。它不像 Agent 那么炫，但很多后台流程就是靠这条抽取链路撑着，准确率提升一个点，节省的人力可能远超想象。而且结构化输出天然适合做自动化评测：只要写一个 JSON schema 校验器，就能量化模型升级前后的字段完整率、格式合法率和取值准确率。

4. 从 Hy3 切到 Hy4 Preview，最容易被低估的迁移成本

4.1 输出分布漂移：同一个 Prompt，未必给你同一个答案

这是我从旧模型切到新模型后非常确定的一个感受：同样的 Prompt，在 Hy3 上输出很稳定，到 Hy4 Preview 上可能会换语气、换分段方式、甚至修改输出字段的边界。不是新模型变差，而是版本更新会带来自然的模型漂移。

模型内部参数更新，概率分布整体变了。原来精心设计的 few-shot 样例，也许在旧模型上很有效，新模型反而不需要；原来它一定会严格执行的一句话规则，新模型可能因为理解更深入，产生了自己的“灵活解读”。

所以迁移的第一件事，不是把 model 字段从 hy3 改成 hy4，而是把你线上的 Prompt、few-shot 样例、后处理解析逻辑全部当成“待回归测试的代码”。任何跳过回归直接切流量的行为，都等于在赌模型分布没有变。生产环境可不能这么赌。

4.2 评测集要贴近真实场景，不要只拿脑筋急转弯试

很多人换模型时喜欢问“鸡兔同笼”“树上 10 只鸟”这类题目。它们能反映一部分推理能力，但和你的业务大概率无关。如果线上业务是售后工单分析，评测集里至少要有售后客服的高频说法、真实长句、错别字和脏数据。

我习惯把评测集做成一个 JSONL 文件，每条记录包含输入、预期行为、检查规则。检查规则不一定是“参考答案完全一致”，可以是“JSON 可解析且 fields 包含某些 key”“不能出现某个违规短语”这种机器可判定的条件。最后写一个简单脚本，批量调用新旧两个模型，输出对照表。

这里有几个硬经验：

• 评测样例最好不少于 50 条，覆盖正常输入、边界输入、异常输入；
• 每条不能只看内容对不对，还要监控响应时间、token 消耗、失败率；
• 先用规则化检查做第一轮过滤，再针对差异大的结果做人工抽检。

指标上我越来越不喜欢只依赖单一的人工打分，因为人的主观波动太大。规则判定能确保客观，人工复核能补足语义判断，两个结合才更靠谱。

4.3 灰度切换与双跑：比任何广告宣传都有用

更稳的迁移方案，不是“从旧模型全量切到新模型”，而是先拿 5%~10% 的流量导到新模型，跑一段时间，再对比新旧结果。

我通常这样设计灰度：

• Shadow Mode：旧模型正常响应用户，新模型在后台同步跑一遍请求，不返回给用户，只落日志，用来评估差异和延迟；
• 5% 灰度：把少量真实流量切到新版本，观察用户反馈、错误率、超时；
• 按场景放开：如果只是某些场景收益明显，就只对这些场景放开，其他场景继续走旧模型。

还可以把同一个请求同时发给新旧两个模型，统计结果不一致率。不一致率过高时，要谨慎排查是不是新版输出格式改变了，或者某些请求进入了你不熟悉的“新能力区”。

4.4 成本和延迟：参数翻倍，账单不一定等比例翻倍

如果走 API，服务方把基础设施细节都隐藏了，你可能只看到 token 单价。但如果做私有化部署，新成本模型里最要命的是 GPU 数量和网络带宽，而不是模型能力本身。

MoE 的精妙之处在于：总参数量大，激活参数量却可能远小于总参数量。所以和 295B 稠密模型比，770B MoE 模型每次请求的实际计算量未必线性增长。但权重读取和跨机通信仍是大头，尤其多并发上来时，显存带宽会迅速成为瓶颈。

不能仅凭“770B > 295B”就判断一定贵很多。服务方用什么量化、什么并行策略、什么调度算法，都会影响最终成本。建议直接拿同一批请求分别打两个版本，统计 p50/p95 延迟、成功率和 token 消耗，再结合真实单价算单次调用成本。不看这些实测，只按参数估预算，很容易被实际账单打脸。

我的习惯是拿 100 条同样请求，在低峰期跑三遍，取平均。除了看延迟，还要对比输出 token 数。因为不同模型对同一任务写的 token 数量可能差很多，直接影响成本和下游解析负担。

5. 我实测中遇到的几个值得注意的变量

5.1 长文档摘要：输出长度和稳定性是第一道坎

我常用的长文本测试，是把一份约三十页的上市公司年报丢进模型，要求给出摘要并列出关键财务指标。实测下来，模型越大，输出结构往往越稳定，但偶尔还是会遇到输出截断或字段缺失。

原因不一定是模型笨，可能是单次请求的 max_tokens 上限限制了输出空间，也可能是文档里有复杂的表格和扫描件格式。处理长文档时，我现在比较稳的套路是：

• 先把文档按章节切块，每块单独做初步信息提取；
• 再做一次全局汇总，让模型基于各块的摘要而不是原始全文做最终输出；
• 关键数字，要求模型在回答里给出原文页码或位置，方便人工考证。

关键数字错误率确实下降了，但只要涉及多页表格交叉引用，我仍然发现会偶尔出错。落地时一定要加一道规则校验，比如“模型输出的净利润数字必须能在原文某个字符串片段中找到，否则标记为高风险并转人工”，不要盲信大模型。

5.2 Prompt 风格：System Prompt 太长时会“选择性失忆”

很多 Agent 框架喜欢把企业知识库、问答风格、敏感词规则全部塞进 System Prompt，一写就是几千字。大模型确实能处理很长的 System Prompt，但如果你发现它在长 System 后开始忽略最前面的指令，不要惊讶，这是注意力分配的物理限制。

我实测后感觉比较有效的几个做法：

• 把最关键、最希望模型严格遵守的规则放在 System 最前面和最后，不要埋在中间；
• 每条规则尽量写成“必须/禁止”的强指令，少用“可以/建议”这种弱语气；
• 需要强约束的规则尽量压缩到 10 条以内，其余规则通过用户输入或工具调用上下文给出，避免所有规则都堆在 System 里。

更有意思的是，参数更大的模型有时对长 System 未必更友好，它可能更容易推出自己的一套执行逻辑，把 Prompt 里没写明白的边界自己脑补完。所以切换到新版本后，System Prompt 一定要回归测试，不要沿用旧版一劳永逸。

5.3 Preview 版本最容易翻车的三个细节

Preview 在我理解里意味着“能力已经很好，但还不是最终定版”。具体使用时要特别留意三件事：

• 服务端配置可能调整，偶尔会出现限流或 5xx。我不会把 Preview 模型直接放到不可降级的核心生产链路上，即使放，也会加“失败自动切回旧版”的兜底；
• 温度参数对输出影响可能比旧版本更敏感。结构化抽取任务里，如果 temperature 还用 0.7，可能同一输入得到完全不同的 JSON 字段值；建议结构化输出把温度调到 0.1 甚至 0；
• 同一提示词在新版可能触发不同的 prefill 策略，导致长 prompt 的响应延迟比预期高。最好在业务允许的延迟阈值上加一道监控和告警，而不是等用户先发现。

这些都是从 Preview 版本里比较容易踩到的坑，但反过来也说明 Preview 的价值在于提前暴露问题，适合你为正式版本做准备。

6. 到底要不要切到 Hy4 Preview？我的判断流程

6.1 先做小成本验证，别急着做架构决定

我的建议是：拿业务里最核心的 30~50 条真实数据，写一个简单评测脚本，分别请求旧版和新版，获得三个输出：旧版结果、新版结果、规则判定结果。人工只复核差异较大的几条，判断新版本是否真的带来提升，还是只是换了一种表达。

如果新版关键指标明显落后，那就继续留在旧版，等正式版再说。如果新版明显好，也不用全量切，按场景拆开灰度放流。Preview 模型存在的意义是让你提前体验和反馈，不是让你拿全量生产环境当试验田。

6.2 判断“切”还是“不切”的场景表

我根据自己的项目经验整理了一个评估矩阵，不一定适用于所有人，但能帮你对号入座：

这个表格侧重说明一点：不是所有业务都需要 770B。很多任务用一个小模型加更合理的 RAG 链路，效果可能比一味追大更皮实。技术人容易被参数数字吸引，但“生产力落地”从来不是看参数墙上的数字，而是看它能不能在你真实业务流里稳定产生净收益。

6.3 我的最终建议

从大模型迭代节奏看，参数规模从 295B 到 770B，会是许多产品能力的分水岭。但“分水岭”要被你真正用上，前提是评测、灰度、回退、成本计量这些工程环节已经搭好。我见过太多团队把模型版本升级当成一次简单 config 改动，结果上线当天 Prompt 全飘、输出格式崩得措手不及。

与其问“Hy4 Preview 能不能超过 Hy3”，不如问：“我的评测集能不能反映真实业务？灰度方案能不能随时切回旧版？数据链路有没有为更长上下文做好准备？” 这几个问题想清楚了，你自然知道自己该不该切，什么时候切。

我现在比较固定的做法是：每个大版本发布后，先用最高频的 30 个业务请求做一轮离线评估，把差异报告发给业务方看，再决定要不要进入灰度。版本升级不是“越新越跑”，而是“用数据跑赢犹豫”。希望下次你在群里看到类似参数跃迁的消息时，能先想起这些容易被忽略的落地细节，少踩一点我踩过的坑。