Every figure here is labelled measured or projected and carries its source. The live chat is on the home page; this page is the working record. Preliminary · rev 0.7 · 2026-10-25
A 27B model reads about 15 GB of weights for every token; on today's hardware that memory traffic is the cost, in dollars and in watts. QNM-27 is a decode engine built around that fact: shaped to one model family, fed from memory, with nothing on the chip that does not move or multiply those bytes. Qwen3.8-27B already runs on it, on an FPGA, bit for bit against the reference. The chip is a projection. The run is not.
Talk to the device live on the home page when a session is up. Below: a replay of the recorded run from 25 October 2026, 03:18 UTC: the official Qwen3.8-27B weights in our 4-bit format, all 64 layers executed by the QNM-27 kernel on an AWS F2 (Virtex UltraScale+ with HBM), the output checked against the reference bit for bit. Timings are the ones the host logged; nothing is simulated.
Official checkpoint 1d4bf0f, 27.78 B parameters, 48 Gated DeltaNet layers and 16 full-attention layers.
Packed once, 24 HBM channel images of 0.53 GiB, loaded over PCIe in 8 s and kept resident.
Every hidden state, every recurrent state and every attention cache row matched the reference bit for bit; next token 220, the same as the fp32 reference.
64 layers end to end on the device, evening run with the fused recurrence: 180 ms in the DeltaNet recurrence (was 400), 102 ms in the MLPs, 24 ms in attention, 7 ms in the final norm and output projection. The replay above is the morning run.
The demonstrator is an F2 instance we bring up for a session; a live run follows exactly the path shown here. It is not kept on around the clock.
One token has run on hardware. Multi-token generation with device-resident state is bit-exact in simulation for 128 tokens and is the next hardware step.
Running a capable model on a device, a robot or a private server is paid for in bytes moved. One decoded token at batch 1 and 4k context, with 4-bit MLP and 6-bit attention weights, splits like this.
15.3 GB × 8 bits × 6 pJ/bit for LPDDR5X, against 25.6 billion int4 × int16 MACs at about 0.12 pJ each. The compute bar is drawn to the same scale; at about 0.4% of the memory bar it is barely visible. Lower energy per token comes from moving fewer bytes and moving them efficiently. A general-purpose GPU spends most of its silicon and power on things a decode loop never uses: on an L40S we measured 5.7 to 8.9 J per token for this model, against a 0.73 J memory floor.
Qwen3.5-27B, Qwen3.6-27B and Qwen3.8-27B share one architecture and differ only in weights. QNM fixes the shapes and operators in hardware and keeps the weights in memory, so one chip runs all three and any fine-tune. Fixing the architecture is what lets the datapath stream weights at the memory's pace with no instruction fetch, no cache hierarchy and no scheduler in the way; the arithmetic is ordinary, the byte traffic is not.
Decode reads the whole model once per token, so the design is judged by bytes moved, not operations.
One tape-out runs Qwen3.5, Qwen3.6, Qwen3.8 and your fine-tunes. New weights are a file, not a new chip.
A register and command interface any Arm or RISC-V host can drive. A hardware sequencer runs each token.
Every figure here is labelled as measured or projected, and the data behind it ships with the evaluation package.
QNM is a block, not a chip. Your memory controller feeds it weights and your CPU tells it what to run. Interface below is the planned M2 definition.
Correctness before performance claims. Everything below is reproducible from the repository and ships with the evaluation package; FPGA results are from the AWS F2, GPU baselines from an L40S we instrumented ourselves.
Qwen3.8-27B, all 64 layers on the 24-engine kernel at 250 MHz core and 400 MHz HBM: every hidden state, recurrent state and attention cache row matched the reference, 0 of 248,320 logits differ, next token identical to the fp32 reference. Hardware program time 533 ms in the morning run and 313 ms in the evening run with the fused recurrence. Two runs, 25 October 2026.
Stage 1 kernel, 16 October: 32 int4 GEMV engines fed by 32 HBM channels at 450 MHz. All seven layer-3 weight matrices matched the golden model bit for bit (23,552 results, 0 mismatches) and a 1.72 GB weight stream sustained 93.9% of the 460.8 GB/s memory peak. The full-model kernel runs 24 engines at a 400 MHz memory clock.
Consecutive greedy decode steps of a reduced-size model through the real RTL, with the recurrent state kept on the device, the KV cache growing and the convolution ring wrapping: every logit of every step matched the golden model.
Worst relative error between our reference model and the official implementation, across all 64 layers in fp32 on real activations.
Floating-point datapath vectors checked against the golden model, and mismatches. Round-to-nearest-even with flush-to-zero.
GEMV row engine RTL against the golden model at 4, 6 and 8-bit weights, including real Qwen weight rows of length 17,408, with random stalls on both interfaces.
GPU baseline: Qwen3.8-27B, llama.cpp Q4_0 on an L40S at batch 1, 71% of peak memory bandwidth, about 230 W during decode.
Second GPU baseline: Qwen3.8-27B official FP8 checkpoint in vLLM 0.31 on the same L40S, batch 1, 4,096-token context, about 224 W. The L40S has no native FP8 math, so vLLM falls back to a weight-only kernel.
Round-to-nearest quantization, no calibration. Wikitext-2 perplexity over 65,536 tokens; zero-shot ARC-Challenge and HellaSwag over 500 questions each, normalized accuracy, about ±2 points of sampling noise. Plain 3-bit rounding costs 17% or more in perplexity, so 3-bit needs a calibrated method; that study is not yet run.
| Weight format | Bits / weight | Perplexity | vs bf16 | ARC-C | HellaSwag |
|---|
Batch-1 decode on a Qwen 27B-class model. Lower is better.
GPU and SoC figures are whole-card or whole-module power; QNM figures are accelerator plus DRAM, which favours QNM. L40S speed and power were measured by us on Qwen3.8-27B with llama.cpp Q4_0 and with vLLM on the official FP8 checkpoint. RTX 5090 speed is third-party measured and its decode power is reported, not measured. Thor and Strix Halo power is estimated within their published power modes. The FPGA demonstrator is not on this chart: an FPGA is a correctness and architecture vehicle, and its energy per token says nothing about the ASIC.
Cost per million generated tokens, batch 1, from our parametric ASIC model against hardware we measured or whose figures are public. The hardware numbers are fixed; the sliders are the assumptions every such number hides. Move them and see which way the comparison goes.
Every row is a projection from our parametric ASIC model at N5. Conservative and optimistic columns span the uncertainty in memory energy, utilization, wafer cost and DRAM prices. Power counts the accelerator and its DRAM.
| Parameter | Conservative | Typical | Optimistic | Unit |
|---|
Batch 1 at 4k context. MTP verifies a draft token from the model's own multi-token-prediction layer in the same weight pass. Weights: 4-bit MLP, 6-bit attention, group 128, entropy-coded at 60% of the measured ideal. Model and sources ship with the evaluation package.
We are looking for three teams whose product needs a capable local model inside a power and cost budget that a GPU does not fit: robots, industrial edge systems, private inference appliances. A design partner gets the FPGA system to run their own prompts and fine-tunes, the evaluation package, and a say in the first silicon configuration.
A real workload: the model size you need, the tokens per second that make it useful, the watts and dollars you can spend per unit. A willingness to run it on our hardware and tell us where it falls short.
Scheduled time on the FPGA demonstrator with your prompts, the numbers we measure with you, the RTL evaluation build under NDA, and a seat at the table when the Edge configuration is fixed.
A short written statement of fit after the evaluation, good or bad. Paid pilots once the hardware earns it; nothing before.
Vendor-independent RTL and everything needed to evaluate it, kept separate from FPGA-vendor and cloud-specific integration.
Parameterized SystemVerilog, 4/6/8-bit weight paths.
Normative formats with a bit-exact Python golden model.
cocotb and Verilator regressions, vector testbenches, real-weight tests.
Weight packer, tokenizer and decode loop with host fallback.
AWS F2 reference design, deployment scripts and the recorded run above.
Area, power and cost model with every input sourced.
Jack Al-Kahwati is the founder of StarDrive Inc. and runs the Valley Semiconductor program inside it. His background is systems engineering across aerospace, autonomy and software, building things that have to work in the field under power, mass and cost limits, which is the constraint this chip is designed around.
The engineering log below is the working record of this program: every build, every failure and every measurement, dated. That record, not this paragraph, is the credential.
Dated progress, newest first.
The site gained a chat box that talks to the FPGA when a session is up (one device, one conversation at a time, every token off the hardware), an economics lab driven by the ASIC model, and an open call for three design partners. The chat server has run against a software stand-in; its first turn on the real device is the next hardware step.
The timing-repair build closed every constraint (core clock worst slack 0.000 ns, hold +0.007) after a frightening post-placement number that turned out to be an unchanged matrix engine placed badly. Its image ran the token on the F2 at 22:28 UTC: bit-exact again, 0.313 s of hardware time against 0.533 in the morning, the DeltaNet sublayer at 3.75 ms per layer exactly as the cycle count predicted, and no more state traffic through the host.
The program takes the name Valley Semiconductor. The core keeps its part number, QNM-27. Nothing else on this page changed with the name.
The fused-recurrence build missed the 250 MHz core clock by 83 picoseconds on three new paths in the vector unit: the state-row address arithmetic in the register-file address mux, the streamed operand reaching the lane in one cycle, and the store-slot decode. No image was made from it. The repair registers all three, changes no arithmetic, and passed every bit-exact suite including the 128-token decode before the rebuild started.
Three quarters of the 533 ms went into the DeltaNet recurrence, which the vector unit was running as 48-cycle descriptors at 8% lane utilization. A new fused instruction streams the 128 state rows through the lanes with no drain between rows: 37,500 cycles per value head became 13,600, bit for bit. The recurrent state now lives in HBM between tokens instead of crossing PCIe, which removes 7.9 s from each token. Predicted hardware time per token after both changes: about 313 ms.
Qwen3.8-27B, all 64 layers, on the AWS F2 at 03:18 UTC. Every hidden state, recurrent state and attention cache row matched the reference, the logits matched exactly, and the next token was the reference's. Hardware program time 533 ms; the token took 8.4 s end to end because each recurrent state was staged through the host. The run above is the replay of that log.
The first full-model attempt hung on about one matrix-vector product in ten. Simulation at full engine count reproduced it: the result writer's four-entry queue overflowed when eight results arrived back to back at two pieces per beat. Sixteen entries and a bookkeeping fix cleared it; the hardware high-water mark is now 4 of 16.
The 32-engine full-model kernel would not route at 250 MHz; the shortfall was wire, not logic. Twenty-four engines, each owning one HBM channel of 640 MiB, closed the core clock with zero slack. The 32-channel weight images were repacked to 24 channels on the F2 itself.
The Stage 1 kernel ran on an AWS F2 FPGA. Every result for seven real Qwen weight matrices matched the golden model bit for bit, and a 1.72 GB weight stream sustained 432.7 GB/s across all 32 HBM channels. Two host-side traps cost a few hours: the AWS clock generator holds the design in reset until software releases it, and a Python register write was being split into three PCIe transactions.
Twelve place-and-route builds. The last three failures were all on the 450 MHz memory clock: an unregistered FIFO, a level compare driving three sets of write enables, and finally 1.8 ns of plain wire from the far-edge HBM ports to readers placed near the compute array. Two register stages on the read data fixed it.
3-bit MLP weights with 6-bit attention raise perplexity from 6.94 to 8.15, and full 3-bit reaches 10.33. Getting below 4 bits per weight will need calibrated quantization, which is the next compression experiment.
Qwen3.8-27B FP8 in vLLM 0.31 on the L40S: 25.0 tok/s at batch 1 with a 4,096-token context, about 224 W, roughly 8.9 J per token. llama.cpp Q4_0 remains the faster GPU baseline at 40.6 tok/s.
4-bit MLP with 6-bit attention scores 59.0% on ARC-Challenge and 73.8% on HellaSwag, against 58.8% and 74.6% for bf16, within sampling noise. Full 4-bit loses 2 points on HellaSwag.
Qwen3.8-27B on an L40S with llama.cpp Q4_0: 40.6 tok/s at batch 1, 71% of peak memory bandwidth, about 230 W, 5.7 J per token.
Our reference matches the official implementation to a worst-case relative error of 1.6 × 10⁻⁷ in fp32 on real activations.
The matrix-vector engine matches the golden model bit for bit at 4, 6 and 8-bit weights, including real Qwen weight rows. 3.8 million arithmetic test vectors, zero mismatches.
Shapes and operators fixed in hardware, weights loaded from memory, so one design runs every Qwen 27B release.