企业官网建设流程全解析

上周我把同一个Agent任务分别发给Hy3和Hy4 Preview：一份包含改签规则的公告，要求模型判断多个日期边界并填一张退改费申请表。Hy3在条件分支里绕了两轮，把周六的值日判断错了；Hy4 Preview第一次就先把规则拆成“普通时段、节假日、临近起飞”三类，最后还自己复查了一遍有没有漏掉日期边界。任务不大，但这个结果让我对“腾讯混元从295B到770B”这个变化，从抽象数字变成了具体冲击。

这轮升级让我最在意的不是参数又涨了多少，而是“架构跃迁”这个词第一次真正落到了生产力层面。770B不是295B的简单放大版，它改变了模型在复杂任务里的行为方式。这篇文章我想从一个做大模型应用的工程师视角出发，聊聊我对Hy3与Hy4 Preview的观察、770B推理落地时绕不开的工程问题，以及从295B迁移到770B时我自己会怎么操作。不会给你复读官方参数，只会讲那些我在跑测试和做降级预案时真正用到的东西。

1. 重新审视参数增长：295B到770B，规模究竟改变了什么

1.1 先分清总参数与激活参数，否则会被数字绕进去

很多人看到770B第一反应是“这个模型这么大，推理一定很慢”。这个判断放在Dense模型上基本成立，但放在现在的架构演进里就不一定了。

Dense模型的意思是：每次推理，无论输入什么token，所有权重都要参与计算。所以参数量和计算量强绑定，模型越大，单次前向越贵。这也是为什么传统Dense模型很难无限制往上堆参数——堆到一定规模后，推理成本会直接把产品拖死。

MoE（Mixture of Experts，混合专家）改变了这个逻辑。它把模型拆成一个路由器和一堆专家网络，每个token进来之后，路由器只选择最相关的少数几个专家参与计算。这里就出现了两个关键数字：总参数和激活参数。总参数决定模型“记住了多少东西”，激活参数决定“算一个token实际要花多少代价”。

770B这种量级，几乎不可能是纯Dense模型走到底，更合理的推演是把大量参数放进不同的专家里，每次token只激活其中一小部分。也就是说，295B到770B，增加的绝大部分是“知识容量和记忆容量”，而不是“每一步计算的固定开销”。从这个角度看，总参数涨了约1.6倍，实际单token推理成本可能并没有同比例上涨。

我在自己的压测里也感受到了这一点。同一条复杂逻辑链任务，Hy4 Preview的输出质量和稳定性明显高于Hy3，但从提交请求到收到最终完整回复的端到端耗时，并没有出现成倍恶化。这背后就是稀疏化设计在起作用。

1.2 从Dense到MoE：为什么规模越大越要“分散办公”

用一个生活化的类比来理解MoE：过去一个全才员工处理所有类型的问题，能力上限受限于这个人的知识储备。现在改成一家咨询公司，前台根据问题类型，把需求转给对应的行业专家小组。总员工数增长了，但每一个具体问题，只需要少数专家参与。

这带来的好处有两个。第一，模型的知识面可以铺得非常宽——295B可能已经覆盖了大量领域，但770B可以把更多长尾知识、专业术语和低频模式装进去。第二，单次调用的计算成本被限制住了——如果不限制参与计算的专家数量，770B根本没法做实时推理。

但MoE也不是银弹。专家数量的增加会带来路由均衡问题。如果所有token都挤向少数几个专家，那些专家会过载，其他专家又闲置，模型整体效果反而不如一个规模更小的Dense模型。所以架构跃迁的重点不只是“把参数堆到770B”，还包括怎么让专家分工足够合理，怎么让路由策略足够聪明。

从公开信息和实际表现来看，Hy4 Preview在复杂推理、长上下文指令跟随方面的稳定性提升，很像是在MoE的路由策略、专家粒度和注意力机制上做了整体重构，而不是简单地把Hy3的每一层都加宽。这种“架构级”的变化，才会让模型在同样的问题上表现出不同层次的思考路径。

1.3 架构跃迁对使用者的三个隐藏影响

