BitDance Sampler

Forget everything your KSampler muscle memory tells you. BitDance isn't a diffusion UNet or DiT that scrubs noise out of a latent over N steps - it's an autoregressive model that generates the image as a sequence of binary tokens, one chunk at a time, exactly like a language model writes a sentence. BitDance Sampler is the node that does that generation, and it's the heart of the whole pack. In the starter workflow it sits between the text encode nodes and the VAE decode, wired with model and vae from the loader, positive and negative from text encoding, and resolution from the BitDance Resolution node.

How it actually samples

The mechanism matters here because it explains every setting. The Qwen3 text encoder produces your prompt embeddings, which get prepended to special image-start tokens. The model then works in blocks of 64 visual tokens at a time - the parallel_num layout baked into the architecture. For each block, a binary diffusion head (vision_head) predicts the tokens in continuous space, and torch.sign() snaps them into the discrete binary states that the model's binary tokenizer understands (a vocabulary of 2^256 states, per the author's explainer). The LLM consumes those tokens, updates its KV cache, and the process repeats block by block until the whole latent grid - e.g. 16×16 tokens for a 1024px image - is filled. That's why a 20-step image here isn't 20 denoising steps; it's 20 diffusion sub-steps per block, repeated across every block.

That's also why the sampler matters so much: BitDance puts binary tokens on a continuous system, and it needs an Euler solver to decode the hidden tokens properly. The author is emphatic that euler_maruyama is the one to use - it's the default for a reason. euler is offered as an alternative, but the "generic face" artifacts people complain about in BitDance threads trace right back to using the wrong solver.

The inputs that matter

• sampler_name - euler_maruyama (default). Keep it.
• num_sampling_steps - default 20, up to 200. The author's guide recommends 20–50; the step count multiplies the per-block work, so this is the biggest lever on both quality and time.
• guidance_scale - default 7.5 (range 1–20). Below 1.0 is disabled territory; the README notes the node now builds separate attention masks for positive/negative prompts of different lengths, which fixed a crash at guidance_scale > 1.0.
• num_images - 1 to 8 per run. On a consumer card, be honest with yourself about 8.
• seed - standard 64-bit seed, default 42.

Output is a single bitdance_latent - and this is a trap if you're used to ComfyUI: it is not a standard latent. You cannot feed it to a normal VAE Decode. It's the token sequence plus the grid geometry, and only BitDance VAE Decode can turn it into pixels.

VRAM reality

This is a 14B LLM running generation, so it's heavy, and the pack's history is mostly VRAM war stories. The Feb 2026 update specifically fixed severe OOM crashes on 16–24 GB cards at 1024px+: the sampler now force-unloads models between the text encoding, sampling, and decode phases instead of trying to hold everything at once. Expect real-world numbers like ~12 minutes per image on a 4090 and under a minute on a 5090, both reported in the launch threads. If you still OOM, drop to a 1024x1024 or smaller preset, cut steps to 20, and make sure the loader's quantization is fp8_e4m3fn_scaled - that's the combination the pack is tuned for.