企业官网建设流程全解析

Hy4 Preview 放出来那天，我所在的几个技术群里讨论最热烈的不是各种榜单分数，而是那个刺眼的数字：770B。把它和上一代 Hy3 的 295B 放在一起，这已经不是普通意义上的模型迭代，更像是一次架构级别的重新定义。很多人第一反应是“无非多堆卡、多堆人”，但真上手就会发现，从 295B 到 770B 这一跳，训练侧怎么做并行、推理侧怎么塞进显存、业务侧怎么把模型能力转化成真实生产力，每一个环节都要重新想一遍。

这篇文章不打算聊一堆评测分数，只聊架构和落地。我会先拆解 Hy3 到 Hy4 Preview 的架构跃迁思路，再给出一套从显存测算、量化选型到 vLLM 部署的实操流程，最后把我在实际部署中踩过的坑全部列出来。如果你正在做模型选型、推理部署，或者负责 AI 基础设施运维，这篇内容值得从头看到尾；就算你暂时只是好奇“770B 的大模型到底怎么跑起来”，也能从里面找到答案。

1. 内容整体设计与思路拆解

1.1 Hy3 的 295B：MoE 把“总参数”做成了一种知识储备

Hy3 的 295B 总参数，用的核心架构还是大家熟悉的 Transformer decoder-only 外加 MoE。MoE 的中文叫“混合专家”，简单说就是把原来 Transformer 每一层里的 FFN（前馈网络）替换成一组“专家”，每个专家其实就是一个独立的前馈子网络。输入一个 token 时，并不会让这组专家全部计算一遍，而是由一个 Router 网络从所有专家里选 Top-k 个出来，只计算这 k 个专家。

这种设计带来的直接好处就是：总参数可以做到很大，但单次推理真正计算的参数量并不多。Hy3 的参数总量是 295B，但推理时的激活参数可能只有二三十 B 的级别。你可能会觉得奇怪——既然都做成 295B 了，为什么不让它每次把全部专家都算一遍？因为如果全部算，推理成本会直接翻几十倍，根本没有商业化落地的可能性。所以 MoE 本质上是在模型容量和单次推理成本之间做了一个关键取舍。

我一般用一个类比跟团队解释：一家公司请了 295 个领域顾问，但每次开会，人力部门只会根据会议主题喊来其中两三个对口顾问。顾问虽然都要发工资，但开会的时间成本却跟参会人数直接挂钩。模型总参数越大，公司知识储备越足；每次激活参数少，开会效率才不会被拖垮。这就是 MoE 大模型的产品逻辑：要的是知识总量，不是每次计算的总量。

1.2 Hy4 Preview 的 770B：多出来的不只是“更大”

Hy4 Preview 把总参数直接推到 770B，这个量级意味着什么？单纯看总参数，它是 Hy3 的 2.6 倍。如果再算上激活参数提升、上下文窗口扩大、路由机制改进这几个变量，新模型的能力画像其实已经不能用“更大一号”来形容了。

从我观察到的技术细节来看，Hy4 Preview 至少在几个层面做了明显调整：

• 专家规模扩大而且粒度更细。以前可能是若干个大专家平分领域，现在专家数量大幅增加，每个专家覆盖的知识面更窄、更垂直，这相当于从“全科顾问”变成了“专科门诊”。
• 引入共享专家机制。在细粒度专家之外，专门放几个始终被激活的“共享专家”，用来捕获高频通用知识，比如语法、常识推理、指令理解这些。这样能减少 Router 在不同领域知识之间来回切换带来的不稳定。
• 注意力模块做了升级。长上下文场景下，分组查询注意力（GQA）这类结构基本是标配，Hy4 Preview 在 KV Head 的配置和注意力计算上做了重新平衡，尽量让长文本推理时显存开销不要涨得太疯。
• 训练侧和推理侧都针对通信做了优化。770B 规模的模型一旦分布到几十甚至上百张卡上，数据通信不再是“辅助问题”，而是直接影响训练稳定性和推理吞吐的核心问题。

我甚至认为，Hy4 Preview 更大的意义不是“更大”，而是它把 MoE 从“实验室跑得动”推向了“生产环境用得起”。如果只是堆参数而没解决推理部署的可行性，那 770B 就只是一张 PPT 上的数字。

1.3 架构跃迁到底“跃”在哪：从常规升级到系统性重构

