[Engine] Problem with timeouts when loading a large model: Startup_wait_expired

When loading local models with a size of about 180 GB, the error “Startup_wait_expired” appears.

It’s just that there isn’t enough time, and the loading fails due to a timeout.

In Strata version 0.2.1 · Engine 0.1.46, it was enough to adjust the timeout in the file \Strata\host\server\native-control.mjs from 300 to 600, and the problem disappeared — the model started loading.

In Strata version 0.2.6 · Engine 0.1.50, to fix the problem, you have to edit several files.

Is it possible to increase the timeouts in advance or even move this parameter to the settings so that you don’t have to fix it with each engine update?

Thanks for the issue. To keep the tracker readable, every item needs an area prefix in the title and the parts of the issue form filled in. This one is missing:

Start the title with its area: [Engine], [GUI], [TUI], [Benchmark], [Docs] or [Other], then a short description. Example: "[Engine] decode stops after 2 minutes".

Edit the issue (title and description) and this note goes away on its own. If it is still missing parts in 5 days it will be closed, which is not a rejection: fix it and comment /reopen.

Details: CONTRIBUTING.md

Thanks, this follows the format now.

Same here with a 177 GB Q8_0 (Linux, CUDA, 2× A5000): cold start ~950 s. Open PR #3817 makes the wait configurable with
STRATA_ENGINE_READY_S and lifts the 600 s limits in runner.py and runtime.py. Patching those three places locally works.

GUI: the start wait follows the model's size, as `strata launch` does…

GUI: ask the installed Control for the start wait it actually takes, …

control: the operation record takes a long start wait too, and the te…

GUI: ask for the longer wait only when all three of a Control's ceili…

GUI: ask the installed Control for the start wait it actually takes, …

control: the operation record takes a long start wait too, and the te…

GUI: ask for the longer wait only when all three of a Control's ceili…

I am encountering the same problem with Strata Desktop 0.2.7 and CUDA engine 0.1.52 on Windows 11. Diagnosed with the help of AI

System configuration:

GPU: NVIDIA RTX 4080, 16 GB VRAM
RAM: 64 GB
Model: Qwen3.8-Flash-Next IQ3_S (GSQ-RCO)
Context: 65,536 tokens
Resident expert budget: initially 41 GiB, subsequently reduced to 32 GiB
GPU expert cache: automatic

Observed behaviour:

The desktop GUI repeatedly reports Startup_wait_expired, although the underlying engine continues initialising.

During troubleshooting, I observed:

The engine initially required approximately 330 seconds to report ready.
Subsequent attempts continued loading for more than 800 seconds without becoming ready.
After reducing the resident expert budget to 32 GiB, the engine eventually reported ready after approximately 694 seconds.
The server began listening on 127.0.0.1:18501, confirming that it had reached its API-ready state.
However, the GUI continued reporting Startup_wait_expired, and the engine subsequently began a controlled shutdown.

The 32 GiB configuration change was verified in both the persistent tuning configuration and the native instance used by the GUI.

Code investigation:

I examined the installed host/server/native-control.mjs and found two separate timeout mechanisms:

The control.start() call uses a 300-second default wait, with a maximum of 600 seconds where engine_ready_s applies.
The subsequent GUI health-check loop uses a fixed 300,000 ms deadline.

The GUI awaits control.start() before entering the health-check loop, so simply extending the latter deadline may not address the initial Startup_wait_expired error.

Suggested improvement:

Could the startup timeout be exposed in the desktop GUI's Expert settings, with a configurable value such as 1,200 seconds?

Ideally, the setting would apply consistently to the runtime startup and GUI readiness checks, avoiding manual patches after application updates.

Update: Successful workaround for `Startup_wait_expired` on Windows — Strata 0.2.7

I have now successfully resolved the startup problem and have Qwen3.8-Flash-Next IQ3_S running under the native Strata Desktop GUI.

The GUI reports Ready, and the runtime confirms:

app-1: ready
http://127.0.0.1:18500
config/launch verified
generation checked

The runtime controller is running with --startup-wait 1200.0.

Root cause

Strata 0.2.7 has multiple independent timeout limits. Increasing the timeout in native-control.mjs alone is insufficient because the Control management and journal layers enforce additional 600-second limits.

The underlying strata_control/runtime.py already supports startup waits up to 1,800 seconds through MAX_START_WAIT = 1800, but some higher-level components still enforce 600 seconds.

Changes required

1. host/server/native-control.mjs

