BOOGU: Load Turbo Pipeline

BOOGULoadTurboPipeline loads the distilled member of the Boogu family: Boogu-Image-0.1-Turbo, a text-to-image model that gets you a usable image in around four inference steps instead of fifty. Same ~10B diffusion core, same Qwen3VL encoder, but step-distilled so it trades a bit of refinement for roughly an order of magnitude less compute per image. First impressions threads on release noted how clean the outputs were "for just 4 steps" - and how synthetic they could look. That's the honest trade: fast and great for iterating on a composition, not the final 4K pass.

Distillation is a well-worn pattern by now - SDXL Turbo, Lightning, Z-Image Turbo all did the step-count collapse - and the rule that keeps getting people burned applies here too: fewer steps does not mean you can keep your old settings. A distilled model has much of the guidance baked into its weights, so cranking guidance scales and steps back up past what the model wants mostly just burns the image and doubles render time. On the turbo pipeline, trust the defaults in BOOGUGenerate (low steps, guidance in the model) rather than your base-model habits.

What it does

Same loader class as Base and Edit, different model folder: it builds a BooguImageTurboPipeline from ComfyUI/models/boogu/Boogu-Image-0.1-Turbo/ and outputs the shared pipeline type for BOOGUGenerate. Two things distinguish it from the other loaders, both visible once you reach Generate:

• Text-to-image only. The pipeline raises an error if you connect an input image - the turbo variant was distilled for pure T2I. Don't feed it edit jobs.
• DMD-aware sampling. BOOGUGenerate exposes use_dmd_student_inference and dmd_conditioning_sigma specifically for this pipeline (Distribution Matching Distillation-style student inference, off by default). Experiment with the toggle if you're chasing a quality/speed sweet spot; most people leave it off.

The inputs

Identical shape to its siblings: dtype (default bf16 - keep it), device (cuda, or cuda:N), enable_model_cpu_offload for when VRAM is tight, and optional force_reload to drop the cached pipeline after changing dtype/device. The single output, pipeline, wires into BOOGUGenerate. Because the loader caches per variant, running a Turbo pipeline alongside a Base or Edit one in the same graph is fine - they're separate cache entries.

Installing

cd ComfyUI/custom_nodes
git clone https://github.com/boogu-project/ComfyUI-Boogu

or grab it from ComfyUI Manager (search "Boogu"). Then the two things Manager won't do: install the standalone boogu package (pip install -e /path/to/Boogu-Image) and drop the model folder at ComfyUI/models/boogu/Boogu-Image-0.1-Turbo/. Note the README's model listing also mentions a separate turbo LoRA (boogu_image_turbo_lora_rank_128_bf16) - that's for the native ComfyUI workflow; the legacy pipeline folder path handles the turbo weights itself.

Common issues

• ModuleNotFoundError: No module named 'boogu' - the recurring one: the standalone package is a required install, not optional.
• "Resolved model path does not exist" - folder must be exactly ComfyUI/models/boogu/Boogu-Image-0.1-Turbo/; extra_model_paths.yaml won't help this legacy loader.
• Error if you connect an image - that's the T2I-only guard doing its job. Remove input_image; if you need Boogu editing, that's the Edit pipeline's job.
• Results look washed out or oversaturated - you're probably running turbo with base-model settings. Drop the steps, leave the guidance near the defaults, and let the distillation do its thing.

And the perennial note: this pack is the legacy path. Boogu is natively supported in current ComfyUI (files from Comfy-Org/Boogu-Image, including fp8 and quantized variants that this custom node can't run), and the README's advice for most users is to use that instead. The turbo loader is the right call when you specifically want the old pipeline-folder workflow - or want a four-step iteration loop without moving to native nodes.