从 295B 到 770B，如果只是把每层专家从 8 个复制到 20 个，那工程上确实很容易，但效果大概率上不去。从公开技术演进和大型 MoE 模型的一般设计规律来看，这一代跃迁至少动了三样东西。

第一，专家粒度和路由策略。更大的 MoE 会把专家做得更“细分”，例如从 128 个专家扩展到 256 个甚至更多，避免少数几个“万能专家”扛下大部分负载。同时 Router 不再简单做概率采样，而是带负载均衡约束的 Top-k 选择，加上辅助损失来让各专家利用率更均匀。

第二，共享专家与任务专家的分工。通用知识放共享专家，领域知识放任务专家，两者分离之后，专家之间的知识重叠会明显减少。Hy4 Preview 能在代码、数学、Agent 工具调用这些场景上表现更稳，很大程度就是因为这套分工。

第三，长上下文场景下的注意力与 KV Cache 压缩策略。模型能“记住”多长的对话、能在多长的文档里保持一致性，不只看参数规模，还取决于注意力机制怎么处理远距离依赖。Hy4 Preview 把上下文窗口做大，同时压低 KV Cache 的显存占用，才能让长文档分析这类生产力场景真正落地。

从工程视角看，这次“跃迁”不是在原模型上修修补补，而是从训练数据、专家划分、并行策略到推理部署全部重新设计。这也是为什么 295B 到 770B 表面上只是“参数翻倍 + 零头”，实际工程量却是几何级上升。

2. 核心细节解析与实操要点

2.1 总参数、激活参数与显存：先算一笔账

每次把新模型交给部署团队，我做的第一件事永远不是直接拉镜像启动，而是先算显存账。特别是 MoE，很多人误以为“MoE 省显存”，这其实是个大坑。

先说权重。一个 770B 参数的模型，如果用 FP16/BF16 存储，每个参数占 2 字节，那么权重文件总量大概是 770 × 2 = 1540GB，约 1.5TB。这里必须说清楚：MoE 的稀疏激活节省的是计算，不是显存。虽然每次推理只算少数专家，但所有专家的权重都得常驻显存，因为下一轮请求可能用到任何一个专家。所以 770B 模型的权重显存需求，和同规模 Dense 模型是一样的。

接下来看 KV Cache。自回归推理需要把历史 token 的 Key 和 Value 缓存下来，计算公式大约是：

KV Cache 大小 ≈ 2 × 序列长度 × 层数 × KV Head 数 × Head 维度 × 单字节数

我举一个接近实际规模的例子：假设模型有 64 层，KV Head 数为 8，Head 维度是 128，承载 32768 个 token 的上下文，用 FP16 存储。代入公式：

2 × 32768 × 64 × 8 × 128 × 2 ≈ 85.9 亿字节，约 8GB

如果你只有一路并发，这个数还能接受；但如果同时有 16 路并发请求，KV Cache 就直接冲到 128GB 以上，比很多小模型整个权重文件还要大。所以说，大模型的显存压力经常不是来自权重，而是来自 KV Cache 和并发请求数量。

综合看，你要部署 770B 模型，理论上每卡 80GB 的显卡，单机 8 卡总显存 640GB，连权重都不够放；即使加上量化把权重压到 770GB 或 385GB，KV Cache 仍然是个大头。所以“大规模模型 = 多机 + 并行策略 + 量化”基本是标配，没有哪个单独手段能搞定。

2.2 从 295B 到 770B，并行策略怎么选

既然单卡甚至单机都放不下，就需要把模型“切”到多张卡上。业内常用的三种切法：张量并行（TP）、流水线并行（PP）、专家并行（EP）。现在我按 770B 模型的部署视角来拆解它们的取舍。

• 张量并行（TP）：把同一个网络层的权重切到多张卡上，相当于大家共同完成一个矩阵乘法。好处是单层计算可以并行加速，坏处是每层都需要多次 AllReduce 通信，通信频率极高。这种并行适合放在单机内，因为 NVLink 带宽足够高，跨机 TP 会把网络完全打爆。
• 流水线并行（PP）：按 Transformer 层数横向切开，卡 1 算完第 1 层把中间结果传给卡 2 算第 2 层，类似于工厂流水线。通信频率不高，适合跨机，但会带来“流水线气泡”，部分显卡在等待上游数据时处于空闲状态，集群规模越大气泡越明显。
• 专家并行（EP）：这是 MoE 场景的专属切法。把不同专家放到不同卡上，Router 把 token 路由到对应专家所在的卡，专家算完再传回来。这里的通信是 All-to-All，每个 token 都可能去别的卡走一趟，跨机时最容易成为瓶颈。

