TensorCash 挖矿实操：从选硬件到跑出第一份证明

大多数工作量证明，把电烧在了一个没人想要的数字上。TensorCash 不是这样。矿工干的活是一次真实的前向传播——和回答一句提示词时跑的模型推理完全是同一件事——而「这次传播确实发生过」的证明，正是延长链的那样东西。这份工作在变成区块之前，就已经派上了用场。

这篇是把矿工跑起来的实操指南。在挑硬件、敲命令之前，先想清楚你到底想从中拿到什么——这决定了你该怎么跑。

你想怎么挖？

按你打算怎么运行来选路径。三条路跑的是同一套 worker 软件，区别只在于推理需求从哪来、你的应用把请求发到哪。

路径	适合谁	关键开关
提供方 / broker worker	最省事的起点——靠提供方带来的需求赚钱。	`WORKER_MODE=broker` + `BROKER_WS_URL` + `PROVIDER_JWT_TOKEN`。只走出站 WSS，不需要开入站端口。
本地 HTTP + 自建节点	给自己的应用留一个私有端点。	`WORKER_MODE=standalone`，跑一个节点，在 `http://localhost:$HTTP_PORT/v1` 上提供 OpenAI API。
Mac / 本地 / 开发	在笔记本上先试试。	TensorMiner 应用，或 llama.cpp worker（Metal）。

已经在跑业务流量，还是从零开始？ 都行。外部需求不足时，worker 会自己生成提示词（回填），让 GPU 继续挖矿；真实请求一来，它们就在同一次前向传播上挖矿，不多花一分钱。

接下来还有两个选择：用哪张网络（测试网 / 主网），以及由谁来验证你的证明。broker / 提供方 worker 默认把验证委托给提供方；如果你自建节点，就要在本地验证和委托验证之间做选择（第 3 步）。

两种搭法。 不想动手的话，走方案 A——把一段提示词粘进编码 agent（Claude Code、Cursor 等），它会识别你的硬件并把一切配好，动手改任何东西之前都会先问你。想弄懂并掌控每一步，就照方案 B 来。

方案 A：交给编码 agent

把下面这段提示词粘到你的编码 agent 里。先自己读一遍——它会装软件、跑 Docker，而且写好了在做任何不可逆的操作前先征求确认。

You are setting up a TensorCash mining worker on this machine. Work step by step
and ask for confirmation before installing software or running containers.

1. Detect the hardware: OS, CPU architecture, and GPU. For NVIDIA, report the
   compute capability (sm_XX). For Apple, report the chip (M-series) and unified
   RAM.

2. Choose the path:
   - Apple Silicon  -> the native TensorMiner app (Metal). If no signed build is
     available, fall back to the llama.cpp host worker.
   - NVIDIA GPU     -> Docker + vLLM. Pick VLLM_VERSION by architecture:
       Ampere / Ada (sm_80–sm_89, e.g. A100, RTX 30xx/40xx) -> 0.10.0  (prebuilt wheel)
       Hopper       (sm_90, H100/H200)                      -> 0.19.0  (prebuilt wheel)
       Blackwell    (sm_120, B200/GB10/RTX 50xx)            -> 0.19.0, BUILT FROM SOURCE
         against the CUDA-13 NVIDIA PyTorch container (the PyPI wheel is CUDA-12
         and will std::bad_alloc on the first GPU allocation). The first build is slow.
   - No GPU         -> the CPU worker image (tiny model, slow; for testing only).

3. Make sure Docker works:
     docker run --rm hello-world
     # NVIDIA only — must print your GPU:
     docker run --rm --gpus all nvidia/cuda:12.8.0-base-ubuntu22.04 nvidia-smi
   Install Docker (and the NVIDIA Container Toolkit, if needed) if these fail.

4. Ask me which network: testnet (start here) or mainnet.

