Jordan（SemiAnalysis / ClusterMAX）¶

⚠️ 全名待核：他在本库唯一一期材料里全程只被叫 "Jordan"，自己也没报全名。本库据"在 HPE 做了十年硬件系统设计 + 2025 年 6 月加入 SemiAnalysis 技术员 + ClusterMAX 负责人"这组自述推测他可能是 Jordan Nanos，但转录稿里没有这个姓，故本页只用 Jordan，姓氏不写进任何断言。

背景: SemiAnalysis 技术员，ClusterMAX（GPU 云托管集群评级榜单）负责人。2025 年 6 月加入；此前在 Hewlett Packard Enterprise 做了十年硬件系统设计——⚠️ 他自己点出的那个巧合很关键：他当年设计的硬件系统，正是"ChatGPT 之前、以及 2022/2023 那波狂热里涌进市场的那些 NeoCloud"在买的东西（[00:00:02]）。
首次收录: Latent Space / ClusterMAX 3.0，2026-10-02
本库中的位置: 第一个从"实测买方"角度说话的基础设施声音。本库此前的基础设施材料全部来自供给侧（Dylan Patel 的卖方分析、Sean Lie / Andrew Feldman / Walter Goodwin 的芯片侧、Baseten / Akshat Bubna 的服务侧）或需求侧的自述。⚠️ 而他的工作是"去租来、跑 benchmark、看它坏不坏"——这是本库第一份把 GPU 云当被测对象的材料。
他进 SemiAnalysis 的方式本身是一条很好的轶事（[00:01:02]）："在 SemiAnalysis 找到工作最好的办法，就是找到一件 SemiAnalysis 在做的事然后批评它，然后 Dylan 就雇你去修它——我的情况正是这样。"

立场与关注点¶

一、⚠️ 安全：问题的层级比所有人以为的都低¶

来源：Latent Space / ClusterMAX 3.0

他的检查清单"相对非常简单"（[00:08:10]）：软件版本是不是最新、驱动是不是最新、配置对不对；第二类是网络密钥（InfiniBand 侧的 M key、P key 之类是否正确配置部署）。
⚠️ 他最该被引用的一句："当人们在跑两三年前的软件版本、而那些 CVE 网上都有完整文档时——你根本不需要一个前沿模型来给它写 PoC exploit，你只需要知道该往哪儿看。"（[00:08:10]）
他的做法是把检查工具开源：随文放出免费 CLI（装好跑 cmax）查集群软件版本，终端输出直接给升级链接。
⚠️ 本库标注：这条与本库 LLM 与基础设施安全页上以模型/agent 为中心的其余材料形成一个很有用的对照——他指认的洞不在前沿，在运维。

二、门槛要故意逐代抬高，而本代的门槛是一张具体的部署清单¶

来源：Latent Space / ClusterMAX 3.0

他对 ClusterMAX 1 的批评就是他的方法论（[00:01:02]）：只覆盖 24 家供应商（当时市面约 120 家）、过于聚焦 Slurm 而漏掉 Kubernetes。3.0 追踪 323 家。
⚠️ 本代的新门槛是 2026 年有没有在部署 GB300 NVL72，而他把"做不到"的原因列成了一张工程清单（[00:10:11]）：新网络、机架内 scaleup domain、ARM CPU、Blackwell GPU、800G 网络、强制直接液冷——"所以从物理数据中心、到你怎么部署操作系统、到你怎么管理网络里的驱动，几乎每一件事都变了。"
⚠️ 他对"我们只是做了战略取舍不做 GB300"的回应是全期最锋利的一问（[00:11:12]）："那等明年 Vera Rubin 来了怎么办？你要信谁？"
可靠性是头部客户最在意的第一条标准，而他给的具体判据是支持团队"一小时内修好而不是两周"（[00:11:12]）。
⚠️ 测试方式本身被 agent 改了（[00:02:04]）：第一代"所有测试都是手动的——那是 Claude Code 之前、Codex 变认真之前"；现在是一个一年半积累的 benchmark repo，"非常自动化，我们可以用 coding agent 把这些东西拉起来跑，让它们自主修掉一堆问题，不需要我们介入"。本库记这条为把 LLM 用在实践中的一个一手案例。