三种并行方式不是互斥的，实际部署通常混合使用。我做一个经验性的建议：TP 优先等于单机卡数，用满机内的 NVLink；跨机部分优先用 PP，减少高频通信；到了像 770B 这种超大 MoE 模型，再叠加 EP，而且 EP 的卡组最好放在同一机架或者同一交换机下，避免跨交换机的高延迟 All-to-All 把吞吐拖垮。很多人一上来就无脑开 EP=32 跨机，结果通信比计算还慢，那是没想清楚网络拓扑。

2.3 量化：把 770B 塞进有限显存的关键手段

如果权重 1.5TB 原封不动加载，即便用 32 卡 80GB 集群，每卡也要摊到近 48GB 权重，再叠加 KV Cache 和中间激活，80GB 显存很快就见底。所以量化几乎是必选项。

量化本质是降低每个参数的字节数。常见路线和对应权重体积如下：

实际部署时，我推荐先用 FP8 跑通全链路。原因是 FP8 在 H100/H800 这类卡有原生加速，算子支持也比较成熟，效果损失相对可控。INT4 虽然能把 770B 模型压到不到 400GB，对显存极度友好，但 MoE 模型中每个专家都有自己的动态范围，量化时如果只做全局 scale，很容易把某些专家压出偏差，进而导致路由错误、输出质量下降。如果你确实要上 INT4，务必用 AWQ 这类带校准的量化方法，并且在校准集里混入足够多的领域数据。

这里还有一个很多初做量化的人会忽略的点：Router 层和 Attention 层的量化精度要比 FFN 专家层更高。Router 一旦被量化出误差，选错专家的概率会明显增加，等于直接把模型智商拉低。所以对于 770B 这种超大 MoE，最好是混合精度：关键路由层保持 FP16/BF16，专家层做 FP8 或 INT4。

2.4 长上下文与 KV Cache 优化

Hy4 Preview 把上下文窗口继续拉大，意味着你可以在一个请求里塞进整份文档、整段代码仓库。但长上下文真正的执行难点不在“能不能接”，而在“接了之后显存够不够、速度会不会掉”。

• 优先给 max-model-len 设一个业务合理值。不要盲目拉满 64K 或 128K，如果业务最多只用到 8K，就设 8K，省下来的 KV Cache 空间可以换更多并发。
• 并发控制要看 KV Cache 天花板。哪怕权重被量化压缩得很小，KV Cache 一旦因为并发请求增多而暴增，照样会 OOM。建议用“权重显存 + 单请求 KV Cache × 最大并发”这个公式倒推 max-num-seqs。
• 打开 prefix caching 会救很多命。像多轮对话、Agent 场景，每次请求的前缀通常都是相同的系统提示词，开启 prefix caching 后这部分 KV Cache 可以被复用，实测能把长会话场景的显存压力降低 20% 到 40%。
• 业务侧可以配合做“摘要压缩”。如果上下文确实长到模型窗口扛不住，先在外部把文档切片并生成摘要，再喂给模型，效果往往比硬塞全文更稳定。

3. 实操过程与核心环节实现

3.1 部署前的环境准备与节点检查

在真正启动一个 770B 模型之前，环境检查这一步省不得。我通常按下面顺序来：

先看显卡和驱动：

nvidia-smi

这一步确认每台机器的显存型号、驱动版本、卡数。然后看机内拓扑：

nvidia-smi topo -m

重点看同一台机器内部是不是完整的 NVLink 全互联。如果卡与卡之间的连接走的是 PCIe，那 TP 并行会受影响，TP=8 的收益会比 NVLink 环境明显下降。

接下来做多机通信摸底。如果打算用多机部署，先跑一个 NCCL all_reduce 带宽测试。典型命令：

mpirun -np 8 -hostfile hosts ./build/all_reduce_perf -b 128M -e 8G -f 2