5. Ask me where the inference should go:
   - To a provider (broker mode): set WORKER_MODE=broker and BROKER_WS_URL +
     PROVIDER_JWT_TOKEN from my provider dashboard; verification is handled by them.
   - To me, as a local model (standalone): set WORKER_MODE=standalone, run the
     local node, and expose the proxy's OpenAI endpoint (HTTP_HOST/HTTP_PORT).
   Also ask whether I want to run my own verifier (full sovereignty: the
   core-miner-validation-api stack with NODE_START_FLAGS=--desktop) or delegate it.

6. Pick a chain-approved mining model: check the explorer
   (testnet: explorer-testnet.tensorcash.org, mainnet: explorer.tensorcash.org)
   and set MODEL_NAME, plus MODEL_COMMIT to pin the approved revision.

7. Set the worker env. Read the capability values straight off the GPU:
     nvidia-smi --query-gpu=name,memory.total,compute_cap --format=csv,noheader
   -> COMPUTE_TYPE=nvidia-<compute_cap>, GPU_MODEL, GPU_MEMORY_GB. Also set
   MAX_MODEL_LEN, GPU_MEM_UTIL, WORKER_CAPACITY. Start the stack.

8. Verify: hit the worker's /health, confirm it connected to the broker (or node),
   curl /v1/chat/completions and show me the reply, then tail the logs until you
   see proofs/shares. Finally, show the log lines proving a share and how to stop it.

跑通了，你就已经在挖矿了——直接跳到跑起来了吗？。想知道它刚才都干了什么，就继续往下看。

方案 B：自己动手

第 1 步：你手上是什么硬件？

你有	用什么	引擎	说明
Apple Silicon Mac（M1–M4）	TensorMiner 应用，或 llama.cpp worker	llama.cpp 跑在 Metal 上	原生 GPU 加速；用应用的话不需要 Docker。
NVIDIA GPU	Docker + vLLM	vLLM（CUDA）	主线路径。版本取决于你的卡——见 vLLM 构建版本。
没有 GPU / 纯粹好奇	CPU worker 容器	llama.cpp（CPU）	小模型，慢。适合在测试网上跑第一次。

后面的步骤都默认你已经选好了一条。用原生应用的 Mac 用户可以跳过 Docker 那一节。

第 1b 步：查清你的 GPU 和 CUDA（NVIDIA）

一条命令就能问出你要填的全部信息：该用哪个 vLLM 构建版本，以及 worker 向 broker 上报的三个能力值。

nvidia-smi --query-gpu=name,memory.total,compute_cap --format=csv,noheader
# e.g.  NVIDIA GeForce RTX 4090, 24564 MiB, 8.9

从左往右对着读就行：

compute_cap → COMPUTE_TYPE = nvidia-<compute_cap>（上面的 8.9 → nvidia-8.9），同时决定你的 vLLM 构建版本（见 vLLM 构建版本）：8.0–8.9 → 0.10.0，9.0 → 0.19.0，12.0（Blackwell）→ 0.19.0，从源码编译。
name → GPU_MODEL（例如 RTX-4090）。
memory.total → GPU_MEMORY_GB（取整到 GB）。

你装的 CUDA 版本（用来填 CUDA_VERSION）就在 nvidia-smi 的输出头部，或者：

nvidia-smi | grep -o 'CUDA Version: [0-9.]*'   # -> CUDA Version: 12.8
nvcc --version 2>/dev/null | grep release      # if the toolkit is installed

用 Terraform 在整个机群上做这件事是另一回事——见文末的机群规模下的 CUDA 探测。

第 2 步：Docker（NVIDIA 与 CPU 路径）

**macOS：**装 Docker Desktop。 **Linux：**装 Docker Engine 和 Compose 插件；用 NVIDIA 的话，再装 NVIDIA Container Toolkit。

先确认能用，再往下走：

docker run --rm hello-world          # prints "Hello from Docker!"
docker compose version               # v2.x

# NVIDIA only — this MUST list your GPU:
docker run --rm --gpus all nvidia/cuda:12.8.0-base-ubuntu22.04 nvidia-smi

如果容器里的 nvidia-smi 看不到你的卡，先把这个问题解决——不解决，下面的一切都跑不起来。

