torch-conv-kan: Convolutional Kolmogorov-Arnold Network layers for PyTorch

What torch-conv-kan actually changes about a convolution

A standard convolution is a weight matrix that slides over the input: elementwise multiply, then sum into one output pixel. torch-conv-kan keeps the sliding and the summation and replaces the weight matrix with a set of univariate non-linear functions, one per kernel position. The README states the difference plainly: "the 'traditional' convolution is a matrix of weights, while Kolmogorov-Arnold convolutions are a set of functions." The kernel is no longer a lookup table of scalars but a small function bank that gets evaluated at each input value.

The project is aimed at people who already train vision models in PyTorch and want to test whether that substitution pays off. It ships the layers, the models that wrap them, and the training scripts. The README also points to the paper behind the design, Kolmogorov-Arnold Convolutions: Design Principles and Empirical Studies (arXiv 2407.01092), so the repository is a companion to a research result rather than a general-purpose library. If you want a drop-in nn.Conv2d replacement for production, this is not that, and the README never claims it is.

The function basis is the whole design decision

The open question in a Kolmogorov-Arnold convolution is what the univariate functions should be. torch-conv-kan answers it by shipping several families side by side. The README lists KANConv1DLayer, KANConv2DLayer and KANConv3DLayer for the B-spline formulation from the original KAN work; KALNConv layers for a Legendre polynomial basis; FastKANConv layers; plus ChebyKAN, Gram, WavKAN, JacobiKAN, BernsteinKAN, ReLU KAN and Bottleneck KAN convolutions added over successive updates. Each family is a different answer to the same question, and the repository expects you to pick.

That structure has a cost. The layer names are not interchangeable in behaviour, only in interface, and the README does not present a decision table telling you which basis wins on which dataset. The empirical comparisons live in the paper and in reports/, not in the README prose. The 2026/08/17 update adds ConvNeXtKAGNBlock, described as a ConvNeXt V2-style block with a Gram KAN layer in place of the MLP, and KAGNConv1DLayerV3, KAGNConv2DLayerV3 and KAGNConv3DLayerV3 with a built-in GRN. So the surface area keeps growing, and picking the right layer is genuinely on you.

Installing torch-conv-kan and running a first KAN convolution

There is no published package. The repository is the distribution channel: clone it and install requirements.txt, which pins torch, torchvision, accelerate, hydra-core, omegaconf, timm, einops, lion-pytorch, ray[tune], optuna from git, and a long tail of training and metrics dependencies.

git clone https://github.com/IvanDrokin/torch-conv-kan
cd torch-conv-kan
pip install -r requirements.txt

Expect that install to be heavy. optuna is pulled from a git URL rather than PyPI, and ray[tune] plus albumentations and medpy come along even if you only want the layers. The README does not document a minimal subset, so there is no supported lighter install path for inference-only use.

The repository layout gives you the entry points: cifar.py, tiny_imagenet.py and imagenet_1k.py are the top-level training scripts, configs/ holds hydra configs, and train/ holds the accelerate-based training code. The README does not spell out the exact config names or the argument syntax for those scripts, so read configs/ before running one. The README does state that the training code is accelerate-based, so a multi-GPU or mixed-precision run goes through accelerate launch rather than plain python. What you should see on a successful start is the hydra config dump followed by per-epoch progress from the trainer.

Model zoo, pretrained weights and the one number worth quoting

The repository does not stop at layers. The README lists ResNet-like, U-Net-like, U2-Net-like, MoE-based, VGG-like, DenseNet-like and RDNet-like models, with baseline implementations kept under models/baselines so you can compare a KAN variant against its conventional counterpart in the same codebase. That pairing is the most useful part of the layout: the comparison is built in rather than left to you.

Pretrained weights exist. The 2024/05/31 update announces Imagenet1k pretrained weights and training scripts; the 2024/06/20 update announces a VGG11-style model with Bottleneck Gram convolutions reaching 68.5% Top1 on the Imagenet1k validation set with 7.25M parameters. That is the concrete result the project offers, and it is a fair one to weigh: a compact model, a specific basis, a stated accuracy. The README does not give the training compute behind it, so you cannot judge the cost side from the README alone.

