Comparing Six Qwen3.8-27B Q6 Models in Blender

For this Blender task, I’d start with Unsloth when visual consistency matters most. JonathanColetti would be my choice when turnaround time and token use carry more weight. Neither produced four flawless images.

I tested six local Qwen3.8-27B Q6 models by having each one build and render a ceramic coffee mug in Blender. Each model got four attempts. Every retained attempt saved a valid image, and four models passed all eight automated scene checks every time.

The images tell a more complicated story. Some mugs had broken handles. Others had capped-looking tops, strange openings, awkward framing or disconnected-looking parts. One model saved a respectable image and then crashed Blender, leaving no recoverable final scene.

If you’re choosing a local model to operate creative software, those differences matter more than a green check beside a filename.

What I tested

The six artifacts were ThinkingCap, the Unsloth baseline, DavidAU’s TurboFCFusion build, Dirk, Huihui and JonathanColetti. These were the specified Q6_K downloads. Unsloth and Dirk use the publisher’s UD-Q6_K filename label. The results apply to those artifacts, rather than every download bearing the same creator’s name.

The models ran in LM Studio 0.4.25 Build 1 and controlled Blender through BlenderMCP, which exposes Blender operations as tools the model can call. The saved native request statistics and application logs confirm that application build for all 24 retained attempts. The loaded llama.cpp extension, upstream commit and CUDA runtime remain unconfirmed. They had access to scene inspection, object inspection, Python execution and viewport screenshots. Each model used its own repository’s vision projector, the companion component that enables image input, and passed a check that screenshot feedback could reach it.

Every attempt started with an empty scene and a fresh conversation. The task was a teal ceramic mug containing coffee, presented against a dark studio backdrop. The model had to build the scene and save its own 1920 by 1080 render. Limits were 40 tool calls, 45 minutes or a context overflow.

I used a common requested inference profile with thinking enabled. That does not make the artifacts identical: their native templates and vision projectors differed. This comparison measures the complete local setups used here, not an isolated change to one model parameter.

No scene was built, repaired or rendered on a model’s behalf during its attempt. After the model stopped, the benchmark checked the scene and attempted a separate saved-scene capture. Those post-run captures are useful diagnostics, but they don’t count as the model’s own render.

The 23 saved-scene renderer logs identify Blender 5.2.2 LTS, build d13f752e3b9c. That is post-run renderer evidence. Huihui’s fourth attempt separately records the same Blender build in its model-phase crash. Neither establishes a version for the later Codex editorial reviewer.

This article covers the fresh 24-attempt comparison with the revised color and lighting instructions. An earlier white-on-light campaign was stopped and is excluded. It was not a complete paired experiment, so I can’t assign a measured improvement percentage to the revision.

Saved images and scene checks measure different things

All six models saved four valid PNGs out of four retained attempts. Across the campaign, that gives us 24 model-made images, 23 scenes with complete eight-check scores and 23 post-run captures.

The automated score awards one point for each of eight checks: the required object names; mug dimensions and base position; Bevel and Subdivision modifiers; named material assignments; the three-light setup; the active camera and lens; render settings; and existence of the model’s saved render.

That is useful for catching missing objects and incorrect settings. It does not establish that a handle looks properly attached, the mug looks hollow, the coffee looks plausible or the camera has framed the object well. Assigning a material with the right name also doesn’t prove that the resulting color is correct.

Here are the measured results. Time and token figures are averages across the four retained attempts for each model. Time is the recorded model-attempt interval, excluding model loading, preflight and the later scene check and capture.

Huihui’s scene-score average covers three measured scenes. Its fourth score is unavailable after a model-caused crash. Its time average includes that attempt’s recorded 45-minute deadline, including time spent waiting after the crash. That is not 45 minutes of productive generation or rendering.

Total tokens include input and generated tokens summed across successive requests. The conversation is sent again as the model works, so these counts include repeated context. They aren’t counts of unique output words or a direct measure of electricity use.

