Before we start

We are now on Part 3 of this project. A quick recap:

• Part 1 covered the machine: why I rebuilt my local AI system around WRX90, a Threadripper PRO 9955WX, 128 GB of eight-channel ECC memory, and two RTX 3090 Founders Edition cards.
• Part 2 covered commissioning: the tests that proved the hardware was stable, the mistakes the testing exposed, and the limits of the AI cluster that I built.

Part 3 is what you have been waiting for – what models can it run?

I did not build an approximately $11,000 local AI server just to have it sit there as an art piece. I built it to run serious open-weight models, push beyond the machine’s 48 GB of physical VRAM, and determine whether local inference could become a practical part of my research, workflow, and applications.

So I put four very different models through the machine:

• GPT-OSS-120B
• Laguna S 2.1 (118B)
• Qwen3.6-27B-FP8
• Step 3.7 Flash (198B)

The smallest was a dense 27B model that fit across both GPUs. The largest was a 196.96B-parameter mixture-of-experts model with a 113.82 GiB quantized artifact—more than twice the server’s physical VRAM.

I measured time to first token, time to first answer token, prompt processing, generation speed, context scaling, model placement, speculative decoding, concurrency, vision, GPU behavior, and system-memory use.

Then I gave every model the same four prompt tests—my own practical benchmark. Each test was based on something I genuinely care about, giving the models realistic work instead of another collection of abstract benchmark questions.

1. The Hardware Exam — Analyze measurements from the real server, identify its bottlenecks, and recommend defensible hardware and software improvements.
2. The Horror Story — Write a tightly constrained first-person horror story while following strict requirements for length, continuity, structure, and tone.
3. The Surf Simulator — Build and validate a playable third-person 3D surfing game with controls, scoring, visual effects, and a complete browser-ready handoff.
4. The Digital Twin — Reconstruct the physical server as an interactive offline 3D technical visualization with inspection, airflow, power, and camera modes.

And one of the most important lessons was this:

The machine crushed all expectations for model performance, given that I ran some serious big boy models compared to the compute I have. I built a monster machine – something that can run crazy intelligence now. Which means, as open-source models get better, smaller, and more efficient in the future, I will be running what I believe, will be Opus 4.8 level intelligence by the end of next year if my bet is correct.

Four models · two backends · one machine

The Local Model Gauntlet

Dense GPU-resident inference, hybrid CPU/GPU MoE inference, long context, MTP, vision, and four shared capability tests.

4 Models tested

48 GB Physical VRAM

131K Largest context passed

113.82 GiB Largest artifact

Model	Architecture	Backend	Context	Role in campaign
GPT-OSS-120B	116.8B / 5.1B active MoE	llama.cpp	131K maximum	Hybrid performance and long-context anchor
Laguna S 2.1	117.56B / about 8B active MoE	llama.cpp	100K	Agent-focused hybrid model
Qwen3.6-27B-FP8	27B dense	vLLM TP=2	100K showcase	Fully GPU-resident serving control
Step 3.7 Flash	196.96B / 11B active MoE	llama.cpp	90K	Capacity-ceiling test

The rules of the test

I structured the campaign in two layers: raw inference characterization and standardized prompt testing.

The first was raw inference characterization. This is where I measured how each deployment fit, where its weights lived, how generation changed as context grew, how long a prompt took to process, whether MTP helped, what concurrency did, and whether the machine remained stable.

The second layer was standardized prompt testing. Every model received the same four assignments: the Hardware Exam, Horror Story, Surf Simulator, and Digital Twin. I drew inspiration from the day-one open-model testing performed by Bijan Bowen. He does excellent work showing what newly released models can actually build, instead of merely repeating their benchmark scores. Shout-out to him for helping inspire this part of the campaign.

The two layers answer different questions.

• Raw inference asks whether the machine can serve the model efficiently.
• The prompt tests ask whether the model can do anything useful in the real world.

People naturally gravitate toward benchmark numbers when a new model appears. Those numbers are useful, but they do not tell you whether the model can finish your task, recover from its own mistakes, validate a visual application, or recognize when it is wrong. The most useful model is not always the largest or newest one. Adoption comes from real-world usefulness, which is one reason Qwen’s smaller models have become so popular.

Every showcase task started in a fresh OpenCode session and an isolated workspace. In other words, each prompt test was performed agentically. The answer-only tasks had tools disabled. The application tasks received access to the local filesystem, shell, browser, and a pinned Three.js runtime, but no internet access and no subagents. The backend restarted between cases so one model’s state could not bleed into the next task.

