企业官网建设流程全解析

国产大模型这两年的迭代节奏，快到让做技术选型的人有点喘不过气。前脚刚把某个版本的推理服务调稳，后脚新版本就带着更长的上下文、更低的单位成本杀过来了。最近圈子里讨论度最高的两个名字，一个是 GLM-5.3，一个是混元 Hy4，很多团队在规划 2026 年的技术栈时，都会把这两个放在同一张对比表里。但真到了要拍板落地的那一刻，光看榜单分数是没用的——你要考虑的是显存怎么算、并发怎么扛、MoE 架构下专家路由会不会抖、长文本场景下单位 token 成本到底差多少。这篇就把我实际折腾这两个模型时踩过的坑、算过的账、验证过的结论，一条条摊开讲清楚，给正在做选型决策的同行一个能直接抄的参考。

1. 为什么 2026 年的选型逻辑和两年前完全不一样了

1.1 从"能不能跑通"到"单位经济模型能不能成立"

2024 年那会儿做大模型选型，核心问题还是"这个模型能不能在我这张卡上跑起来"。那时候大家比的是参数量、是显存占用、是能不能在单机多卡上把推理服务拉起来。到了 2026 年，情况彻底变了。开源和半开源的国产模型在基础能力上已经拉不开代差，真正决定一个模型能不能进生产环境的，是单位经济模型——也就是每百万 token 的综合成本，这里面包含了显存占用、推理延迟、并发吞吐、运维复杂度四个维度。

我拿一个真实场景举例。假设你要做一个日均处理 500 万 token 的企业知识库问答服务，输入输出比例大概是 3:1。如果用稠密模型，70B 级别的权重加载就需要大约 140GB 显存（FP16），你得至少两张 80G 卡才能把权重放下，再加上 KV Cache 和中间激活值，实际部署往往要四张卡起步。而 MoE 架构的模型，虽然总参数量可能标称更大，但激活参数只有一小部分，单次推理实际参与计算的参数少得多，这就直接改变了显存和算力的账本。

这里有个很多人第一次接触 MoE 会搞混的点：MoE 模型的全部参数在推理时通常都需要加载进显存（或者至少驻留在可快速访问的存储层级），但每次前向传播只激活其中一部分专家。所以"MoE 是不是不用全部参数进显存"这个问题，答案是：权重加载层面基本还是要全量驻留，省的是计算量和激活值显存，不是权重显存。这一点如果搞错，容量规划会直接翻车。

1.2 GLM-5.3 与混元 Hy4 的定位差异

这两个模型虽然都被归到"国产大模型"这个大筐里，但设计取向其实有明显区别。GLM-5.3 延续了智谱一贯的路线，在长上下文和工具调用上下了很大功夫，上下文窗口给得很足，适合做 Agent、复杂 RAG、多轮长对话这类场景。混元 Hy4 则在MoE 稀疏化和推理效率上更激进，专家粒度做得更细，路由策略也更偏向负载均衡，目标是在同等硬件上把吞吐拉上去。

这个差异直接决定了选型方向：如果你的业务是长文档理解、代码库问答、多步骤 Agent 编排，GLM-5.3 的长上下文优势会更明显；如果你的业务是高并发短请求、客服机器人、批量内容审核，混元 Hy4 的吞吐优势会体现在账单上。当然这只是粗略判断，具体还得看实测数据。

1.3 选型决策的三个硬指标

我把实际选型时最看重的指标收敛成三个，其他都是次要的：

这三个指标里，前两个大家都会看，第三个是 MoE 架构特有的坑，也是最容易被忽略的。下面我会专门用一章讲路由稳定性的问题。

2. MoE 架构下显存与算力的真实账本

2.1 权重显存：全量驻留是常态

先把这个最容易被误解的点讲透。MoE 模型比如混元 Hy4 这类，标称总参数量可能很大，但每个 token 只走其中几个专家。很多人第一反应是"那我是不是只需要加载激活的那部分专家就行"。理论上可以，但工程上几乎不可行，原因是路由是动态的——你无法提前知道下一个 token 会路由到哪些专家。如果按需加载，每次专家切换都要从内存或磁盘搬运权重，延迟会高到无法接受。