作为API使用者，我们看不到内部权重，但能感受到三个直接影响：

第一个是能力曲线的突变点变了。过去需要写很长的思维链提示词才能让模型完成的推理任务，现在用很短的指令就能触发。我测过一个多条件判断任务，用Hy3时需要我在Prompt里明确写出“请先列出所有分支条件，再逐项判断”，Hy4 Preview不需要这些“拐杖”也能自己完成拆解。

第二个是输出分布发生了漂移。不要以为模型变强了，原来调好的Prompt就还能继续用。同一个Prompt在两个模型下的输出风格、冗余度、格式遵守度都可能不同。这是迁移时最容易踩的坑。

第三个是上下文窗口和KV Cache压力同时变大。能力更强的模型往往被用于更长、更复杂的任务，而长输入会占用大量显存。用户实际感知到的“延迟变高”，很多时候不是模型参数变大，而是请求长度变长后KV Cache膨胀导致的。

2. 770B能落地推理，靠的是绕开三堵墙而不是硬堆算力

2.1 显存墙：光权重就装不下的数学题

先算一笔账。一个770B参数的模型，如果用FP16精度存储，仅权重就需要约1.5TB显存。用INT8量化可以降到约770GB，用INT4量化大约是385GB。

这是什么概念？一张A100 80GB的显卡，连INT4量化后的权重都装不下，需要多卡并行。而实际推理时还有额外的KV Cache、激活值、临时计算缓冲，都会占用显存。如果输入长度很长，KV Cache可能再吃掉几百GB。所以770B能对外提供服务，背后一定是一套多机多卡集群，并且大概率做了量化或精度混合。

对API用户来说，不需要自己操心部署细节，但需要理解一个现象：为什么并发一高，延迟就飙升？因为显存里不只有权重，还有每一路请求的KV Cache。并发数上去后，显存被占满，服务端只能排队或做批处理，单请求的延迟自然恶化。

2.2 带宽墙：激活参数才是推理速度的命门

我们再看第二个约束：显存带宽。

大模型生成token的过程是逐字生成的。每生成一个token，都需要把激活参数对应的权重从显存读取到计算单元。如果激活参数很大，即使算力再强，数据搬运也会卡住瓶颈。

我一般用一个非常粗糙的估算公式来感受量级：

单卡理论吞吐上限 ≈ 显存带宽 ÷（激活参数 × 权重字节数）

假设一个模型的激活参数是50B，FP16权重（每参数2字节），每个token就需要读取约100GB数据。单张H100的显存带宽约3.35TB/s，理论极限也就每秒33个token左右。要是激活参数达到200B，这个数字会降到个位数。实际运行时还要算上通信开销、调度损耗，能跑到理论值的一半就算不错了。

这也是为什么看模型时不能只看总参数。总参数决定显存容量需求，激活参数决定token生成速度。如果一个770B模型把激活参数控制得和之前295B模型相当甚至更低，那它在推理速度上不一定吃亏，反而因为知识容量变大而表现更好。

2.3 API使用方真正该盯住的三个指标

我不建议普通开发者在自己的服务器上折腾770B推理，这不现实也没必要。大多数场景用官方API就好。但调用API时，不要只盯着“响应快不快”这种模糊感受，要盯三个可量化指标：

• TTFT（Time To First Token）：从提交请求到返回第一个token的时间，主要受输入长度的prefill计算影响。长文档分析类任务尤其要关注。
• TPOT（Time Per Output Token）：生成每个token的平均耗时，直接决定用户等待完整回复的体感。这个指标更接近上面说的带宽瓶颈。
• RPM/TPM限流：每分钟请求数和每分钟token数。模型升级后，如果业务方还按旧模型的调用量预估，很可能在流量高峰直接打到限流阈值。

我之前做一个文档解析工具时就踩过这个坑。旧模型单次请求平均输出300个token左右，切到新模型后，因为模型会先输出一段“思考小结”再给结果，平均输出token涨到了450，再加系统提示词的输入token也在增加，整体TPM消耗量涨了约50%，限流和账单同时报警。