I also kept three acceptance questions separate:

1. Did the inference backend complete the request?
2. Did the model deliver an application that ran as submitted?
3. Was the finished result actually good?

• An HTTP 200 proves only the first.
• A model saying “done” does not prove the second.
• A non-empty PNG does not prove the third.

This sounds obvious until an agent gives you six different image hashes that all show effectively the same frame, or creates one-pixel placeholders and claims they came from a browser.

That actually happened.

What the machine was running

As a quick reminder, my AI server uses a Threadripper PRO 9955WX with 16 cores and 32 threads, 128 GB of DDR5-6000 ECC RDIMM across all eight memory channels, and two RTX 3090 Founders Edition cards connected through PCIe Gen4 x16 links. There is no NVLink bridge. The GPUs do not combine into a single 48 GB device; each backend must deliberately distribute model weights, KV cache, and computation across both cards.

I used llama.cpp and vLLM, but for different deployment goals. llama.cpp handled the oversized quantized MoE models because its tensor-placement controls allowed me to keep selected expert tensors in system memory while placing the remaining model components on the GPUs. This turned the machine into a hybrid inference system rather than a VRAM-only box.

Qwen was different. It was a dense 27B FP8 model that fit entirely across the two GPUs, so I served it with vLLM using tensor parallelism. That gave the campaign a fully GPU-resident control and allowed me to test continuous batching, concurrency, vision, and MTP. Modern versions of vLLM can offload model parameters to CPU memory, including selected MoE expert parameters, but that was not the configuration qualified in this campaign. CPU offloading also creates additional CPU-to-GPU traffic during each forward pass.

Dense and sparse models behave differently. A dense model uses all of its model layers for every generated token, so spilling a large portion of its weights across PCIe can severely reduce generation speed. An MoE activates only a subset of its experts per token, making carefully engineered hybrid placement much more practical. Architecture—not merely the parameter count printed on the model card—determined what this machine could run well.

Main model buffers

Where the oversized models lived

Bar scale is 120 GiB. Sidecars and KV cache are not included in these main-buffer segments.

Laguna · selected auto-fit 68.35 GiB

Step · vanilla 113.82 GiB

Step · MTP mode 113.82 GiB main model

GPU 0 main weights GPU 1 main weights Host main weights

The 48 GB of physical VRAM did not define total model capacity. Architecture, quantization, system memory, and backend placement determined what could run.

GPT-OSS-120B

GPT-OSS used a 59.02 GiB MXFP4 GGUF through llama.cpp. The model contains approximately 116.8B total parameters and activates 5.1B parameters per token. OpenAI released GPT-OSS weights natively quantized in MXFP4, so this was not an unofficial low-bit conversion applied after release.

Because the artifact exceeded VRAM, the first 12 layers’ expert tensors were kept in system memory while everything else stayed on the GPUs. The selected 50K profile used an asymmetric 23/13 split because a symmetric split repeatedly ran out of memory on GPU 0.

The final characterization reached the model’s full 131K context window.

Laguna S 2.1

Laguna used a 68.35 GiB UD-Q4_K_XL GGUF through llama.cpp. It has roughly 117.56B total and about 8B active parameters. llama.cpp auto-fit placed about 20.13 GiB of model buffer on GPU 0, 19.39 GiB on GPU 1, and 30.47 GiB in host memory. The server used Q8 KV and a 100K context with thinking enabled.

Qwen3.6-27B-FP8

Qwen was the dense control: 27B parameters, official block-FP8 weights, vLLM tensor parallelism across both GPUs, and the model fully resident on GPU.

On RTX 3090, this stack used vLLM’s Marlin FP8 weight-only kernel. It is not accurate to call this native FP8 tensor-core execution. The raw campaign tested BF16 and FP8 E4M3 KV, concurrency, long inputs, vision, thinking, and MTP.

Step 3.7 Flash

Step was the big boy model. I selected it because I wanted the largest practical MoE I could run on the machine at that point in the campaign. I needed baseline data near the server’s capacity ceiling, even if generation fell to only 5 tokens per second. DeepSeek-V4-Flash-0731 was released while Step testing was already underway. The newer DeepSeek model was larger and technically within reach only through an extremely aggressive quantized hybrid configuration, but replacing Step in the middle of the campaign would have destroyed the comparison and delayed the project again. I was already too deep in the sauce to turn back.

