A camera sees everything and understands nothing. For decades, that has been the fundamental limitation of physical security at scale: vast amounts of footage, limited ability to act on it in real...
TL:DR – AxeleraScript allows customers to compile their own models, not just supported models with their own weights, but their own models, on Axelera hardware!
Introducing AxScript: one language, every AI workload
Among the many AI accelerator companies out there, axelera.pro is one of the few with a chip that can support any type of workload: convolutional networks (CNN), vision transformers (ViT), large language models (LLM), vision-language models (VLM), vision-language-action models (VLA), diffusion models as well as any modality: video, images, audio, text, time-series, among others . Today we are introducing AxScript, the programming language that unlocks that hardware capability, so any developer can bring their own unique workload to Axelera silicon.
Why we built it
The AI model landscape moves faster than any vendor's model zoo. Most AI accelerators ship with a fixed menu of supported models, and an increasing number of them focus solely on LLMs. If your model is on the list, you are fine. If it is not, you wait, or you leave.
We took a different view. Our hardware was designed to run the full spectrum of AI workloads. What was missing was a way to hand that capability to developers directly. AxScript is that way.
What AxScript is
AxScript is a Python-based domain-specific language for programming the axelera.pro Cores directly. Think of it as the layer that gives you the same control over our silicon that our own engineers have. An AxScript program implements a whole model: its operators, its data movement, its scheduling on the accelerator.
You can use AxScript in two ways.
Directly, as a language. Developers write AxScript programs that implement entire models. We are releasing documentation and an agentic harness that pair a developer with AI assistance to make this task dramatically simpler: the agent analyzes the source model and helps produce model-specific AxScript, while the developer keeps control of the result. The language ships with the surrounding toolkit a real porting job needs, including evaluation tooling and quantization tools, so you can measure accuracy and performance at every step.
Indirectly, via AxGraph. AxGraph is our graph compiler. It ingests models in standard formats, including ONNX and PyTorch, and compiles them automatically. This is the "play button" experience: no manual work, suitable for standard architectures where you just want your model running. In addition, developers can extend AxGraph by implementing custom operator layers in AxScript. When doing so, AxGraph will compile those layers using the custom AxScript kernels.
The two paths are not separate stacks. Whether a model arrives through AxGraph or is written by hand in AxScript, it lands on the same optimizing backend and code generation pipeline. And the two flows feed each other: performance techniques proven in hand-written AxScript are folded back into the automated compiler in regular cycles, so AxGraph users inherit optimizations first pioneered at the language level. AxScript can run ahead of the automated flow, which makes it the natural home for new model architectures, proofs of concept, and aggressive performance work.
Programmability at performance
Compiler generality does not just mean being able to compile a model. It means the result runs with high performance and accuracy, better leveraging the underlying hardware. That is the bar AxScript was built to meet. Because the language exposes the datapath directly, performance optimization can be done in a targeted way, and the complexity of a full model port stays manageable for a single engineer. That combination, programmability at performance, is a first of its kind.
"Generality is cheap if you accept low performance. AxScript is different: it gives developers direct programmability while leveraging everything the hardware can do”, says Ioannis Koltsidas, VP Software, “Programmability at full performance is what makes this a first."
The results are already visible inside Axelera. Qwen3.5, a recent model with a complex architecture that would previously have taken weeks to port, was ported as an AxScript program in one day by a single engineer assisted with AI.
"Since we released AxScript internally, we are seeing an exponential growth in the models we can support, and our customers are thrilled," says Manuel Botija, VP Product ". We cannot wait to open this to more developers and see what they produce."
One language across the roadmap
AxScript is a single language across the Axelera roadmap. The same AxScript code targets the Metis and Europa accelerators shipping today and will carry forward to future generations, including the already announced Titania. Developers who invest in AxScript invest once, and their work travels with the silicon.
Availability
Models produced with AxScript will start shipping in Voyager SDK 1.9 in September. We will initially provide language access to selected customers, followed by public availability before the end of the year. If you have a workload you thought could never run at the edge, we would like to hear about it! Join the community and share your ideas on what should get ported next.