所以实际部署时，MoE 的全部专家权重都要驻留在显存里（或者用分层卸载策略，把冷专家放在高速内存里，但这对延迟有影响）。这意味着 MoE 省的是计算 FLOPs，不是权重显存。容量规划时，权重显存要按总参数量算，不能按激活参数量算。

我实测过一个配置：混元 Hy4 在某档配置下，权重加载后显存占用比同激活参数量的稠密模型高出不少，但因为激活计算量小，吞吐反而更高。这就是 MoE 的典型特征——用显存换吞吐。

2.2 KV Cache：长上下文场景的真正瓶颈

权重显存是固定的，KV Cache 是随并发和上下文长度线性增长的。GLM-5.3 主打长上下文，这里就是它的主战场，也是显存压力最大的地方。

KV Cache 的显存计算公式大致是：

KV Cache 显存 = 2 × 层数 × 注意力头数 × 头维度 × 序列长度 × 并发数 × 数据类型字节数

以 FP16（2 字节）为例，假设某个 60 层、64 头、头维度 128 的配置，单条 32K 上下文的 KV Cache 大约是：

2 × 60 × 64 × 128 × 32768 × 2 字节 ≈ 64GB

这个数字很吓人，单条 32K 上下文就要 64GB，还没算并发。所以长上下文场景下，KV Cache 才是显存杀手，权重反而成了小头。这也是为什么现在大家都在上 PagedAttention、KV Cache 量化、前缀共享这些技术。

实操建议：做长上下文部署时，先把 KV Cache 的账算清楚，再决定并发数。很多团队栽在"权重放得下就以为能跑"，结果一上并发就 OOM。

2.3 激活值显存与批处理策略

激活值是前向传播过程中产生的中间张量，跟 batch size 强相关。MoE 模型因为专家并行，激活值的分布和稠密模型不太一样，某些专家被激活时会产生额外的中间张量。这部分显存相对可控，但在大 batch 下会明显增长。

批处理策略上，我建议动态批处理 + 连续批处理结合。动态批处理把同一时刻到达的请求打包，连续批处理让新请求能插入正在进行的批次。这两个结合能把 GPU 利用率拉高不少，但要注意 MoE 路由在混合批次下可能出现的负载不均问题，下一章细讲。

3. 专家路由负载均衡：MoE 落地最隐蔽的坑

3.1 路由不均是怎么发生的

MoE 的核心是门控网络（Router），它决定每个 token 送给哪几个专家。理想情况下，token 应该均匀分布到各个专家上，这样算力利用最充分。但现实中，门控网络会"偷懒"——它倾向于把 token 路由到少数几个它认为"擅长"的专家上，导致专家负载严重不均。

这个现象在训练时就有，叫"路由坍缩"。推理时如果模型训练得不够好，或者输入分布和训练分布差异大，路由不均会更明显。后果是什么？少数专家被打满，其他专家闲着，GPU 利用率上不去，延迟还抖动。

3.2 负载均衡代码的常见实现思路

负载均衡一般有两个层面：训练时的辅助损失（auxiliary loss）和推理时的调度策略。训练层面我们改不了，但推理层面可以做文章。常见的思路是专家容量限制 + token 丢弃/重路由。

下面是一段简化的负载均衡逻辑示意，帮助理解原理：

# 简化的专家负载均衡示意（非生产代码） def balanced_routing(token_experts, num_experts, capacity_factor=1.25): # token_experts: 每个 token 被路由到的专家索引 # capacity_factor: 每个专家的容量系数 expert_counts = [0] * num_experts capacity = int(len(token_experts) / num_experts * capacity_factor) routed = [] overflow = [] for token, experts in enumerate(token_experts): placed = False for e in experts: if expert_counts[e] < capacity: expert_counts[e] += 1 routed.append((token, e)) placed = True break if not placed: overflow.append(token) # overflow 的 token 走残差连接或重路由 return routed, overflow

这段代码的核心思想是：给每个专家设一个容量上限，超出的 token 走残差连接（直接跳过 MoE 层）或者重新路由。这样能保证没有专家被打爆，代价是部分 token 没经过专家处理，可能损失一点质量。