The UD-Q4_K_XL artifact was 113.82 GiB. The model has 196.96B total parameters and 11B active parameters. It ran through llama.cpp at an effective 90,112-token context.

In the vanilla placement, approximately 19.84 GiB of main weights lived on GPU 0, 19.49 GiB on GPU 1, and 77.22 GiB in host memory.

For text and code, I used the official Q8 MTP sidecar. For the Digital Twin, I used the separate F16 vision projector without MTP because the tested backend could not combine Step vision and speculative decoding correctly.

A quick guide to the speed numbers

Locally inferencing a model can get confusing really quickly, because if there is one thing the AI industry is known for, it’s the ability to pick the worst names and abbreviations possible. Ask OpenAI – their model’s names are all over the place, respectfully of course (respect to OpenAI – Codex is superior to anything out there, but guys, your naming really isn’t great). When you start running models locally, you become a magician of sorts, but have a name for this in tech world – inference engineer.

Quick recap:

• TTFT – Time to First Token: the delay between sending a request and receiving the first model token.
• TTFAT – Time to first answer token measures how long it takes before the model begins the answer channel after reasoning. This is not as important as TTFT.
• Prefill: the phase in which the model processes the input tokens and constructs the corresponding KV-cache state.
• Decode is the generated-token rate after prompt processing; tokens/second (t/s). This is what every normie pretty much only cares about when they “do AI” for the first time.

The most important thing to remember: prefill is compute bound and decode is memory bound .

Serving throughput

Serving throughput includes more of the request path and can be measured across concurrent users. Eight concurrent requests may produce far more aggregate tokens per second while each individual request becomes slower. This is why I will not mash every result into one giant “tokens per second” leaderboard. llama.cpp gave me native per-request timing objects. Qwen’s raw vLLM results used TPOT-derived generation. Qwen’s showcase used a gateway-observed client output rate.

GPT-OSS-120B: the machine was faster than the estimate

GPT-OSS was the first model I tested. OpenAI released GPT-OSS-120B and GPT-OSS-20B on August 5, 2025, making them its first open-weight language models since GPT-2. By the time I tested the new machine, the open-source community had spent nearly a year testing, quantizing, serving, and learning the larger model’s behavior.

GPT-OSS-120B remains useful for document analysis, local reasoning, and bounded tool use, but its long autonomous behavior no longer represents the best agentic models available. It contains approximately 117B total parameters while activating only 5.1B per token—about 4.4% of the model. That makes it unusually fast for its size and made it the right first baseline for a machine with no previous inference data.

The first fit attempts failed LMAO.

The problem was not simply that the model was too large. The problem was where the memory pressure landed after moving expert tensors into RAM. A symmetric GPU split was wrong under this placement.

The working 50K context window configuration kept the expert tensors from the first 12 layers in system memory and used a 23/13 tensor split. It retained 2.29 GiB free on one GPU and 2.85 GiB on the other.

The result:

At the full 131K context window, using a deliberately straightforward rather than heavily optimized launch profile, GPT-OSS generated around 34 tokens per second. That is pretty darn good for a model of this size. The prompt took approximately 93 seconds to process at 1,415 tokens per second, but generation remained completely usable afterward.

This destroyed my original estimate. I had expected roughly 10–20 tokens per second. The machine delivered three to five times that at the shallower anchors.

The 2.64-times prefill improvement

I also tested llama.cpp microbatch size. At 49K, changing microbatch from 512 to 2048 moved measured llama-bench prefill from 679.07 to 1,790.22 tokens per second. That is a 164% improvement. Decode did not meaningfully change. The cost was VRAM, especially on the card holding the final layers because of the larger logits buffer. Microbatch 2048 became the qualified ceiling. A 4096 microbatch did not fit the memory policy.

This was one of the clearest examples of why local inference is delicate. My expectation was around a 1.3-times gain. The machine delivered 2.64 times. When it comes to inference engineering – every case is unique.

The phase inversion

During prompt processing, the GPUs did most of the work while the CPU was relatively quiet.

During generation, CPU use jumped to roughly 9.5 cores because the CPU was executing and feeding the resident experts from RAM. The workload changed character between phases.

That is also why a CPU upgrade cannot be reduced to “more cores equals more speed.” The number of CCDs, fabric paths, expert placement, PCIe traffic, and exact backend behavior all matter.

