microsoft/VibeVoice · error · NotImplementedError

{solver_type} is not implemented for {self.__class__}

Error message

{solver_type} is not implemented for {self.__class__}

What it means

solver_type selects the intermediate-solver used inside multistep updates; this scheduler only implements `midpoint` and `heun`. Legacy names `logrho`, `bh1`, `bh2` are silently remapped to `midpoint`; everything else raises NotImplementedError in the constructor. This mirrors upstream diffusers behavior.

Source

Thrown at vibevoice/schedule/dpm_solver.py:280

        self.sigma_t = torch.sqrt(1 - self.alphas_cumprod)
        self.lambda_t = torch.log(self.alpha_t) - torch.log(self.sigma_t)
        self.sigmas = ((1 - self.alphas_cumprod) / self.alphas_cumprod) ** 0.5

        # standard deviation of the initial noise distribution
        self.init_noise_sigma = 1.0

        # settings for DPM-Solver
        if algorithm_type not in ["dpmsolver", "dpmsolver++", "sde-dpmsolver", "sde-dpmsolver++"]:
            if algorithm_type == "deis":
                self.register_to_config(algorithm_type="dpmsolver++")
            else:
                raise NotImplementedError(f"{algorithm_type} is not implemented for {self.__class__}")

        if solver_type not in ["midpoint", "heun"]:
            if solver_type in ["logrho", "bh1", "bh2"]:
                self.register_to_config(solver_type="midpoint")
            else:
                raise NotImplementedError(f"{solver_type} is not implemented for {self.__class__}")

        if algorithm_type not in ["dpmsolver++", "sde-dpmsolver++"] and final_sigmas_type == "zero":
            raise ValueError(
                f"`final_sigmas_type` {final_sigmas_type} is not supported for `algorithm_type` {algorithm_type}. Please choose `sigma_min` instead."
            )

        # settable values
        self.num_inference_steps = None
        timesteps = np.linspace(0, num_train_timesteps - 1, num_train_timesteps, dtype=np.float32)[::-1].copy()
        self.timesteps = torch.from_numpy(timesteps)
        self.model_outputs = [None] * solver_order
        self.lower_order_nums = 0
        self._step_index = None
        self._begin_index = None
        self.sigmas = self.sigmas.to("cpu")  # to avoid too much CPU/GPU communication

    @property
    def step_index(self):

View on GitHub (pinned to 94da20d98b)

Solutions

  1. Set solver_type to "midpoint" (default, cheaper) or "heun" (2nd-order correction, slightly better quality per step).
  2. If you wrote "logrho"/"bh1"/"bh2", note they work but are remapped to midpoint — just use midpoint explicitly.
  3. Strip/normalize whitespace when loading solver_type from user config.

Example fix

# before
sched = DPMSolverMultistepScheduler(..., solver_type="taylor")

# after
sched = DPMSolverMultistepScheduler(..., solver_type="heun")
Defensive patterns

Strategy: validation

Validate before calling

SOLVERS = {"midpoint", "heun", "logrho", "bh1", "bh2"}
assert solver_type in SOLVERS, f"solver_type must be one of {sorted(SOLVERS)}"
sched = DPMSolverMultistepScheduler(..., solver_type=solver_type)

Type guard

def is_supported_solver_type(v) -> bool:
    return isinstance(v, str) and v in {"midpoint", "heun", "logrho", "bh1", "bh2"}

Prevention

When it happens

Trigger: Constructing with `solver_type="taylor"`, `"rdm"`, `"midpoint "` (trailing space), or any string outside {midpoint, heun, logrho, bh1, bh2}.

Common situations: Configs copied from papers or other solver implementations that advertise more solver types; typos; whitespace introduced by YAML string handling.

Related errors


AI-assisted analysis of microsoft/VibeVoice@94da20d98b (2026-08-15). Data as JSON: /api/errors/82e0a3b968f3c846. Report an issue: GitHub.