SpikingJelly: A PyTorch Framework for Spiking Neural Networks

The gap SpikingJelly fills between event data and a trainable model

Spiking neural networks are usually presented as a separate research stack: a simulator, a dataset format, and a training loop that does not look like the deep learning code most engineers already write. SpikingJelly's stated position is narrower and more practical. It is a PyTorch-native framework for SNNs, and the README's first bullet under Why SpikingJelly is a beginner-friendly API, followed by ANN2SNN conversion, event-based datasets and acceleration backends. The intended user is someone who already has PyTorch, torchvision and torchaudio installed and wants spiking behaviour inside that same model definition rather than beside it. The repository topics point the same way: pytorch, snn, deep-learning, dvs. If your work involves DVS cameras, gesture or speech event streams, or converting a trained artificial network into a spiking one, this is the audience the project is written for. If you need a general-purpose simulator for computational neuroscience rather than a training framework, the README does not describe that use case.

LIFNode, surrogate gradients and the shape of a SpikingJelly model

The mechanism is visible in the Quick Start. A network is an nn.Sequential built from spikingjelly.activation_based modules: layer.Flatten, layer.Linear, and neuron.LIFNode with tau=2.0 and surrogate_function=surrogate.ATan(). So the spiking neuron is a module in the graph, not a special training regime. The README describes the modelling area as activation-based SNN components: spiking neurons, surrogate gradients, stateful and stateless modules, plus predefined SNN models. Surrogate gradients are the piece that makes this trainable at all, since a spike is not differentiable; the surrogate function supplied to the neuron stands in for the derivative. Statefulness matters for data flow: a spiking neuron carries membrane state across time steps, which is why the framework talks about multi-step execution and why backends are compared on multi-step LIF neurons. The backend is chosen when the neuron is created and, per the README, can be changed later, and all backends are stated to be compatible with torch.compile. That last point is the one that separates this from a hand-written CUDA extension: the spiking operations stay inside the compiled PyTorch graph.

Installing it and the version constraints that will bite first

Installation is deliberately unglamorous. The README says to install PyTorch, torchvision and torchaudio first, then pip install spikingjelly for the latest stable PyPI release. There is a pre-release channel: pip install --pre spikingjelly, described as installing V2 pre-releases from PyPI when they are published. From source it is git clone of the repository, cd spikingjelly, pip install . Optional extras are separate installs rather than one meta-package. CuPy is pip install cupy-cuda12x or cupy-cuda11x. Triton is pinned: pip install triton==3.3.1. NIR exchange is pip install "spikingjelly[nir]" from PyPI or pip install ".[nir]" from a source checkout. Lightning integration is pip install lightning jsonargparse[signatures]. The constraints are the first real friction: Python >=3.11 and PyTorch >=2.6.0, tested with 2.7.1. A team still on Python 3.10 or an older PyTorch cannot use this build without upgrading. The triton pin is the other one to note, because a pinned triton version tends to constrain the rest of your environment.

Where the scaling story is documented and where it is not

For large models the README lists memory-efficient training with spike compression, labelled memopt, experimental distributed execution for multi-GPU workloads, precision policy tools, and spiking transformer components. The word experimental is the README's own, and it applies to the distributed path. The precision tools are illustrated by fp8 mixed-precision utilities. Analysis tooling covers FLOPs, SynOps and memory-access profiling, plus inference energy estimation, which is the metric that motivates spiking hardware in the first place. The backend performance section points to an execution-time comparison image for multi-step LIF neurons on torch versus cupy, with triton covered in the backend tutorials rather than the README. I have not run that comparison and the README gives no numbers in text, so treat the image as the project's own claim and reproduce it on your own shapes before assuming a backend will pay off. The honest reading is that the single-GPU, torch-backend path is the well-trodden one, and memopt, distributed execution and fp8 are the parts you should expect to debug.

Datasets, NIR and Lava: the parts that reduce glue code

