Nodo. Pruebas

Pruebas que puedes hacer para comprobar la correcta configuración.

Información general

Es muy frustrante cuando parece que hiciste todo bien y aun así no logras entrar en la época.

Mejor revisarlo todo varias veces.

¡Atención! En el texto puede haber errores, ya que no entiendo mucho sobre la configuración de servidores. Más correcto sería decir "realmente no entiendo", pero estas pruebas me ayudaron.

Verifica la correcta instalación de las claves

Sucede que, como resultado de que varias personas configuraron los nodos o confundiste el comando para asignar la Consensus Public Key, terminas con claves diferentes en el Nodo y en la Red.

Así seguro no entrarás en la época. ¡Revisa!

Verificación de la Consensus Key

🔎 PASO 1. Averiguar la Consensus Public Key en el nodo

¡Atención! La verificación se realiza en el servidor donde está el ML Node (o Network Node, aún no lo tengo claro, ya que por ahora ambos nodos están en el mismo servidor para mí).

docker exec node wget -qO- "http://127.0.0.1:26657/status" | jq -r '.result.validator_info.pub_key.value'

obtendrás aproximadamente:

{
  "value": "AD+NQncKPBzqw0u8KcSmlIMqogg7i4nhDfLIgIkGYiY="
}

👉 Copia el campo "value".+

🔎 PASO 2. Averiguar la Consensus Public Key en la red

¡Atención! La verificación se realiza en el servidor donde creaste las claves. Es decir, no en el Network Node ni en el ML Node.

Ahora mira qué considera la red como tu clave:

curl -s http://node2.gonka.ai:8000/chain-api/productscience/inference/inference/participant/gonka1yplcem8kfe6vm06t4sl8fskm0we2zslxxu90ta | jq

¡Atención! Sustituye lo que está en negrita por la dirección de tu clave caliente.

Recibirás:

"AD+NQncKPBzqw0u8KcSmlIMqogg7i4nhDfLIgIkGYiY="

Como resultado obtendrás una respuesta como esta:

{ "participant": { "index": "gonka1yplcem8kfe6vm06t4sl8fskm0we2zslxxu90ta", "address": "gonka1yplcem8kfe6vm06t4sl8fskm0we2zslxxu90ta", "weight": -1, "join_time": "1771876365572", "join_height": "2792955", "last_inference_time": "0", "inference_url": "http://203.168.252.195:8000", "status": "ACTIVE", "coin_balance": "0", "validator_key": "7GEr4jV5GjCv+C+jKOq3Eh4bwxMVs7kafm7tcWP0EOo=", "consecutive_invalid_inferences": "0", "worker_public_key": "", "epochs_completed": 0, "current_epoch_stats": { "inference_count": "0", "missed_requests": "0", "earned_coins": "0", "rewarded_coins": "0", "burned_coins": "0", "validated_inferences": "0", "invalidated_inferences": "0", "invalidLLR": { "value": "0", "exponent": 0 }, "inactiveLLR": { "value": "0", "exponent": 0 }, "confirmationPoCRatio": null }

Nos interesa el valor "validator_key".

🔎 PASO 3. Compáralos. Deben ser idénticos

Deben coincidir. Y en nuestro caso no coinciden. No es de extrañar que no entremos en la época ))

Las razones de esta discrepancia pueden ser variadas. Creo que ustedes mismos sabrán cómo solucionarlo.

Cómo arreglarlo: Creo que lo entenderás por ti mismo. No es difícil.

---------------------------------------------------------------------------

Averigua el modelo en tu nodo

curl http://localhost:5000/v1/models

¡Atención! Si no ves nada, es posible que tu ML Node esté en otro puerto. Posibles opciones:

5000
8000
8080
9200

es decir, simplemente reemplaza este número en el comando.

Respuesta esperada:

root@mlnode-308:/app# curl http://localhost:5000/v1/models {"object":"list","data":[{"id":"Qwen/Qwen3-235B-A22B-Instruct-2507-FP8","object":"model","created":1772106402,"owned_by":"vllm","root":"/root/models/Qwen3-235B-A22B-Instruct-2507-FP8","parent":null,"max_model_len":240000,"permission":[{"id":"modelperm-f9056e19f4b1494c9854c8df9887394b","object":"model_permission","created":1772106402,"allow_create_engine":false,"allow_sampling":true,"allow_logprobs":true,"allow_search_indices":false,"allow_view":true,"allow_fine_tuning":false,"organization":"*","group":null,"is_blocking":false}]}]}root@mlnode-308:/app#

¡Atención! Después de ejecutar este comando entrarás en el contenedor Docker. Para seguir trabajando con la línea de comandos en el servidor, debes salir del contenedor con el comando: exit