The TODO list is honest about what is unfinished: VGG19-like and ResNet50-like models were training on Imagenet1k at the time of writing, finetuning and PEFT exploration were in progress, and pruning and visualization methods were still being worked on. The project status line at the top says "Under Development" in the README's own words.

Where torch-conv-kan is the wrong tool

The API is not stable. The README's own update log is a sequence of fixes and additions: a bug fix in trainer.py's output hook on 2024/05/23, a memory leak fix in trainer.py on 2024/05/25, a KACN Conv instability fix on 2024/05/31, and a note on 2024/06/15 that LBFGS optimizer support "is not well-tested, please raise an issue if you face any problems with it." A repository that ships its own memory leak and instability fixes is one where you should pin a commit rather than track main.

There are no tagged releases. Nothing in the repository indicates a version number, a changelog file, or a semantic versioning policy, so there is no upgrade path other than diffing commits. Combined with a last push on 2026-08-20, the project is recent but shows no release discipline.

Finally, the deployment story is absent. A Kolmogorov-Arnold convolution evaluates a bank of functions per kernel position instead of multiplying by stored scalars, and the README does not discuss export to ONNX, TorchScript, TensorRT or any quantized runtime, even though the opening paragraph mentions quantization as a topic the project demonstrates. If your constraint is latency on a fixed accelerator, the README gives you nothing to plan against.

torch-conv-kan against Efficient-KAN and the wider KAN layer ecosystem

The nearest comparison is the KAN layer ecosystem itself, including Efficient-KAN. The difference is scope, not quality. Efficient-KAN and similar projects implement the KAN layer as a drop-in for an MLP: you get a layer, you place it in your own network, and the surrounding architecture is yours. torch-conv-kan starts from the convolution and goes outward, shipping 1D, 2D and 3D convolutional KAN layers plus whole ResNet, VGG, DenseNet, U-Net and ConvNeXt-style models with training scripts, hydra configs and Ray Tune hyperparameter search.

If your problem is a tabular or sequence model where you want to replace a linear layer, a general KAN implementation is the smaller dependency and the clearer fit. If your problem is an image model and you want to know whether a Gram or Bernstein basis beats a plain convolution at the same parameter budget, torch-conv-kan is built for exactly that question, and its models/baselines directory is the reason. The trade-off is that you inherit the full requirements.txt, including ray[tune] and the git-installed optuna, whether or not you run a sweep.

Maintenance, licence and what a version bump costs you

The repository is not archived, and the last push was on 2026-08-20, which is recent enough that the project is being touched, though the absence of releases means there is no maintenance signal beyond commit activity. The README's update log runs from May 2024 to August 2026 with long gaps, so the cadence is bursty: a run of daily updates in mid-2024, then a single entry two years later adding ConvNeXtKAGNBlock and the V3 layers.

Upgrading means pulling main and re-reading the update log, because layer signatures changed along the way, for example the WavKAN reimplementation on 2024/05/27 described as "much faster now" and the V3 layers with built-in GRN. Pin a commit hash in your own environment and record which one, since the project gives you no tag to name.

The licence is MIT, as stated in the repository's LICENSE file and metadata. MIT is permissive: it allows commercial use and modification with the copyright notice and permission notice retained. That is a statement about the licence text, not legal advice, and the paper behind the design (arXiv 2407.01092) is a separate artefact with its own terms if you plan to cite or redistribute it.

Editorial conclusion

Adopt torch-conv-kan if you already train PyTorch vision models and want to swap a standard convolution for a function-based kernel without rewriting your training loop, or if you are reproducing the Imagenet1k VGG11 Bottleneck Gram result at 68.5% Top1 with 7.25M parameters. Do not adopt it if you need a stable, documented API, if you depend on a maintained release cadence (there are no tagged releases), or if you need inference on edge hardware where a learned per-location function bank has to be evaluated. Verify first that the layer class you plan to use has a matching baseline in models/baselines, and check the last push date against your own tolerance for churn.

Frequently asked questions

Official sources

1. Issues
2. IvanDrokin/torch-conv-kan on GitHub
3. License: MIT
4. README