VLA Model Catalog
The 'which robot model can I actually run' cheat sheet, as a node
- model_info_json
- checkpoint
- policy_type
- backend
The VLA space moves fast and it's full of papers that never become runnable things. VLA Model Catalog is the pack's answer to that chaos: a curated, up-to-date map of official VLA runtimes and checkpoints, with the crucial distinction between robot-ready models and research-only architecture papers baked right into the menu. It's a reference node - pick a model, get its facts - and it saves you from the hour of Googling that each of these models would otherwise cost.
The single input is a model dropdown with 15 curated entries, including:
- SmolVLA 450M - the one the pack points beginners at for small consumer hardware
- X-VLA 0.9B - cross-embodiment
- π0 base / π0-FAST / π0.5 base - the Pi family
- GR00T N1.7 3B - cross-embodiment
- WALL-OSS - mixture-of-experts VLA
- MolmoAct2 - action reasoning
- VLA-JEPA, LingBot-VA, FastWAM, EO-1, EVO-1, OpenVLA-OFT, Octo - the rest of the zoo
The value is in the metadata that comes back. Four outputs: model_info_json (the full record - what it is, what it's for, what it needs), checkpoint (the actual weights path), policy_type (what kind of policy it is), and backend (which runtime it expects - LeRobot, openpi, GR00T, JAX, etc.). That last one matters because it tells you where to run it: the pack keeps heavy policy runtimes in isolated environments, and this node is how you look up which environment a given model belongs to.
The curation is the point, and the pack is deliberately careful about it: "Available" means a supported isolated runtime/checkpoint path exists. Entries marked as base models or architecture-only research still require embodiment-specific fine-tuning and transforms before they'll control anything - the catalog says so per entry, and you should trust it. lerobot/smolvla_base, for example, is a great fine-tuning starting point but is not a universal zero-shot controller.
Installing it
In the main pack - ComfyUI Manager (search "ComfyUI VLM nodes") or:
cd ComfyUI/custom_nodes
git clone https://github.com/gokayfem/ComfyUI_VLM_nodes
python -m pip install -r ComfyUI/custom_nodes/ComfyUI_VLM_nodes/requirements.txt
No extra dependencies - it's a lookup node, it downloads nothing and runs nothing.
Common issues
- You picked a base model expecting it to drive a robot → the most common misunderstanding. The catalog labels these for a reason: base/architecture-only entries are research artifacts until fine-tuned for your embodiment. Read
model_info_jsonbefore wiring anything to a policy server. - "Where do I run this?" →
backendanswers that. SmolVLA wants a LeRobot environment, π0 wants its LeRobot extra, GR00T wants the Isaac-GR00T stack. Match the backend, don't guess. - Checkpoint path doesn't exist locally →
checkpointis the upstream source, not a promise of local files. You still download weights through the relevant runtime.
Honestly, for most readers the actionable takeaway is in the first entry: start with SmolVLA on small hardware. The catalog exists so you don't have to trust your memory of what this week's paper claimed.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| model | COMBO | SmolVLA 450M — fast consumer hardware | 15 options: SmolVLA 450M — fast consumer hardware, X-VLA 0.9B — cross-embodiment, π0 base — generalist VLA, π0-FAST — tokenized fast actions, π0.5 base — open-world generalization, GR00T N1.7 3B — cross-embodiment, +9 |
Outputs (4)
| Name | Type | Description |
|---|---|---|
| model_info_json | STRING | — |
| checkpoint | STRING | — |
| policy_type | STRING | — |
| backend | STRING | — |