一台没有AMD GPU的工作站，连上了一块按小时计费的MI300X。所有操作都通过十二个按标签限定的MCP工具完成——盘点、功耗、重启、硬件扫描、GPU状态、远程执行，全部走这条路。

这块卡来自AMD Developer Cloud，计费1.99美元/小时。工具第一次返回的两项读数都是错的，两次都靠解析输出而不是信任状态字段纠正过来。最后那张格式表与AMD公布峰值有两处不一致，这个不一致本身就是结果，不是附注。

打开网易新闻 查看精彩图片

先决条件：标签决定一切

需要一个已创建GPU实例的AMD Developer Cloud账号。devcloud.amd.com底层是DigitalOcean——同一套v2 API，同样的实例ID——但令牌来自My AMD Team账号，不是个人的DigitalOcean账号。

实例必须打上标签。这个服务器里每一次查找都按tag_name限定范围，所以没打标签的实例对它不可见，而打了标签但属于别人的实例同样不可见。

DIGITALOCEAN_ACCESS_TOKEN放在环境变量里，或放在权限0600的.env文件里，或放在~/ocean.txt里。服务器和ssh-droplet.sh使用同一套查找顺序。实例上需要以root身份配置SSH密钥，全程BatchMode=yes，密钥不对就直接失败，不会停在密码提示上。Python 3需要httpx和python-dotenv装在系统解释器里，不用虚拟环境——.mcp.json用裸python3启动服务器。

显存数字：全部可映射

三张表里的所有内容都是通过MCP服务器用hardware_scan、rocminfo和lspci从机器上读出来的，时间是2026年9月16日。

有两个数字值得单独看。VIS_VRAM等于VRAM：这是大BAR配置，整个显存都可被CPU映射，帧缓冲没有任何部分藏在旧的256MB窗口后面。rocminfo报告了三个GLOBAL池——粗粒度、细粒度和扩展细粒度——每个都是200,998,912KB，这是同一个显存的三种描述方式，不是三份独立分配。

rocmsmi报告的是87，相除得到87.8%。工具做了截断，这里引用的是工具的输出。

“VF”这个标记很关键。这是一块虚拟化的MI300X，不是裸卡：ASD、PFP、MES、SOS这类固件查询返回“Not supported on the given system”，amd-smi看不到分区信息。MEC（32948）、RLC（65）、SDMA（24）、SMC以及RAS/XGMI这些TA则正常报告。

控制平面：十二个工具，按标签限定

get_help是描述其他工具的那个工具，它真正的输出就是整个服务器的形状：一套面向本项目AMD MI300实例的DigitalOcean控制平面，范围限定在打了gemma标签的实例上。

这套工具的设计把“信任状态”这件事从流程里拿掉了。两次错误读数都说明同一个问题：状态字段会骗人，解析出来的输出不会。