极致堆料：八卡液冷巨物的物理规格
这台名为 Camino Grando 的机器并非普通消费级产品，而是专为极端算力需求打造的工业级工作站。其核心配置令人咋舌：机箱内堆叠了 8 块 Nvidia RTX Pro 6000 Blackwell Server Edition GPU，每块拥有 96 GB VRAM，总计提供惊人的 768 GB 显存。作为对比，目前主流的 RTX 5090 仅配备 32 GB VRAM，这意味着该机器在显存容量上相当于 24 张 RTX 5090 的总和。为了容纳这些庞然大物，机器采用了 4 U 机箱设计（可机架或桌面安装），整机重量高达 121 磅。计算平台方面，它搭载了一颗 AMD EPYC 9474F CPU（48核96线程）以及 512 GB DDR5 内存。> "This is definitely sold last week... I got something new. Oh, yeah. This is the Camino Grando"。这种硬件规模通常只出现在数据中心，而博主将其搬到了个人工作环境中。
散热与供电：液冷系统与电力挑战的平衡术
如此密集的硬件带来了严峻的热管理和功耗问题。八张显卡并非通过风冷散热，而是全部覆盖定制铜水冷头（涵盖核心、显存和供电模块），将双槽卡变为单槽宽度，并共用一个包含 450ml 储液罐的闭环水冷系统。> "Every pair of cards has its own little manifold... you can pull one GPU out without draining the loop"。这种设计允许在不排空冷却液的情况下热插拔显卡，极大提升了维护便利性。然而，功耗是另一大瓶颈：八张卡满负荷运行需 4800 瓦，整机峰值功耗可达 6.5 kW。博主并未使用标准的单一电源插座，而是通过四个独立 PSU 分别接入不同电路（包括 240V/20A、120V/15A 甚至 Jackery 电池）来分散负载。> "You need something special for that... make sure they're on different circuits"。
多 Agent 并发：从单人聊天到团队级负载的范式转移
博主指出，传统本地 LLM 运行模式（单人、单窗口、30-40 tokens/s）已无法适应现代开发工作流。当前开发者往往同时运行多个 Coding Agent，每个 Agent 需处理约 50,000 tokens 的完整上下文（而非仅提示词）。> "Even if you're solo, you're not running one chat window... That's a team's worth of load from one person"。若以团队规模计算，负载需乘以 10 倍。为此，博主测试了在一个无云端依赖的本地环境中运行 400B 参数、上下文窗口超 40万 tokens 的 LLM。尽管 PCIe 通道分配存在局限（7张卡16 lanes，1张8 lanes）且无 NVLink 互联导致通信依赖 PCIe，但该机器成功承载了这种高强度的并发任务。> "I ran that all one box, no cloud"。
性能折中与噪音控制：降频运行的意外发现与使用场景限制
在实际测试中，博主将每张 GPU 功耗限制在 300瓦（而非默认的600瓦），原因包括家庭电路承载能力有限以及高负载下机器曾意外重启。> "I ran the GPUs capped at 300 watts each instead of the default 600"。有趣的是，降频并未导致性能减半，反而证明了在特定工作负载下能效比的重要性。此外，噪音控制也是关键考量：尽管可选配 6200 RPM 或 3000 RPM 风扇，噪音范围在 39-70 dB，但博主强调该机器绝不适合放置在办公桌旁。> "You're not going to have this on your desk next to you"。这种极端硬件更适合专用机房或隔离空间，以支持如 400B 大模型等巨型模型的本地化部署与多 Agent 协同工作。
极致静音与高效液冷散热
尽管设备在满载运行时噪音较大，需要保持距离才能舒适使用，但其内部温控表现极为出色。测试中观察到的最高GPU温度为62摄氏度，CPU峰值温度仅为65摄氏度。这证明了该设备的液冷系统并非噱头，而是其存在的核心理由，具备极高的散热效率。为了进行后续测试，系统配置为Ubuntu 24.04、Nvidia开源驱动610版本、CUDA 13以及VLM Nightly环境，并在测试期间保持更新。所有八张GPU均启用Tensor Parallelism（张量并行）技术，以支持大规模模型的分布式推理。
大模型显存占用与硬件对比分析
测试涵盖多个大型语言模型，其中GLM 5.2拥有433GB权重，支持49,600个token的上下文窗口。该模型加载后占用约738GB显存，占整机784GB可用VRAM的95%。这是目前唯一能在桌面级单台设备中完整容纳此类超大模型的方案。相比之下，此前评测过的DJX Station虽拥有252GB高带宽内存（速度更快），但总容量不足以容纳GLM 5.2。对于较小模型如Quen 3 235B（144GB）和GLM Flash 5.3（约185GB），该设备则处于性能甜点区，既能运行大模型又能为多会话留出空间。
单用户推理速度与首字延迟表现
在基准测试中，使用2048 token提示词生成128 tokens输出。单张RTX Pro 6000上30B参数模型约为100 tokens/秒，而八卡并行下GLM 5.2达到48 tokens/秒，Quen 3 235B为85 tokens/秒。现代模型表现更佳：Deepseek V4 Flash达102 tokens/秒，GLM 5.3为104 tokens/秒，Quen 3.8 Flash Next以126 tokens/秒领先。在提示词处理阶段，Quen 3.8 Flash Next高达12,600 tokens/秒。对于短提示词（2000 token），Flash Next首字延迟仅0.25秒，GLM 5.2接近1秒。当提示词增至128,000 token（相当于整个代码库）时，Flash Next首字延迟为14.5秒，GLM 5.2需50秒。Quen 3 235B在处理超长提示词时出现崩溃，未能完成测试。
长上下文稳定性与功耗策略影响
在128,000 token的超长上下文中，各模型生成速度并未显著下降。Flash Next在长上下文下仍保持约120-122 tokens/秒的生成速度，GLM 5.2也稳定在40-50 tokens/秒左右，显示出极强的上下文处理能力。此外，VLM服务的Prefix Caching（前缀缓存）功能显著加速了重复对话场景：GLM 5.2在16,000 token历史后，开启缓存使首字延迟从5.9秒降至0.83秒（提升7倍）。功耗方面，将功率限制从600瓦降至300瓦对生成速度影响微乎其微：GLM 5.2在300瓦限制下仍能达到111 tokens/秒（对应32用户负载），而在600瓦时仅为轻微差异。值得注意的是，在300瓦限制下，八张GPU总功耗仍高达约1,550瓦（单卡约126瓦），表明系统整体能耗依然巨大，但能效比在限制下表现合理。
功耗限制与硬件通信瓶颈
在测试中，RTX Pro 6000 GPU 的功耗表现揭示了硬件设计的限制。当空闲且加载模型时，GPU 待机功耗约为 700瓦；而在6张卡满载推理时，每张卡约消耗1,700瓦。作者观察到的峰值功耗为 268瓦，这表明在推理过程中，这些显卡主要受限于内存带宽而非计算能力。由于卡间通过 PCIe 总线通信，它们从未接近600瓦的功耗上限。
"Doubling the power limit bought me nothing more than heat and a less stable box."
提高功耗限制并未带来性能提升，反而增加了热量并降低了系统稳定性。此外，GPU 同步数据时需通过 PCIe 传输，这并非 NVLink 那样的高速互联。作者指出这种通信延迟是显而易见的，并表达了对测试 Envy Link（NVLink 的误称）或 A100/H200 等高端硬件的兴趣。这种架构意味着在多卡并行时，通信开销可能抵消额外计算带来的增益。
多卡扩展与模型性能权衡
在多 GPU 环境下，增加显卡数量并不总是能线性提升速度。以 Qwen3-235B 模型为例，在4张卡上使用 Tensor Parallelism (TP=4)时，速度为 58 tokens/秒；而在8张卡上使用 TP=8 时，速度反而降至 37 tokens/秒。这是因为 PCIe 上的 All-Reduce 通信成本超过了额外计算资源带来的收益。
对于较小且能容纳在4张卡上的模型，作者建议运行两个副本（每张卡跑一个），而非在一个8卡集群上运行单个大模型，这样可以服务两倍的用户。在 GLM-5.2 的测试中，官方配置下的速度为 48 tokens/秒；若开启 MTP（多令牌预测），早期测试显示速度可达约 100 tokens/秒，但配置较为复杂。这些案例强调了在部署时需仔细权衡并行策略与通信开销。
生态系统兼容性与新特性支持
尽管这些工作站级 GPU 已存在近两年，但软件生态仍在追赶。例如，GLM-5.3 Flash 在标准 VLM（视觉语言模型）镜像上无法启动。作者尝试了六种不同配置，均因内核错误失败，原因是该模型使用的注意力机制变体尚未被 Blackwell 工作站内核支持。
"It's too new. So, once VLM upstreams it and supports it, you might get slightly different numbers."
这表明新模型特性可能需要等待上游库更新才能获得最佳性能或兼容性。作者指出，一旦支持到位，性能可能会有所不同甚至更好。这提醒用户在使用最新硬件和模型组合时，需关注软件版本的匹配度，避免因内核不支持而导致部署失败。
1000 AI Agent 并发压力测试实战
为了验证系统极限，作者启动了四台机器（Maya, Ravi, Lena, Tom），每台运行多个 Agent 子任务，共同指向 Grandondo 服务器。初始测试中，32个并发Agent（每台机器8个）使 GPU 利用率达到 100%，功耗升至约 185-190瓦，显存使用率达 96GB/96GB。此时系统运行 DeepSeek-V4-Flash，吞吐量约为 3,000 tokens/秒。
随后压力逐步升级： - 128个并发Agent（每台32个）：系统稳定运行。 - 512个并发Agent（每台128个）：利用率保持100%，系统继续处理。 - 1,000个并发Agent：这是极限测试。系统最终成功启动，总吞吐量达到 6,000-7,000 tokens/秒。
在1,000个Agent的负载下，KV Cache 使用率为 41%，错误数为零。虽然首字延迟（TTFT）较高且系统负载较重，但所有任务均完成。在测试期间，总生成 token 数超过 630,000。
不同用户规模下的性能数据对比
作者对五种模型进行了从1到64个并发用户的基准测试，每个用户发送相同的 448 token prompt。以下是 Qwen3.8-Flash 在不同并发数下的每用户吞吐量表现：
| 并发用户数 | 每用户速度 (tokens/秒) |
|---|---|
| 1 | 126 |
| 4 | 90 |
| 8 | 82 |
| 16 | 61 |
| 32 | 37 |
| 64 | 20.6 |
随着用户增加，总吞吐量上升（因为机器生成更多 token），但每用户速度下降。在8个并发时，每个 Agent 获得 82 tokens/秒，这比大多数云端 API 单个用户的速度更快。而在64个并发时，每用户速度降至 20.6 tokens/秒。
对于 GLM-5.2，首字延迟（TTFT）随并发增加显著上升： - 8用户时：1.5秒（Flash模型） vs 5.5秒 (GLM-5.2) - 16用户时：2.5秒 (Flash模型) vs ~9-10秒 (GLM-5.2)
在64用户负载下，Qwen3.8-Flash 的聚合吞吐量达到 530 tokens/秒（此处指单用户视角或特定配置下的峰值，原文语境为对比各模型在64并发时的表现），解码突发速度高达 2,880 tokens/秒。这些数据显示，虽然高并发下单用户延迟增加，但系统整体仍能维持可观的吞吐量。
等待时间与交互流畅度
在测试 GLM-5.2 模型时，首字生成时间（Time to First Open）达到了令人沮丧的 33 秒。这种延迟在当下极度追求效率的环境中显得尤为突兀，正如评测者所言：“我们这些人现在是多么缺乏耐心啊”。尽管等待过程漫长，但系统确实在后台持续工作。“这东西 literally 在为我们编写内容”。对于必须经历这一等待过程的用户，评测者表达了歉意：“GH, I'm sorry you have to go through that”。这种交互体验揭示了当前硬件在处理大规模并发 AI 代理时的瓶颈，即虽然最终能完成任务，但初始响应的滞后性可能影响开发者的即时反馈循环。
性能基准与横向对比评测
为了量化单台机器的实际承载能力，评测者提供了具体的性能指标：“使用正确的模型，16 个开发者对编码代理或一个开发者拥有 16 个代理”。在单台机器的测试中，每个模型能够达到 每秒 60 tokens 的生成速度，且等待时间仅为 2.5 秒。为了提供参照系，评测者引用了 Storage Review 的测试数据：“Storage Review... had the exact same machine as me”。他们在同一台机器上运行了 Claude Code 会话，结果显示：“他们得到了每秒每个用户 39 tokens”（在8个并发会话下）。这一数据与通过 API 访问 Claude Opus 的性能相当。“这大约就是你从 Claude Opus 的 API 中得到的结果”。这一对比证实了本地部署在特定配置下具备与高端云端 API 相媲美的吞吐能力。
目标受众与市场定位分析
关于是否购买此类设备，评测者指出个人开发者需谨慎考虑成本效益：“如果你是一个独立的开发人员... 你最好能从你的工作中赚到不错的钱，或者出租它之类的事情”。对于单人用户而言，这种配置可能略显过剩：“对我来说，这对一个人来说有点杀鸡用牛刀”。然而，对于中小企业团队而言，价值巨大：“主要目标受众显然是企业、小型企业、中型企业”。在团队场景下，8 个代理每个每秒 80 tokens 的速度使得整个代码库能在 14 秒内被处理。评测者强调，这是近期测试过的两台机器之一：“我不觉得我被限制在我能运行多少代理”。对于构建团队式 AI 工作流的个人开发者，这也是一个可行的方案：“如果你是一个人... 嘿，这并不疯狂”。
硬件部署与技术门槛提示
评测者提醒用户注意此类新硬件的维护成本：“这真的是相当新的硬件”。使用者需要适应非稳定版的驱动和软件栈，例如 VLM nightly builds。“你需要习惯每晚的 VLM 构建版本”。部署过程可能需要一定的技术动手能力：“也许要把手弄脏，做一些幕后活动”。虽然 NVIDIA 和 VLM 提供了部署食谱（recipes），但往往需要用户自行调整参数以适应硬件规模。“他们并不总是列出你正在运行的确切内容”。例如，官方食谱可能针对四张 RTX Pro 6000 显卡，用户需手动修改 tensor parallel size（张量并行大小）为 8。评测者分享了自己的经验：“我最近用四块 RTX Pro 6000s 做了那个构建”，并建议用户参考相关教程以完成定制化部署。
结论
Camino Grando以768GB显存确立了本地运行400B+大模型及千级Agent并发的硬件标杆，其液冷散热与能效控制表现优异。然而，PCIe通信瓶颈导致多卡扩展无法线性提升速度，甚至出现8卡性能低于4卡的倒挂现象；新模型兼容性尚不成熟。尽管高并发下首字延迟显著增加，但其吞吐量已媲美云端高端API。该设备并非个人开发者的性价比之选，而是专为具备技术运维能力、追求极致本地化与并发能力的中小企业或团队设计的专用基础设施。