Raon-1 mini: KRAFTON's 28.8B MoE, and the vLLM PR That Lasted 184 Seconds

At 06:34:19 UTC on 28 October, a pull request titled "[Model] Add Raon-1-mini support" opened against vllm-project/vllm. It was not a stub: 27 files, 3,971 lines added, 22 removed, plus a test suite and a documentation page. At 06:37:23 — three minutes and four seconds later — it was closed, unmerged, and still flagged as a draft. KRAFTON, the South Korean publisher behind PUBG, had proposed putting its new 28.8B open-weight model into the most widely deployed inference engine in the world, and then taken it back before anyone reviewed a line.

The model behind the pull request is real, and it has been downloadable since 21 October. Raon-1 mini is a hybrid-attention mixture-of-experts model that activates about 4.3B parameters per token, ships under Apache 2.0, and by 28 October had 2,208 downloads in the trailing month and 221 likes on its Hugging Face repository. What does not exist yet is the ordinary path: a stock vLLM install that can serve it without a forked wheel. That gap — between a checkpoint on the internet and a model you can put in a deployment manifest — is the whole story, and the coverage so far has mostly skipped it in favour of the benchmark table.

What KRAFTON actually published

The artifacts went up on Hugging Face on 21 October at 00:14 UTC, which is the date every Korean trade outlet used the same day. The main repository's safetensors index reports 28,783,218,402 parameters in BF16 — the "30B-class" figure in the press releases is rounding, and 28.8B is the number to carry into a capacity plan.

• Total and active parameters — 28.8B total, ~4.3B active per token.

• Licence — Apache 2.0 on the weights, configuration and components, with commercial use permitted.

• Access — the repositories are gated, but access is granted on request through a checkbox and does not appear to be manually reviewed for most requests.

• Variants — the base MXFP8 checkpoint, an NVFP4 build, a GGUF repository, an MLX checkpoint for Apple silicon, and a separate DFlash2 draft model for speculative decoding.

• Hosting — the repository sidebar reports that the model "isn't deployed by any Inference Provider". The card advertises a limited-time free trial in KRAFTON's own playground; there is no published per-token price anywhere.

• What the licence does not cover — KRAFTON's training datasets, its training methodology, undistributed software, and the hosted API and playground, which run under separate terms.

It is a preview, and KRAFTON labels it that way in the card's opening line. The company says a full release is planned alongside a technical report covering "the training process and final performance". No date was given, and the training-token count is not disclosed anywhere in the card — which is the single biggest hole in any claim about how efficient this model is to train.

The framing from KRAFTON's side is cost. Chief AI Officer Kangwook Lee described it as the product of "AI R&D capabilities accumulated for more than 5 years" and said the company intends to use a cheaper LLM to "expand the scope of AI use across various industries". Raon-1 mini is the first language model under the Raon brand, which KRAFTON has used since April for speech, TTS and vision-encoder releases.

The architecture is where the real bet sits

A 3:1 ratio of linear-attention to full-attention layers is the part worth understanding, because everything else about the model's serving economics follows from it.

• Layers — 25 total, split as 18 Raon Delta Attention (RDA) layers and 7 gated MLA layers.

• Experts — 128 in total, 6 routed plus 1 shared active per token, with an expert intermediate size of 1,088.

• Dimensions — hidden size 2,560, 40 attention heads across both layer types, RDA head dimension 128, gated MLA at 192 QK / 128 V with 576 / 512 query and KV LoRA rank.

• Position encoding — NoPE, with no rotary embedding anywhere in the stack.

• Vocabulary — 259,840 tokens, with an untied LM head.

• Activation and residuals — SiTU-GLU, with Raon-mHC residual connections across four streams.

RDA is KRAFTON's modification of Kimi Delta Attention, and the change it describes is specific: decoupling the erase and write gates and applying independent write-gate scaling after the convolution, so the raw convolution history is preserved rather than overwritten. Raon-mHC is described as a cheaper implementation of DeepSeek's mHC. Neither is a from-scratch invention, and that is not a criticism — "trained from scratch" in the card refers to KRAFTON designing and pretraining the model on its own data, not to reinventing every block in it. Two of the model's three headline techniques are re-engineered versions of published ones, and the third is a 3:1 hybrid schedule that other labs have also converged on.

The payoff is the KV cache. Because only the 7 gated MLA layers retain one, the card puts the cost at roughly 8 KiB per token in BF16. At the full 262,144-token context that is about 2 GiB per sequence — a number that fits comfortably on a single 32 GB card and would not fit at all if all 25 layers cached. This is the actual product claim hiding under the benchmark table: not that Raon-1 mini is smarter than its peers, but that long-context inference on it is cheap enough to run on hardware you might already own.

The benchmark table, counted rather than summarised

