md

QUICKSTART.md

@@ -173,7 +173,7 @@ Do not debug `meshnet-node` until this works.
 
 ```bash
 cd /path/to/neuron-tai
-python3 -m venv .venv-rocm
+python3.12 -m venv .venv-rocm
 source .venv-rocm/bin/activate
 python -m pip install --upgrade pip setuptools wheel
 python -m pip install -e packages/tracker -e packages/node -e packages/p2p -e packages/gateway -e packages/relay
@@ -185,6 +185,9 @@ Keep this separate from a known-good CPU `.venv` until ROCm is verified on that
 machine. ROCm wheels are large and host-runtime-sensitive; a failed ROCm install
 should not break the CPU fallback environment.
 
+Use Python 3.12 for this env. Python 3.14 is currently a bad fit for the
+Qwen3.6/FLA path because `torch.compile` is not supported there.
+
 **Verify PyTorch sees ROCm:**
 
 ```bash
@@ -230,6 +233,9 @@ HF_HOME=/path/to/models .venv-rocm/bin/meshnet-node start \
 - `torch.version.hip is None` means you installed a CPU/CUDA torch build, not ROCm.
 - `torch.cuda.is_available() == False` with a ROCm build usually means host driver,
   permissions, unsupported hardware, or missing runtime libraries.
+- `which meshnet-node` should not point at `~/.local/bin/meshnet-node` for ROCm
+  testing. Run `.venv-rocm/bin/meshnet-node ...` so the node uses the same ROCm
+  PyTorch, `transformers`, and FLA packages you verified.
 - Missing libraries such as `libamdhip64.so`, `libMIOpen.so`, `librocsolver.so`,
   or `libroctx64.so` are host ROCm runtime problems, not meshnet-node problems.
 - Some AMD APUs and consumer GPUs require newer ROCm/Radeon support than server