Yeah, this is partially why in my approach I've done this instead, and not used diffusion model:
1. Convert the state into one shared prompt.
2. Run that shared prompt through the model once.
3. Fork the model’s internal state once per question.
4. Add a different question to each fork.
5. Ask each fork for its next-token scores.
6. Calculate only 64 possible label scores—not the whole vocabulary.
Basically ... skip decode.
Won't be as fast as doing diffusion model parallel across a pile of questions at once, but:
a) let's you use pretty much any existing text model (with some modifications). I've got qwen3.6 moe and qwen3.8 flash next running, am getting gemma4 working now
b) the problem you identified
It's possible I'm getting high on my own supply and misunderstand entirely the whole thing, but it seems to work?
https://github.com/rdaum/eider/commit/9c2d5c049068c33da2a48b...
I don't have the chutzpah to go creating PRs for vLLM to do the same.
> 6. Calculate only 64 possible label scores—not the whole vocabulary.
This I don’t understand though, could you expand this please?
Instead I use a fixed set of up to only 64 single-token labels. At model load, I gather only those 64 rows from the vocabulary head into a small matrix. Each question maps its permitted answers onto some of those labels.
It is a probability distribution conditional on the allowed labels. Calibration is a separate problem that I have to solve still and will be model specific :-) But I do seem to get reasonable answers right now.
So "64" is just in the end the endpoint’s maximum answer-label set. Most questions use only two or three of those rows. And, yeah, some calibration required. WIP on that
So one could pack all of common state, every question, every answer in the same prefill, using attention mask to only let them attend to their logical parent.
Then additionally do position encoding for token based on their logical position rather than physical.
Then the diffusion step also applies an attention mask to prevent bidirectional attention between answers.
What I described was -- we have a bunch of orders to the kitchen, all of which have the same "base" meal but different topics.
> Cook the "base" meal once, divide servings onto multiple plates, then add different toppings to each plate.
vs what you suggest:
> Put the base meal and every topping through the kitchen together, but use some kind of dividers so the toppings never mix up together.
Except.. ok, that analogy is confusing lol.
So I don't see the advantage to their approach until you're up beyond 6 or 7 questions?
Latest commits added gemma4 and instructions. I'll work on making a version of all of this that is standalone and not specific to DGX Spark.