Nodes/VLM_nodes/VLA Model Catalog
ComfyUI Node Runs on cloud

VLA Model Catalog

The 'which robot model can I actually run' cheat sheet, as a node

By gokayfem·Created 3 years ago·Updated 9 days ago· 583
VLA Model Catalog
    • model_info_json
    • checkpoint
    • policy_type
    • backend
    modelSmolVLA 450M — fast consumer hardware

    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_json before wiring anything to a policy server.
    • "Where do I run this?"backend answers 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 locallycheckpoint is 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.

    CategoryVLM Nodes/Robotics

    Inputs (1)

    NameTypeDefaultDescription
    modelCOMBOSmolVLA 450M — fast consumer hardware15 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)

    NameTypeDescription
    model_info_jsonSTRING
    checkpointSTRING
    policy_typeSTRING
    backendSTRING