You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Engine] strata update: 0.1.52 test start fails on Linux with 'unknown argument: --eos' (general engine run with dsv41 config) #4440
strata update rejects engine 0.1.52 on Linux for a DeepSeek V4.1 setup. The test start launches the general engine binary (0.1.52-linux-x86_64-cuda-cuda13/strata) with the saved dsv41 run-config arguments. That binary exits with unknown argument: --eos, so the update is marked failed and 0.1.50 is kept.
The rest of the log is the engine's usage text. The update message embeds part of it (the --adapt-async help), which makes the error hard to read.
Expected
The test start should run the engine that matches the pack's arch (dsv41 for deepseek41), or drop arch-specific flags the general engine doesn't take. If the probe can't be run for this config, the message should say that instead of reporting a failed engine.
Notes
Nothing is wrong with the GPUs or memory: both cards are idle with plenty of free VRAM.
Retrying with --force was not tried, because the arguments are identical.
The failure message shows the usage text instead of the first line (unknown argument: --eos), which hides the cause.
I am seeing exactly the same Engine 0.1.52 test-start failure for exactly the same reasons. Since the issue I opened (#4443) is a duplicate of this one, I have closed it.
I use Strata with both DeepSeek V4.1 and Qwen3.8FN but when updating the Strata engine the model config file used is the one for DeepSeek V4.1 which leads to a failed test-start. See the workaround I found for this issue in my comment below.
Strata update (https://github.com/Niko1221/Strata/releases/latest/download)
Reading the signed update feed
downloading engine 0.1.52 linux-x86_64-cuda-cuda13: 100% (645 of 645 MB)
Unpacking 0.1.52 linux-x86_64-cuda-cuda13
Checking the package signature and every file
Test-starting engine 0.1.52 linux-x86_64-cuda-cuda13 before switching to it
Engine 0.1.52 is loading the model (0 s)
Engine 0.1.52 is loading the model (30 s)
Engine 0.1.52 has loaded the model; waiting for it to answer one token (41 s)
Switching to engine 0.1.52 linux-x86_64-cuda-cuda13
Engine 0.1.52 is installed and will be used on the next start
Feed sequence 116, signed by 5d1bc23abbeffd0d
Engine 0.1.50 -> 0.1.52 updated (tested: started, answered one token, stopped)
Control 0.1.53 up to date
Saved tuning presets: marked for the short re-check (nothing was deleted).
The previous engine version is kept; strata components rollback returns to it.
Note that in my case, this strata engine upgrade was really worth it, token generation speed increased from around 75 tps with engine 0.1.50 to 115 tps with engine 0.1.52 (using Swift 1.5 IQ3 XXS).
Thank you for the workaround; --model-config with a Qwen config pointed at the cause. The update test-starts the new general engine with one installed model's run config, and with DeepSeek and Qwen installed the DeepSeek one sorts first, so the general engine got options it does not know. Fixed on our side; the fix ships in the next update (0.2.8). The test start now skips DeepSeek run configs (they run on strata-dsv41, a separate package); with only a DeepSeek model installed, the update checks that the new engine runs (--version) instead. This is PR #4267 (ai-bits), ported with the author kept.
Activity
AndrewDBN commentedon Oct 28, 2026
I am seeing exactly the same Engine 0.1.52 test-start failure for exactly the same reasons. Since the issue I opened (#4443) is a duplicate of this one, I have closed it.
I use Strata with both DeepSeek V4.1 and Qwen3.8FN but when updating the Strata engine the model config file used is the one for DeepSeek V4.1 which leads to a failed test-start. See the workaround I found for this issue in my comment below.
AndrewDBN commentedon Oct 28, 2026
WORKAROUND
I have found a workaround for this specific issue: just specify a working Qwen3.8FN model config file when updating.
strata update --force --model-config ~/.local/share/strata/install/strata-swift-iq3_xxs.json
Strata update (https://github.com/Niko1221/Strata/releases/latest/download)
Reading the signed update feed
downloading engine 0.1.52 linux-x86_64-cuda-cuda13: 100% (645 of 645 MB)
Unpacking 0.1.52 linux-x86_64-cuda-cuda13
Checking the package signature and every file
Test-starting engine 0.1.52 linux-x86_64-cuda-cuda13 before switching to it
Engine 0.1.52 is loading the model (0 s)
Engine 0.1.52 is loading the model (30 s)
Engine 0.1.52 has loaded the model; waiting for it to answer one token (41 s)
Switching to engine 0.1.52 linux-x86_64-cuda-cuda13
Engine 0.1.52 is installed and will be used on the next start
Feed sequence 116, signed by 5d1bc23abbeffd0d
Engine 0.1.50 -> 0.1.52 updated (tested: started, answered one token, stopped)
Control 0.1.53 up to date
Saved tuning presets: marked for the short re-check (nothing was deleted).
The previous engine version is kept;
strata components rollbackreturns to it.Note that in my case, this strata engine upgrade was really worth it, token generation speed increased from around 75 tps with engine 0.1.50 to 115 tps with engine 0.1.52 (using Swift 1.5 IQ3 XXS).
yudhanjaya commentedon Oct 29, 2026
Confirming that @AndrewDBN 's workaround worked - strata updated on my system and tok/s is the highest I've seen to date
Niko1221 commentedon Oct 29, 2026
Thank you for the workaround;
--model-configwith a Qwen config pointed at the cause. The update test-starts the new general engine with one installed model's run config, and with DeepSeek and Qwen installed the DeepSeek one sorts first, so the general engine got options it does not know. Fixed on our side; the fix ships in the next update (0.2.8). The test start now skips DeepSeek run configs (they run onstrata-dsv41, a separate package); with only a DeepSeek model installed, the update checks that the new engine runs (--version) instead. This is PR #4267 (ai-bits), ported with the author kept.