看输出里的 algbw，也就是算法带宽。单机内 NVLink 环境一般能看到几百 GB/s，跨机走 IB 通常在 20GB/s 到 100GB/s 之间。如果跨机带宽远低于预期，先查网卡速率、交换机端口、MTU 配置，不要等模型跑起来再去定位通信问题，那时候排查成本翻倍。

3.2 使用 vLLM 部署 Hy4 Preview

环境确认没问题后，我推荐用 vLLM 这类成熟推理框架来做第一版部署。假设我们有一批 32 卡 80GB 显存的节点，希望以 TP=8、PP=4、EP=8 的拓扑来组织，启动命令大致如下：

python -m vllm.entrypoints.openai.api_server \ --model /models/Hy4-Preview-A770B \ --tensor-parallel-size 8 \ --pipeline-parallel-size 4 \ --expert-parallel-size 8 \ --max-model-len 32768 \ --gpu-memory-utilization 0.92 \ --dtype bfloat16 \ --trust-remote-code

逐个解释关键参数：

• --tensor-parallel-size 8：张量并行度设成 8，正好对应一台 8 卡机器的 NVLink 全互联域，通信效率最高。
• --pipeline-parallel-size 4：按层切 4 段，对应 4 组设备，这样总设备数是 8×4=32。
• --expert-parallel-size 8：专家并行度设 8，具体取值要看模型本身的专家路由实现。如果该模型内嵌的 EP 组和 TP 组合适，vLLM 会自动调度；如果版本不一，需要查日志确认实际生效的并行组合。
• --max-model-len 32768：把最大上下文长度限制在 32K，避免推理时的 KV Cache 爆炸。
• --gpu-memory-utilization 0.92：允许框架用到单卡 92% 的显存，留一点余量给 CUDA context 和其他临时分配。
• --dtype bfloat16：以 BF16 加载权重。如果这一步就用 FP8 权重，需要额外加载量化后的模型文件。

启动之后，可以先用 curl 做一次最简单的接口测试：

curl -X POST http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "Hy4-Preview", "messages": [{"role": "user", "content": "用 Python 写一个快速排序"}], "max_tokens": 512, "temperature": 0.3 }'

接口返回的 JSON 结构和 OpenAI 服务一致，业务方接起来不需要改太多代码。如果响应正常，再逐步加压测试；千万不要第一步就跑并发压测，否则几个并发请求可能直接把显存吃满。

3.3 服务指标与性能摸底

部署起来只算完成了前半段，我的习惯是启动服务后立刻盯几个关键指标。vLLM 自身暴露了 Prometheus 格式的指标，访问/metrics就能拿到：

curl http://localhost:8000/metrics | grep vllm

我最关心三个指标：

• TTFT，也就是客户端发起请求到收到第一个 token 的时间。这个指标反应 prefill 阶段速度，长输入下尤其敏感。
• TPOT，也就是每个输出 token 的平均生成时间。这个指标决定“流式输出”的流畅度，TPOT 大于 100ms 时，用户会明显感觉到打字机输出的卡顿。
• 吞吐量，通常用每秒处理请求数或者每秒输出 token 数来衡量。并发越高，吞吐越高，但延迟也会上升，需要做权衡。

如果需要自己写压测脚本，Python 里用 openai 库做个简单循环就能做基础压测：

import openai client = openai.OpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY") def single_request(prompt: str) -> str: resp = client.chat.completions.create( model="Hy4-Preview", messages=[{"role": "user", "content": prompt}], max_tokens=128, temperature=0.3, ) return resp.choices[0].message.content for i in range(10): print(single_request("请介绍分布式系统的三种基本架构"))

这个脚本只是功能验证，真正做压测建议用 locust、wrk 或者专门的大模型评测工具。压测过程中要同时观察nvidia-smi里的显存和利用率，防止 OOM 或者 GPU 空转。

3.4 业务接入与 Prompt 适配

模型部署完成并测通之后，紧接着就是业务方接入。Hy4 Preview 的 API 层面向下兼容 OpenAI 格式，所以大部分原有对接代码可以继续用，但有几个地方必须重新调。

温度参数建议重新测。Hy3 时代一些业务固定的 temperature，换到 Hy4 Preview 后可能因为路由行为变化导致输出随机性不同。我通常的做法是拿 50 条业务典型 prompt，分别用 temperature=0.2、0.3、0.4 跑一遍对比效果，再定默认值。

