ZML is an inference stack built close to the hardware. It lowers models directly onto NVIDIA, AMD, TPU, and Trainium targets from a single codebase, without depending on and suffering from the Python-heavy runtime layers that most of the ecosystem is built around.
\nThe guiding idea behind zml/v1 was simplicity: give ZML a model and its weights, and the system would take care of compilation, placement, and execution for you. That made the first version approachable and effective for standard deployments, but it also baked too much behavior into implicit global state. As the project pushed into partial compilation, custom passes, sharding, quantization, and more backend-specific execution paths, those implicit shortcuts became constraints. ZML/v2 is the rewrite that makes those concepts explicit: platform ownership, compilation, memory, IO, and placement are now first-class, so advanced use cases can be expressed directly instead of forced through workarounds.
\nZML/v2 is a complete rewrite of the framework with a focus on developer experience, performance and most importantly composability. This is a fundamental departure from the original design which was a lot more turnkey but could make more complex programs a bit harder than necessary.
\nSo we’ve decided to strongly orient the design towards composability while also offering an uplift in performance.
\nThe new API centers around zml.Platforms, which is the main abstraction across accelerators, runtimes, IO etc. In ZML, a platform is instantiated and from then on used to transfer data, build, compile and execute programs.
This is how it all starts:
\nconst platform: *zml.Platform = try .auto(allocator, io, .{});\nZML offers various platforms selection mechanisms: compile-time, runtime and manual. The automatic runtime selection is the default and will pick the best available platform on the system, but users can also choose to compile for a specific platform or manually create a platform with custom options.
\nThe then built program can now run transparently on all comptime-time enabled platforms, which can be enabled via the --@zml//platforms:{cuda,rocm,tpu,neuron}=true build flags. Doing so will download the runtime, strip it to its bare minimum and embed it inside the binary sandbox.
For instance, here is the entire CUDA sandbox:
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n \n \n \n \nZML/v2 enables the explicit allocation and use of pinned memory. Pinned memory is memory that is not movable nor swappable and thus can be directly accessed by the DMA engine of the accelerators. This functionality is exposed via the zml.mem.DmaAllocator which, combined with Zig’s explicit allocator model, enables unique optimizations and removes extraneous copies found in other frameworks.
Data transfers between host and accelerator now compose with std.Io.Writer via zml.io.MemoryWriter, enabling zero-copy and overlapped data movement across the board.
For instance, loading a model from disk to GPU memory now happens at SSD speed when using O_DIRECT, even with staging through the system memory, since transfers are overlapped. This enables NVIDIA GPUDirect-like performance on raw POSIX.
\n\n\n\n\n\nThanks to injectable std.Io, ZML implements a full userland VFS built into the program. It supports local files, HTTP endpoints, S3 buckets and Hugging Face repositories. Concretely, this means that models can be loaded directly from each of those sources without downloading to disk first, regardless of the underlying FS implementation.
Let’s try to register an HF implementation and load the tokenizer directly from Hugging Face:
\nvar vfs: zml.io.VFS = try .init(init.gpa, init.io);\ndefer vfs.deinit();\n\nvar hf_vfs: zml.io.VFS.HF = try .auto(init.gpa, init.io, &http_client, init.environ_map);\ndefer hf_vfs.deinit();\ntry vfs.register("hf", hf_vfs.io());\n\n// Use the VFS IO from now on\nconst io = vfs.io();\n\nconst tokenizer: zml.Tokenizer = blk: {\n const file = try std.Io.Dir.openFile(.cwd(), io, "hf://Qwen/Qwen3-8B/tokenizer.json", .{});\n defer file.close(io);\n var reader = file.reader(init.gpa, &.{});\n const bytes = try reader.interface.readAlloc(init.gpa, try file.length(io));\n defer init.gpa.free(bytes);\n break :blk try .fromBytes(init.gpa, io, bytes);\n};\nOr load the model directly from Hugging Face:
\n\nSharding is now a first-class citizen of the programming model instead of an implicit backend detail. We introduce a new public zml.sharding API with PhysicalMesh, LogicalMesh, Strategy, Sharding, and Placement. Compile / load / buffer APIs now take explicit sharding information and finally zml.ops.manualComputation expresses a shard-local primitive similar to JAX’s shard_map.
It also fully leverages Shardy or GSPMD based on the target platform transparently.
\nZML/v2 provides a pluggable attention backend system, giving a clean way to select and configure different attention implementations without rewriting model code around each kernel.
\nInstead of baking backend-specific logic into every call site, zml.attention exposes an explicit Backend plus backend-typed Parameters, Metadata, and paged-attention Context, so the same high-level attention path can target vanilla behavior or optimized CUDA FlashAttention variants like Tri-Dao’s FA2 and FA3.
The backend is selected automatically based on the platform and accelerator.
\nIn this release, we took the opportunity to integrate FlashAttention 2 and 3 built on CUDA for sm80 up to sm121.
Our build now runs entirely on the 100% hermetic LLVM toolchain @llvm. This enables full reproducibility, better cross-compilation support, and a more consistent development experience across platforms. This means that ZML supports remote execution on services such as BuildBuddy or NativeLink.
\nOn macOS, we no longer rely on Xcode nor Command Line Tools to build ZML. The macOS SDK is downloaded as part of the build.
\nCross compilation is also fully supported, enabling fully working containers for any supported ZML platform to be built right from a Mac.
\nTry it today via the llm CLI:
\n\n