Smart Model Recommender (LMSL / TDS SDK)

Most model-picking in ComfyUI happens in a dropdown, from memory, with a vague sense that the 14B thing you downloaded three months ago might be better than the 1.3B one but also might not run. Smart Model Recommender flips the question. Instead of "is this checkpoint okay?", it asks "I want to do Wan 2.1 text-to-video on this machine - what have I got that works?"

It's the sibling of SmartModelAdvisor in the same pack, and the two are opposite directions of one query: the Advisor validates a choice you made; the Recommender reads your intent and proposes one.

What it needs, plainly

The Recommender is a read-only window onto the TDS SDK - the same optional dependency the Advisor uses. If that SDK isn't sitting in custom_nodes/TDS (or reachable via TDS_ROOT), every query comes back empty with a "not ready" reason. The repo's English README doesn't tell you this; the Chinese one inside the package does.

With it working, the flow is: at startup the pack probes your hardware, scans your weight directories, and runs a feasibility match on everything. The Recommender then filters that cached catalog by intent and returns what's left, ordered by whether it fits.

How the filtering actually works

domain is a plain string matched for exact equality against the SDK's catalog domain - diffusion, text_encoder, vae, llm, other are the shapes you'll see. Leave it empty for no domain filter.

tags is the interesting part. It's a comma-separated string, and multiple tags are ANDed, not ORed. Each token is matched two ways: against a small built-in family table (wan2.2, wan2.1, wan, flux, qwen, ltx, hunyuan, sdxl, sd3, lightx2v, umt5, vae, lora, clip), and as a plain substring of the filename. So wan2.1,t2v narrows to the Wan 2.1 text-to-video main model, not the i2v one - but only because t2v appears in the filename. Case is handled; a rename that drops t2v kills the filter.

The candidate pool starts from items judged ok or tight, plus - when include_offload is on - items judged offload, meaning too big for your VRAM but runnable with layered offloading inside your VRAM-plus-half-RAM ceiling. Sorting puts ok/tight first, then the SDK's score, then footprint descending: among equally feasible options, the bigger model usually looks better. Duplicates by filename are dropped, then the list is cut to limit.

Inputs and outputs

• domain (default diffusion) - the coarse category.
• tags (default wan2.1,t2v, which is the author's own example of a well-formed intent) - comma-separated, AND-matched, and it accepts full-width commas too if you're typing in Chinese.
• limit (1–10, default 3) - how many picks.
• include_offload (default on) - whether slow-but-runnable counts as recommended.

Two string outputs. primary is just the filename of the top pick - empty string if nothing matched - which is the value you'd copy into a loader. report is the readable listing (intent, hit count, each pick's status, footprint, headroom) with the raw JSON appended, so you get both forms in one wire.

That's the whole node. It doesn't load anything, doesn't change your graph, doesn't touch your loader's dropdown. You read the report and go pick.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/mxh678988/lmsl-smart-offload
export TDS_ROOT=/path/to/TDS   # only if it isn't in custom_nodes/TDS

No pip dependencies in the pack itself. Restart, then confirm the bridge came up - state=ready in the log, or check the read-only endpoint directly:

curl -s 'http://127.0.0.1:8188/lmsl_sdk/recommend?domain=diffusion&tags=wan2.1,t2v&limit=3'
curl -s http://127.0.0.1:8188/lmsl_sdk/status

The /recommend route takes the same arguments as the node, and tags works either as ?tags=a,b or repeated ?tags=a&tags=b. Poking it with curl before wiring anything into a graph is the fastest way to tell a node bug from an SDK problem.

Where it bites

Empty picks are a filter problem, not a bug. If report says no candidates after filtering, work backwards: is domain spelled exactly as the catalog spells it? Most model families land in diffusion, but LoRAs and upscalers often end up in other - filtering by domain alone and expecting a LoRA gets you nothing. Turn on include_offload before assuming a big model is out of reach.

offload in the status column is a speed warning. With include_offload on by default, the top pick may be the biggest thing you own that technically runs - with most of it in system RAM, where every trip is an order of magnitude slower than VRAM. Read the status, not just the rank.

It reruns every time. Like its sibling, this node returns NaN from IS_CHANGED, so it never caches - correct for a live query, mildly hostile to the cache around it if you park it mid-chain.

Nobody's talking about it. This pack has no community discussion attached - no threads, no reports, no prior art. The ranking is the SDK's feasibility score with a size tiebreak, which is not the same as "which model looks best." Treat it as a filter over your own library that saves you scrolling a dropdown, and keep your own taste in the loop.