Averiguar la configuración del nodo

docker exec -it mlnode-308 cat /proc/238/cmdline | tr '\0' ' '

Respuesta esperada:

/usr/bin/python3.12 -m vllm.entrypoints.openai.api_server --model Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 --dtype float16 --port 5001 --host 0.0.0.0 --max-model-len 240000 --enable-auto-tool-choice --tool-call-parser hermes --tensor-parallel-size 4 --pipeline-parallel-size 2 --enable-expert-parallel --quantization fp8 --gpu-memory-utilization 0.846 --kv-cache-dtype fp8 --swap-space 4 --enforce-eager --cpu-offload-gb 4 --model /root/models/Qwen3-235B-A22B-Instruct-2507-FP8 --served-model-name Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 root@ecs-99605001-024:~#

¡Atención! Necesitas sustituir mlnode-308 por el nombre de tu nodo. Si lo olvidaste, puedes averiguarlo con el comando:

docker compose ps

Respuesta esperada- alguno de estos:

Puedes mostrar los nombres de todos los contenedores:

docker ps --format '{{.Names}}'

Respuesta esperada

Estado de la GPU

curl http://localhost:8080/api/v1/gpu/devices | jq

Respuesta esperada:

Verifica la configuración declarada

Comprobamos la correcta configuración del nodo:

Muestra con qué ajustes está tu ML Node. Probablemente se ejecuta en el servidor ML Node (si los tienes separados).

¡Atención! Estos parámetros se dan como ejemplo. Seguro están desactualizados. A ti te será diferente.

Verificación del nodo con parada

Detén el nodo

curl -sS -X POST "http://127.0.0.1:8080/api/v1/stop" -H "Content-Type: application/json"
sleep 3

Respuesta esperada:

{"status":"OK"}

Comprueba el estado del nodo

curl -sS "http://127.0.0.1:8080/api/v1/state"

Respuesta esperada:

{"state":"STOPPED"}root@submodel-sxA100-19-14:~/gonka/deploy/join#

Si ves otra cosa, vuelve a ejecutar el paso de detener el nodo.

Ejecuta la Prueba Forzada del nodo

BLOCK_HEIGHT=$(curl -s "http://node1.gonka.ai:8000/chain-rpc/status" | jq -r '.result.sync_info.latest_block_height')
BLOCK_HASH=$(curl -s "http://node1.gonka.ai:8000/chain-rpc/status" | jq -r '.result.sync_info.latest_block_hash')

curl -sS -X POST "http://127.0.0.1:8080/api/v1/pow/init/generate" \
  -H "Content-Type: application/json" \
  -d "{
  \"node_id\": 0,
  \"node_count\": 1,
  \"block_hash\": \"D3470A4DDA3D4173BE7C7A55AF52323C19CAC8307DB492CFD004D0C83561068B\",
  \"block_height\": 2753612,
  \"public_key\": \"7GEr4jV5GjCv+C+jK0q3Eh4bwxMVs7kafm7tcWP0E0O=\",
  \"batch_size\": 1,
  \"r_target\": 10.0,
  \"fraud_threshold\": 0.01,
  \"params\": {
    \"dim\": 1792,
    \"n_layers\": 64,
    \"n_heads\": 64,
    \"n_kv_heads\": 64,
    \"vocab_size\": 8196,
    \"ffn_dim_multiplier\": 10.0,
    \"multiple_of\": 8192,
    \"norm_eps\": 1e-5,
    \"rope_theta\": 10000.0,
    \"use_scaled_rope\": false,
    \"seq_len\": 256
  },
  \"url\": \"http://api:9100/v1/poc-batches\"
}"
echo

Respuesta esperada

Consulta el progreso de la prueba en los logs

docker logs mlnode-308 --tail 50 -f

En unos minutos (normalmente 5–15) debería aparecer el resultado final. Tras completar el PoC:

Respuesta esperada:

Es importante que las CUDA se carguen al 100%

Para salir de la prueba pulsa la combinación CTRL+C

Habilitar el nodo

curl -sS -X POST "http://127.0.0.1:9200/admin/v1/nodes/node1/enable" -H "Content-Type: application/json"

Respuesta esperada

{"message":"node enabled successfully","node_id":"node1"} root@submodel-sxA100-19-14:~/gonka/deploy/join#

Comprueba el estado de tu nodo:

curl http://localhost:8080/api/v1/state

Respuesta esperada:

root@ecs-99605001-024:# curl http://localhost:8080/api/v1/state {"state":"INFERENCE"}root@ecs-99605001-024:#

Averigua el estado PoV de tu nodo:

curl http://localhost:8080/api/v1/pow/status

Respuesta no esperada:

"detail":"Cannot run POW because MLNode is currently in ServiceState.INFERENCE mode. Please stop ServiceState.INFERENCE first."}root@ecs-99605001-024:~#

Cuál es la "respuesta esperada" aún no lo sé ))

Verificación de contenedores

Después de arrancar, lo primero es asegurarse de que los parámetros que elegiste para tu node-config.json hayan funcionado en mlnode

Iniciamos los logs del contenedor mlnode

docker logs -f --tail=200 mlnode-308

Si vemos que el modelo se cargó como en la captura, en general podemos salir del contenedor con la combinación CTRL+C

Iniciamos los logs del contenedor node

docker logs -f --tail=200 node

Se ejecuta en el Network Node.

Si el nodo no se había sincronizado, deberíamos ver la descarga de "chunks" del blockchain

625 - cantidad total, 160 - último cargado

salir del contenedor con la combinación CTRL+C

Comprueba la sincronización del nodo con la red

curl -s "http://127.0.0.1:9200/admin/v1/setup/report" | jq '.checks[] | select(.id == "block_sync")'

Respuesta esperada

Es decir, aquí el número debería ser pequeño. Es el tiempo en segundos desde la creación del último bloque.

Comprueba el bloque actual de la red

curl -sS http://node1.gonka.ai:8000/chain-rpc/status | jq -r '.result.sync_info.latest_block_height'

Comprobar el bloque en el que está nuestro nodo

Por ahora no sé cómo )

Y compáralos. Deberían estar cerca.

Lista de verificación para entrar en la época

Ayuda a entender en qué dirección buscar el problema.

curl -s http://localhost:9200/admin/v1/setup/report | jq '.checks[] | {id,status,message}'

Respuesta esperada:

La flecha roja marca el campo de verificación que FAIL absolutamente todos tienen. Este parámetro PASS solo lo tienen los master-nodes de Gonka (eso creo).

La flecha azul señala el campo que tú puedes tener FAIL - si aún no has entrado en ninguna época.

Enlaces

Artículo en Telegram: Gonka - Puesta en marcha. O mineros en busca de rentabilidad. PARTE_1
Artículo en Telegram: Gonka - Puesta en marcha. O mineros en busca de rentabilidad. PARTE_2
Gonka Documentation FAQ https://gonka.ai/FAQ/#how-do-i-fix-errno-validator-signing-info-found-when-starting-from-a-state-sync-snapshot

FIN

AnteriorContenedor Docker SiguienteComandos útiles

Última actualización hace 4 días

hashtagInformación general

hashtagVerifica la correcta instalación de las claves

hashtagVerificación de la Consensus Key

hashtag🔎 PASO 1. Averiguar la Consensus Public Key en el nodo

hashtag🔎 PASO 2. Averiguar la Consensus Public Key en la red

hashtag🔎 PASO 3. Compáralos. Deben ser idénticos

hashtagAverigua el modelo en tu nodo

hashtagAveriguar la configuración del nodo

hashtagEstado de la GPU

hashtagVerifica la configuración declarada

hashtagVerificación del nodo con parada

hashtagDetén el nodo

hashtagComprueba el estado del nodo

hashtagEjecuta la Prueba Forzada del nodo

hashtagConsulta el progreso de la prueba en los logs

hashtagHabilitar el nodo

hashtagComprueba el estado de tu nodo:

hashtagVerificación de contenedores

hashtagIniciamos los logs del contenedor mlnode

hashtagIniciamos los logs del contenedor node

hashtagComprueba la sincronización del nodo con la red

hashtagComprueba el bloque actual de la red

hashtagComprobar el bloque en el que está nuestro nodo

hashtagLista de verificación para entrar en la época

hashtagEnlaces

Información general

Verifica la correcta instalación de las claves

Verificación de la Consensus Key

🔎 PASO 1. Averiguar la Consensus Public Key en el nodo

🔎 PASO 2. Averiguar la Consensus Public Key en la red

🔎 PASO 3. Compáralos. Deben ser idénticos

Averigua el modelo en tu nodo

Averiguar la configuración del nodo

Estado de la GPU

Verifica la configuración declarada

Verificación del nodo con parada

Detén el nodo

Comprueba el estado del nodo

Ejecuta la Prueba Forzada del nodo

Consulta el progreso de la prueba en los logs

Habilitar el nodo

Comprueba el estado de tu nodo:

Verificación de contenedores

Iniciamos los logs del contenedor mlnode

Iniciamos los logs del contenedor node

Comprueba la sincronización del nodo con la red

Comprueba el bloque actual de la red

Comprobar el bloque en el que está nuestro nodo

Lista de verificación para entrar en la época

Enlaces