Laguna S 2.1: usable speed, overhyped

Laguna’s raw inference performance was better than its final showcase results. The model arrived as Part 3 began and generated considerable excitement. I ultimately found that excitement overblown, but I am still glad the model was released: every credible open-weight release gives the community something new to study, test, and improve.

Laguna at near empty context, generated around 44 tokens per second. At 46,871 input tokens, it processed the prompt at 414.05 tokens per second and generated at 34.95 tokens per second. TTFT was 113.242 seconds, and the first answer token arrived at 117.812 seconds.

The long request showed no model disk reads and no swap traffic. GPU temperatures peaked at only 54°C and 48°C. During prefill, GPU 0 PCIe receive traffic reached roughly 20.72 GiB/s. The hybrid path was visible in real time: the machine was moving host-resident model data into the GPU pipeline.

The selected auto-fit target was also a measured decision. A 1,536 MiB target slipped to 1,516 MiB free under live inference—just below the intended floor. Raising the target to 1,792 MiB moved another 518.62 MiB into host memory without a meaningful generation penalty.

Laguna was not too slow. Its problem was finishing (lol). That matters later.

Qwen3.6-27B-FP8: the model that punched above its weight

For anyone in this space longer than 1 month, you get real sick of this punchline: “punching above its weight.” But the data shows. Qwen was the smallest model in this campaign by a huge margin. It was also the most practical all-around model.

The raw vLLM campaign completed 48 of 48 baseline, context, KV, and concurrency trials across 3,120 measured requests. The MTP block completed 12 of 12 trials across another 192 requests.

There is one publication caveat I will not hide: the internal campaign review retained a clean-room process issue because agents were resident under the rule in force at the time. The measurements are valid retained campaign evidence, but a small sentinel replication remains required before I call those raw rows publication-final benchmark results. The special-workload suite was also a qualifying pilot, not a final score. With that disclosed, the numbers are still extremely useful.

Context scaling

Using BF16 KV:

The longer prompt mostly increased the wait before generation. Qwen’s generation rate stayed comparatively flat.

Context scaling

Generation remained usable deep into context

GPT-OSS uses llama.cpp native timing. Qwen uses vLLM TPOT-derived generation. The panels are separate because the timing instruments differ.

GPT-OSS-120B · llama.cpp native

Empty

83.3 t/s

8K

77.6 t/s

32K

63.8 t/s

49K

54.7 t/s

131K

34.0 t/s

Qwen3.6-27B-FP8 · vLLM TPOT

512

49.45 t/s

2K

49.45 t/s

8K

48.57 t/s

32K

46.49 t/s

These are deployment-specific results, not a cross-backend speed leaderboard.

FP8 KV almost doubled capacity

The backend reported 193,925 tokens of KV capacity with BF16. FP8 E4M3 reported 381,163 tokens. That is a 96.55% increase. The speed differences were mostly within one percent. On this combination of model, vLLM, and RTX 3090s, FP8 KV was a capacity optimization, not a speed optimization. That is still incredibly useful.

Concurrency

At a 2,048-token input and 128-token output, BF16 KV aggregate serving throughput scaled like this:

Concurrency eight delivered 2.66 times the aggregate work of concurrency one. It did not make each user faster. Per-request latency increased. That is the difference between throughput and responsiveness.

MTP was the biggest clean win

At concurrency one, Qwen moved from 49.14 to 69.53 output tokens per second with one-token MTP. That is a 41.49% gain. At concurrency eight, aggregate output moved from 320.75 to 444.35 tokens per second. That is a 38.53% gain. The selected Qwen configuration used one speculative token. Draft acceptance was approximately 86%, end-to-end latency fell by about 29%, and reported KV capacity decreased by only 4.98%. MTP was not a theoretical optimization. It materially changed the experience.

The thermal note

A warm-start MTP concurrency-eight run could trigger NVIDIA software thermal slowdown at stock power. I did not delete that result. The qualifying runs used a near-cold admission state. That gives me a future test: controlled power caps, heat soak, and airflow. It does not mean the machine failed. It means one aggressive serving corner found another boundary.

Step 3.7 Flash: the big daddy model

Step was the entire reason I wanted this machine. Not specifically this exact model, but this class of model: something wildly larger than physical VRAM that could still become usable because it was sparse.