3. 生产力质变不靠感觉：Hy4 Preview强在哪些可验证的场景

3.1 长链路任务里的“自主拆解”能力

我做应用测试时，很少看模型能不能答对百科知识题，更关注它面对一个需要多步推理、多条件判断的现实任务时，能不能自己把路径拆出来。

举例来说，让模型处理“从一份几十页的PDF里，找出所有不符合报销政策的发票，并说明每一条违反了哪个条款”这种任务。Hy3的表现是：能找出明显的违规项，但对于需要结合不同章节条款做交叉判断的情况，容易漏掉。Hy4 Preview则更倾向于先把政策规则结构化，再逐条对照发票记录，并且能在回答里给出“违反第几章第几条”的溯源链路。

这种差异背后的逻辑是：更大的总参数量让模型对“规则类知识”的存储和调用更精准，稀疏化的专家结构又让不同领域的知识之间减少相互干扰。结果就是模型在长链路任务中更少出现“中途忘记规则”的问题。

3.2 多步任务成功率：0.95和0.98不是差3%，是差出一整个量级

做Agent类应用的同学一定对单步成功率特别敏感。因为Agent的最终成功率不是单步成功率，而是每一步成功率的乘积。

假设一个任务需要拆成6步：

• 如果每一步成功率是0.95，最终成功率是0.95的6次方，约73.5%。
• 如果每一步成功率是0.98，最终成功率是0.98的6次方，约88.6%。
• 如果任务拆成10步，0.95的10次方只剩约59.9%，0.98的10次方还有约81.7%。

看起来单步只提升了3个百分点，多步任务的整体可靠性却从“勉强能用”变成了“可以上生产”。这是我对“生产力落地”最直观的理解：不是模型单次回答更漂亮了，而是整个业务系统的崩溃率显著下降。

我在测试Hy4 Preview时，刻意构造了一个需要连续调用三次工具、中间还要根据上一次结果修正参数的任务。Hy3在第二次工具调用后常常出现“忘记上下文约束”的问题，Hy4 Preview则明显更稳，能正确地把第一次结果的字段传给第三次调用。这种稳定性，在小样本测试里可能只差一两个case，放到每天跑几十万次的线上，就是巨大的可靠性差异。

3.3 搭建自己的“回归场景集”，而不是靠几个人肉测

大模型升级最怕的是“感觉变好了，但某些冷门场景悄悄变差了”。所以我在准备从Hy3切到Hy4 Preview时，第一件事不是改代码，而是搭一套轻量回归集。

回归集不需要很大，但覆盖面要足够。我自己常用的结构是这样：

这套用例不追求全，追求“能代表线上真实流量”。上线前把Hy3和Hy4 Preview都跑一遍，逐条对比输出。判断标准不是“哪个更像人话”，而是“哪个更符合业务约束”。防止被少数惊艳案例带偏，忽略了那些稳定输出的老场景。

4. 从Hy3切到Hy4 Preview，我给团队的迁移清单

4.1 先做冒烟，别急着重写Prompt

很多团队拿到新模型的第一反应是“这模型更强了，我要不要换个更复杂的Prompt来榨干它的能力”。我的建议是：**先别动Prompt，用原来的配置直接跑一遍。**只有这样才能看清模型升级带来的真实差异，而不是把自己调整Prompt的影响也混进去。

冒烟阶段我会跑三类任务：

1. 知识问答类：确认基本的事实输出能力没有退化。
2. 结构化输出类：让模型输出JSON或按固定模板填表，检查格式稳定性。
3. 长文本处理类：给一段长文档做摘要或抽取，观察TTFT和输出完整性。

如果这三类都过了，再进行Prompt层面的优化。如果出了问题，也能明确知道是模型能力变化导致，而不是自己的新Prompt写得不对。

4.2 用影子模式做对比，不要直接全量切换

我在迁移时特别推荐“影子模式”。做法很简单：线上流量正常走Hy3，同时把同样的请求复制一份发给Hy4 Preview，但新模型的结果只落库、不返回给用户。这样积累一段时间后，就能拿到同一条请求在两个模型下的真实对比数据。

