Introducing Slimmable NAM: Neural Amp Models with adjustable runtime computational cost

I'm excited to share a paper I've recently completed: "Slimmable NAM: Slimmable NAM: Neural Amp Models with adjustable runtime computational cost"

The paper was accepted for the 2025 NeurIPS workshop on Artificial Intelligence for Music: Where Creativity Meets Computation; I'll be presenting it in 2 weeks in San Diego. In the meantime, anyone can access it here: https://arxiv.org/abs/2511.07470. A video demonstrating the method as well as open-source code and a demo plugin are linked within.

What is Slimmable NAM exactly?

This paper describes a novel technique for training neural amp models whose CPU usage can easily be reduced after training--kind of like how you can truncate an IR.

In the past, the most common way I've seen people do this is they take a model they like, then re-train a smaller "distilled" model using that "big" model's predictions as the source data (if they didn't make the original model/don't have the original data--both very common).

The problems with this are:

1. It takes time and effort. You're training a new NAM. Sure, NAM is one of the fastest-training methods out there, but it's still work to set things up, and you'll want a computer with a GPU if you don't want to wait long. That's not everyone, and I get that.

2. You're (probably) not training on the original data. The reality I've observed with NAM is that most musicians don't make their own models. Instead, most people buy or download models from others. If you do this, chances are that you don't have the original data the model was trained on. It's kind of like a game of "telephone" where each re-training brings you farther away from the original.

3. Isn't it annoying that you have to bother with this at all? Again, think about IRs. Being able to modify a model to get a "cheaper" version is really nice! This is one of the most fumbly bits about the whole neural modeling thing, given how the tech is used in practice.

Slimmable NAMs solve all of these: at training time, one simply trains the model using the method from this paper, and the resulting model that comes out can be slimmed in real time. Training takes a comparable time to the original method (you're not separately training a standard, lite, feather, nano, ...) and can give you quite a few different options how to run it once you're done.

"A2": A new standard NAM architecture

I think this changes the possibilities for NAM in a pretty significant way. With Slimmable NAM, it makes sense to me to put a new iteration on the "standard" architecture on the roadmap.

Current situation

Since the beginning, NAM has had a bit of a special place in the music industry: As an open-source tech, I've consciously not made any official "products" of my own who own the technology exclusively. Instead of competing with companies in the music industry, NAM is positioned to work with them: With NAM, anyone can build a product on top of state-of-the-art tech; and musicians, with their NAMs trained using the open-source code, are freed from being "locked" into one company who exclusively owns their sound. With open source as the foundation, both are free to meet each other.

On the flip side, this makes technical development complex. Other industries have navigated this--PCs and Windows, Android and smart phones, etc. Here's what I've seen so far in the music industry. On one hand, some products have taken the path of adopting NAM "natively", using NeuralAmpModelerCore to run the models on their products. Some products, such as the MOD Dwarf, had existing hardware that limited what kinds of models could be run; others, like the DIMEHEAD NAM Player and Darkglass Anagram, designed their hardware with the intent to support running NAM's "standard WaveNet"--the most commonly-shared NAM model architecture. To date, the industry has not shown a solution where the standard WaveNet is supported on dedicated hardware that's seen as "budget".

On the other side, products in the low-cost segment often use a "NAM-to-X" approach where NAMs are "converted" to a different proprietary model that is then run on-device. Examples include the Sonulab StompStation (VxAmp); Sonicake Pocket Master, Valeton GP-5, and GP-200 (SnapTone); the Hotone Ampero II line (Sound Clone), and the NUX Amp Academy Stomp (Image), to name a few.

But again, this is not new. Another open standard that's been adopted in a rather frictionless way has been the use of linear models (via impulse responses stored in WAVE files) as a common way of modeling speaker cabinets and microphones. Now that the industry tends to use chips that can support it, many products have "IR loaders" that can do more or less the same thing--modulo some maximum IR size (512, 1024, 2048, ... samples). That affects the details of the sound, but the "main" sound of the model (IR) is arguably "there". Perhaps truncation is a sort of approximation or "conversion" to square a "big" model with a less-capable chip.

It's also worth pointing out how all of these conversions are rather seamless--everything is handled practically in an instant.

Then there's the variety of "X"es. I think there's some confusion about it, and (as I've said) I think that someone who's conscientious about all this might appreciate keeping it all straight. Slimmable NAMs give the ability ("within NAM" and the open-source) to have a uniform, predictable experience with a model--if a given product supports playing slimmable NAM architecture X at size Y, then one could set those on the open-source plugin and know exactly how that sounds--and expect the same experience no matter where the model is played.

Looking forward

So, for the to-be-determined "A2" architecture, here are the metrics that should all stay the same or get better:

1. Modeling accuracy.

2. CPU usage (at full size)

3. Training time (i.e. you shouldn't have to train longer to maintain accuracy)

In addition to this, I'd like for the CPU usage at useful "slimmed" sizes to be chosen to work nicely with the industry's product goals. With the "A1 standard", I just picked something that worked fine for myself--no thought about whether it might need 51% of some chip's CPU and a tiny tweak would have let two models be run at the same time. This time, I want to be considerate of those boundaries and be on the other side wherever possible.

Conclusion

In my mind, "Slimmable NAM" is at least a neat, novel tech solution to a problem I haven't seen anyone tackle in this space, so I'm pleased to get to share it with the world. I hope that it'll be useful in practice, but that's on guaranteed. Now that the tech seems feasible, here's the part where we're going to explore the other dimensions--is this good enough to be the solution? Of course I hope so, but we shall see.

Also, I enjoyed making this tech. I've said in the past that NAM has been a sort of "crossword puzzle" for me--something where I think it's just enjoyable to work on the problems. In this case (unlike historically with NAM), I did do some literature survey to see whether other folks had solved this problem already (before writing the paper about it, at least). Even if this isn't "the" solution, I think it's still a data point or a little nugget of knowledge along the way.

There are other "research" ideas I've been wanting to develop, but this felt like a nice, useful, "cute" first one to start with (and the first piece of publicly-disseminated research I've done in a while). So, I'm excited to share more cool things like this in the future. For me, NAM isn't just a tech for musicians but partially a little "academic home" for me to enjoy doing a bit of research (and where I'm privileged for my professional situation to now permit me to do so as I please!)

In that same academic spirit, please feel free to get in touch about this work if you have questions or thoughts. I'd love to discuss.