The artifact was 113.82 GiB. The model had 196.96B total parameters and 11B active parameters. It ran at a 90K context. In vanilla mode, around 77.22 GiB of the main model lived in host memory. In the MTP mode, host placement rose to 81.47 GiB, plus part of the draft sidecar.

The machine still had at least 37.1 GiB of host RAM available in the useful rows.

Vanilla versus MTP

The selected two-token configuration improved generation by 25.5% with 87.7% acceptance. A separate natural-stop check reached 36.69 tokens per second with 89% acceptance. That is a nearly 197B-parameter model, running locally, with a 90K context, at a genuinely interactive speed.

With MTP, Step’s generation speed at 90K context approached what GPT-OSS delivered at its full 131K window. That is incredible for a nearly 197B-parameter model. Step was still weaker than I expected in the capability tests, especially compared with Qwen3.6-27B-FP8. Parameter count alone did not translate into better practical performance; Alibaba simply did an exceptional job with the much smaller Qwen model.

Speculative decoding

MTP delivered the largest clean speedups

Parent and MTP values are matched within the same model, workload, and timing instrument.

Qwen · concurrency 1

49.14 Parent t/s

→

69.53 MTP t/s

+41.49% · 85.99% accepted

Qwen · concurrency 8

320.75 Parent aggregate

→

444.35 MTP aggregate

+38.53% · 86.88% accepted

Step · fixed-work decode

28.11 Vanilla t/s

→

35.28 MTP t/s

+25.50% · 87.70% accepted

Qwen concurrency-eight values are aggregate output throughput, not single-request generation speed.

Why Step still felt slow

I asked Step for four concise sentences.

It produced 1,345 completion tokens because most of its work happened in reasoning. The first token arrived in 0.206 seconds because part of the prompt was cached. The first answer token arrived at 33.164 seconds.

This is why decode speed alone cannot describe the experience of using a reasoning model. I intentionally left Step’s reasoning unconstrained because I wanted to test its intended behavior rather than force a shorter answer. The resulting delay is therefore part of its measured usability, not an accidental configuration mistake. Step could generate tokens quickly enough while still making the user wait more than 33 seconds for the final answer to begin.

Vision and MTP did not combine

The F16 vision path worked by itself. It correctly read a frozen synthetic chart and reached 28.21 tokens per second generation. But MTP plus vision failed at the token-position boundary after image encoding. This was deterministic in the tested llama.cpp build. It was not an OOM. It was not bad weights. It was not a thermal problem. For text and code, I used MTP. For the Digital Twin, I used vision without MTP.

The visible PCIe ceiling

During the raw Step test, GPU 0 PCIe receive traffic approached 25 GB/s. That matters. It weakens the claim that replacing the 16-core CPU would automatically add 20% generation. The CPU cores were not saturated and the PCIe path was already busy. A 24-core or 32-core Threadripper PRO may help some hybrid configurations, especially when more expert work executes on CPU and more CCD fabric becomes available.

The shared model gauntlet

Raw performance told me the machine could run the models. Now I wanted to know whether the models were any good.

Shared four-test showcase

The machine finished. The models often did not.

Outcomes combine submitted runtime behavior, contract compliance, and operator artifact inspection. Diagnostic repairs never become passes.

GPT-OSS

Laguna

Qwen

Step

Hardware Exam

Fail

Fail

Fail

Fail

Horror Story

Strong; continuity errors

Strong; over length

Strong; 22 words over

Operator favorite

Surf Simulator

Non-executing

Runnable partial; gameplay failed

Strong partial; no surfable wave

Best design; gameplay failed

Digital Twin

Failed as submitted

No application

Only app that ran as submitted

Broken submission; best latent design

No Surf Simulator fully passed. No model produced a faithful finished Digital Twin. Every Hardware Exam answer was technically unreliable.

Test 1: the Hardware Exam

This result was brutal. Every model failed.

The Hardware Exam gave each model the real server configuration, the measured GPT-OSS placement, and observations collected from the machine itself. It asked each model to identify the limiting path, evaluate whether DDR5-6400 would improve performance, reason about moving the KV cache into system memory, recommend one hardware upgrade, and prioritize software optimizations. The goal was not to reward confident technical language. It was to determine whether the advice was accurate and safe enough to apply to a real machine.

All four answers sounded confident. None were safe to use.

