服务器专题 | 第15期：端口数好看，带宽要看上行

服务器 · 2026-10-25 · 九羲科技

一张扩展卡上印着能接 16 块盘，看着很慷慨。接满之后同时跑，速度却上不去，换盘、换线都没用。问题不在盘，也不在卡的做工，而在卡中间那颗 Switch 的算账方式：它卖的是端口，下游口可以很多，但通往 CPU 的上行只有一根。下游所有口同一时间要走的流量，最终都要挤过这根管子。

Switch 的结构其实很好画：一端是上行端口（USP），连向根端口，也就是 CPU；另一端是一排下行端口（DSP），每口挂一块设备¹。数据包从哪个口进、该往哪个口出，由 Switch 内部的包交换决定，端口之间不是一条共享总线，谁也不用等谁先说完话。但共享的东西换了个地方：上行带宽。内部交换再快，也快不过上行这根管子，这是物理上的硬约束，不是固件调一调就能绕过去的。

超订比，先拿通道数算一遍

超订比的算法很直白：下行通道总数除以上行通道数。同一代际之间，通道数可以直接比，因为每通道速率相同。Gen4 每通道 16 GT/s，Gen5 每通道 32 GT/s³，代际不同先换算，不能拿 Gen5 的下行通道数直接除 Gen4 的上行。

同一代际内，超订比就是通道数之比。1:1 不超订，2:1、4:1 意味着所有盘同时满载时，上行只能满足一半、四分之一（示意图为程序绘制，算账方法见正文）

超订本身不是原罪。16 块盘同时满载，是个很极端的场景。日常负载里，盘与盘之间常常错峰：有的在等应用发请求，有的在写，有的空闲。这时候 4:1 的超订跑起来毫无感觉，端口多反而是好事——接得多、布线省、扩展灵活。超订成立的条件，是负载错峰。条件一变，账就变了：备份窗口里所有盘一起读，或者训练任务 checkpoint 一起写，错峰假设当场失效，超订比就从纸面数字变成真实排队。

非阻塞三个字，只管内部不管上行

厂商资料里常见的“非阻塞”，要当心它管辖的范围。它通常指的是 Switch 内部交换结构本身不构成瓶颈：内部带宽足够，任意下行端口之间转发不互相卡²。但这句话不包括上行。内部不堵、上行堵，是完全可能同时成立的两种状态。验收时问错了问题，就会得到一个正确的、却没用的答案：内部确实非阻塞，上行确实只有 x16。

一个对照的例子能把这条界线画清楚。HighPoint 的一颗 Gen5 扩展方案，上行给 x16，下行给 4 个 x4 口，上下行刚好 1:1¹。这种配置不怕齐跑，因为账面本来就是平的。反过来，16 块 Gen4 x4 的盘挂在一根 Gen4 x16 上行上，下行潜力是上行的 4 倍²，齐跑时必然有人排队。两种配置没有高下之分，只有账算没算清的区别：前者买的是确定性，后者买的是端口密度和错峰假设。

一进多出的 Switch 拓扑：上行 x16 是唯一出口，下行每口 x4，齐跑时总量必受上行约束（示意图为程序绘制）

落到买方清单，这件事可以收成三问。第一问，上行是多少通道、哪一代，写进配置表，不要只写下游口数。第二问，负载里有没有齐跑时刻，备份、checkpoint、批量扫描这些时刻，错峰假设还成不成立。第三问，厂商说的非阻塞，管的是内部还是全程，要求对方把上行带宽白纸黑字写出来。端口数是招牌，上行才是管子。招牌可以大，管子不能细——除非买方已经想清楚，自己的负载本来就不需要同时走满。

以小见大的一层判断：服务器里很多“性能不够”的抱怨，根子不在单块设备的速度，而在汇总点。CPU、Switch、网卡，每一级汇总都是一次再算账。看配置单时顺着数据流往上走，每经过一个汇总点就问一句：这里的口子比进来的总量小多少。问过三遍，整机的真实瓶颈大体就现形了。

没完全想通、留下一个问题：超订比算的是峰值通道数，真实负载的错峰程度却没有现成指标。买方能不能在采购前，用自己的历史 IO 曲线反推一个“有效超订比”，而不是只看峰值比？这个算法公开资料里谈得少，值得找实测对照。

· · ·