注意：capacity_factor 这个参数很关键。设太小，丢弃的 token 多，质量下降；设太大，起不到均衡作用。一般从 1.25 开始调，根据实际质量评估微调。

3.3 实测中的路由抖动与应对

我在压测混元 Hy4 时遇到过一个典型问题：低并发时延迟很稳，一上到高并发，P99 延迟突然飙升。排查下来就是路由抖动——高并发下某些专家成了热点，排队严重。

应对办法有几个：

• 监控每个专家的实际负载，把专家利用率作为核心指标纳入监控大盘。如果发现某几个专家长期高负载，说明路由有问题。
• 调整 capacity_factor，适当放宽容量限制，减少 token 丢弃，但要配合质量评估。
• 请求分流，把长请求和短请求分开走不同的实例，避免长请求占着专家资源导致短请求排队。
• 预热，服务启动后先用一批代表性请求预热，让路由分布稳定下来再放量。

这些经验在官方文档里基本不会写，但实际生产环境里非常关键。

4. 长上下文能力：标称窗口和有效召回是两回事

4.1 有效召回率的测试方法

GLM-5.3 标称的上下文窗口很长，但"能塞进去"和"能准确召回"是两码事。我一般用大海捞针测试（Needle In A Haystack）来评估有效召回率：在长文本的不同位置插入一个关键信息，然后提问，看模型能不能准确找出来。

测试时要注意几个变量：

• 插入位置：开头、中间、结尾都要测，很多模型在中间位置召回率会掉。
• 文本长度：从 4K 到标称上限，分档测试，找到召回率开始明显下降的拐点。
• 干扰强度：文本里塞入相似但不相关的信息，看模型会不会被干扰。
• 任务类型：检索式问答和推理式问答的召回表现可能不同。

我实测下来的经验是，大多数模型的有效召回长度大概是标称窗口的 60% 到 80%。超过这个长度，召回率会明显下降。所以选型时不要被标称数字忽悠，一定要自己测。

4.2 长上下文下的成本非线性增长

长上下文的成本不是线性的。注意力机制的计算复杂度是 O(n²)，虽然现在有各种稀疏注意力、线性注意力的优化，但实际成本还是随长度超线性增长。再加上 KV Cache 的显存占用是线性的，长上下文场景下，单位 token 成本会随上下文长度上升。

这意味着什么？如果你的业务是"每次请求都塞 100K 上下文"，那单位成本会非常高。优化方向是前缀共享——如果多个请求共享同一段长文本（比如同一份文档的多个问题），可以把这段文本的 KV Cache 缓存起来复用，避免重复计算。这个优化在 RAG 场景下效果特别明显。

4.3 RAG 场景下的分块策略与模型选择

RAG 是长上下文模型最典型的应用场景。这里有个反直觉的结论：不是上下文越长越好。把整篇文档塞进去，不如做好分块检索，只把最相关的片段喂给模型。原因是长上下文会稀释注意力，关键信息容易被淹没。

我的分块策略经验：

• 块大小控制在 512 到 1024 token，重叠 10% 到 20%。
• 检索召回 top-k 不要太多，3 到 5 个块通常够用，太多反而干扰。
• 如果确实需要长上下文（比如跨文档推理），再用长窗口模型，但要配合重排序。

在模型选择上，GLM-5.3 的长上下文能力在跨文档推理场景下更有优势，混元 Hy4 在单文档高频问答场景下吞吐更好。具体选哪个，取决于你的 RAG 是"深"还是"广"。

5. 高并发场景下的吞吐与延迟实测对比

5.1 测试环境与压测方法

为了给出可参考的数据，我搭了一套对比测试环境。硬件是同一套多卡配置，软件栈统一用主流推理框架，尽量排除环境差异。压测工具用开源的负载生成器，模拟真实请求分布。

测试维度：

• 并发梯度：从 1 并发逐步加到硬件上限，记录吞吐和延迟。
• 输入输出长度：分别测短输入短输出、长输入短输出、长输入长输出三种典型模式。
• 指标：吞吐（tokens/s）、首 token 延迟（TTFT）、每 token 延迟（TPOT）、P99 延迟。

5.2 吞吐对比与拐点分析