• GPT-OSS relied on an obsolete understanding of expert offload, invented command-line flags, and proposed a platform configuration that the real machine could not support.
• Laguna treated active model bytes as if they translated directly into FLOP requirements, produced an implausibly large KV-cache estimate, and made incorrect claims about PCIe behavior and the value of faster memory.
• Qwen misunderstood how the CPU-resident experts were being used, relied on an invented KV-cache shortcut, and recommended hardware changes that were not safe to apply without additional validation.
• Step produced 26,979 output tokens and took 14 minutes, 3 seconds. Its first answer token arrived after approximately 12.8 minutes, yet the final response still contained unsupported claims about KV cache, AVX-512, ReBAR, PCIe-slot placement, and CPU upgrades.

I was surprised the most by the Step model. More parameters did not fix it. More reasoning did not fix it. The lesson is not that these models are useless. The lesson is that fluent hardware advice is not physical evidence.

Test 2: the Horror Story

This was the campaign’s most successful test. I am a massive fan of horror stories—especially the “lost in the woods” stories that can keep me reading Reddit until the early hours of the morning. On the surface, the assignment was simple: write a short first-person story about becoming lost in the woods and encountering something unexplained. The difficult part was making it feel as if a person had written it, rather than a language model assembling familiar horror-story ingredients. In that sense, it was simultaneously the easiest test to complete and one of the hardest to perform convincingly.

All four models wrote readable, complete stories. For once, the differences felt less like failure analysis and more like taste.

GPT-OSS wrote 1,406 words. It created strong atmosphere and an effective tapping motif, but its clock moved backward without acknowledging the inconsistency, and the ending repeated itself. Temporal continuity remains a recurring weakness in generated fiction: a model can reproduce timestamps and sequences without consistently maintaining their logical relationship throughout a story. It was a small error, but an important one in a tightly constrained writing test.

Laguna wrote a restrained, effective story and produced its strongest output of the campaign. It exceeded the length limit.

Qwen built a strong cadence premise and connected the recurring motif to the narrator’s lasting damage. It ran 22 words over the body limit and repeated the central rhythm more than necessary.

Step won.

That is my judgment as the operator and reader, not a fake numeric score.

Within the first paragraph, it felt like a person had written it. The pacing, restraint, transitions, voice, and ending were simply better. It was the strongest piece of writing produced anywhere in the campaign.

This is where the largest model felt largest.

I will let you be the judge. You can read each complete, unedited story here: GPT-OSS-120B, Laguna S 2.1, Qwen3.6-27B-FP8, and Step 3.7 Flash.

•   GPT-OSS-120B
•   Laguna S 2.1
• Qwen3.6-27B-FP8
•   Step 3.7 Flash

The Horror Story Test

Step 3.7 Flash

Excerpt from the model’s retained campaign output

“I turned around to head back the way I came, and that’s when the crunch was right behind me. Not 20 yards, not 10, like someone was standing 3 feet back, right on my heel.”

“Every time I stopped, it stopped. Every time I walked, it walked. I didn’t call out again.”

Test 3: the 3D Surf Simulator

Every model failed. The difference was how interesting the failure became.

I am a big-time surfer. So naturally, the dream of having the greatest invention humanity has ever invented, was to create a surf simulator game to play – not to understand the fundamental nature of the universe. The surf simulator was also chosen because physics is also implied via the game itself. When you make a surf game, gravity, water flow, wave formation (energy), tides, time, space, ect., are all subjectively pushed through the model’s weights without explicitly saying so.

This is where the prompt matters. I feel that I could have done a better job with the prompt, but it was hilarious to see each model attempt to one shot the game. We still have a long way to go with local models, but I will say this – even though each model failed so hard it was funny, they also did a decent job at one-shotting the game.

GPT-OSS

GPT-OSS wrote source files but never performed the validation loop the prompt required. It created placeholder captures and stopped. The application did not execute.

Laguna

Laguna worked. It made 103 model requests, generated 129,544 output tokens, and spent about 93 minutes iterating. It found and repaired several of its own JavaScript and DOM problems.

Chrome eventually reached a Three.js canvas and HUD without errors. Then I played it. The game did not work as a surf game. Required handoff files were also missing. The model had been busy for an hour and a half. It had not finished the product.

Qwen

Qwen was dramatically better. In 31 requests and about 33.6 minutes, it built a procedural surfer, ocean shaders, controls, scoring, particles, and Web Audio behavior. Its alleged gameplay screenshot still showed the title overlay, and its final response claimed the captures looked correct.

