Apache TVM FFI: One C ABI for Kernels, DSLs and Frameworks

The wheel-count problem TVM FFI is built to remove

A kernel library that wants to reach PyTorch, JAX and CuPy usually ends up maintaining a separate binding for each, plus a build matrix across Python versions. The README frames the goal plainly: "ship one wheel to support multiple frameworks, Python versions, and different languages." The named beneficiaries are kernel libraries such as FlashInfer, kernel DSLs such as TileLang and cuteDSL, frameworks and runtimes including PyTorch, JAX and PaddlePaddle, and ML infrastructure projects that need Python, C++ and Rust interop. The repository also lists coding agents as a target, describing a unified mechanism for shipping generated code in production. That is a wider audience than a typical FFI project claims, and it tells you the design is trying to sit underneath the tooling rather than inside one framework. If your extension is Python-only and consumed by one framework, the value here is close to zero; the payoff appears when the same compiled artifact has to be loaded by several hosts.

What the ABI actually carries: a C boundary, DLPack tensors and a compact call convention

The core is a stable, minimal C ABI. Around it sit three documented pieces. First, tensor interchange uses the DLPack protocol, which the README describes as zero-copy interop across PyTorch, JAX and CuPy. Second, there is a compact value and call convention covering common data types, which the README positions for ultra low-overhead ML applications. Third, multi-language support is listed out of the box for Python, C++ and Rust, with a stated path toward more languages. The concepts documentation splits the model into named parts: Any, Object and Class, Tensor, Function and Module, plus exception handling. The repository layout matches that story: include/ holds the headers, src/ the implementation, python/, rust/ and addons/ the language surfaces, and examples/ carries runnable directories for abi_overview, stable_c_abi, kernel_library, cubin_launcher, inline_module, python_packaging and rust_stubgen. Packaging tooling is documented separately for Python, stub generation and C++ tooling, which is the part most adopters underestimate.

Installing apache-tvm-ffi and running a first example

The README gives a pip install for the package and a compatibility package for older PyTorch. The second line matters if you are on torch 2.9 or earlier, because the README labels torch-c-dlpack-ext a compatibility package for torch <= 2.9.

pip install apache-tvm-ffi
pip install torch-c-dlpack-ext  # compatibility package for torch <= 2.9

After that, the quickstart is the entry point, and the repository ships example directories you can read before writing anything. The one that corresponds most directly to the ABI description is examples/stable_c_abi/, with examples/quickstart/ covering the basic flow. The pyproject.toml declares requires-python >= 3.9 and a single runtime dependency, typing-extensions>=4.13, with a comment that 4.13 added get_annotations. There is also an optional cpp extra that pulls in ninja, and a torch dependency group that adds torch, setuptools, ninja, numpy and ml_dtypes. If you plan to build from source rather than install the wheel, the documentation points at a Build from Source page under the developer manual; the README does not inline those steps, so treat the docs site as the source of truth for a source build.

The RFC stage is the real constraint, not the feature list

The README states that C ABI stability is the top priority and then, in the same section, that the project is in an RFC stage. Main features are described as complete and ABI stable, but the project says it recognizes potential needs for evolution and plans to stay in the RFC stage for three months from the v0.1.0 release. The versioning rule during that window is explicit: releases are 0.X.Y, where a bump in X indicates C ABI-breaking changes and Y indicates other changes. After the RFC stage the project intends to follow semantic versioning. Read that as a warning about pinning. If you vendor a compiled kernel that talks to this ABI, a 0.X bump can break it, and you should pin an exact version rather than a range. The recent tags bear this out: v0.1.13-post2, v0.1.13-post3 and v0.1.14-rc4 all sit inside the 0.1 series, with post releases and a release candidate in the same window. The README does not document a rollback procedure or a compatibility shim between 0.X versions, so plan your own pinning and test matrix.

Where TVM FFI is the wrong tool

If your artifact is consumed by exactly one Python version inside one framework, the ABI layer is overhead you will pay for and never collect on. The same is true if you need a frozen interface today: the RFC stage means C ABI-breaking changes are permitted on X bumps, and no page in the README promises otherwise. A second boundary is language coverage. Python, C++ and Rust are listed as out of the box, with the README saying only that there is a path towards more languages; if your host language is not among those three, the documentation does not claim support. A third boundary is scope. The README does not present this as a build system, a code generator or a runtime scheduler. It is an ABI and an FFI. Projects looking for a compiler stack or an execution engine are looking at a different layer, and the naming similarity to Apache TVM does not make this the same product. Finally, the pyproject classifiers mark the package as Development Status 4 - Beta, which is consistent with the RFC labelling and should temper any assumption of long-term interface guarantees.

How it differs from writing your own pybind11 or C extension layer

The common alternative is a hand-written binding per framework, typically pybind11 or a C extension with its own tensor marshalling. That approach gives you total control and no external ABI to track, and for a single-target library it is often the shorter path. The difference in approach is where the convention lives. A pybind11 module exposes your functions through Python's C API, so the contract is Python's, and every additional host (JAX, CuPy, Rust) needs its own adapter. TVM FFI puts the contract in a C ABI with a documented value and call convention, then layers Python, C++ and Rust on top of it, with DLPack handling tensor exchange so the same compiled library can be loaded by different hosts. The cost is that you now depend on a project in an RFC stage and must follow its versioning. The benefit is that the adapter work is written once, by the project, instead of once per host, by you. That trade is worth taking only when you actually have more than one host.

Licence, packaging and what maintenance costs look like

The project is Apache-2.0, and the repository carries the standard Apache layout: LICENSE, NOTICE, KEYS, a licenses/ directory and ASF headers on source files. The pyproject.toml also declares license text Apache 2.0 and the Apache Software License classifier. For most adopters this is a permissive licence with an explicit patent grant and a NOTICE obligation, but the exact terms are in the LICENSE file and this is not legal advice. On maintenance, the last push to the repository was on 2026-09-10, and the most recent tags are v0.1.14-rc4 from 2026-09-01, v0.1.13-post3 from 2026-08-10 and v0.1.13-post2 from 2026-08-04. The upgrade cost is the part to budget for: during the RFC stage an X bump can break the C ABI, so any compiled artifact you ship against it needs to be rebuilt and retested, and the README does not describe a compatibility layer that would let you skip that. Keep an eye on the release process page under the developer manual if you need to know how tags are cut.

Editorial conclusion

Adopt TVM FFI if you maintain a kernel library or a kernel DSL and you are tired of rebuilding the same binding layer for every framework and Python version, and if you can absorb ABI-breaking changes during the RFC stage. Do not adopt it if you need a frozen ABI today, or if your extension is a single Python-only package with no other consumer. Before committing, read the Stable C ABI page, confirm which release tag you are pinning, and check whether every target framework you ship to is listed in the quickstart.

Frequently asked questions

Official sources

1. apache/tvm-ffi on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases