摘要

  • 5x9 Networks 的 Big VM 方案在一颗 144 核 Xeon 6780E 上运行一个转发器，承载 64,000 个用户；演示稿称，在启用 ACL、未启用分层 QoS 时达到 200 Mpps，并在 500 字节包长下达到 800 Gbps。1.6 Tbps 来自双 CPU 扩展，不是单 CPU 结果。
  • 从 16 个 Small VM 转发器合并为一个 Big VM，确实减少了缓存内的重复状态；与此同时，执行、变更和用户状态进入更集中的边界，除非另有已测试的冗余和恢复机制。
  • 公开演示稿没有给出状态同步、故障注入、重启、升级、会话丢失或恢复测试。运营商必须分别验收吞吐与故障行为，不能把一条性能路径直接视为可用业务容量。

BNG 位于固定宽带最容易被抽象化、也最不能靠抽象运行的交界处。它终结 PPPoE 或 IPoE 会话，完成三层转发，还可能执行每用户 QoS、ACL、AAA 和合法监听要求。这个节点失效时，问题不只是哪一个包没有转发，而是用户状态在哪里、是否一致、能否在业务允许的时间内恢复。

5x9 Networks 联合创始人兼 CTO Branimir Rajtar 在 2 月 11 日 APRICOT 2026 的 Network Operations 场次介绍了 Getting 1+ Tbps from an x86 server。这份 19 页演示稿记录了一条清晰的工程路径：从多个小转发器，转向一个覆盖整块 NUMA 域和全部 CPU 核心的大转发器；其间使用 SR-IOV、Intel DPDK，并调整 CPU、缓存、PCIe、DMA、BIOS、网卡和代码。

这是供应商自己的测量记录。它可以证明供应商做了什么、报告了什么；它不能自动成为独立验收，也不能被扩大成所有业务条件下的容量。

最初的 Small VM 架构使用两颗第二代 Xeon Gold，每颗 18 核，共运行 16 个转发器。5x9 报告，在未启用分层 QoS 时达到 40 Mpps，启用后为 26 Mpps；500 字节包长下分别为 160 Gbps 和 100 Gbps。这个配置中的差距约为 35%。它不是所有 QoS 实现都会付出的固定税率，却足以说明：业务功能改变，容量数字也会实质改变。

后续提升并非来自“x86”三个字。演示稿把约 30% 的提升归于较新的硬件和应用工作，把另一个约 30% 归于 DPDK、CPU、PCIe、BIOS 和网卡的深入调优，又把 20% 归于性能分析与代码重写。每个百分比都属于这一实现，不能机械相加到其他平台。它们共同揭示的事实更重要：包转发依赖一条具体的物理与软件链。

5x9 最终把主要瓶颈定位为 CPU 缓存未命中和等待。大量内存对象占用缓存，频繁变化的数据造成停顿；处理器按缓存行读取，即使真正有用的数据对象更小。团队把读结构与写结构分离，调整 PCIe/DMA 调度和哈希算法，并称把路由表的内存占用缩小了 90%。

Small VM 的问题由此变得具体：16 个转发器把同样的信息在缓存中存了许多遍。Big VM 将它们合并，让一个虚拟机跨越整块 NUMA 域和全部 CPU 核心，共用一套工作状态。

这是一项可以解释的物理收益。更好的缓存局部性减少主内存往返和等待，重复表与进程开销也可能下降，活跃服务器数量可能随之减少。收益并不虚构；但依赖也没有消失。

演示稿当前的单 CPU 配置使用 Xeon 6780E。Intel 官方资料确认这是一颗 144 核处理器，具有 108 MB 缓存、最多 88 条 PCIe 5.0 通道，服务器模式 TDP 为 330 W。这些规格并不验证 5x9 的 BNG 测试，却说明 CPU、内存、PCIe 通道与插槽、网卡和供电仍然属于转发路径。

在这颗 CPU 上，5x9 报告：一个转发器、64,000 个用户、启用 ACL 且未启用分层 QoS 时 200 Mpps、500 字节包长下 800 Gbps、占用 32 GB 内存。演示稿把两颗 CPU 的扩展结果写为 1.6 Tbps。因此，一台服务器与一颗 CPU不能混写；如果标题只留下 1.6 Tbps，就会把第二颗处理器从证据边界中抹掉。

用户规模和功能限制同样不能省略。演示稿称，超过 100,000 个用户后性能开始下降，虽然最多支持 260,000 个用户；如果所有用户都启用分层 QoS，性能约下降 30%；如果所有用户都使用 NAT，下降 30%至 40%。这意味着 800 Gbps 是特定包长和功能状态下的路径结果，不是 BNG 能提供的所有业务的统一容量。