They did not. When I played it, there was still no usable wave to surf. This was by far the best result up to that point, but it remained a partial implementation. Interesting observation – sound was generated for the game despite me not embedding any sound for the prompt. This seems to be a newly emergent capability in newer models. From what I watch, one shotted games are coming with sounds, whether the user asked for them or not. Singularity @georgehotz?

Step

Step produced the best one-shot visual design. It created structured Three.js modules, controls, HUD, and a real transition from the title screen into gameplay. Then the delayed browser check showed an essentially pale, empty gameplay scene without a convincing visible surfer or surfable wave. Best design did not mean working game.

Test 4: the Digital Twin

The Digital Twin exam was designed for a model to recreate the actual machine I just built – in cyberspace. I am not sure if I should have done this with CAD for the models. Each model had to reconstruct the real server as an offline interactive Three.js technical visualization.

I really liked this test – because it shows what the regular folk would realistically do with a local LLM. Recreating my machine digitally speaking, allows me to test different parts, configurations ect – it has real life application for me. This was the second hardest test in terms of large language capabilities. It also taught me the most about visual-agent validation.

GPT-OSS

GPT-OSS created HTML and JavaScript geometry, but served the wrong root, broke its module imports, and supplied six tiny placeholder images.

It failed. Not only did it fail – but it was the worst model for this test.

After the campaign, I corrected only the missing import mapping as a diagnostic. That revealed a crude black chassis, primitive blocks, fan cylinders, and basic controls.

That helped explain what the model had attempted. It did not change the score. This reinforces that the GPT OSS model was never intended to run long term agentic tasks. Despite it only being less than a year since it came out – that is like a lifetime for AI capabilities.

Laguna

Laguna produced no application. In the valid text-only retry, it spent two full output-limited turns thinking about coordinate orientation instead of building. There was no HTML. No JavaScript. No CSS. No README. No captures.

This was the clearest model failure of the campaign. I am still not sure why, but the model just could not figure out the task.

Qwen

Qwen produced the only Digital Twin that ran as submitted. It used vision to inspect the evidence, repaired lighting and chassis visibility, copied the pinned runtime, and fixed a self-containment problem. The app loaded.

Inspection, airflow, power, and camera modes worked. It took 121 requests, 95,834 output tokens, and about 55 minutes. The result was still weak as a twin. The geometry was generic, the GPU placement was unclear, front and rear framing were poor, and the final capture set did not actually prove the six states the model claimed. Its automation captured effectively the same initial state repeatedly; different hashes came from animation noise.

Qwen won practical completion. It did not win fidelity. Whatever Alibaba did to this model, they added a little extra sauce to it. It continues to perform the best relative to the number of parameters it has. Crazy.

Step

Step generated the largest and most ambitious Digital Twin codebase. It also failed three times. Automatic compaction destroyed the task identity in the first attempt. With compaction disabled, the second attempt exceeded the 90K context.

The third attempt continued from the existing files, made 111 requests, and reached the exact context ceiling. It ended with broken module paths, one blank capture, no README, and five missing captures. Across the retained attempts, the Twin consumed 110,956 output tokens and roughly one hour and 42 minutes.

The final defect was a relative import path. After the scored campaign, I corrected only that path and served the existing artifact. The model was not rerun. What appeared was the strongest-looking Digital Twin design in the entire group.

And it still failed. The model did not deliver a working application. The diagnostic preview showed latent quality, not a pass. That distinction is non-negotiable.

Time was a factor, but not the factor

I expected Step to be slow. That alone would not make it a bad model. If a larger model takes longer and produces something materially better, the trade can be worth it. This is local inference. I am not paying by the token every time it thinks. But time remains part of usability.

Step’s story was worth waiting for. Step’s Hardware Exam was not.

Build-agent effort

More tokens did not guarantee completion

Bar lengths use a logarithmic presentation so the smallest and largest sessions remain visible. Labels show exact output-token totals.

GPT-OSS-120B

Surf · 5,074

Twin · 5,157

Laguna S 2.1

Surf · 129,544 · about 93 min

Twin · 36,995

Qwen3.6-27B-FP8

Surf · 78,225 · 33.6 min

Twin · 95,834 · 55 min

Step 3.7 Flash

Surf · 39,646

Twin · 110,956 · about 102 min

GPT-OSS stopped prematurely. Laguna and Step spent heavily without shipping the requested products. Qwen showed the best practical balance.

