Golem 上挂出的容量还不是已经付款的任务

把 CPU 线程、内存和磁盘挂到 Golem，只说明你愿意提供这些资源。请求者真的把任务派过来，以及派过来的任务有没有变成 GLM，是后面的两步。容量、任务计数和付款不能互相代替。

这几项分别是什么

安装说明里的 YA_RT_CORES、YA_RT_MEM、YA_RT_STORAGE 分别是共享的线程数、内存（GiB）和磁盘（GiB）。镜像自带的默认值很小，文档要求你改成真正想共享的数量，并给宿主机留余量。默认报价写的是每线程每小时 0.1 GLM，文档同时说按当前市场这可能偏高，要自己对照 Stats 上的提供者列表调整。报价存在提供者数据里，不是监控上的收入。

golemsp status 的 Tasks 段给出近 1 小时已处理、近 1 小时进行中，以及累计已处理，并写明含失败。这些是工作次数，不是 GLM。Golem Stats 首页还有全网“正在为请求者计算”的提供者数量，那是网络尺度，不是你这台机器的账单。

监控上能看到的是节点名称、CPU 型号、核心数、在线标记，以及滚动 24 小时和累计 GLM。它不列出每一单任务。

要核对什么

• 在状态或安装配置里读出你实际挂出的核心、内存和磁盘，不要用机器的全部硬件代替。
• 看近 1 小时进行中和已处理是否为 0。0 表示这段状态采样里没有对应任务，不是“容量等于收入”。
• 累计已处理包含失败。失败次数不能当成收款次数。
• 回到监控：GLM 栏没有数字就是未知，不要因为核心数大于 0 就填收入。

接下来怎么分支

• 容量很大但任务计数一直是 0：先做 离线与连通检查，包括虚拟化设备和网络。报价过高也只会让请求者绕开你，监控无法证明这一点。
• 任务计数在增加但 GLM 仍空着：付款和余额见 GLM 付款和容量。不要用任务次数乘默认 0.1 来估算到账。
• GLM 有数字但和“挂出的核心数”不成比例：核心数不是工时。两项 GLM 的读法见 滚动 24 小时和累计。

举例

举例，不是实测：配置写成 4 线程、8 GiB 内存、40 GiB 磁盘，状态里近 1 小时已处理 0、进行中 0、累计已处理 0。这表示这次状态采样没有任务工作。它不表示滚动 24 小时 GLM 是 0；那一栏若缺失，仍是未知。全网图表上的提供者人数也不能填进你的收入。

相关工具

在 Golem 项目页 只保存你要盯的节点。免费每项目 5 台已保存设备，Pro 50 台。一台机器下多看几个公开字段不另占名额。