Hy4 preview 开源部署：770B MoE 上线前要算哪些账

Hy4 preview 已经开放权重，开发者自然会想到“能不能自己部署”。但 770B 总参数、49B 激活参数的 MoE，不能只按激活参数估算机器。真正的容量账包括权重存储、量化、KV cache、专家路由、互联带宽和升级运维。

先说结论

开放权重带来控制力，但 770B MoE 仍需要完整的容量和高速互联规划。

要测试量化、并发、长上下文、冷启动和回滚，不能只测一个温热请求。

工具执行要隔离，默认限制出网；开放权重不会消除安全责任。

先用托管入口建立质量基线，再决定是否承担自部署的长期运维成本。

先区分三个数字

总参数决定权重规模，激活参数影响每个 token 的计算量，上下文长度决定 KV cache 可能增长到多大。49B 激活并不意味着只需要存 49B 参数；未被当前 token 激活的专家权重仍然需要可访问。1M 上下文也不意味着每个请求都应该发送 1M token。

部署前的五项检查

第一，确认官方仓库提供的权重格式、许可证和推理框架支持。第二，选择量化方案后，用固定任务检查质量损失，不要只看显存是否下降。第三，按照目标并发和上下文长度压测 KV cache，记录峰值内存和尾延迟。第四，验证专家路由和张量并行在目标互联上的通信开销。第五，为模型版本、配置和回滚保留不可变制品。

为什么 API 仍可能更划算

自部署适合有数据边界、稳定吞吐和基础设施团队的组织。对于早期评估或流量波动的产品，TokenHub、OpenRouter 或其他托管 API 往往更容易控制成本。比较时要计算 GPU 折旧、电力、带宽、值班和升级时间，而不是只把 API 单价和裸 GPU 租赁价相减。

如果使用 SandBase 做统一路由，应先确认 Hy4 preview 在实时模型目录和接口中可用，再记录 provider、模型、request ID、token、延迟和错误率。网关可以帮助复测和审计，但不能替代底层集群的容量规划。

安全与可观测性

开源权重不等于默认安全。生产服务要隔离模型节点和业务数据，限制网络出口，给工具调用设置审批，并对输入输出做脱敏和审计。至少监控首 token 延迟、生成吞吐、GPU 利用率、KV cache 使用率、排队时间和失败重试。

第一轮试点的容量工作表

在选硬件之前，先列出目标精度、副本数量、最大上下文、并发量和服务等级目标。权重显存只是第一行，还要加上 KV cache 余量、专家路由通信、激活缓存、操作系统开销，以及滚动升级所需的空间。单个预热请求能够跑通，并不代表多个用户同时提交长上下文时仍然稳定。

测试计划应覆盖冷启动、稳定热流量、突发流量和主动取消请求。对同一组固定样例记录 p50/p95 首 token 延迟、解码吞吐、排队时间、错误率和输出质量。量化后、推理框架升级后都要重复测试，并保留未量化或参考运行作为质量锚点。

运维边界同样重要

把模型权重当作生产软件管理：固定仓库提交和运行时版本，扫描下载制品，限制出网，并对含有私密数据的 prompt 做日志脱敏。健康检查应真正执行一个小型、可复现的请求，而不只是检查进程是否存活。专家分片故障或陈旧缓存都应触发可执行的告警和安全回滚。

对于 Agent 工作负载，要把工具执行与推理 worker 隔离。模型可以提出 shell 命令、网络访问或文件写入，但由审批层决定哪些动作被允许。这样既保留开源权重的灵活性，也不会把模型节点变成无边界的自动化主机。

最后要提前设计退出路径：如何排空流量、保存进行中的请求，以及在质量或延迟回退时恢复上一版本。可以保留一个小规模托管 API 作为故障应急，但必须在事故前演练。明确谁批准权重升级、谁维护 benchmark 样例、哪些日志保留多久。自部署的价值是控制力，而控制力只有在团队能承受压力下运维、审计和回滚时才真实存在。