影子模式最值钱的地方在于它用的是线上真实流量，而不是测试集。业务场景千奇百怪，你自己构造的用例总有覆盖不到的地方。跑个半天一天的影子流量，很多意外情况就自然暴露出来了。比如某个特定类型的用户输入，旧模型会拒绝回答，新模型却给了一大段生成内容——这种差异在黄金集里根本发现不了。

对比时我建议记录三个字段：模型返回是否成功、是否符合预期结构、延迟和token消耗差异。不用一条条人肉看，除非你想做一些抽样式的人工质量评估。

4.3 Prompt、超参和Token消耗要重新校准

具体操作上，这几点值得留意：

• max_tokens：新模型在复杂任务里可能输出更长内容。如果原来的max_tokens设置偏小，会出现“结果被截断但finish_reason为length”的情况。线上如果解析JSON，截断会导致大面积报错。建议先在测试环境把同一批任务跑一遍，看输出token分布是否明显右移，再决定要不要上调上限。
• temperature：不要因为模型变强就把temperature调高。做工具调用、数据抽取这类确定性任务，我会保持在0.2以下。高温度带来随机性，对生产力场景基本是副作用。
• 系统提示词：原来的“你必须严格按照JSON格式输出”“不要输出任何多余内容”这类强约束，在新模型上可以适当放宽。能力更强的模型对指令的理解更准确，过于强硬的措辞反而可能让它变得畏手畏脚。

成本方面也要重新算。API的单价是一个维度，但更关键的是单次请求的实际token消耗。新模型如果输出更长的推理过程或结构化中间结果，即使单价没涨，单次成本也可能上升明显。放大规模前，先拿线上平均输入输出长度套一下新模型的实际消耗，再决定是否值得切换。

4.4 按场景分流，而不是一刀切全量迁移

不是所有业务都需要立刻切到Hy4 Preview。我会按场景做分流：

• 复杂Agent、长文档分析、多步规则判断——优先切新模型，收益最明显。
• 高频短问答、简单分类、路由——继续用Hy3或更小的模型，成本可控且延迟更低。

这种“大模型处理难题，小模型处理简单任务”的混合架构，在成本上比无脑全量切换划算得多。可以让流量先按5%到10%的比例切到Hy4 Preview，观测几天错误率和延迟，再逐步提高。切换过程中要保留一键回滚到Hy3的能力，配置中心里把模型名和Prompt版本绑定，出问题时秒级切回。

4.5 回滚预案不是“把模型名改回去”这么简单

最后提醒一个容易忽略的细节：如果是在线链路依赖了模型输出格式，回滚时不只是把model字段改回Hy3。你需要同时确认几个东西：

1. Prompt版本：是不是也回滚到了与Hy3匹配的版本。
2. 输出解析逻辑：如果线上解析器已经为Hy4 Preview的返回格式做了适配，切回Hy3后解析器可能不兼容。
3. 缓存策略：如果按问题做了结果缓存，切回Hy3后要防止命中旧模型生成的内容，否则灰度就失去了意义。
4. 监控指标：回滚后要盯错误率和平均延迟至少半小时，确认不是雪崩式回滚。

我的习惯是：把“模型版本+Prompt版本+解析器版本”当成一个整体来发布，而不是单独改模型名。上线前准备好完整的回滚包，这样不管是模型问题还是Prompt问题，都可以一键恢复到上一个稳定组合。

腾讯混元从Hy3到Hy4 Preview这条路，我认为真正值得关注的不是770B这个数字本身，而是大模型正在从“科研竞赛”走进“工程基础设施”。模型参数越来越大、能力越来越强，但落地时的稳定性和可控性才是决定生产力能不能兑现的关键。个人体会最深的一点是：别把一次模型升级当作“换个更聪明的脑袋”，要把它当作一次完整的技术架构变更来对待。谁先把评估、影子模式、灰度回滚这套流程跑熟，谁就能在下一轮大模型迭代时更从容。