三、⚠️ 什么样的人才能建基础设施：他给了一条很硬的定义¶

来源：Latent Space / ClusterMAX 3.0

正面（[00:29:23]）："对建一家基础设施公司来说，你真正理解负载怎么运作、并且有被'训过模型、跑过集群'所塑造的观点，这件事太重要了。"
⚠️ 反面他说得很不客气："而不是那些加密矿工——'嘿我找到一块地、我有点电、我有点钱'——他们没有执行能力。"
⚠️ 能力分布极窄（[00:35:27]）："大多数 silver 和全部 bronze，没有人在上面训前沿模型。很多推理、一点 RL、很多研究，但老实说那些人里我一个都不会信任去建一个 10 万 GPU 的集群，除了 Azure。" 被问"谁已经证明过"时他的答案是 "五家公司。"
他对 Dylan"所有 NeoCloud 都该自己去训个前沿模型"这条建议并不完全同意（[00:32:25]）："我不确定每个人都该有训前沿模型的技能。" ⚠️ 本库记为一处未收口的分歧。

四、评估层自己在产业化，而他主动纠正了一处常见误读¶

来源：Latent Space / ClusterMAX 3.0

⚠️ "InferenceMAX 的名字是因为它关于推理性能，但它其实是关于芯片的，是在比较芯片和系统。"（[00:45:30]）
要出的 EndpointX 测 serverless 推理 endpoint，"超出纯性能：我们看成本、看可靠性、看安全、看监控基础设施"；他给的理由是："仅仅因为某家在 batch=1 的人造测试上打到更高的数，并不意味着它就是你扩大推理规模时的正确伙伴。"（[00:46:30]）
还会覆盖裸金属、RL 基础设施、sandbox；需求侧的信号是"非常多人来找我们问该选哪个 endpoint 供应商、哪个托管 RL 训练供应商、哪个 sandbox 供应商"（[00:45:30]）。
⚠️ 他真正会听的两条批评恰好相反（[00:39:27]）："你们写得不够" vs "这有三万字我读不完"——"所以我们真的很难在这两者之间平衡。"

五、多芯片与跨站点 RL：他把一条基础设施主张推得比在场任何人都远¶

来源：Latent Space / ClusterMAX 3.0

⚠️ 最该被引用的一条（[00:52:34]）："甚至不必是同一个数据中心。人们在很多很多站点上做 RL：这个数据中心在做 token 生成，那个数据中心在做 token 生成。而在那里用不同类型的芯片其实是可以的。只是这是个非常复杂的 infra 问题，因为你要用不同方式切分模型，权重更新发生在不同时间。"
他同时点了那个硬约束（[00:51:34]）：数值正确性——"哪怕只是 NVIDIA GPU 的两个不同世代，B200 对 B300，你的内存量不同、batch size 不同。" 所以"预训练大概还是同构集群——人们大概不会在 40 万 GPU 的规模上冒这个风险"。
他对中国芯片给的是产能侧的拨回（[00:55:40]）："这些芯片今天确实能用，但它们产不出足够的量来真正服务全部的国内需求。" 详见中美 AI 对照。
⚠️ 他的结论：领先 NeoCloud"将来需要能支持异构算力"，而这会被 Vera Rubin 世代逼出来（[00:49:32]）。详见 AI 基础设施。

⚠️ 读他时该知道的¶

他的全部材料目前只有一期，且那一期是他自己产品的发布期。 本库对他的记录集中在方法论与实测观察，而不采用榜单名次。
⚠️ 他与 Dylan Patel 同属一家机构，所以两人的说法不构成独立验证。 不过本页注意到他在期内两次与 Dylan 公开不同调："不确定每个人都该会训前沿模型"、"这只是产量问题"（把中国芯片从"变好很快"拨回"产不够"）。
组织上的隔离是 Dylan 自述的（[00:37:27]）："Jordan 想做什么就做什么，技术上他甚至不知道我们跟哪些公司有合同。" ⚠️ 本库记为自述，无法核实。