snnTorch: Spiking Neurons as Drop-in PyTorch Activation Layers
Deep and online learning with spiking neural networks in Python
At a glance
- What is it?
- snnTorch wraps PyTorch's autograd around recursive spiking neuron models, so you can swap a spiking layer into an existing network without storing membrane potential traces for every neuron. It is a research and prototyping library, not a deployment runtime, and the export path to neuromorphic hardware goes through NIR.
- Who is it for?
- Adopt snnTorch if you already write PyTorch and want to test whether a spiking formulation changes your results, because the neuron models plug in as activation units and the surrogate gradient functions are exposed separately. Do not adopt it expecting a compiled runtime for Loihi or SpiNNaker; the README describes export through NIR to other SNN libraries, not a bitstream toolchain.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem snnTorch Targets: Spikes Without a Rewrite
Standard PyTorch assumes continuous activations. A spiking neuron emits a binary event at a threshold crossing, and that discontinuity breaks the chain rule: the derivative of a step function is zero almost everywhere and undefined at the threshold. The usual workaround is to build the whole training loop by hand, tracking membrane potentials across timesteps and writing custom backward passes. snnTorch's answer is to keep the neuron as a module inside a normal torch.nn graph. The README states the intent plainly: pre-designed spiking neuron models are integrated so they can be treated as recurrent activation units. The audience is therefore narrow but clear. It is for people who already have a PyTorch model or training script and want to know what changes when the activations become spikes. It is not aimed at someone who wants a pre-trained model zoo or a packaged inference engine. The repository topics list neuron models, neuroscience and spike alongside machine-learning, which matches that framing: the library is closer to a neuron-model catalogue with autograd support than to an end-to-end application framework.
Recursive Neuron Models and What They Do With Memory
The design decision that shapes everything else is stated in the README: neuron models are represented by recursive functions, which removes the need to store membrane potential traces for all neurons in a system in order to calculate the gradient. That matters because a spiking network is unrolled over time. If every neuron's potential at every timestep had to be retained for the backward pass, memory would scale with neurons multiplied by timesteps, and a long simulation would not fit. The recursive formulation means the state carried forward is the neuron's own, and the gradient is computed through that recursion rather than from a stored history. The practical consequence is that the same code path runs on CPU and GPU. The README notes that the lean requirements let small and large networks be viably trained on CPU where needed, and that CUDA acceleration works the same way as in PyTorch provided the models and tensors are on the device. That is a claim about memory footprint and portability, not about speed, and the README does not offer throughput numbers. Treat the CPU statement as a statement about feasibility, not about how long your run will take.
The Module Layout: Neurons, Spike Generation, Surrogates, Plots
snnTorch is not a single class. The README lists eight components. The core snntorch module is described as a spiking neuron library like torch.nn, deeply integrated with autograd. snntorch.functional holds arithmetic operations on spikes, with loss and regularization named as examples. snntorch.surrogate provides optional surrogate gradient functions, which is where the non-differentiable threshold gets replaced by a differentiable approximation during backpropagation; the word optional in the README implies you can supply your own instead. snntorch.spikegen handles spike generation and data conversion, which is the bridge between continuous inputs such as images and the spike trains a network consumes. snntorch.spikeplot draws spike-based data using matplotlib and celluloid, so an animation dependency sits behind that module rather than in the base install. snntorch.utils holds dataset utility functions. Two further modules, snntorch.export_nir and snntorch.import_nir, move models between SNN libraries through NIR, the Neuromorphic Intermediate Representation. That import/export pair is the interoperability story, and it is separate from training.
Installing snnTorch and the Optional Dependency Split
The README gives three installation routes. The pip path is the shortest: run python, then pip install snntorch. From source, it is git clone https://github.com/jeshraghian/snnTorch, cd snntorch, then python setup.py install. For conda, conda install -c conda-forge snntorch. There is also a Graphcore build, pip install snntorch-ipu, for Intelligent Processing Units. PyTorch is a prerequisite and is not pulled in automatically; the README tells you to ensure the correct version of torch is installed for your system to enable CUDA compatibility. Only numpy and pandas arrive with the pip command. Everything else is conditional. export_nir and import_nir need nir>=1.0.6 and nirtorch>=2.0.5. spikeplot needs matplotlib. So a minimal training install is small, and the dependency surface grows only when you use NIR interchange or spike animation. The repository also points to a quickstart Colab notebook under examples/quickstart.ipynb, which is the fastest way to see the API in use without installing anything. The README's own text is truncated mid-sentence at the end of the Quickstart section, so anything beyond that point in the document is not available here.
Where snnTorch Stops: Hardware and the NIR Boundary
The most common misreading of a spiking neural network library is that it will run on neuromorphic silicon. snnTorch trains in PyTorch tensors. The README describes export to other SNN libraries via NIR and import from them, which means the handoff to a hardware toolchain happens in another project, not here. If your goal is to deploy to a specific chip, snnTorch is the wrong layer of the stack unless that chip's toolchain consumes NIR. There is a second boundary worth naming. The recursive neuron formulation is described as removing the need to store membrane potential traces for the gradient, which is an efficiency argument; it is not a statement that snnTorch reproduces the dynamics of any particular biological or analog circuit. Neuron models are approximations with parameters you choose. And the surrogate gradient, while exposed as a module, is still an approximation of a step function: training quality depends on that choice, and the README offers no accuracy comparison across surrogate functions. Anyone expecting spiking networks to match a well-tuned ANN on a standard benchmark should treat that as an open question to test, not a documented property.
How snnTorch Differs From Norse and SpikingJelly
The nearest alternatives are other PyTorch-based SNN libraries, and the meaningful difference is architectural rather than cosmetic. Norse also builds on PyTorch and also supplies surrogate gradients, but its emphasis is on composable, explicitly stateful neuron layers in the same functional style as torch.nn, with the state passed in and out by the caller. snnTorch's README instead stresses that neurons behave like recurrent activation units inside the layer sequence and that the recursion keeps membrane traces out of memory. SpikingJelly takes a third route, with a heavier emphasis on step-based simulation and its own accelerator-oriented execution paths. The line between them for a PyTorch user is how much of the temporal state you want to manage yourself. snnTorch's pitch is that you manage least: the neuron is an activation, not a state machine you thread through your forward function. The trade-off is that the neuron's internal dynamics are less visible in your code, which makes debugging a surprising spike train harder than in a library that hands you the state directly. None of these three is a drop-in replacement for another; the choice is about which abstraction you want to reason in.
Maintenance, Versioning and the MIT Licence
The release history is uneven. v0.8.1 is dated 2024-03-17, v0.7.0 is 2023-07-12, and v0.6.0 is 2023-02-21. The last push to the default branch, master, is dated 2026-09-08, which is later than the newest tagged release, so the repository is active between releases even though the tag cadence is slow. The gap between 0.7.0 and 0.8.1 is roughly eight months, and the jump from 0.6.0 to 0.7.0 was about five months. Minor-version bumps in a pre-1.0 library can carry breaking API changes, and the material here does not include a changelog, so the upgrade cost cannot be estimated from what is available. Pin the version in your requirements file and read the release notes for each bump before moving. The licence is MIT, which permits commercial and closed-source use and requires that the copyright notice and permission notice be included in copies or substantial portions. That is a summary of the licence identifier given in the repository metadata, not legal advice; the citation request in the README is a scholarly norm, not a licence condition.
Editorial conclusion
Adopt snnTorch if you already write PyTorch and want to test whether a spiking formulation changes your results, because the neuron models plug in as activation units and the surrogate gradient functions are exposed separately. Do not adopt it expecting a compiled runtime for Loihi or SpiNNaker; the README describes export through NIR to other SNN libraries, not a bitstream toolchain. Before committing, verify that the neuron model you need is in the snntorch module, confirm the torch build matches your CUDA version, and check whether your target hardware is reachable through the nir and nirtorch dependencies.
Community notes