Every figure below is KRAFTON's. There is no Artificial Analysis entry for Raon-1 mini as of 28 October — the model does not appear in the site's model list at all — no arena placement, and no third-party reproduction. The card's evaluations used gpt-5.6-luna as judge and user simulator throughout, which is disclosed but not independent. Read the numbers as a vendor claim with an unusually detailed appendix.

The table has 18 rows and five columns: Raon-1 mini preview against Qwen3.6-35B-A3B and Gemma 4 26B-A4B as MoE peers, with Qwen3.8-27B and Muse Glimmer 30B shown as dense references. KRAFTON's red highlighting marks the best score within the MoE group, which is a narrower claim than "best" and is why the press line about beating "similarly sized overseas models" needs care.

Counted properly, Raon-1 mini is the outright best of all five columns on four rows:

• AA-Omniscience — 3.5, against −7.2 for Qwen3.6-35B-A3B, −0.5 for Qwen3.8-27B, −34.7 for Muse Glimmer 30B and −46.6 for Gemma 4 26B-A4B. It is the only positive score in the column, which says something real about calibration even though the absolute number is small.

• IFBench — 84.2, against 82.4 for Qwen3.8-27B and 66.6 for Qwen3.6-35B-A3B. A 17.6-point gap over its closest MoE peer on instruction following is the strongest single result in the table.

• LiveCodeBench v6 — 81.6, ahead of 81.2, 83.4, 79.3 and 77.4. Narrow, and a win by four-tenths of a point over Qwen3.6-35B-A3B.

• Chatbot Korean — 92.9, against 90.6, 90.1, 87.0 and 74.5. This is KRAFTON's own internal benchmark, explicitly not publicly released, so it is the least checkable number on the page and the one the model's positioning rests on.

It also tops the MoE group on GPQA Diamond (84.3) and SWE-Verified (70.8, its widest coding-agent margin at 7.6 points over Qwen3.6-35B-A3B), while losing both to Qwen3.8-27B at 89.7 and 74.6. That pattern — beats its own weight class, loses to the dense model one size up — repeats across the table.

The losses are not marginal and they cluster in one place:

• Terminal-Bench Lite — 47.0. This is the worst score in its own comparison row, 16.3 points behind Qwen3.6-35B-A3B and 23.7 behind Muse Glimmer 30B.

• MMLU Pro — 76.5, last of the five, 9.4 points behind Qwen3.6-35B-A3B.

• BFCL v4 — 59.8, behind all three MoE-and-dense rivals except Muse Glimmer, i.e. function calling is not where this model is strong.

• AutomationBench — 29.7, ahead only of Qwen3.6-35B-A3B's 24.9 and 29 points behind Qwen3.8-27B.

• GDP.pdf — 5.8, barely above Gemma 4 26B-A4B's 3.6.

Put together, the honest summary is narrower and more useful than the press release: Raon-1 mini is competitive on instruction following, Korean conversation, calibration and search-style browsing, and weak on knowledge recall, terminal work and tool calling. If your workload is an agent that has to chain function calls reliably, the table argues against it. If it is a long-context Korean-language assistant that follows instructions precisely, the table argues for a test.

What the vLLM pull request proposed, and what it walked back

The pull request came from a KRAFTON fork — branch feat/raon-public-candidate into vllm-project/vllm:main — and the author's own note explains the closure better than any inference: "I'm working on making simple & clean code. When I'm ready then, I will re open this PR." The PR body also discloses that OpenAI Codex assisted with the implementation and that "human line-by-line review and end-to-end validation confirmation are still pending."

What it contained matters even though it did not land, because it is a map of what upstreaming this architecture takes:

• Model and config registration, plus checkpoint loading for the 18 RDA and 7 NoPE MLA layers.

• raon_1 reasoning and tool-call parser adapters — the piece that makes the model usable behind an OpenAI-compatible endpoint rather than a raw completion API.

• Reuse of upstream ModelOpt MXFP8/NVFP4 paths, MLA, hybrid-state handling and DFlash2 interfaces, with no MoE backend forced.

• Optional raon_fast kernels for RDA and mHC, plus config and parser tests and documentation.

Roughly half the work was validated and half was not, and the PR says so plainly. Passing: 11 CPU config and parser tests, pre-commit hooks, an exact-base wheel build and install, native model, tokenizer and parser imports, pinned checkpoint integrity checks, target/draft config pairing, and NVFP4 mixed-precision config resolution. Pending, in the PR's own words: "real GPU generation, numerical/model-quality comparisons, backend/kernel execution, shared KDA regressions, DFlash2/cache/graph correctness, and serving benchmarks." It adds, "No speedup or production-parity claim is made."

The kernel constraints are the detail most likely to bite a team that reads "vLLM support" and assumes it scales. The optional fast kernels require SM10x — Blackwell-class hardware — plus tensor parallelism of exactly one, BF16 convolution history, FP32 recurrent state and a CUDA/C++ build toolchain. Pipeline parallelism, expert parallelism and RecoverSSM are unsupported. In practice that means the fast path is a single-GPU path, which is consistent with the model's whole pitch but incompatible with the way most people actually serve a 28.8B model.

