An Image in 15 Seconds, a Blank Answer After 155: Three Pitfalls of Local LLMs

Same prompt, same model: one run drew a decent image in 15 seconds; another ran for 155 seconds and produced not a single character. What separated them wasn't model capability — it was three settings. This article explains them and how to get around them, especially if you plan to use the model for real work.

The Short Answer

When the same model is great one moment and useless the next, it usually hasn't gotten dumber — three things just aren't matched up: thinking mode, the output budget, and that itchy tool-calling hand.

All the data below comes from a locally deployed Qwen3.8-Flash-Next (125B sparse MoE, IQ3_S quantization, on a machine with 62 GB of RAM and an RTX 5090), at temperature 0.7, with no fixed random seed and single sampling. The task itself is simple: draw a pelican riding a bicycle (the classic SVG version and an animated version), so good versus bad is obvious at a glance.

1. Same Task, Three Outcomes

Look at the first two rows: the same task, the same model — one produced an image in 16 seconds, the other gave nothing after 155 seconds.

2. Pitfall One: Thinking Mode Eats the Budget First

With "thinking" (reasoning) turned on, the model writes a long stretch of reasoning before outputting the answer. On gentle tasks that's a plus; but the budget is shared — the more it reasons, the less is left for the answer, possibly nothing at all.

The two failures above are textbook cases: with a 16K budget, it burned all 16,384 tokens on reasoning (36,688 characters of reasoning text) and never output a single character of the image before being hard-cut. Raise the budget to 32K and it actually converged faster: it stopped after 15,373 characters of reasoning and produced the image normally in 101.8 seconds.

So for tasks that "should directly produce structured content" (draw an image, emit a file, fill in a form), turn thinking off first. If you do turn it on, give it at least a 32K budget and accept that it will be 5–6x slower — and the result won't necessarily be any more detailed than with thinking off.

3. Pitfall Two: The Output Budget Is a Hard Constraint

The second category is tasks that "emit one big file in one go." Asking it to generate a self-contained HTML animation: with an 8K cap, the output HTML was 20,770 characters and got cut off in the middle of a path (it never got to </html>); with the cap raised to 16K, the same prompt yielded a complete 28,204 characters in 97.5 seconds.

The rule of thumb is simple: give it as much output room as the thing you're asking for needs. An SVG is usually 2–8 K characters, and a self-contained animation page is 20–30 K characters — set the limit at that scale instead of gambling on the default.

Incidentally, this is where running locally pays off most visibly: raising the cap costs nothing. When the cloud bills you per output token, you instinctively squeeze the budget — and get truncated output.

4. Pitfall Three: Say "Create," and It Wants to Call a Tool

The first time, the animation task was asked verbatim: "Create an animated SVG …". Its reply was a single sentence:

I'll create an animated SVG of a pelican riding a bicycle with spinning wheels and pedaling legs. Let me set up the project with React and build a detailed, self-contained SVG.

And then it stopped — the response's finish_reason was tool_calls; it was waiting for a tool. Models in this class carry heavy traces of agent training: ask one to "create" something, and it assumes by default that it's in an environment where it can read and write files and run commands, so it starts setting up a project instead of handing in the work.

The fix is simple — just add a constraint sentence:

Output only one complete, self-contained HTML file …. Do not use any tools. Do not explain anything. Start your reply with <!DOCTYPE html>

With those three sentences added, it obediently output the result directly (which is where the complete HTML in the previous section came from).

5. One More You Can't See: Variance

Same prompt, same temperature, asked three times in a row, and you get three different pelicans — 16.2 seconds, 21.2 seconds, 15.3 seconds — with visibly different levels of polish across the three images (the bike frames were all correct; the differences were in details like the throat pouch and neck length).

The conclusion isn't "the model is unstable," but rather: a single result doesn't represent its level. To compare two configurations, either run each several times and look at the median, or admit "I got lucky this time." Elsewhere we've done more rigorous repeated measurements, and drift across restarts for the same configuration can reach ±5–9% — any difference smaller than that, treat as noise.

6. Four Ready-to-Use Rules

1. For finished output, turn thinking off first; if you turn it on, give it at least a 32K budget and accept a 5–6x slowdown.
2. Set the output limit by the size of the artifact: 8K for an SVG, 16–32K for self-contained HTML — don't use the default.
3. Explicitly ask it to "output directly, don't use tools, don't explain," especially when the action word is "create / make / write a."
4. Don't draw conclusions from a single run: run the same configuration several times, and if the difference is under 10%, don't count it as "the optimization worked."

Back to those two outcomes: an image in 15 seconds and a blank answer after 155 seconds came from the same model and the same task. What differed was never model capability, but whether you matched up these three switches. The real barrier to local deployment isn't "getting it running" either — it's these switches.

Methodology: The model is Qwen3.8-Flash-Next (125B sparse MoE, IQ3_S quantization), deployed on our own server (RTX 5090 / 62 GB RAM), at temperature 0.7, with no fixed random seed and single sampling; outputs were checked via screenshots rendered with headless Chromium. Timings and token counts in this article were collected on 2026-10-15.