JSON 输出和工具调用也得重新验证。大参数模型在指令跟随上通常会更强，但“更强”不代表“零失误”。如果你依赖response_format={"type": "json_object"}或者 tools 参数，务必把原来业务里的 few-shot 样例重新测试一遍，有些场景下样例数量可以显著减少，有些反而需要重新调整格式。

长文档处理这块，如果业务输入经常超过 8K token，建议提前设计截断或分块策略。你可以开 prefix caching，也可以把文档先抽摘要再传入。从我的经验看，对 10K 以上的文档直接完整输入并不总是最优解，外部摘要加工后输入，往往既省显存，效果还更稳。

4. 常见问题与排查技巧实录

4.1 OOM 问题：权重放得下，KV Cache 不够

我部署 770B 模型时遇到最多的就是 OOM，而且经常发生在服务稳定运行一段时间后突然出现。第一次遇到时大家都以为是权重加载的问题，结果nvidia-smi一看，权重并没有明显超出，反而是显存里堆了太多 KV Cache。

这种 OOM 的典型场景是：单请求输入特别长，或者并发请求数超过预期，把预留的 KV Cache 空间打满。解决思路是调整推理参数，而不是盲目加机器。

排查路径：

1. 先看nvidia-smi中显存占用，确认是显存真的满了还是没有显存碎片。
2. 看 vLLM 日志，它会提示是哪一步申请显存失败。
3. 看当前请求平均长度和并发数，判断是否超过 max-model-len 或 max-num-seqs 的限制。

处理方案通常是把--max-model-len下调到业务实际需要的长度，把--max-num-seqs也从默认值往下调，或者打开--enable-prefix-caching复用相同前缀。如果这些都无效，再来考虑增加节点或进一步量化。

4.2 多机通信成为瓶颈

有一次我们部署时，业务反馈生成速度不稳定，有时快有时很慢。我盯着nvidia-smi看，GPU 利用率在 30% 和 90% 之间反复横跳，典型的通信等待特征。再一查，问题出在 EP 跨机。当时把专家并行组放到了不同机架，token 在跨机 All-to-All 通信上消耗了大量时间，单条生成链路被网络延迟拖慢。

排查路径：

1. 重跑 NCCL all_reduce 测试，确认跨机带宽是否达标。
2. 用nvidia-smi topo -m和网络设备信息，确认通信链路是否跨交换机。
3. 查看训练或推理框架的通信时间统计，定位是 AllReduce（TP 引起）还是 All-to-All（EP 引起）。

解决思路是调整并行拓扑，把 EP 组的卡尽量安排在同一机架内，让通信路径最短；同时适当减少跨机 EP 规模，增加 PP 分层数。架构上的通信开销有时候光靠参数调不动，必须回到物理拓扑去解决。

4.3 长上下文后半段质量下降

Hy4 Preview 支持长上下文，但很多用户反馈在超大上下文的后半段，模型开始“丢失”前文信息。这跟 RoPE 位置编码的外推能力、KV Cache 精度都有关系。模型在训练时见过的最长长度是有限的，强行用超过训练长度的上下文，效果会断崖式下降。

排查路径：

1. 先验证是“显存不够被截断”还是“模型真读不进去”。看输入是否被框架自动截断。
2. 用小规模长文本做困惑度或专项测试，确认掉点位置。
3. 确认是否开启了 RoPE scaling 或 YaRN 等外推方法。

解决上，我建议如果业务确实需要 32K 以上长文本，不要只依赖模型窗口，外层做一个“检索 + 摘要”的预处理流程，先把关键信息提取出来，再让模型做理解与生成。这样既稳定又省算力。

4.4 问题排查速查表

最后再分享一个从 Hy3 切到 Hy4 Preview 时我自己的真实体会：不要因为模型变大了，就把所有业务流量一股脑全部切过去。先拿 20% 的流量跑一周，重点观察长会话稳定性、延迟和输出质量，确认没有明显问题后再全量切换。部署超大模型时，真正考验人的不是启动命令写不写得出来，而是出了问题之后能不能快速定位到是权重、显存、网络还是业务侧 Prompt 的问题。另外，做显存可行性验证时，我个人强烈建议先用 FP8 权重做一轮真实业务流量的容量测试，再决定要不要往 INT4 走；很多团队直接上 INT4 省了显存，结果路由质量掉点，排障排了两天才发现是量化精度问题，这个成本远比省下的那些显存高。