At approximately line 308, changed the control.start() timeout to:

control.start(instance.profile,{waitSeconds:1200})

At approximately line 337, changed the GUI health-check deadline from 300,000 to 1,200,000 milliseconds:

const deadline=Date.now()+1200000;

2. control/strata_control/management.py

At approximately line 203, changed the start-wait validation from:

wait = _seconds(wait, 0, 600, "start wait")

to:

wait = _seconds(wait, 0, 1800, "start wait")

3. control/strata_control/journal.py

At approximately line 133, changed the direct runtime-start wait range to:

"wait_s": (0, 1800) if kind == "runtime.start" else

At approximately line 135, changed the startup-wait validation to:

"startup_wait_s": (1, 1800)

Errors encountered while isolating the issue

Changing only the desktop timeout resulted in:

Start wait must be finite seconds in 0..600

After updating the management validation, the next error was:

Direct runtime intent has an invalid timeout

Both errors were caused by additional timeout validation limits outside the GUI code.

Model configuration

Windows 11
Strata Desktop 0.2.7
CUDA engine 0.1.52
NVIDIA RTX 4080 (16 GB VRAM)
64 GB system RAM
Qwen3.8-Flash-Next IQ3_S (GSQ-RCO)
65,536-token context
Resident expert budget: 32 GiB

I also reduced the resident-expert budget from the automatically generated 41 GiB to 32 GiB using Expert settings. The original budget exceeded the free physical RAM reported during startup. However, reducing this budget alone did not resolve the startup timeout.

Verification

After applying the timeout changes, restarting Strata Desktop and loading the model through the GUI:

The model reached Ready in the desktop interface.
strata runtime status --profile app-1 reported ready.
The runtime confirmed that its configuration and launch were verified and generation was checked.
The engine was listening on 127.0.0.1:18500.
The GUI successfully retained ownership of the running engine.

Suggested upstream fix: Centralise the startup timeout configuration and validation so the desktop GUI, management layer, journal and runtime all use consistent limits.

Ideally, expose the startup timeout in Expert settings, with support for up to 1,800 seconds, matching the existing MAX_START_WAIT constant.

This would avoid users having to patch three installed source files, especially since application updates are likely to overwrite those changes.

I have backed up the original files, and JavaScript/Python syntax validation passed. The workaround is functioning, although I have not yet completed an end-to-end chat or external API inference test.

Update

Startup workaround succeeds but that engine 0.1.52 still self-stops on batched inference. Seems similar to a different issue, #2386

Thank you, and thanks to the people who patched it locally. The app waited a flat 300 seconds for a model start, while strata launch has scaled the wait with the model's size since 0.2.5. Fixed on our side; the fix ships in the next update (0.2.8). The app now waits five minutes for models up to 40 GB, and ten minutes plus about eight seconds per GB above 40 beyond that (a 45 GB model about 640 s, a 177 GB one about 28 minutes), up to what the installed Control accepts, and keeps the engine's own ready time above it. This is PR #3817 (miketgv), ported with the author kept.

GUI: the start wait follows the model's size, as `strata launch` does…

GUI: ask the installed Control for the start wait it actually takes, …

control: the operation record takes a long start wait too, and the te…

GUI: ask for the longer wait only when all three of a Control's ceili…

Thanks to everyone who patched this locally, and to miketgv for PR #3817. Fixed in 0.2.8: the app now waits five minutes for models up to 40 GB, and ten minutes plus about eight seconds per GB above that, as strata launch does. Update the app and run strata update. Closing; reopen if a big model still times out.

Navigation Menu

Repository navigation

[Engine] Problem with timeouts when loading a large model: Startup_wait_expired #4191

Update: Successful workaround for `Startup_wait_expired` on Windows — Strata 0.2.7

Root cause

Changes required

Errors encountered while isolating the issue

Model configuration

Verification

Update

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

[Engine] Problem with timeouts when loading a large model: Startup_wait_expired #4191

Description

Activity

github-actions commented on Oct 26, 2026

github-actions commented on Oct 26, 2026

const-apex commented on Oct 27, 2026

rob-4x4 commented on Oct 28, 2026

Update: Successful workaround for Startup_wait_expired on Windows — Strata 0.2.7

Root cause

Changes required

Errors encountered while isolating the issue

Model configuration

Verification

Update

Niko1221 commented on Oct 29, 2026

Niko1221 commented on Oct 29, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

Update: Successful workaround for `Startup_wait_expired` on Windows — Strata 0.2.7