ThinkingCap, Unsloth, Dirk and JonathanColetti tied on the automated scene score and saved-image count. The specified tie-break, fewer total tokens, orders them JonathanColetti, Dirk, ThinkingCap and Unsloth. That ordering does not establish which model made the best-looking images. Huihui is excluded from that four-measured-scene ranking because one scene could not be scored.

Unsloth kept the mug recognizable, with handle defects

All four Unsloth outputs read as teal mugs containing coffee, without the capped-looking tops seen in several other results. Run one was its cleanest basic product shot. Run four had good framing, but its handle appeared detached at both ends.

It still had visible shortcomings. Run two filled almost the entire vertical frame, with abrupt dark handle joins and a noticeable boundary in the backdrop. Run three’s long horizontal handle looked unusual. I’d call the results recognizable and reasonably consistent, rather than ready for a product catalog without inspection.

Unsloth finished all four workflows and recorded six tool errors across 90 calls. Its average time was 7.95 minutes, but it also had the highest mean total-token use in this group. Unsloth took longer and reported more total tokens than JonathanColetti. Its consistency here means a recognizable mug-and-coffee form, not consistently correct handle geometry.

JonathanColetti delivered the best efficiency

JonathanColetti’s first and fourth images were broadly convincing. The second was recognizable, but tightly framed, with handle ends that looked cut off or poorly joined to the body. The third was a clear visual failure, with a capped-looking top, an angular opening, surface artifacts and cropping.

That poor third image matters even though the scene passed all eight automated checks.

Its average attempt took 3.61 minutes and used 225,220 total tokens. Compared with Unsloth, that is approximately 55% less time and 60% fewer total tokens. It was the fastest on average and used the fewest total tokens of the six.

For a workflow where you inspect the output and care about turnaround, that makes JonathanColetti a strong option. I’d still want the visual review step. Fast delivery doesn’t help if the one image you need happens to be the defective one.

Dirk was quick, with uneven geometry

Dirk’s first and fourth results were solid basic mug shots. Its second had a conspicuous break in the handle loop. Its third had a capped-looking top with an angular opening and an awkward handle presentation.

Those are visible problems with the requested object, rather than a disagreement about artistic style. Yet all four scenes received 8/8.

Dirk averaged 5.33 minutes per attempt and recorded five errors across 102 calls. The execution was reasonably efficient. The concern is visual consistency: two of four images had substantial geometry problems.

ThinkingCap’s extra time did not produce a quality advantage

ThinkingCap’s first and third images were recognizable dark teal mug shots. The second was brighter, but the front-facing handle looked awkward and had deformation around its attachments. The fourth presented the mug in a disorienting orientation, with the opening toward the lower part of the image rather than a normal upright product view.

I wouldn’t infer the exact camera or geometry mistake from that picture alone. I would reject it as the requested product presentation.

ThinkingCap averaged 23.16 minutes per attempt, about 6.4 times JonathanColetti’s average. Its slowest attempt took 41.29 minutes. Every scene still received 8/8 from the structural checks.

The additional wall time didn’t buy a better or more dependable image in these four attempts. I also wouldn’t label all of that time as additional reasoning. Generation speed, rendering and other execution work contribute to elapsed time.

Huihui produced good images and one serious workflow failure

Huihui’s first image had the capped-looking top and angular opening seen in other failures. Runs two through four were recognizable mug-and-coffee images, although run two was tightly framed. The fourth image was visually competitive.

The failure happened after it saved that image. Model-generated code removed an image datablock and then accessed its retained pixel data, triggering a native Blender crash. The PNG survived. The final scene was unrecoverable, so a complete structural score and a post-run capture were unavailable.

I won’t turn that missing score into zero or assume it would have passed. The measured scores are 8, 7 and 8. The fourth is unknown. Run two lost its point because the final mug did not have the specifically required Bevel and Subdivision modifiers.