第 3 步：决定你要自主到什么程度

矿工产出证明。证明要先被验证才算数，而链本身跑在节点上。这里面有多少由你自己来跑，你说了算。

级别	你自己跑	验证	从哪开始
委托（最简单）	只跑矿工	由提供方的验证者检查你的证明	`simple-worker`
完全自主	矿工 + 节点 + 自己的验证者	本地跑自己的验证者	`core-miner-validation-api`

委托是最平缓的入口：两个环境变量就能跑起来。完全自主意味着你谁都不用信——节点自己跑，每一份证明也由你自己重新校验一遍。

跑节点、跑验证者各自都是一个话题——见怎么跑一个节点和怎么跑一个验证者。底层其实就是节点上的一个 flag：--desktop 跑本地验证者；--http 让节点指向你委托的远端验证者（VALIDATOR_BASE_URL + VALIDATOR_API_KEY）。

第 4 步：跑起来

找到跟你的硬件、以及上面选定的模式对得上的那一段。

Mac — 原生应用（TensorMiner）

原生应用在 Metal 上跑 llama-server，外加一个跟 broker 通信的小 proxy。到 releases 页面下载最新的 TensorMiner 构建版本。

早期构建还没做公证（notarize），所以双击时 macOS Gatekeeper 会拒绝打开。清一次隔离标记，然后启动：

# Remove the quarantine attribute macOS adds to downloaded, un-notarized apps.
xattr -dr com.apple.quarantine /Applications/TensorMiner.app
open /Applications/TensorMiner.app

（等效做法：右键点应用 → 打开 → 在弹窗里确认一次。）在应用里填上你的 broker URL 和提供方 token，选好模型，启动。

Mac — llama.cpp worker（进阶）

想自己管引擎，就带上 PoW 相关的 flag，用 llama-server 加载一个 GGUF 模型。关键接线在于：它在本地端口提供服务，并把找到的 share 通过 ZMQ 推给栈里的其余组件。

# A registered GGUF model on disk; serve it on Metal with the mining flags.
ZMQ_PUSH_HOST=127.0.0.1 ZMQ_PUSH_PORT=7067 \
PROOF_SAVE_DIR="$HOME/pow_logs" \
./llama-server \
  -m "$HOME/models/your-model.gguf" \
  --host 0.0.0.0 --port 8000 \
  --ctx-size 8192 --parallel 10 --jinja \
  --alias "Qwen/Qwen3-8B"

二进制文件同样没做公证的话，照样清一遍： xattr -d com.apple.quarantine ./llama-server && chmod +x ./llama-server。

NVIDIA — broker / 提供方 worker（最简单）

一个容器，GPU 加速，只走出站连接（WORKER_MODE=broker）。在 deployments/simple-worker/ 目录下：

cp .env.example .env
# Edit .env — the only two REQUIRED values:
#   BROKER_WS_URL=wss://broker.tensorcash.org/v1/ws   (from your provider dashboard)
#   PROVIDER_JWT_TOKEN=eyJ...                          (from your provider dashboard)
docker compose up -d
docker compose logs -f

把上报能力的那几个变量（COMPUTE_TYPE、GPU_MODEL、GPU_MEMORY_GB）设成跟你的卡一致，broker 才能正确派活——见环境变量速查。

NVIDIA — 完全自主

一套栈同时拉起节点、vLLM 后端、miner proxy，外加你自己的验证者：

sudo \
  API_KEY=change-me MODEL_API_KEY=change-me \
  RPC_USER=user1 RPC_PASS=pass1 \
  CUDA_VERSION=12.8.0 VLLM_VERSION=0.10.0 \
  WORKER_MODE=standalone \
  CHAIN_NAME=tensor-test \
  NODE_START_FLAGS=--desktop \
  docker compose -f deployments/docker-compose/core-miner-validation-api/docker-compose.yaml up --build