What the machine proved

The server passed the part that mattered most to the hardware project. It runs large language models.

• GPT-OSS reached the full 131K window.
• Laguna remained usable at 46.9K depth without paging its model from disk.
• Qwen drove both GPUs evenly through long autonomous sessions and released its memory cleanly.
• Step placed roughly 77–82 GiB of main weights in host memory and still generated at 35.28 tokens per second with MTP.
• Selected runs did not show persistent OOM, model corruption, disk-backed expert paging, or a machine crash.
• GPU temperatures generally remained in the 40s through low 60s Celsius.

The bottleneck changed with the deployment:

• GPT-OSS exposed the CPU memory and fabric path.
• Laguna and Step exposed heavy PCIe traffic.
• Qwen leaned into GPU compute and power.

What the models proved

GPT-OSS-120B

Use it for responsive local chat, bounded work, fast tool loops, and long-context hybrid inference. Do not assume its speed or confident reasoning makes it a trustworthy autonomous software engineer.

Laguna S 2.1

Use it for attended experimentation and bounded generation when you can inspect the output. Do not assume agentic specialization transfers perfectly across quantization, backend, and harness.

Qwen3.6-27B-FP8

This is the practical winner. It was the smallest model, the most balanced serving deployment, the strongest self-repairing agent, the only model to ship a Digital Twin that ran as submitted, and the model with the largest measured MTP uplift. It still overclaimed its visual validation and needed a human to inspect the result.

Step 3.7 Flash

This was the model that made the machine feel enormous. It was the best writer. It produced the strongest latent visual design. It proved that a nearly 197B-parameter MoE can run locally at an interactive rate on two RTX 3090s and 128 GB of memory.

It was also the slowest, most verbose, most context-hungry model, and it failed to finish both complex visual products. Step was the most impressive model in the campaign. Qwen was the model I would actually reach for first.

What I would change next time

I became impatient near the end of the campaign. FOMO is real in AI: while I was testing, DeepSeek and another Qwen 27B model appeared, and I wanted to jump immediately to the newer releases. I finished the planned campaign, but looking back, I moved too quickly during its early stages. That weakened parts of my prompt design, harness, and overall planning.

• Harness design: The harness mattered far more than I expected. The next visual-agent campaign should provide a minimal known-good Three.js scaffold, import map, and serving root so packaging failures do not overwhelm the actual model comparison.
• Prompt design: I expected capable models to one-shot a finished application from one strong specification. I was wrong. Future application tests need clearer stages, acceptance gates, and validation requirements.
• Inference optimization: I deliberately kept the inference profiles relatively straightforward. The goal was to establish useful baseline results rather than tune every model to its absolute limit. Future model-specific testing can optimize microbatching, speculative depth, placement, cache precision, and power limits separately.
• Model selection: In hindsight, I wish the timing had allowed me to include the new DeepSeek model. Step still provided a valuable capacity-ceiling result, but newly released models need time for backend support, quantization, and inference bugs to stabilize. DeepSeek deserves its own follow-up campaign rather than a rushed substitution at the end of this one.

The real conclusion

Two used RTX 3090s and 128 GB of fast eight-channel memory can run models far beyond 48 GB of physical VRAM at useful speeds. After the time, money, planning, and research invested in this build, watching the machine finally come to life—and exceed my expectations—was a beautiful thing. I am just getting started.

The full redacted methodology, normalized data, charts, frozen public prompts, failure ledger, and privacy controls are available in the project repository:

Part 1 — The Build

Part 2 — The Commissioning

Part 3—the model testing you have so graciously read—concludes the initial V2 build series. I could have built the machine and returned immediately to my AI research. Instead, I documented the entire experience because I want this work to help and inspire other people running compute in makeshift labs wherever they are. I do this because I love it, but also because we need a world where advanced AI is not contained inside a handful of laboratories.

I want to emphasize this because it is important: it does not matter whether you run your own hardware. Open Source AI must win. Technology is not inherently good or evil; its effects depend on who controls it, who can study it, and who can build with it. We cannot allow a small group of people to control the future of AI for all of humanity. Safety matters. Access matters. The future of humanity matters. I encourage you to support open-source models and help spread the word. Based on conversations I have had with some brilliant people in AI, I believe 2027 will be the biggest year yet for the field. Thank you for reading and following my work. You can find my other projects on my personal portfolio website.