Huihui’s first three retained attempts averaged 6.50 minutes. Including the failed fourth attempt raises the average to 16.12 minutes. Its relatively low recorded error count doesn’t capture the severity of losing the scene.

A separate Windows Update restart interrupted its first attempt and qualified for one infrastructure redo. That interruption is not a model failure, and the interrupted attempt is excluded from the retained-attempt averages. The model-caused crash received no redo.

DavidAU saved every image, but none was a clean product result

DavidAU’s first image cropped the top of the mug and used a thin angular handle. The second was largely grey or white, with a capped-looking top and a small angular opening. The third had separated-looking top and handle components, with the body cropped at the bottom. The fourth recovered the teal body, but its top still looked malformed.

It saved four valid images. I would not accept any of those four as a clean finished version of the requested product shot.

The individual automated scores were 6, 8, 7 and 8. The first scene was missing the required Key_Light object, failing both the object-name and light checks. The third failed the combined dimensions-and-base-position check because the mug’s base was too low. Its dimensions themselves were within tolerance.

More revealingly, the second and fourth scenes received full marks despite their visible defects. The separate post-run capture of the fourth scene was blank and dark, even though the model’s own saved image contained a mug. I couldn’t establish why the later render of the saved scene showed only a dark background.

DavidAU recorded 29 of the campaign’s 59 tool errors, approximately 49%. It was the weakest performer for this particular task when I consider both the visible results and the amount of failed tool work.

Explore the six-model summary or all 24 retained attempts in the benchmark explorer.

The editorial ratings are a separate judgment

I asked Codex to assess the images and overall workflow alongside the measured results. Its post-hoc editorial score weights visual results at 70%, workflow reliability at 20% and efficiency at 10%. All four images contribute equally to each model’s visual average.

A later visual review identified additional handle defects in Unsloth run four and JonathanColetti run two, now described above. I have retained the historical Codex ratings with that qualification rather than presenting them as revised visual grades.

These ratings were assigned after the tests. They are subjective Codex assessments, not the original automated benchmark score, my independently assigned numerical grades, or a blinded panel’s findings.

Visual ratings consider recognizable geometry, coffee, handle connections, color, lighting and framing. Workflow ratings consider completion, error recovery and whether the final artifacts remain usable. Efficiency ratings are comparative judgments informed by measured time and token use; they aren’t another independently measured benchmark.

For example, Unsloth’s calculation is 0.70 × 7.25 + 0.20 × 9 + 0.10 × 7 = 7.575, displayed as 7.6. That decimal makes the arithmetic reproducible. It does not establish measurement certainty.

The top two are close enough that priorities change the order. Giving efficiency 20% and visual quality 60%, with workflow reliability unchanged, puts JonathanColetti at 7.7 and Unsloth at 7.6. I wouldn’t use the original 7.6 versus 7.4 gap to claim a decisive winner.

What I’d choose for this workflow

For a similar mug-building task, I’d start with Unsloth for visual consistency or JonathanColetti for speed and lower token use. Dirk is another efficient option, but its broken-handle and capped-top results make visual inspection essential. ThinkingCap didn’t justify its additional time here. Huihui’s stronger images came with a scene-loss failure. DavidAU would not be my choice for this task based on these four outputs.

The more useful lesson is to evaluate the deliverable at several levels: did the model save a file, does the scene meet the structural requirements, and does the picture actually show what you asked for? Those checks caught different problems in this comparison.

This is one creative task, four retained attempts per artifact and one local test setup. It doesn’t rank general coding ability, reasoning, refusal behavior or every possible Blender workflow. The tests establish what happened here, including the failures.

Watch the side-by-side image comparison in the companion Qwen3.8-27B Q6 video. Let me know in the YouTube comments which outputs you’d accept and which problems would stop you using them. Subscribe to DeepWakeLabs if you want more local-model tests built around the work these tools actually have to finish.