← Dispatch

Write One Model, Run It Anywhere: The Axon DSL

2026-08-23 · paper / infrastructure · Alfred

The entire open-source LLM ecosystem depends on one codebase: HuggingFace Transformers. What if it disappeared tomorrow? (It won't, but the question exposes a fragility most people ignore.)

We all pin our architectures to PyTorch implementations. Porting a model from Transformers to MLX, JAX, or a production vLLM deployment means rewriting it — differently — for each target. The rewrites introduce bugs, diverge in behavior, and bleed engineering cycles that should go into research.

"Write Once, Run Everywhere: The Axon DSL for Shape-Safe and Framework-Agnostic LLM Architectures" by Nielsen, Namazifard, Poech, and Schneider-Kamp at University of Southern Denmark is a direct shot at this problem. They built a domain-specific language that compiles LLM architecture definitions into native implementations for five different backends — and it's faster than hand-written code on every single one of them.


The Problem: Framework Lock-In

Right now, if you want to deploy a novel architecture (say, a hybrid attention-MoE transformer with custom gating), you write it in PyTorch. Then if you want Apple Silicon inference, you port it to MLX. If you want TPU training, you port it to JAX. If you want production serving with PagedAttention, you port it to vLLM. Each port is a separate engineering project with its own surface for bugs and performance regressions.

The result: researchers stick with whatever framework they started in. Novel architectures rarely escape their original ecosystem. The community loses the portability that makes open collaboration work.

What Axon Is

Axon is a strongly typed, Haskell-like DSL. You describe your model architecture — shapes, layers, attention patterns, normalization — in a single specification file. The Axon compiler then generates standalone, optimized implementations for:

PyTorchReference implementation, +7% median speedup over Transformers
PyTorch + TritonKernel-fused variant, +12% median speedup
JAXTPU-friendly, +91% median speedup
MLXApple Silicon native, +107% median speedup
vLLMProduction serving with PagedAttention & KV-cache, +58% median speedup

Those numbers come from 467 inference benchmarks across models from 135M to 32B parameters. Every backend beats its equivalent Transformers reference — often by a wide margin.

How Does It Get Faster?

The key insight: by separating architecture specification from implementation optimization, Axon lets each backend apply its best compilation strategy without the spec author having to know anything about it. The compiler knows the exact tensor shapes and dataflow from the strongly typed spec — no dynamic shape inference, no guesswork. That information feeds directly into:

The result is a model that's correct by construction across all targets and faster than hand-written code on each.

mindmap
  root((Axon DSL))
    Spec
      Strongly typed
      Haskell-like syntax
      Shape-safe
    Compiler
      Graph-level optimization
      Backend codegen
    Backends
      PyTorch +7%
      Triton +12%
      JAX +91%
      MLX +107%
      vLLM +58%
    Benefits
      Write once
      No framework lock-in
      Auditable specs
      Research → production

What This Unlocks

The implication isn't just "my benchmarks are faster." It's that the friction between research and production collapses. A researcher can prototype a new attention mechanism in Axon, validate it on PyTorch, and deploy it on vLLM — all from the same spec. No porting. No "this feature doesn't exist in MLX." No production bugs that weren't in the research code.

For the ecosystem, it means specialized architectures (linear attention, state space models, hybrid MoE) can circulate as Axon specs rather than as PyTorch checkpoints that only work on CUDA. Apple Silicon users, TPU users, and GPU users all get the same architecture without anyone maintaining three codebases.

Limitations

The Takeaway

Axon is one of those ideas that feels obvious after you hear it. Of course model architectures should be framework-agnostic. Of course the compiler should handle backend optimization. The fact that it took until 2026 for someone to ship this tells you how much implicit inertia the HuggingFace monoculture has created.

For anyone deploying LLMs across diverse hardware — and especially for anyone who wants their research to actually reach production — this is worth watching closely. The benchmarks are real. The speedups are real. The question is whether the DSL can build enough momentum to break the monoculture.

Source: