Frontier models are surprisingly good at kernel code migration. Given a clear description of an API change and the driver source code, models like Claude 3.7 Sonnet and GPT-5 Codex can generate correct migration patches for a majority of syntactic change cases. But they are expensive and slow. A single GMA run with a frontier model costs ~$0.15 and takes ~45 seconds. For an enterprise maintaining hundreds of drivers across continuous kernel updates, this adds up fast.
KERN models are our answer: domain-specific models fine-tuned on kernel evolution trajectories. They are not general-purpose code models that happen to know some kernel code. They are models that understand the intent behind API changes — why a function was deprecated, what behavioral contract shifted, what the maintainer's reasoning was. This understanding, encoded through fine-tuning on rich training examples, enables them to generate correct migration patches at a fraction of the cost and latency of frontier models.
General-purpose code models treat kernel code as "just code." They understand C syntax, function calls, pointer arithmetic, and control flow. But they miss kernel-specific patterns that are critical for correct migration:
Frontier models can handle these patterns when given sufficient context (documentation, examples, explicit instructions). But this context consumption is exactly what makes them expensive. KERN models internalize these patterns during fine-tuning, so they don't need to be provided at inference time.
The key insight behind KERN model training is that code pairs alone are insufficient. A training example that shows "old code" and "new code" teaches the model what changed, but not why. Without the "why," the model learns surface patterns that don't generalize to new API changes.
Each KERN training example is an evolution trajectory — a rich, multi-signal representation of a kernel API change and its consequences:
A single evolution trajectory might include 5-20 driver adaptations for the same API change. This is critical because different drivers use the same API in different ways, and the correct migration depends on the usage pattern. A model trained on multiple adaptations per API change learns to match the adaptation strategy to the usage context, not just to the API delta.
Our training corpus contains approximately 12,000 evolution trajectories extracted from kernel versions v4.0 through v6.8. This covers 8 years of kernel evolution across all major subsystems. The trajectories are filtered for quality: each must have a clear API change, at least 2 in-tree driver adaptations, and a commit message that explains the motivation.
We fine-tune using LoRA (Low-Rank Adaptation) adapters on top of Qwen3-Coder at two scales: 7B and 32B parameters. LoRA is the practical choice for domain adaptation — it modifies a small fraction of the model's parameters while preserving the base model's general capabilities. This matters because KERN models still need to understand C, parse diffs, and generate syntactically valid patches. We don't want to lose those capabilities in pursuit of kernel-specific knowledge.
The training objective uses GRPO (Group Relative Policy Optimization), a reinforcement learning method that optimizes model outputs against a reward signal. Unlike supervised fine-tuning (SFT), which trains the model to reproduce the golden patch exactly, GRPO rewards any patch that achieves the desired outcome. This is important because there are often multiple correct migrations for the same API change — different variable names, different ordering of operations, different decomposition of error handling. SFT penalizes valid alternatives; GRPO rewards them.
The training pipeline is:
Binary rewards are the obvious choice for code generation: does the patch compile (1) or not (0)? But binary rewards provide weak learning signal. A patch that fails compilation because of a single missing semicolon gets the same reward as a patch that is completely wrong. The model cannot distinguish "almost correct" from "completely wrong," which makes learning slow and unstable.
KERN models use a gradual reward signal that maps directly to KDRIFT's four-stage validation pipeline:
This gradual signal means a patch that compiles but fails Sparse gets a reward of 0.25. A patch that passes compilation and Sparse but fails QEMU boot gets 0.50. Partially correct patches provide proportional learning signal. The model learns that getting closer to correct is rewarded, even when the final result isn't perfect.
The choice to use AST similarity rather than a fourth validation stage (runtime analysis with lockdep/KASAN) for the final 0.25 is pragmatic. Runtime validation takes 30-60 seconds per case, which would make GRPO training prohibitively expensive (each training step requires generating and evaluating multiple candidate patches). AST similarity is computed in milliseconds and correlates strongly with runtime correctness — patches that are structurally similar to the golden reference almost always pass runtime validation.
KERN models are in active development. The numbers below are from our current best checkpoints, evaluated on the DRIFTBENCH test split:
KERN-7B matches GPT-5 Codex on DRIFTBENCH at 1/40th the inference cost. On an A100 GPU, KERN-7B processes a migration case in ~0.8 seconds, compared to ~2 seconds of API latency for GPT-5 Codex. The cost difference is entirely in compute: local inference on your own hardware versus per-token API pricing. For high-volume migration workloads (hundreds of drivers, continuous kernel tracking), this is the difference between viable and prohibitive.
KERN-32B approaches Claude 3.7 Sonnet performance, reaching 58% full-pipeline success compared to Sonnet's 61%. The 3-point gap is concentrated in Class 5-9 (semantic) changes, where the larger context window and reasoning capabilities of frontier models still provide an edge. For syntactic changes (Classes 1-4), KERN-32B matches or slightly exceeds frontier model performance — the domain-specific training compensates for the smaller model size.
Both KERN models are significantly faster than frontier models for local inference scenarios. An enterprise with a dedicated A100 can process their entire driver set against a kernel upgrade in minutes, without sending proprietary driver code to an external API. This addresses a key concern for enterprises with confidential out-of-tree drivers — the code never leaves their infrastructure.
KERN models are optimized for the LPA path — fast, template-conditioned generation for syntactic changes. They are not intended to replace frontier models in the GMA path, where tool use, iterative refinement, and deep reasoning are required. The two-tier architecture naturally accommodates this: KERN models power the fast path, frontier models power the deep path, and the escalation policy routes cases appropriately.
The practical deployment is a hybrid: KERN models handle 75% of cases locally at minimal cost, and frontier models handle the remaining 25% through the GMA with full tool access. This hybrid approach achieves near-frontier accuracy at a fraction of the cost, while keeping confidential code local for the majority of cases.
KERN models are currently in development. Enterprise early access is available for teams maintaining 10+ out-of-tree drivers. Contact us to discuss your use case and get early access to KERN-7B.