unslothai/unsloth · error · RuntimeError

Subprocess error: {error_msg}

Error message

Subprocess error: {error_msg}

What it means

Raised by ExportOrchestrator._wait_response when the worker sends a structured {'type': 'error', ...} message. This is the export worker's own error report — an exception inside the subprocess (e.g. during merge, GGUF conversion, or safetensors writing) that it caught and forwarded instead of crashing. The chained message (error_msg) is the worker-side root cause.

Source

Thrown at studio/backend/core/export/orchestrator.py:375

        deadline = time.monotonic() + timeout

        while time.monotonic() < deadline:
            remaining = max(0.1, deadline - time.monotonic())
            resp = self._read_resp(timeout = min(remaining, 2.0))

            if resp is None:
                if not self._ensure_subprocess_alive():
                    raise RuntimeError("Export subprocess crashed during wait")
                continue

            rtype = resp.get("type", "")

            if rtype == expected_type:
                return resp

            if rtype == "error":
                error_msg = resp.get("error", "Unknown error")
                raise RuntimeError(f"Subprocess error: {error_msg}")

            if rtype == "log":
                # Forwarded stdout/stderr line from the worker.
                self._append_log(resp)
                continue

            if rtype == "status":
                message = resp.get("message", "")
                # One structured export_progress line per phase (consolidated in the
                # server log, like training/download progress); also shown live.
                if message:
                    logger.info("export_progress", phase = message)
                    self._append_log(
                        {
                            "stream": "status",
                            "line": message,
                            "ts": resp.get("ts", time.time()),
                        }

View on GitHub (pinned to 203007d190)

Solutions

1. Read the error_msg suffix — it is the worker's traceback cause and names the failing step
2. Check free disk space at the export output location (GGUF conversions temporarily need the model size again in scratch)
3. Verify the model checkpoint fully downloaded (all shards present, no .incomplete files) and reload it
4. If the error names an unsupported layer/tensor in GGUF conversion, update the converter or choose a different export type
5. Retry with a smaller quantization_method list to isolate which quant fails

try:
    orch.run_export(export_type, params)
except RuntimeError as e:
    msg = str(e)
    if msg.startswith("Subprocess error:"):
        cause = msg[len("Subprocess error:"):].strip()  # worker-side root cause
        surface_to_user(cause)

When it happens

Trigger: Unsafetensors weights during GGUF conversion; out-of-disk-space while writing merged safetensors; unsupported tensor dtypes/architecture in convert_hf_to_gguf.py; a quantization method the worker cannot run; invalid export params (bad dtype, missing shard files).

Common situations: Disk full in the models/export directory; partial or corrupted model download so a shard fails to load; new/quantized model architecture the bundled GGUF converter does not support; misconfigured export parameters from the UI.

Related errors

• GGUF conversion produced a symlink, refusing to relocate it:
• GGUF conversion produced no files: no .gguf outputs for {abs
• GGUF conversion produced a symlinked Modelfile, refusing to
• Timeout waiting for '{expected_type}' response after {timeou
• Failed to export GGUF model

AI-assisted analysis of unslothai/unsloth@203007d190 (2026-08-15). Data as JSON: /api/errors/a3925808897ea275. Report an issue: GitHub.