WORKER_MODE=standalone 从你的本地节点取任务，而不是从 broker 取；NODE_START_FLAGS=--desktop 启动本地验证者。VLLM_VERSION 按你的 GPU 从 vLLM 构建版本里挑。

把算力用在自己身上（本地 HTTP）

如果你选了本地模型那条路，miner-proxy 本身就讲 OpenAI API——所谓「自己用这份算力」，无非是把应用指过来。standalone worker 上，调 http://localhost:$HTTP_PORT/v1/chat/completions。proxy 监听 HTTP_PORT——simple-worker / llama 路径上是 8080，完整 compose 栈上是 8030。发给链上钉住的挖矿模型的每一条提示词都在挖矿；请求其他模型则按普通推理处理（只做审计，不产 share）。空闲时间由回填填满。

别把它暴露出去。 除非你确实打算对外开放，否则保持 HTTP_HOST=127.0.0.1（只监听本机）：proxy 注册的是开放的 OpenAI 风格路由，CORS 也很宽松，所以一旦设成 HTTP_HOST=0.0.0.0，就要用防火墙或带鉴权的反向代理挡在前面。（broker 模式的 worker 绑本机只是留个调试口子——真实流量是从 broker 进来的。）

没有 GPU — CPU worker

和 broker worker 那条路同一个形状，只是换成 CPU 镜像和一个小模型。慢，但足以把整条链路从头到尾验证一遍。在 deployments/simple-worker-cpu/ 目录下：

cp .env.example .env   # set BROKER_WS_URL + PROVIDER_JWT_TOKEN
docker compose up -d && docker compose logs -f

第 4b 步：设定挖矿模型

只有用链上已批准的模型挖矿，你的证明才算数。用别的模型挖出来的证明，没有任何验证者会接受。

在区块浏览器上看哪些模型已获批准——先从测试网开始：

测试网：explorer-testnet.tensorcash.org
主网：explorer.tensorcash.org

（也可以直接问节点：bitcoin-cli getmodelslist 列出已登记的模型，复制一个模型哈希，再用 bitcoin-cli getmodelregistrationstatus <model_hash> 查它的状态——getmodelinfo 会返回完整记录。）

设定方式有两种：

启动时——worker 启动时带的环境变量：

MODEL_NAME=Qwen/Qwen3-8B          # an approved model
MODEL_COMMIT=9c925d64...          # pin the exact approved revision (recommended)

运行时——通过 proxy 切换，不用重启：

curl -s http://127.0.0.1:8080/v1/mining/active-model \
  -H "Authorization: Bearer internal-secret" \
  -H "Content-Type: application/json" \
  -d '{"model_name":"Qwen/Qwen3-8B","model_commit":"9c925d64..."}'
# GET the same path to see what's active now.

能钉住 commit 就钉上：批准是按 revision 走的，不钉住的模型名可能漂到一个链上没批准的构建上去。

环境变量速查

你真正会去动的那些变量。表里给的是常见取值；能力字段会由 worker 上报给 broker 用于派活匹配，所以要按你的真实硬件来填。

变量	含义	常见取值
`BROKER_WS_URL`	broker 的 WebSocket 端点（broker 模式）。必填。	`wss://broker.…/v1/ws`
`PROVIDER_JWT_TOKEN`	你的提供方 token，必须以 `eyJ` 开头。必填。	`eyJ...`
`WORKER_MODE`	`broker`（走提供方）或 `standalone`（走本地节点）	`broker`
`HTTP_HOST` / `HTTP_PORT`	proxy 提供 OpenAI API 的地址和端口（本地 HTTP 用法）	`127.0.0.1` / `8080`
`MODEL_NAME`	worker 服务并挖矿所用的模型（必须已获链上批准）	`Qwen/Qwen3-8B`
`MODEL_COMMIT`	钉住已批准的模型 revision	`9c925d64...`
`MAX_MODEL_LEN`	最大上下文长度	`8192`
`GPU_MEM_UTIL`	允许 vLLM 占用的显存比例	`0.9`
`COMPUTE_TYPE`	上报的架构字符串	`nvidia-8.9`
`GPU_MODEL`	上报的显卡型号	`RTX-4090`
`GPU_MEMORY_GB`	上报的显存容量	`24`
`WORKER_CAPACITY`	上报的并发任务数	`4`
`CUDA_VERSION`	基础镜像的 CUDA tag	`12.8.0`
`VLLM_VERSION`	vLLM 构建版本（见对照表）	`0.10.0`
`CHAIN_NAME`	自建节点接哪张网：`tensor-test` / `tensor`	`tensor-test`
`NODE_START_FLAGS`	`--desktop`（本地验证者）/ `--http`（委托出去）	`--desktop`

测试网还是主网。 broker worker 本身不认网络——你的 BROKER_WS_URL 和 token 指向哪个 broker，就是哪张网，所以先接测试网的 broker。自建节点的话，网络由节点的 CHAIN_NAME 决定：测试网是 tensor-test，主网是 tensor。先从测试网开始。 主网挖矿是有协调的——把真家伙指过去之前，先跟你的提供方确认一下。

vLLM 构建版本（TensorCash 镜像兼容性）

下面是 TensorCash worker 镜像按 GPU 架构构建并钉住的 vLLM 版本，不是对 vLLM 的通用建议。没有自动检测，请自己对着卡选：

你的 GPU	架构	`VLLM_VERSION`	怎么装
A100、A6000、RTX 30xx/40xx	Ampere / Ada（sm_80–sm_89）	`0.10.0`	预编译 wheel，装上就能用。
H100、H200	Hopper（sm_90）	`0.19.0`	预编译 wheel。
B200、GB10、RTX 50xx	Blackwell（sm_120）	`0.19.0`	从源码编译，基于 CUDA-13 的 NVIDIA PyTorch 容器。

Blackwell 镜像为什么要走源码编译：TensorCash 的 Blackwell 镜像跑在 NVIDIA 的 CUDA-13 PyTorch 容器上，而预编译的 CUDA-12 vLLM wheel 混进这个 CUDA-13 运行时后，会在第一次分配 GPU 显存时崩掉。所以这个镜像基于容器自带的 CUDA-13 PyTorch 从源码编译 vLLM。第一次编译很慢——之后的运行会直接复用镜像。

这条只针对 TensorCash 的镜像构建，不是对上游 vLLM 的一般性判断——上游近期的发行版默认发 CUDA-12.9 的 wheel，同时也提供 CUDA-13 的二进制。自己做镜像的话，按 vLLM GPU 安装文档来（例如源码编译时的 torch_cuda_arch_list），并保证版本和 TensorCash 的 PoW 补丁集对得上。

跑起来了吗？

三步检查，按顺序来：

# 1. The worker is up.
#    Broker / simple-worker publishes NO host port by default — check from inside
#    (use the CPU service name `simple-worker-cpu` on the no-GPU image):
docker compose ps
docker compose exec simple-worker curl -fsS http://127.0.0.1:8080/health
#    Local-HTTP / full compose stack (port published) — from the host:
curl -fsS http://127.0.0.1:8030/health
#    Sovereign full stack: the node's model API answers on :8050.

# 2. It connected. In the logs you should see the broker handshake (broker mode)
#    or "ZMQ listener started (standalone mode)" (standalone):
docker compose logs -f

# 3. Proofs are flowing. Watch for proof/share lines, or the files written to
#    your proof directory (PROOF_SAVE_DIR, e.g. ~/pow_logs).

一个 share 越过当前的难度目标，它就成了区块，奖励会打进你的钱包。接受与否在设计上就是统计性的：网络检查的是你这份证明的某个性质，而不是把整次前向传播重跑一遍。这道门槛拦的是 grinding——不干活却伪造证明——而不是诚实输出中那些正常的波动。（另有两篇配套文章详细讲了这为什么是安全的。）

跟它对话 — 推理愉快

miner-proxy 是一个兼容 OpenAI 的入口。走本地 HTTP 这条路时你已经把 HTTP_PORT 映射出来了，任何客户端指过去就行——工作量证明搭的是同一次传播的便车，你完全察觉不到（模型名换成你当前激活的那个）：