DPDK 与 SR-IOV 解释了路径为何能变短。DPDK 的 Poll Mode Driver 直接访问收发描述符，通常用轮询替代普通包中断，并绕过传统内核网络栈。SR-IOV 则让一个 PCIe 物理设备通过 Physical Function 暴露多个 Virtual Function。它们改变了包如何进入用户态和虚拟机，却不回答用户状态复制到哪里、转发进程退出后会发生什么、网卡或 VF 能否在不重置会话的情况下替换，也不说明另一台服务器如何接管。

CUPS 也有明确边界。控制面与用户面分离，可以把会话控制、策略与包转发分开；它不等于数据面自动连续。控制器仍然健康时，Big VM、CPU、PCIe 路径、网卡或整台服务器仍可能成为需要接管的物理与状态边界。

公开材料没有冗余拓扑，没有状态同步方法，也没有说明 N+1 余量。它没有展示主动杀死转发器、拔除 VF 或网卡、丢失 CPU 或服务器的测试；没有重启时间、升级和回滚顺序；没有会话丢失与恢复数量；没有混合包长与完整功能组合下的结果；也没有客户生产验收。

这些缺口不证明 5x9 没有做这些工作，更不能据此宣称 Big VM 不可靠。它们只限定了公开结论：供应商展示了一条性能路径，但没有公开验收更大的故障与变更边界。

从 16 个进程合并到一个进程，运营单位也变了。Small VM 会付出缓存重复的成本，却可能把一个进程对应的用户集合压得更小。Big VM 提高工作集效率，同时把更多会话状态带进同一个软件、CPU 与维护窗口。运营商可以再部署多个 Big VM、独立服务器或状态复制；演示稿没有给出这一层，因此不能替它补齐。

权力分布由此清楚。5x9 控制代码、测量工具、测试配置和产品表述；Intel 与网卡供应商控制芯片、固件、DPDK 兼容性和资格组合；接入运营商控制拓扑、备用容量、业务功能、变更窗口以及面向客户的验收阈值。APRICOT 控制的是发布记录，而不是平台认证。

成本也落在相同边界。运营商支付新一代 CPU、受支持网卡、具备足够 PCIe 通道的服务器、工程调优、许可、重复测试和故障时需要的闲置容量。演示稿提出“更少服务器、成本更低”，但没有给出总成本或功耗测量。一台能够接收同样状态与流量的备用服务器，即使平时空闲，也不能从经济计算中删除。

用户承担集中化的另一面。如果大转发器能在可接受时间内被替换、状态保持一致，他们可能得到更灵活、更低成本的宽带服务。如果不能，一个进程或一台服务器事件就可能关联更多会话。本文没有声称真实事故已经发生；它指出能够区分这两种结果的验收试验。

可信的反事实并不要求丢弃 Big VM。运营商可以用两个或更多大转发器和服务器形成 N+1，明确状态同步方式，并在规定的包长、IPv4/IPv6、ACL、分层 QoS、NAT、AAA 与控制面负载下测试。然后主动终止转发器、移除 VF 或网卡、重启虚拟机、丢失 CPU 或服务器，执行升级与回滚，记录多少会话重置、恢复用了多久、备用路径接管后还剩多少持续吞吐。

在用户较少或边缘站点，Small VM 可能因为较小的影响范围而值得承担缓存成本；5x9 的演示稿本身也保留了这种选择。ASIC 或白盒方案也可以比较，但必须使用同一套业务与故障记录，而不能让不同平台各自挑选最有利的数字。

号码资源不在这个验收边界之内。ASN 和前缀可以识别运营主体并显示对外路由，BGP 可以证明一条路径被宣告和可达。它们不能证明路由背后的 BNG 能在变更中保存用户状态、分层 QoS 或 NAT。RIR 和会议也没有合法机制替运营商认证内部业务容量。

5x9 记录中真正重要的工程成就，不是软件让物理限制消失，而是工程师在缓存行、内存对象、NUMA、PCIe、网卡与代码中找到限制并移动它们。下一个边界同样具体：一个转发器、一组会话状态，以及它所依赖的硬件。

缓存效率可以减少服务器数量，却不会自动缩小故障域。APRICOT 展示的结果在其包长、功能和处理器边界内有价值。只有同一架构穿过运营商承诺能够承受的故障与变更测试，这条吞吐路径才成为可交付容量。

来源