Architecture Name
SDAR2.X
Parent issue
#7
Motivations
Autoregressive language models generate tokens sequentially, which limits decoding parallelism and increases inference latency. Standalone parallel decoding explores whether a language model can generate multiple tokens concurrently without depending on a separate target model for verification.
SDAR2.X continues the SDAR research line and explores whether its block-parallel training and decoding mechanisms can be made more general and reusable. The goal is to study possible improvements in parallel generation while preserving a clean causal history and stable persistent model state.
SDAR2.X and DSpark address different stages of the same broader research direction. DSpark uses a parallel drafting backbone instantiated with DFlash, while DFlash cites SDAR among related block-diffusion approaches. This suggests a possible, rather than established, path for applying ideas explored in SDAR2.X through DSpark. Whether this transfer is useful will need to be evaluated experimentally.
Parent issue #7 represents the temporal placement of SDAR2.X in the dLLM research direction. It does not imply that SDAR2.X technically inherits the PrefiAll architecture.
Our hypothesis is that a model can generate and evaluate multiple provisional tokens in parallel while advancing its persistent state only with committed tokens. This separation may support efficient parallel generation without allowing uncommitted predictions to corrupt the causal history.
Proposed Architecture
The initial SDAR2.X study uses a recent Qwen-series model family as its testbed and explores a native block-parallel generation approach.
SDAR2.X maintains two types of token states:
- Committed prefix: validated tokens that form the persistent causal context and are allowed to update the model's persistent inference state.
- Provisional block: candidate tokens generated in parallel. Positions inside this block may exchange information, but they do not immediately modify persistent state.
After each generation step, only a valid left prefix of the provisional block is committed. The remaining provisional tokens are discarded or regenerated. Model-specific attention, caching, and state-management components are preserved where possible and adapted only when required by block-parallel generation.
The initial investigation will cover:
- Direct block-parallel training.
- Multiple parallel block sizes.
- Confidence-based and adaptive commit lengths.
- Sequential left-prefix commitment.
- Fresh-window regeneration.
- Commit-only persistent-state and cache management.
SDAR2.X focuses on the standalone model architecture and decoding algorithm. Application through DSpark is treated as a possible downstream direction rather than a confirmed integration path. The relationship among DSpark, DFlash, and SDAR motivates us to examine whether selected SDAR2.X mechanisms can be adapted to DSpark-compatible inference workflows.
Preliminary results (if any)
An early prototype from the SDAR research line, built on a recent Qwen-series model, has completed a limited set of internal standalone-generation tests. The current observations are preliminary feasibility signals only and are not sufficient to establish robustness or generality. Matched autoregressive baselines, controlled ablations, and end-to-end speed measurements have not yet been completed. Therefore, no final quality or efficiency claim is made at this stage.
Experiments Plan
Phase 1: Correctness and feasibility
- Verify block-parallel training and inference.
- Confirm that provisional predictions do not corrupt persistent state.
- Test repetition, termination, cache consistency, and long-generation stability.
- Reproduce the current prototype from documented configurations.
Phase 2: Matched baseline comparison
Compare SDAR2.X with the corresponding autoregressive model using the same model scale, checkpoint initialization, evaluation data, hardware, batch size, and generation settings.
The first controlled experiment will use one manageable model configuration. Larger model scales will be evaluated only after the baseline protocol is stable.
Phase 3: Architecture and decoding ablations
- Compare multiple parallel block sizes.
- Compare fixed and adaptive commit lengths.
- Evaluate confidence thresholds and scheduling strategies.
- Compare sequential prefix commitment with fresh-window regeneration.
- Evaluate alternative state-update and block-attention configurations.
Phase 4: Quality and efficiency evaluation
Quality evaluation will cover representative reasoning, mathematics, coding, and instruction-following tasks.
Efficiency measurements will include:
- Time to first token and inter-token latency.
- Tokens per second and end-to-end generation time.
- Average committed tokens per generation step.
- GPU memory usage.
Phase 5: Application and integration through DSpark
Where technically appropriate, selected SDAR2.X mechanisms may be adapted to a DFlash-compatible form and evaluated through DSpark. This exploratory stage will examine whether parts of the standalone approach can be integrated into practical inference workflows without changing their core semantics.
The integration study will measure compatibility, generation correctness, latency, throughput, scheduling overhead, and the additional engineering cost introduced by deployment.
Success criteria
The experiments will provide evidence in favor of the proposal if they demonstrate:
- Correct and stable block-parallel generation.
- A reproducible quality-efficiency trade-off against a matched autoregressive baseline.
- Identifiable effects from block size and commit strategy.
- Preliminary evidence of a technically feasible integration path from SDAR2.X to DSpark through DFlash-compatible mechanisms.
Exact quantitative thresholds, datasets, checkpoints, and hardware configurations will be declared before the controlled experiments and recorded in the corresponding implementation pull request.
Architecture Name
SDAR2.X
Parent issue
#7
Motivations
Autoregressive language models generate tokens sequentially, which limits decoding parallelism and increases inference latency. Standalone parallel decoding explores whether a language model can generate multiple tokens concurrently without depending on a separate target model for verification.
SDAR2.X continues the SDAR research line and explores whether its block-parallel training and decoding mechanisms can be made more general and reusable. The goal is to study possible improvements in parallel generation while preserving a clean causal history and stable persistent model state.
SDAR2.X and DSpark address different stages of the same broader research direction. DSpark uses a parallel drafting backbone instantiated with DFlash, while DFlash cites SDAR among related block-diffusion approaches. This suggests a possible, rather than established, path for applying ideas explored in SDAR2.X through DSpark. Whether this transfer is useful will need to be evaluated experimentally.
Parent issue #7 represents the temporal placement of SDAR2.X in the dLLM research direction. It does not imply that SDAR2.X technically inherits the PrefiAll architecture.
Our hypothesis is that a model can generate and evaluate multiple provisional tokens in parallel while advancing its persistent state only with committed tokens. This separation may support efficient parallel generation without allowing uncommitted predictions to corrupt the causal history.
Proposed Architecture
The initial SDAR2.X study uses a recent Qwen-series model family as its testbed and explores a native block-parallel generation approach.
SDAR2.X maintains two types of token states:
After each generation step, only a valid left prefix of the provisional block is committed. The remaining provisional tokens are discarded or regenerated. Model-specific attention, caching, and state-management components are preserved where possible and adapted only when required by block-parallel generation.
The initial investigation will cover:
SDAR2.X focuses on the standalone model architecture and decoding algorithm. Application through DSpark is treated as a possible downstream direction rather than a confirmed integration path. The relationship among DSpark, DFlash, and SDAR motivates us to examine whether selected SDAR2.X mechanisms can be adapted to DSpark-compatible inference workflows.
Preliminary results (if any)
An early prototype from the SDAR research line, built on a recent Qwen-series model, has completed a limited set of internal standalone-generation tests. The current observations are preliminary feasibility signals only and are not sufficient to establish robustness or generality. Matched autoregressive baselines, controlled ablations, and end-to-end speed measurements have not yet been completed. Therefore, no final quality or efficiency claim is made at this stage.
Experiments Plan
Phase 1: Correctness and feasibility
Phase 2: Matched baseline comparison
Compare SDAR2.X with the corresponding autoregressive model using the same model scale, checkpoint initialization, evaluation data, hardware, batch size, and generation settings.
The first controlled experiment will use one manageable model configuration. Larger model scales will be evaluated only after the baseline protocol is stable.
Phase 3: Architecture and decoding ablations
Phase 4: Quality and efficiency evaluation
Quality evaluation will cover representative reasoning, mathematics, coding, and instruction-following tasks.
Efficiency measurements will include:
Phase 5: Application and integration through DSpark
Where technically appropriate, selected SDAR2.X mechanisms may be adapted to a DFlash-compatible form and evaluated through DSpark. This exploratory stage will examine whether parts of the standalone approach can be integrated into practical inference workflows without changing their core semantics.
The integration study will measure compatibility, generation correctness, latency, throughput, scheduling overhead, and the additional engineering cost introduced by deployment.
Success criteria
The experiments will provide evidence in favor of the proposal if they demonstrate:
Exact quantitative thresholds, datasets, checkpoints, and hardware configurations will be declared before the controlled experiments and recorded in the corresponding implementation pull request.