curl -s http://localhost:8030/v1/chat/completions \
  -H "Authorization: Bearer internal-secret" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Qwen/Qwen3-8B",
    "messages": [{"role": "user", "content": "Say hello in one sentence."}],
    "max_tokens": 64
  }'

正常的回复就是标准的 OpenAI 结构——{"choices":[{"message":{"role":"assistant","content":"Hello! …"}}], …}；用 GET /v1/models 可以列出已加载的模型。端口：完整 compose 栈是 8030，simple-worker / llama 路径是 8080。broker / simple-worker 上 proxy 端口不会映射出来——改成在容器里跑（docker compose exec simple-worker curl -s http://127.0.0.1:8080/v1/chat/completions …），或者在 compose 文件里把 8080:8080 那行取消注释。不注入 PoW 的裸推理在 vLLM 的 :8000 上。默认密钥是 internal-secret，launch_linux.sh 那套栈上则是 super-secret-token。

如果它回了你一句话，那你就是在同一次前向传播上，既提供了推理，又挖了矿。推理愉快。

让这一切成立的那道检查

挖矿和验证是同一条流水线的两端。你的 worker 产出的证明不需要你凭信任接受——它是可重放的，验证者也是开源的。拿它跑一遍你自己产出的 share，再跑一遍别人产出的：任何人都能确认是哪个模型干的活、重放结果是否吻合，全程不必信任矿工。

如果你把验证委托了出去，提供方替你跑的正是这一步——哪天你不想再信任他们，就把自己的验证者拉起来，把 --http 换成 --desktop。其他什么都不用改。

再往深一层

光靠上面的内容就足够挖矿，这一部分你可以永远不看。它是留给想调优 worker、或者要管一整个机群的人的。

miner-proxy 到底在干什么

miner-proxy 是一个 worker 的大脑。它是横在推理引擎前面的一个小服务，同时干三件事：

提供推理。 它对外暴露兼容 OpenAI 的 API（/v1/chat/completions、/v1/completions、/v1/responses、/v1/models），把请求转发给 :8000 上的 vLLM。在客户端看来，它和一个 OpenAI 端点毫无区别。
注入工作量证明。 它给每一次前向传播挂上当前的挖矿上下文——区块哈希、VDF 输出、tick 和难度目标。vLLM 的 PoW 采样器在生成过程中就把证明算出来，所以出答案和出证明是同一次传播，不是两次。
收集并分发证明。 一个 ProofCollector 通过 ZMQ 从采样器接收完成的证明。够区块级别的解会作为结果转发出去；没到区块目标的 share 走自己的通路。具体发到哪，取决于模式：

	Standalone（自建节点）	Broker（提供方路由）
挖矿任务（新区块 / VDF）来自	你本地的 core-node，走 ZMQ	broker，走 WebSocket
结果 / share 发往	你的 core-node	broker
入站端口	到节点的本地 ZMQ	没有——只走出站 WSS

proxy 还负责跑 VDF prover、缓存证明（通过 /v1/proof/{id} 提供，方便验证者来取），并暴露 /health 和 /status。

挖矿配置：流量、回填，以及什么会被提交

**问题在于：**挖矿需要前向传播，但你不一定随时都有用户在发提示词。空转的 GPU 什么也挖不到。

解法是回填。 真实流量掉到目标线以下时，proxy 会自己生成合成提示词，让 GPU 保持忙碌、让证明持续产出。它会朝着 MIN_ACTIVE_REQUESTS 个并发请求的热池补足，每 MONITOR_INTERVAL 秒检查一次。回填的提示词打向你链上钉住的挖矿模型，并且（默认）带一个 /no_think 指令，好让输出停留在共识熵门限所预期的区间里。

可调的旋钮：