What you can run this week

KRAFTON ships its own vLLM fork pinned at ref raon-1-mini-preview, documented against an NVIDIA B300 and served through an OpenAI-compatible API with tool calling. The documented launch uses --max-model-len 262144. Every route below is KRAFTON's own, and none of them is upstream:

• vLLM — install from github.com/krafton-ai/vllm at the pinned ref with VLLM_USE_PRECOMPILED=1. This is the only path to the fork's parser adapters and DFlash2 support.

• Transformers — 5.16.1 with accelerate 1.15.0, device_map="auto", and CPU offload viable on a 32 GB GPU.

• RTX 5090 — the NVFP4 checkpoint, 32,768-token context, 2,048 batched tokens, 8 sequences and a 3 GiB FP8 KV cache; it needs CUDA Toolkit 13 with nvcc present.

• DGX Spark — an ARM64 container at ghcr.io/krafton-ai/raon-vllm-spark:sm121-4e09534, running 128K context at no more than 8 sequences.

• llama.cpp — a KRAFTON branch and a GGUF Q4_K_M build, with upstream support listed as pending.

• MLX — mlx 0.32.4 and mlx-lm 0.32.2 against the separate MLX checkpoint.

The speculative-decoding draft model is worth a note because 2.18× is the number that will get quoted. KRAFTON measured it on a single B300 with an MXFP8 target model and vLLM 0.28.0 at block size 8, and describes it as "up to" 2.18× higher output throughput than autoregressive decoding, varying by hardware and workload. That is a vendor benchmark on hardware most readers do not have. It is also the kind of claim that depends heavily on acceptance rate, which depends on your prompt distribution.

Sampling is not the usual defaults and is worth copying exactly: temperature 1.0, top_p 0.95, top_k 20, no repetition or frequency penalty, and presence penalty 0 for coding and math against 1.5 for everything else. Thinking mode is on by default and the card advises against turning it off. Get the presence penalty wrong and you will conclude the model is worse than it is.

One operational caveat that has nothing to do with quality: a fork pin is a supply-chain decision. You get KRAFTON's build of vLLM, not the upstream release train — no upstream CI on your configuration, no upstream security patches until someone rebases, and every vLLM upgrade becomes a merge rather than a version bump. For a preview model being evaluated, that is a reasonable trade. For a production dependency, it is the thing to put in the risk register next to the model itself.

How to test it without betting on it

Raon-1 mini is not in the OrcaRouter catalogue, and nothing here should be read as claiming otherwise — we do not serve it. What we do serve is its comparison set, which happens to be the right control group: Gemma 4 26B-A4B at $0.06 per million input and $0.33 per million output tokens, Qwen3.6-35B-A3B at $0.248 and $1.485, and Qwen3.8-27B at $0.33 and $2.40, all at provider list price with no markup. Those are the models it was measured against, reachable through one key, which makes the useful experiment cheap: run KRAFTON's own prompts against the hosted baselines and run the same prompts against the local preview, and see whether the vendor table survives your data.

That is a better use of a week than reading the table harder. The fork install is an afternoon; the comparison is what tells you whether a 4.3B-active model with a 17.6-point IFBench lead and a 16.3-point Terminal-Bench deficit fits your workload. If a hosted baseline is already carrying traffic, routing it alongside the preview through one endpoint with automatic failover means an unproven checkpoint never sits alone on the critical path — the evaluation can run in production shape without the production risk.

What would change this assessment

Four things, in rough order of consequence.

An upstream vLLM merge, because it turns a fork pin into a version number and pulls the model into every downstream packaging, quantisation and serving tool that assumes mainline support. KRAFTON has said it will reopen the PR when the code is ready; the pending GPU validation list in the closed one is a fair description of what "ready" has to mean.

An independent evaluation, because eighteen vendor rows judged by a single model is one author's opinion at scale. The AA-Omniscience result is the most interesting number in the table precisely because it is the kind of thing an independent harness would confirm or destroy quickly.

The full release and technical report, because a preview with no disclosed training-token count cannot support any claim about training efficiency, and efficiency is the entire argument. Until that lands, "trained from scratch" is a statement about provenance, not about cost.

And a hosted endpoint with a published price, because right now the only way to use Raon-1 mini is to run it, and the only way to price it is to amortise your own GPU hours.

For now the accurate description is short. Raon-1 mini is a real, downloadable, Apache-2.0, 28.8B-total/4.3B-active model released on 21 October, with a genuinely interesting KV-cache story, a vendor benchmark table that flatters it on four rows and embarrasses it on three, a serving stack that exists only as a KRAFTON fork, and an upstream pull request that lasted 184 seconds. That is more useful than either "KRAFTON just shipped a frontier model for free" or "nothing to see until vLLM merges".