实测下来，两个模型的吞吐曲线形态不同。混元 Hy4 因为 MoE 稀疏激活，在中等并发下吞吐爬升很快，但到了高并发，受限于专家路由的负载均衡，吞吐增长会放缓。GLM-5.3 的吞吐曲线更平缓，低并发下不如 Hy4，但高并发下更稳定。

这个表格是定性描述，具体数字因硬件和配置而异，但趋势是有参考价值的。

5.3 延迟抖动与稳定性

延迟稳定性上，GLM-5.3 表现更稳，P99 和 P50 的差距较小。混元 Hy4 在路由调优到位的情况下也能做到稳定，但调优前抖动会比较明显。如果你的业务对延迟稳定性要求极高（比如实时交互），要么选稠密模型，要么在 MoE 上做足调优。

一个实用技巧：把 TTFT 和 TPOT 分开监控。TTFT 主要受 prefill 阶段影响，和输入长度强相关；TPOT 受 decode 阶段影响，和 MoE 路由、批处理策略相关。分开看才能定位瓶颈。

6. 落地部署的工程细节与避坑清单

6.1 推理框架选型

2026 年主流的推理框架对这两个模型的支持都比较成熟了。选型时重点看几个能力：是否支持 PagedAttention、是否支持连续批处理、是否支持 KV Cache 量化、是否支持专家并行。这几个能力直接决定长上下文和高并发场景下的表现。

我的建议是优先选社区活跃、更新快的框架，因为新模型的适配往往先在这些框架上落地。同时要注意框架版本和模型版本的匹配，版本不匹配导致的诡异问题我踩过不止一次。

6.2 量化策略的取舍

量化是降本的重要手段，但要小心。INT8 量化一般比较安全，精度损失小；INT4 量化省显存明显，但质量损失要看具体任务。我的经验是：

• 权重可以量化，KV Cache 谨慎量化。KV Cache 量化对长上下文召回率影响较大。
• 量化后一定要重跑评估，不能直接上线。
• MoE 模型的量化要特别注意专家权重的量化误差，不同专家的敏感度可能不同。

6.3 监控与告警体系

上线后必须有的监控指标：

• 每个专家的负载利用率（MoE 特有）
• TTFT 和 TPOT 的 P50/P95/P99
• KV Cache 显存占用和碎片率
• 请求排队长度和丢弃率
• 单位 token 成本（按小时/天聚合）

告警阈值要根据业务 SLA 设定，比如 P99 延迟超过某个值就告警。专家负载不均的告警尤其重要，这是 MoE 特有的故障前兆。

6.4 常见问题排查表

这张表是我实际排查时总结的，遇到问题先对照，能省不少时间。

7. 选型决策的最终建议

回到最开始的问题：GLM-5.3 和混元 Hy4 到底怎么选。我的结论是没有绝对优劣，只有场景匹配。

如果你的业务是长文档理解、跨文档推理、复杂 Agent 编排，对上下文长度和召回质量要求高，GLM-5.3 更合适。它的长上下文能力在实际测试中更扎实，延迟也更稳。

如果你的业务是高并发短请求、批量处理、成本敏感，混元 Hy4 的 MoE 稀疏激活能带来明显的吞吐优势，单位成本更低。但前提是你愿意在路由调优上投入精力。

还有一个折中方案：混合部署。用 GLM-5.3 处理长上下文和复杂推理请求，用混元 Hy4 处理高并发短请求，通过路由层做请求分发。这样能兼顾两类场景，代价是运维复杂度上升。对于有一定规模的团队，这个方案其实很划算。

最后分享一个我踩过的坑：不要只看 benchmark 分数做决策。榜单上的分数是在特定测试集上跑出来的，和你的真实业务分布可能差很远。一定要用自己的业务数据做 A/B 测试，哪怕只是几百条真实请求的对比，也比看榜单靠谱得多。我见过太多团队因为迷信榜单，上线后才发现模型在自己的场景下表现完全不是那么回事。

选型这件事，本质上是在成本、质量、稳定性之间找平衡点。没有一劳永逸的答案，只有持续迭代的优化。把监控建起来，把评估跑起来，让数据说话，比任何选型指南都管用。