变量	默认值	作用
`MINING_ENABLED`	`true`	总开关。broker 模式下设为 `false` 就只做推理，不跑 PoW。
`MIN_ACTIVE_REQUESTS`	`32`	热池目标值；低于它就触发回填。
`MONITOR_INTERVAL`	`1.0`	两次回填检查之间的秒数。
`MINING_DISABLE_THINKING`	`true`	在回填提示词后面追加 `/no_think`。
`MINING_STALE_THRESHOLD_SECONDS`	`60`	超过这么久没收到新区块就暂停回填。
`MINING_SOLUTION_COOLDOWN_SEC`	`0`	找到解之后可选的冷却暂停。

「只提交回填的，还是全都提交？」 这由模型决定，不由某个 flag 决定。规则是：

来自你链上钉住的挖矿模型的证明会被提交，作为 share 或解——不管它来自回填还是真实用户的提示词。挖矿模型上的真实流量等于白挖。
来自其他任何模型的证明只做审计：缓存下来备查，绝不提交。

所以并不存在「只挖回填」这个开关。如果你想让面向用户的推理不参与挖矿、只让回填算数，那就跑两个模型：给用户用一个没钉住的模型（走审计通路），另外单独跑一个链上钉住的挖矿模型，只让回填打过去——也就是双后端方案（MINING_VLLM_ENABLED=true，在 :8001 上再起一个实例）。除此之外，最简单也最高效的做法，就是一个钉住的挖矿模型，既服务用户，又在每一次传播上挖矿。

机群规模下的 CUDA 探测（Terraform）

单机上，前面那条命令就够了。到了整个机群，你会希望它自动完成。老实说有两条路：

我们的机群目前怎么做：根本不在 Terraform 里探测。CUDA、vLLM 和目标架构都固化进了容器镜像 tag，每个节点组通过 Kubernetes 的 nodeSelector（或主机名匹配）钉死在已知硬件上。镜像里的 COMPUTE_TYPE 是写死的 ENV。简单直白，代价是镜像和节点得靠人工保持一致。

**更地道的「探测并写入」做法：**让 Terraform 跑探测，把结果喂给 worker 的环境变量。只要 apply 能够到那台 GPU 主机，data "external" 就管用：

data "external" "gpu" {
  program = ["bash", "-c", <<-EOT
    read name mem cc < <(nvidia-smi \
      --query-gpu=name,memory.total,compute_cap \
      --format=csv,noheader,nounits | head -n1 | tr ',' ' ')
    jq -n --arg n "$name" --arg m "$mem" --arg c "$cc" \
      '{gpu_model:$n, gpu_memory_gb:$m, compute_type:("nvidia-"+$c)}'
  EOT
  ]
}

# then inject into the worker:
#   COMPUTE_TYPE  = data.external.gpu.result.compute_type   # e.g. nvidia-8.9
#   GPU_MODEL     = data.external.gpu.result.gpu_model
#   GPU_MEMORY_GB = data.external.gpu.result.gpu_memory_gb

data "external" 是在 Terraform 所在的机器上执行的，所以它适合裸金属，或者你用 SSH 包一层能到达的节点。对于 Terraform 无法执行命令的云实例，就把同样的探测放进 user_data / cloud-init：用 nvidia-smi --query-gpu=...,compute_cap 写出 /etc/worker.env，再让容器去读——和单机那条命令做的事完全一样，只是挪到了开机阶段。两种做法都能让这份映射只有一个来源，不必在镜像 tag 和节点标签之间重复维护。

下一步去哪

参与入口——所有参与方式都在这里：/zh-Hans/build/
在本地端到端跑一遍——regtest 指南：/docs/regtest/
核心节点 API / RPC——/docs/core-node/api/ · /docs/rpc/
自己跑节点 / 验证者——怎么跑一个节点 · 怎么跑一个验证者
验证者 API——/docs/verifier/api/
已批准的模型与区块历史——区块浏览器：主网 · 测试网
为什么它是安全的——验证白皮书

这份工作不是一次白烧的哈希。它是一次有人真正想要的前向传播。

本文由 Imosuke Takakuni 以化名撰写。