The dataset list is the most concrete asset here, and it is long: ASL-DVS, Bullying10K, CIFAR10-DVS, DVS-Lip, DVS128 Gesture, ES-ImageNet, HARDVS, N-Caltech101, N-MNIST, Nav Gesture, SHD, SSC and Speech Commands. The README states that each dataset supports raw event access and frame representations, which is the detail that matters, because it means you can choose between event-level processing and a frame-based pipeline without rewriting your loader. On the deployment side there are three exchange paths: NIR exchange, Lava exchange, and a Lynxi deployment tutorial. The Lynxi tutorial is listed under the Chinese documentation path while NIR and Lava point at English tutorials, so at least one deployment route is documented primarily in Chinese. That is a real cost if your team cannot read it. It is also worth being precise about what exchange means here: the README describes interfaces for exporting SpikingJelly models to neuromorphic hardware or other frameworks, and does not claim that every model converts cleanly.

The limitation that matters most: release policy and licence

Two things in this repository should slow down anyone planning to build on it. First, the version policy. The README's Project Status section says that starting from SpikingJelly V2, release versions follow PEP 440 compatible, SemVe, and the supplied text is truncated mid-word. Combined with the separate --pre install channel, the plain reading is that V2 is in a pre-release phase and the stable PyPI package is a different line. Which line your code is written against is therefore not obvious from the README alone, and the README does not state an end-of-life or support window for the older line. Second, the licence. The repository metadata reports NOASSERTION rather than an SPDX identifier such as MIT or Apache-2.0. The README has a License section and a Citation section, but the licence text is not in the material I have. NOASSERTION is what GitHub reports when it cannot classify the licence file, which can mean a custom licence, a modified licence, or a file the detector did not recognise. For an internal research prototype this may be acceptable; for a product, it is a blocking question. I am not giving legal advice, and I cannot tell you what the terms are, because the terms are not in front of me. Read the licence file in the repository before you depend on this.

How it compares to writing your own spiking layer in PyTorch

The obvious alternative is not another SNN framework but plain PyTorch: implement a LIF neuron as an nn.Module with a custom autograd Function for the surrogate gradient, keep the membrane potential as a buffer, and loop over time steps yourself. That approach has real advantages. You control the backward pass exactly, you carry no extra version constraints beyond your PyTorch version, and there is no licence question. What you give up is everything the README lists as core capabilities. Surrogate functions such as surrogate.ATan come pre-written and tested. The cupy and triton backends exist as neuron-level options, so switching execution path is a constructor argument rather than a rewrite. The thirteen neuromorphic datasets and their raw-event and frame access paths are already implemented. NIR and Lava exchange exists as a documented interface. The trade-off is straightforward: a hand-rolled neuron is a day of work and a permanent maintenance line, while SpikingJelly is a dependency with version and licence constraints you have to accept. For a single experiment, write it yourself. For repeated work across datasets and backends, the framework earns its place.

Who should adopt it, and what to check before the first commit

Adopt SpikingJelly if you are already in PyTorch, your environment can move to Python >=3.11 and PyTorch >=2.6.0, and your work involves event-based data or ANN2SNN conversion. The Quick Start is short enough to evaluate in an afternoon: build the Sequential from layer.Flatten, layer.Linear and neuron.LIFNode, and confirm that torch.compile accepts it. The parts worth prototyping early are the ones the README marks as heavy: memopt spike compression, fp8 precision tools, and the experimental distributed execution path. If your environment is pinned to an older Python or PyTorch, or your legal review requires a recognised OSI licence, stop here rather than discovering the problem after a training run. The specific things to verify first are the licence file in the repository, which release line corresponds to the V2 notes and which to the stable PyPI package, and whether your chosen backend imports cleanly in your environment, since cupy-cuda12x, cupy-cuda11x and triton==3.3.1 are three different installs with three different failure modes.

Editorial conclusion

Use SpikingJelly if you already write PyTorch and want spiking neurons, surrogate gradients and event datasets in the same model definition, and if you can pin Python >=3.11 and PyTorch >=2.6.0. Do not adopt it if your project depends on a stable released API and a clear OSI licence, because the README describes a V2 pre-release channel and the repository carries a NOASSERTION licence rather than an SPDX identifier. Before writing production code, verify the licence file in the repository, confirm which release the V2 notes apply to, and check that your chosen neuron backend (torch, cupy or triton) is importable in your environment.

Official sources

1. fangwei123456/spikingjelly on GitHub
2. Issues
3. Project website
4. README