Lens / Lens-Turbo Sampler (T2I)

LensTurboSampler is the second half of the Lens pack, and it does exactly one thing: take the pipeline from LensTurboLoader, run your prompt through it, and hand you back an IMAGE. No KSampler tricks, no model patching, no upscaling - one prompt in, one image out. The interesting part is that the defaults are the recipe. Lens-Turbo is a distilled model with a narrow operating window, and this node's defaults are tuned to that window. If you respect them, you get a 4-step image in about twelve seconds on a 3090. If you don't, you get mush.

The inputs that matter

• prompt - multiline, plain natural language. This model's text encoder is a 20B LLM, not a CLIP pair, so it wants sentences, not tag soup. That's a real behavioral difference from SD/Flux-era prompting.
• num_inference_steps - default 4, and that's a floor you want to respect for the Turbo model. The tooltips spell out the full menu: Turbo = 4, Lens (RL) = 20, Lens-Base = 50.
• guidance_scale - default 1.0 for Turbo. Same story: Lens RL and Lens-Base want 5.0. There's no "crank CFG for more adherence" here - this model was distilled to run at one specific setting.
• base_resolution - the long-edge target, default 1440, range 256–4096 in steps of 16. The pipeline derives the actual (H, W) from this plus the aspect ratio. One small trap: the README still says 1024, but the shipped node and the upstream model card default to 1440 - trust the node.
• aspect_ratio - a fixed menu: 1:1, 16:9, 9:16, 4:3, 3:4, 3:2, 2:3, 21:9, 9:21. No free-form dimensions.
• seed - plain integer; set it if you want to reproduce.
• negative_prompt - the trap that will bite you. At the Turbo default of CFG 1.0, it is completely ignored - the code only forwards it when guidance_scale > 1.0 and the pipeline variant accepts the kwarg. If you came from SDXL or Flux, you're used to negative prompts mattering. Here they're a no-op unless you bump guidance.

Output is a standard image (IMAGE tensor, float32 in [0,1]) - wire it into SaveImage or anything else that eats images. Full graph is three nodes: LensTurboLoader → LensTurboSampler → SaveImage.

Why the recipe is the recipe

Lens-Turbo is a 4-step distilled model, and distillation changes the rules. The KB's distillation essay puts it plainly: every distillation technique trades quality for speed, and the distilled model only behaves when you run it at its training-time settings. That's why CFG sits at 1.0 and negative prompts go dead - the model was trained to produce a finished image in a few large jumps, not to be steered mid-flight. If you want the steering, switch the loader's repo_id to microsoft/Lens (the RL-tuned variant) and set the sampler to 20 steps / CFG 5.0. That's the "best quality" path this pack offers, at the cost of a few extra seconds and much heavier memory pressure.

Mechanically, the node is a thin wrapper: it builds a CUDA generator from your seed, forwards prompt, resolution, steps, CFG, and (conditionally) negative prompt to the pipeline, then converts the returned PIL image into a ComfyUI tensor. It also releases CUDA cache and prints VRAM diagnostics around each call, so if something OOMs, the log tells you exactly which stage died. Don't be alarmed if the first sample after a fresh ComfyUI start takes a couple of minutes - that's the loader's cold start (~2 min on a 3090), not this node. Every image after that hits the loader cache and runs at full speed.

Install and gotchas

Installation is shared with LensTurboLoader - same pack, same four bash scripts, same ~58 GB of gated model downloads, same 48 GB RAM requirement. See the loader page for the full walkthrough; the short version is that this pack is not drop-in, and the kernels package bug, the gated HF repos, and Microsoft's habit of deleting Lens releases all apply here identically. Also worth knowing: the Lens weights are released by Microsoft for research purposes only, so this whole pack lives in "local tinkering" territory, not product deployment.