Local LLM benchmarks on AMD Strix Halo

I tested this model back in February with an IQ3_XXS quant and llama.cpp defaults. It scored 0/10 on coding (missing imports), 24/30 on writing, and I shelved it. Unsloth's Dynamic 2.0 UD-Q3_K_XL quant and their recommended sampling params (temp 1.0, top_p 0.95, min_p 0.01, top_k 40) changed everything. Coding went to 10/10, LeetCode to 59/59, writing to 26/30. The previous 0/10 was a quant quality and sampling configuration problem, not a model capability problem.

At 229B total and roughly 10B active parameters, it eats 94 GiB. The largest model on disk by a wide margin. AMDVLK is the right backend here, giving 32 t/s generation vs 22 on RADV. That 32 t/s translates to about 8 words/second on writing tasks, which is usable but not fast. PostgreSQL landed at 40/57 with perfect 10/10 on T2 query optimization and 19/31 on T4 procedural. Cassandra scored 30/56, also with perfect 10/10 on T2 anti-pattern detection. Only the second model to ace Cassandra T2 after Gemma-4-26B-A4B. Combined 185/285 puts it 6th overall.

The model has a quirk that cost me several hours to track down. Its chat template hardcodes a <think> token in the generation prompt with no toggle to disable it. The --reasoning-budget 0 flag has no effect. I built a custom Jinja template that strips the thinking prefix, but it turns out the model is equally verbose without it. For the polyglot gauntlet I had to bump context from 32K to 64K because the thinking block was eating half the token budget and truncating code output. That got the polyglot score from 6/65 to 13/65, mostly by rescuing the bash log analyzer (0/8 to 6/8). The Ruby and Go challenges still truncate even at 64K.

I added a database benchmark that tests real PostgreSQL skills against a live Postgres 18 instance. A fresh container spins up per run with 2.7 million rows of seeded e-commerce data. 28 challenges across four tiers, 57 test points total. Tier 1 tests complex SQL writing (window functions, recursive CTEs, LATERAL JOINs, JSONB aggregation). Tier 2 tests query optimization where the model receives a slow query and its EXPLAIN plan, then has to produce a fix that actually reduces cost against the live data. Tier 3 tests DBA diagnosis from simulated pg_stat_activity and EXPLAIN output. Tier 4 is the hard one. Models write PL/pgSQL functions, triggers, exclusion constraints, RLS policies, and batch procedures with savepoint error handling. Their code gets executed and validated through behavioral test cases.

I ran the full Gemma 4 family through it. The dense 31B leads at 46/57, followed closely by the 26B-A4B MoE at 44/57. The E2B and E4B small models land at 27 and 26 respectively. Query optimization (T2) turned out to be the great equalizer. Even the 2B model scores 8/10, correctly suggesting GIN indexes, partial indexes, and covering indexes. Tier 4 is where model size actually matters. The 31B and 26B both score 22/31, acing exclusion constraints, audit triggers, partition management, and batch savepoints. The small models collapse to 7-10/31 on the same challenges. Row-level security and recursive cycle detection defeated the entire family at 0/5 and 0/4.

I built a Cassandra benchmark to test whether models that handle PostgreSQL can also reason about distributed databases. A 3-node Cassandra 5.0 cluster spins up on Strix per run, seeded with 1.5 million rows of IoT sensor data across 8 tables. 32 challenges across four tiers, 56 test points total. The fundamental question is whether the model understands that Cassandra is not SQL with different syntax. Every partition key must be in the WHERE clause. There are no JOINs. ORDER BY only works on clustering columns. Deletes create tombstones. Consistency is per-operation. A model trained on relational patterns will fail even if it knows CQL keywords.

Tier 2 is the most interesting tier and the hardest departure from PostgreSQL. Cassandra has no EXPLAIN, so there is no query optimizer to reason about. Instead, the model receives a broken schema with symptoms and has to identify the anti-pattern. Unbounded partition growth, hot partitions, secondary index scatter-gather, tombstone accumulation from queue patterns, ALLOW FILTERING abuse, compaction strategy mismatches, consistency level math, batch misuse, materialized view pitfalls, and collection size limits. Gemma-4-E2B scored 7/10 here. A 2B model explaining why a logged multi-partition batch is slower than individual async inserts, or why a secondary index on email causes fan-out to all 12 nodes. These concepts need distributed systems understanding, not coding ability.

Tier 4 executes model code against the live cluster. Time-bucketed schema design with TWCS compaction, distributed locks via lightweight transactions, materialized views, counter-based rate limiters, batch denormalization, and Storage-Attached Indexes. The 26B-A4B and 31B both score 14-15/30, acing LWT locks and counters but failing materialized views and batch denormalization. The E2B actually outperforms the E4B here (10 vs 4), perfectly solving both the LWT lock and counter challenges while the 4B model can't produce valid CQL for any of them.

T1 CQL writing scores range from 2/10 (Qwen3.5-4B) to 9/10 (Gemma-4-31B and E4B). The E4B result stands out: a 7.5B dense model matching the 31B on CQL syntax while most MoE models with more total parameters score 7-8/10. TOKEN() range scans, GROUP BY semantics, and PER PARTITION LIMIT with multi-column clustering keys are the remaining unsolved patterns. The dense 31B leads the overall leaderboard at 39/56, edging the 26B MoE (38/56) by one point, breaking the tie that exists on PostgreSQL.

The LRU cache benchmark ran its course. 15 models score a perfect 10/10, making it useless for differentiation. I built a new polyglot coding gauntlet with seven challenges across Python, Bash, Ruby/Sinatra, and Go, totalling 65 auto-graded tests at LeetCode medium/hard difficulty. The challenges test real-world skills like parsing structured logs with nested JSON, matching cron expressions, building awk pipelines, implementing FastAPI rate-limiting middleware, writing HMAC-verified Sinatra webhook handlers, and building recursive Go rule engines.

I ran every model on disk through the gauntlet. Nobody breaks 22%. A three-way tie leads at 14/65 (GPT-OSS-120B, GPT-OSS-20B, and Gemma-4-31B), all winning on bash pipelines. The 20B matches its 120B sibling identically in 3 minutes vs 8, proving the extra 100B parameters add zero value here. Qwen3-30B is right behind at 13/65 and is the only model to score on the Go rule engine (3/10), finishing in 90 seconds. Three challenges remain completely unsolved across all 14 model runs. The cron matcher, the FastAPI rate limiter, and the Sinatra webhook processor all sit at 0/10.

Two clear capability profiles emerged. The Qwen3 family (30B, Coder-Next, 27B dense) excels at Python regex, scoring 9-10/10 on the structured log parser, but completely fails bash extraction. GPT-OSS, Gemma, and the Qwen3.5 MoE family handle bash pipelines well but are weak on regex. Dense models outperform their MoE siblings on structured output. Gemma-4-31B (dense, 14/65) beats the 26B-A4B MoE (10/65) despite being 5x slower. Thinking mode actively hurts. Qwen3.5-9B jumped from 1 to 5 points when thinking was disabled. Model size doesn't correlate with score. The 30B outperforms the 122B, and Nemotron-Cascade-2's IMO gold medal reasoning scored just 1/65.

I also tested whether quantization precision matters by running Gemma-4-26B-A4B at both Q4_K_XL and Q8_0. It doesn't. Run-to-run variance exceeds the quant quality difference when you only have 3.8B active parameters. The benchmark measures model capability ceilings, not quant artifacts.