最近我组装了一台配备四块 RTX Pro 6000 显卡的机器，但既然能拥有八块，谁还需要四块呢？这台机器是上周刚到的。就在我把箱子砸到自己脸上之前，我收到了这个新玩意儿。哦，是的，这就是 Camino Grando 工作站，它在一个机箱里集成了惊人的 768GB VRAM。
这个机箱并没有比之前的那台大多少，事实上，考虑到里面装了八张显卡，它相当小巧。不过它非常重，这台机器几乎和我一样重。里面堆叠了八块 RTX Pro 6000，它们靠得很近，因为整个系统都是液冷散热的。
这里有个小秘密：其实我已经测试这台机器几个月了，我对它兴奋不已。除了显而易见的“它会超级快”以及能容纳并快速运行巨型模型这些优点外，还有一些不太好的地方我想指出来。
那么，这种机器是给谁用的呢？当然，一个拥有十几个代码代理的开发者可以一次性全部使用它；或者整个开发团队可以在办公室里同时使用。例如，一个拥有超过 40 万个 token 上下文窗口的 400GB TLE LLM。是的，我在这一台机器上运行了它，没有使用云端。
当然，我必须对它进行压力测试。大家通常谈论本地运行大语言模型时，指的往往是一个人、一台笔记本、一个模型，每秒生成 30-40 个 token 就很开心了。但那是去年的事了，现在情况完全不同。
即使你是单人开发，你也不会只运行一个聊天窗口。这个仓库有一个代码代理，那边有另一个在写测试，还有一个在进行审查，每一个都会发送 50,000 个 token。这不是你的提示词，而是整个上下文，因为你需要包含所有内容。
这相当于一个人承担了团队的工作负载。如果我是一个真正的团队，那就要乘以 10。今天我要介绍的是 Camino Grando。Camino 已经存在一段时间了，他们的专长是制造这种液冷 GPU 工作站和服务器。
我没有买这一台，是他们借给我用的。以目前的价格，仅显卡就要 1.5 万美元一张，这里有八张。所以你得好好利用它。这台机器采用 4U 机箱设计，你可以机架安装或桌面安装（我选的是后者）。
仅机器本身重达 121 磅，而且包装很大。出于保险原因，我没有独自搬运它，我找了帮手打开箱子。里面是一块 AMD EPYC 9474F CPU，拥有 48 核 96 线程。这是一颗强大的 EPYC CPU。
里面还插了 512GB DDR5 内存，这目前的 RAM 容量简直疯狂。但大家最关心的还是那八块 Nvidia RTX Pro 6000 Blackwell Server Edition，每块拥有 96GB VRAM，总共 768GB。
我试过在上面运行 GLM-5.2 吗？是的，试过了。成功了吗？某种程度上算吧。作为参考，RTX 5090 只有 32GB VRAM，所以这相当于在一个箱子里塞进了 24 块 RTX 5090 的显存。这真是个好标题：如何在 4U 机箱里塞进八张双槽显卡？
你可以拆掉散热器。每块 GPU 都有定制的铜水冷头，覆盖核心、显存和供电模块（VRM）。这使得双槽卡变成了单槽。每两张显卡有一组独立的水路歧管，接头是防滴漏的快速断开接口，红蓝配色区分。
这意味着你可以拔出一块 GPU 而无需排空冷却液。整个系统是一个 CPU 和 GPU 共享的回路，配有内置水泵的 450ml 水箱。
你可能会好奇给这样的机器供电需要多少功率？答案是 6.5kW。这就像把四个电暖器插在同一面墙上，肯定不行。你需要特殊的电力支持。Grando 配备了四个电源供应器（PSU），每个都有标准插头，可以插入不同的插座同时运行。
它们会合并电力输出，但务必确保它们接在不同的电路上。这里有一个人们经常忽略的问题：多显卡的 PCIe 通道数。这就是为什么我们需要 Thread Ripper 或 EPYC CPU，EPYC 拥有 128 条通道。
因此每块显卡分配一定的通道数，确切地说是 16 条（至少大多数是这样）。七块显卡获得 16 通道，其中一块只有 8 条。由于 GPU 占用了大部分通道，只剩下两个 M.2 插槽，你必须明智地使用它们。
我曾遇到过因空间不足而不得不更换模型的问题。此外，这里没有 NVLink，所以所有显卡必须通过 PCIe 相互通信。还有四个热插拔的 200W 电源供应器，总容量为 8kW。
你可能不想全部使用这八个（指电源或功率），因为那会毁掉你的设备。八块 RTX Pro 6000 以满功率 600W 运行，仅显卡就需要 4800W。
我没有 8kW 的电路，所以我有两个 PSU 接在 240V/20A 电路上，一个接普通 120V/15A 插座，另一个接在 Jackery（杰克威）电池上。是的，我用了便携电源。嘿，我只是个人类而已。
先做个简单的说明：我将 GPU 功耗限制在每张 300W，而不是默认的 600W。别走开，我会告诉你为什么这样没问题。部分原因是我的布线情况；另一部分是当我以 600W 运行时，机器在我进行长时间运行的夜间测试中两次直接关机了。
你可能认为：一半的功率，就是一半的速度？但这反而是这个项目中最有趣的发现之一。当我在家以外工作时，我最终会连接到一些我不太了解的网络上——当然不是完全信任的那种。
所以在开始工作前，我会连接 Surfshark VPN。我的终端会话、仓库流量和容器下载都通过 AES-256 加密隧道传输，Clean Web 功能屏蔽了大量我不想要的追踪和广告垃圾。
此外，它还有经过独立审计的无日志政策，以及每次重启都会擦除内存的服务器。考虑到我携带的大量硬件设备，无限连接设备的功能非常重要。它覆盖了我的 MacBook、手机以及背包里连接到互联网的任何其他设备。
当我检查服务器或 SSH 回办公室时，这额外的一层保护非常有意义。所以去 surfshark.com/alexiscin 领取四个月免费试用，如果不满意还有 30 天退款保证。保护你的连接，完成你的工作。
回到视频内容，让我们谈谈噪音问题。Camino 声称噪音在 39 到 70dB 之间，取决于你选择的风扇版本（因为可以定制）。有 6200 RPM 的版本和 3000 RPM 的版本。
但我要告诉你，你不会把这台机器放在你旁边的桌子上使用。
过了一会儿，噪音就平息了。即使在最安静的设置下，在满负荷的GPU负载运行时，它还是很吵。是的，如果你坐在旁边，它会非常响。我建议你离远一点。可能再远点。你还能听到吗？是的，你需要远离它。不过散热是另一回事了。我看到的最高GPU温度是62摄氏度，CPU峰值为65度。因此，这里的液冷并不是噱头。这正是这台机器存在的理由。它非常高效且优秀。好了，让我们来看看一些模型测试结果。系统为Ubuntu 24.04，Nvidia开源驱动610，CUDA 13以及VLM Nightly版本。我在测试过程中一直保持更新。我们使用张量并行技术在所有八块GPU上运行。
排在首位的是GLM 5.2，拥有433GB的权重参数。随后又发布了一些新模型，所以我不得不进行测试。这里列出了我主要使用NVFP4格式运行的五个模型，这是一种浮点4位格式，正是Blackwell架构所支持并为其设计的。最大的“大块头”GLM 5.2，其服务上下文窗口为49,600个token。Qwen 3-235B，这个模型虽然有些年头了，但体量相当大。它是一个混合专家（MoE）模型，激活参数为220亿个，磁盘占用144GB。
GLM Flash 5.3的大小在144到185之间，这可以说是这类机器的甜点区。当然它可以运行更大的模型，但那样你就得处理上下文、多个会话以及同时访问的多个智能体（Agent），所以最好还是停留在这一规模。GLM 5.2加载大约需要4分半钟，占用了784GB可用显存中的738GB。这意味着仅一个模型就耗尽了这台机器约95%的显存，但它能装下。这正是其核心优势所在。基本上没有其他单台桌面设备能做到这一点。
我之前做过一期关于DJX工作站视频，那款机器拥有252GB的高带宽内存（HBM），速度远快于此处的显存，但它没有足够的总容量将所有模型全部放入VRAM中。顺便说一句，DJX工作站在小模型上也表现出色。我想对比一下小模型在这台机器与DJX工作站上的表现，敬请期待接下来的内容。让我们从大多数开发者所处的场景开始：一个用户对应一个智能体。我知道现在你们用的不止这些，但让我们先从基线开始测试：2048个token的提示词输入，输出128个token。
在单张RTX Pro 6000上，30B参数级别的模型生成速度约为每秒100个token。那么当大模型分布在八张PCIe显卡上时会发生什么？GLM 5.2的生成速度为每秒48个token。对于一个433GB的大模型来说，这个成绩相当不错，虽不算惊艳，但足够快。我们稍后再回头讨论这个问题。Qwen 3-235B的速度为每秒85个token，哇哦。接下来是一些更现代的模型：DeepSeek V4 Flash为每秒102个token，GLM 5.3为每秒104个token。
Qwen 3.8以每秒126个token的速度赢得此项测试，紧随其后的是Qwen 3.8 Flash。这是基于Qwen 4架构的模型，如果你不知道我在说什么：之前发布的Qwen 3.8模型实际上是基于Qwen 3架构（包括Qwen 3和Qwen 3.8 Flash），而Next版本则采用了Qwen 4架构。别问我为什么，我也不知道他们为什么要这样做。另一个你应该关注的指标是提示词处理速度，因为这在代码编辑器中使用智能体时至关重要。
例如，GLM 5.2的提示词处理速度约为每秒2,200个token。Qwen 3-235B则大幅提升至每秒4,779个token。GLM 5.3 Flash达到8,300，DeepSeek V4 Flash为8,700。而Qwen 3.8 Flash Next更是高达12,600，这速度真快。现在来看看实际应用中单个用户的首字生成时间（Time to First Token），提示词长度为2,00个token。Flash Next仅需四分之一秒，GLM 5.2接近一秒，其他模型介于两者之间。
回顾每秒12,700个token的提示词处理速度，这意味着2,00个token的输入几乎是瞬间完成的。接着我给它一个128,000 token的提示词，这基本上是一个小型代码库。在Mac、迷你PC或我测试过的其他任何设备上，处理128,000 token的提示词通常意味着“去泡杯咖啡吧”。哦，好吧。咖啡可以等，我还在等待即将发布的M5 Ultra芯片，那可能会改变一些情况，但对于旧设备来说，你将需要等待几分钟。
随着提示词长度的增加，首字生成时间也会相应延长，有时甚至大幅增加。Qwen 3.8 Flash Next在128,000 token时，首字生成时间为14.5秒。GLM 5.3 Flash约为18到20秒，DeepSeek V4 Flash为26秒。而在GLM 5.2上，哇哦，需要50秒。这就是那个“大块头”嘛，所以也在意料之中。尽管如此，最大模型的处理时间仍不到一分钟，最快的则约为15秒。Qwen 3-235B没能坚持到最后，我们只得到了32个token，之后它在其余测试中崩溃了。抱歉。
这就是八张GPU发挥其价值的样子，因为提示词处理是推理的第一阶段，发生在token生成之前。这一阶段完全由计算密集型任务主导，所有处理都在GPU芯片上完成。但第二阶段是token生成。那么当所有这些上下文都存储在内存中后，生成速度会如何变化？嗯？这里的曲线几乎都是平的。Flash Next即使在128,000 token的上下文下，生成速度仍保持在每秒约120到122个token。
GLM 5.2也保持稳定，大约在40到50之间，没有任何模型出现减速。这简直令人难以置信。现在插一句题外话，因为这关系到智能体（Agents）。我使用VLM来服务这些模型，而VLM具有前缀缓存功能。如果你的对话中已有约16,000个token，在不使用缓存的情况下发送另一条消息给GLM 5.2，首字生成时间为5.9秒；而开启缓存后仅为0.83秒，速度快了7倍。
你会发现整个过程中都有类似的模式。你可能会说：“Alex，这很明显啊，开启缓存不就行了吗？”然而，特别是在智能体工作流（Agentic Flows）中，你确实需要开启这个选项。还记得功耗限制吗？我在300瓦和600瓦下运行了相同的测试。你说300瓦会比600瓦慢，好吧，其实是我说的，但你心里也是这么想的吧？GLM 5.2在300瓦下为每秒48个token。Qwen 3-235B为85（注：此处原文可能有误或指代其他模型，按原意翻译）。
GLM 5.2（此处原文可能有误，结合上下文推测可能指另一模型或重复提及），现在我们有32个用户的情况下，在300瓦下达到了每秒111个token。而Qwen 3-235B在64用户、254个token的情况下，速度为每秒254个token。那么在600瓦下表现如何呢？哇哦，结果几乎一样。我甚至不认为那有什么差别。“真的吗？”好吧，实际上是254和252。是的，我知道。冷静点，这已经足够接近了。
看看实际的GPU功耗：在300瓦的限制下，八张GPU在进行推理时总共消耗约1,550瓦。这是针对GLM 5.2的情况。“那只是其中一个插头，它消耗了126瓦。”
空闲状态下，每张卡功耗约为1700瓦。我见过的峰值是268瓦，这意味着这些卡在推理过程中受限于显存带宽。它们通过PCIe相互通信，因此从未接近600瓦的限制。提高功耗限制除了产生更多热量并使系统更不稳定外，没有任何其他好处。这让我想到一个困扰我已久的问题：工作站版（600瓦上限）与Max Q版本之间的区别，我想这会是另一期视频的内容。敬请期待，记得订阅。顺便说一句，仅仅加载模型而不进行任何操作时，GPU的空闲功耗约为700瓦。就这样闲置着，毫无意义地消耗电力。所以请记得支付电费。别误会我的意思，
这并非魔法。每当这些AGPU同步时，它们都会通过PCIe传输数据，你能感受到这种延迟。这不是NVLink。我很想在这个频道上测试一些NVLink功能。如果你正在收听并且手头有这类设备，请告诉我并联系我。有人有A100或H200吗？在之前的测试中，Qwen 3 235B模型使用四张GPU和4路张量并行，达到了每秒58个token。我在全部八张GPU上使用TP8测试时，
速度降为每秒37个token。因此，更多的GPU反而更慢，因为通过PCIe进行All-Reduce的成本超过了额外计算带来的收益。你需要维持这种平衡并进行调整。因此，对于较小且能容纳在四张卡上的模型（而非全部八张），你实际上可能更适合在每个机器上运行两个副本，每张卡四个，从而服务两倍的用户数，而不是在八张卡上只运行一个副本。GLM 5.2以每秒48个token的速度
运行，使用的是官方标准配方。这里没有使用投机解码（Speculative Decoding）。如果你对投机解码感兴趣，我制作了一个单独的视频介绍它，链接会在下方提供。开启MTP后我在之前的测试中获得了每秒约100个token的速度，但那个配置稍微有点繁琐。目前生态系统仍在追赶这些GPU的步伐。尽管它们以某种形式存在已近两年，但仍被视为
相当新的产品。例如，GLM 5.3 Flash在任何标准VLM镜像上都无法启动。我尝试了六种不同的配置，每次都遇到相同的内核错误，因为该模型使用了一种Blackwell工作站内核尚未处理的注意力变体。它太新了。因此，一旦VLM将其合并上游并支持该功能，你可能会得到略有不同的数字，甚至可能更好。好了，让我们试试这个。这将非常疯狂。
这四台机器都将向Grandondo发送请求，显然它不在这个房间里，但你或许能听到它的声音。是的，它在启动中。这是Maya，她正在为订单API运行测试套件。这是Ravi，他在处理指标仪表板。Lena正在加固库存报告脚本。是的，这段代码不是我写的。好吧，但这仍然是一个测试。还有那边的Tom，他正在将Q Worker容器化。是的，他们都在忙碌。好吧，这正是重点所在。我需要让他们保持繁忙状态。
好了，现在我们要开始干活了。每个机器都在处理大量任务。不管代理需要什么，每一个都启动了多个代理和子代理，同时指向Grandondo。其中一些需要权限确认。“设为始终允许”，“砰”的一声，然后确认。他一定在做些危险的事情吧？可能是Maya或Lena的操作。这里显示了在Grandondo上运行的每个GPU的利用率和显存使用情况。我们达到了100%利用率，每块GPU功耗跃升至约185至190瓦，每张RTX Pro 6000的显存使用了90/96 GB。
这里运行的是DeepSync V4 Flash，速度相当快且不错。所有这些代理和子代理都获得了它们应有的份额，绰绰有余。我们将每台机器启动32个代理作为开始。“砰”的一声，三、二、一，开始。哇哦，这正在启动中。你或许能从另一个房间听到声音。不错。我们总共有128个并发代理，每台机器32个。它以每秒约3000个token的速度运行着。好了，让我们停止这个测试。
我们将每台机器的代理数量增加到128个。天哪，这将会疯狂起来。“全部启动”，哦哟，它正在运行中。512个并发代理。哇哦。利用率仍然保持在相同的水平，即100%。这应该是这样的。让我们试试256个代理吧。这是给Maya、Ravi、Lena和Tom的，也就是这里的四位忍者各256个代理。开始吧，“全部启动”。
三、二、一。“砰”的一声，嗯，它似乎不太喜欢这样。肯定是不太乐意。哦哟，它在努力尝试中。“1000个并发代理”。嘿，它做到了。我们达到了每秒6000到7000个token的速度，并且确实完成了任务。它不得不进行启动过程。哇哦。KV缓存占用41%，零错误。首token延迟相当高，虽然系统表现得不是特别开心，但它正在完成工作。由于我一直在说话期间，我们已经完成了超过63万个token的总量。不错嘛，干得好，人类们。你们可以回家了。再见Maya，我会想你的。
我针对所有五个模型分别运行了1、2、4、8、16、32和64个并发用户。使用相同的448 token提示词，没有排队，每个用户实际上都处于同时飞行状态。Qwen 3.8 Flash模型下，第一个用户的速度为每秒126个token。随着我们增加更多用户，总吞吐量上升
因为机器生成的总每秒token数增加了。但是每个用户的每秒token数量下降了。因此，对于四个用户，我们得到90个；八个用户时是82个。顺便说一句，这可以是八个不同的用户，也可以是一个开发者并行运行八个代理的情况。所以在这里，你的所有八个代理共享每秒82个token的速度，这仍然相当不错。每个
代理的速度比大多数人从云API获取单个代理的速度还要快。16个用户时是61，32个用户时是37，而到了64个用户时，我们降到了20.6。这并不出色。让我们看看这些其他模型的数据以及我们的表现情况。当然，Qwen 3.8是最快的。GLM 5.3 Flash和DeepC4 Flash的速度大致相同。以下是单个用户的数据，
然后是四个、八个以及令人难以置信的64个用户时的数据。你真的在同一时间运行了64个代理吗？说实话吧，你最多同时运行了多少个代理？请在评论区留言。在那种情况下，机器以530个token每秒的聚合速度输出峰值解码或令牌生成突发高达2880。以下是单个用户、四个用户、八个用户的
数据，最后我们得到了64个用户的情况。这里显示了来自Qwen 3.8 Flash的530个token每秒的数据。接下来，首Token时间看起来相当有趣吧？特别是对于GLM 5.2而言。“首Token时间”是指直到所有内容出现之前的等待时间。在八个用户时，所有三个Flash模型大约需要1.5秒的时间；GLM 5.2则需要5.5秒。在十六个用户时，我们达到了2.5秒和接近10秒的时间对于GLM 5.2。而在64个用户时，你知道的，我们正处于一个
你可能并不想那样做，尤其是面对 GLM 5.2。等待首字生成时间长达 33 秒，GH，很抱歉你要经历这些。我们如今真是缺乏耐心，不是吗？这东西 literally 在替我们撰写内容了。拜托，快点啊，任务的主宰们。顺便感谢大家坚持看完整个视频，也感谢频道的会员们，非常感谢你们的支持。简而言之：
使用合适的模型，无论是 16 名开发者各运行一个编码代理，还是一名开发者同时运行 16 个代理。每一个模型都能达到每秒 60 个 token，且从一台机器（希望它放在另一个房间）发出的等待时间仅为 2.5 秒。作为参考，Storage Review 拥有与我完全相同的机器（他们寄给我的），他们也对此进行了评测。他们在同一台机器上对 MiniMax 运行了 Claude Code 会话，在八个并发会话下，每个用户获得了每秒 39 个 token。这大致相当于通过 API 使用 Claude Opus 所获得的速度。
那么，我会购买这样一台机器吗？嗯，我是买不起的，但我可以谈谈我的看法。如果你是独立开发者，这是这样一台机器：你不再需要把模型当作一个让你等待的东西来思考。此外，如果你是独立开发者并购买这样一台机器，你最好能从你的项目中赚取可观的收入，或者将其出租等。这里的主要目标受众显然是企业、中小企业或中型企业，那里有团队在使用这些设备运行工作。
八个代理，每个每秒 80 个 token。在提示词中包含整个代码库仅需 14 秒。依我之见，这对一个人来说有点杀鸡用牛刀了，但这是我最近测试过的两台机器之一，在这类机器上我不再感到受限于我能运行的代理数量。如果你是一个人构建像团队一样的代理群，嘿，这也不算太疯狂。
你还需要考虑的一点是，这仍然是相当新的硬件。因此，你需要习惯每晚更新的 VLM 构建版本。你可能需要稍微动手处理一些幕后活动；或者如果你只想搭建并运行它，食谱（配置指南）是存在的。Nvidia 网站上有很多他们的配方/脚本，VLM 也有我目前正在使用的食谱，非常实用。他们并不总是列出你正在运行的确切配置。例如，这里有一个针对四张 RTX Pro 6000 的食谱。所以你需要根据自己的规模进行修改，例如将 Tensor Parallel Size（张量并行大小）设置为 8。或者如果模型足够小，你可以运行几个实例。
正如我之前提到的，我最近用四张 RTX Pro 6000 进行了构建，你可以点击旁边的链接观看。感谢收看，我们下次再见。