Programmable switches and SmartNICs can now run machine-learning models directly on network traffic at line rate — spotting attacks or congestion in nanoseconds — but doing so forces a network operator to be simultaneously an ML expert, a hardware-description-language programmer, and a switch-resource accountant, hand-tuning a model to fit a switch's brutal constraints (a single neural-network layer can eat a quarter of the switch's tables); Homunculus (Stanford, Purdue, Lund) turns that into a compiler problem — the operator declares the training data, the accuracy goal, and the target hardware, and the system automatically searches the model design space, prunes anything that won't fit the switch, and generates the low-level P4 or Spatial code — producing models with up to 12% better F1 score than hand-tuned ones from ~30 lines of high-level script.
The argument in one glance
-
Problem
The network can now think — but only if one person is three experts
How fast a network reacts decides how robust and secure it is: mitigating a fault, absorbing a microsecond traffic burst, catching an attack early. These reactions increasingly need machine-learning inference, and programmable switches (Intel Tofino), SmartNICs, and network accelerators (Xilinx FPGAs, Taurus) can now run ML models DIRECTLY on packets at line rate — support-vector machines, decision trees, even small neural networks, deciding in nanoseconds. The catch: building one of these in-network ML pipelines requires a single operator to be, simultaneously, an ML architect, a low-level hardware programmer, and a switch-resource accountant. That triple expertise is a wall almost nobody clears.
-
What people did
Compile a hand-designed model onto the switch
Prior systems help map a model to hardware. IIsy exploits the structural similarity between classical ML algorithms and match-action tables, mapping SVMs/K-Means/decision trees onto switch pipelines. N2Net compiles binary neural networks to tables. Taurus adds a dense compute block (MapReduce) and a high-level language (Spatial) so switches can run linear-algebra ML at line rate. Each makes the final compilation step tractable.
-
Why it fell short
The operator still has to design, tune, and fit the model by hand
Every prior tool assumes the model already EXISTS — hand-designed, hand-tuned, and pre-shrunk to fit. The onus stays on the operator to invent an architecture, tune its hyperparameters, and squeeze it under the switch's savage resource limits, all while meeting throughput and latency targets. And those limits are savage: an SVM can eat 8 of ~32 match-action tables (25% of the switch), a single DNN layer up to 12 tables. The design space of model architectures crossed with hardware mappings crossed with network constraints is astronomically large, and navigating it by trial-and-error demands exactly the three-way expertise that is so rare. In-network ML stalled not because it lacked value but because building it was a Sisyphean task.
-
This paper's idea
Make it a compiler: declare intent, let the system search and generate
Homunculus (Stanford, Purdue, Lund) reframes in-network ML as a compilation problem. The operator writes ~30 lines in a declarative DSL (Alchemy) specifying three things they DO have expertise in: the training data, the accuracy objective, and the target hardware with its constraints. Homunculus then runs the whole pipeline as compiler stages: it explores the model design space (across algorithm types and hyperparameters), uses Bayesian optimization to search efficiently, and — the key twist — encodes the switch's resource limits and network constraints as FEASIBILITY CONSTRAINTS that PRUNE the search rather than expand it, so any model that won't fit is discarded before it is even trained fully. It generates the P4 or Spatial code for the chosen backend from templates, tests it in a cycle-accurate simulator, and iterates until a compliant, high-performing model emerges. Result: models with up to 12% better F1 than hand-tuned baselines, and per-packet models that react immediately instead of waiting for a whole flow.
Why this problem is worth solving
A network’s intelligence is bounded by how fast it can react,
and the frontier of fast reaction is
running
ML inference on the network devices themselves — the
switches, NICs, and accelerators that forward packets —
rather than shipping traffic off to a server and waiting.
Because it happens in the DATA PLANE (the packet-forwarding
path) at line rate, decisions land in nanoseconds:
classifying traffic, balancing load, or flagging an attack
as the packets fly by. The enabling shift was programmable
data planes — switches whose behavior an operator can
reprogram — which turned the forwarding path from a fixed
pipeline into something that can run real computation
the fundamental
programmable unit of a PISA-style switch: a table that
MATCHES fields of a packet against entries and applies an
ACTION when one hits. Complex behavior is built by chaining
many MATs into a pipeline. They are the switch’s scarcest
resource — a real switch has only a few dozen — so every
model mapped onto the switch is really a competition for
tables: an SVM might consume 8 of them, a single neural-
network layer up to 12, which is why fitting a model into
the budget is the central engineering agony
And yet in-network ML is not mainstream, for a reason the paper names precisely: the abstraction gap. The whole point of programmability was to let operators change network behavior QUICKLY AND EASILY. Adding a new protocol header in P4 is easy. But expressing a sophisticated ML model in P4 or Verilog is the opposite of easy — it demands ML architecture skill, hardware-description-language fluency, AND intimate knowledge of the switch’s resource budget, all at once, all in one head. The operator must design a model, tune its hyperparameters, and hand-shrink it to fit tables so scarce that a single layer can claim a quarter of them, while never violating the throughput and latency the network requires. That is three PhD-shaped skill sets welded together, iterated by hand across an astronomical design space. Homunculus’s premise is that this is not a human task at all — it is a compiler’s task — and that the operator should supply only what they genuinely know (the data, the goal, the hardware) while the machine handles the search, the fitting, and the code generation.
What people did before, and where it broke
- IIsy (map classical ML to MATs). Exploits the structural match between SVMs/K-Means/decision trees and match-action tables to compile them onto PISA switches. Real and useful — but the operator must have already designed the model, and IIsy shows an SVM eating 25% of the switch’s tables, with the fitting left to the human.
- N2Net (binary neural networks on MATs). Compiles BNNs to tables by truncating weights to a single bit. Runs at line speed, but the accuracy loss is baked in, and a single hand-designed anomaly-detection layer still takes up to 12 tables — the operator owns the design-and-fit problem.
- Taurus (a compute block + Spatial DSL). Adds a dense MapReduce array and a high-level language so switches can run linear-algebra ML at line rate — a better substrate, but the operator still hand-designs, transforms, and programs the model in low-level Spatial.
- AutoML frameworks (AutoKeras, Auto-sklearn, HyperMapper). Automate ML model search and hyperparameter tuning brilliantly — for software targets. None of them knows a switch has 32 tables or must sustain a terabit per second, so they will happily produce models that cannot be deployed in the data plane at all.
- The gap. No system combined AutoML’s search with the data plane’s hard hardware and network constraints, so in-network ML remained a hand-crafted, three-expertise craft. Homunculus is the first to make the switch’s resource budget and the network’s line-rate demands first-class inputs to an automated model search that ends in deployable P4/Spatial code.
How Homunculus works
Declare intent, search under constraints, generate code
-
Alchemy DSL: declare data, objective, target new
The operator writes ~30 lines of embedded Python: a DataLoader wrapping the training data, a Model specifying the objective metric (e.g. F1 score) and optionally an algorithm list, and a Platform (Taurus/Tofino/FPGA) carrying its resource limits (tables, LUTs, compute units) and performance constraints (throughput, latency). Compositional operators (sequential >, parallel |) let multiple models be chained into a DAG. The operator writes NO model definition and NO hardware code.
-
Candidate selection: prune algorithms up front new
The optimization core first rules out whole algorithm classes that cannot possibly fit the target — a DNN whose multiply-adds exceed a MAT switch's capacity is dropped immediately. When multiple models are composed, it also reconciles their constraints (a stage feeding a 0.5 GPkt/s consumer must itself run at 0.5 GPkt/s), disqualifying inconsistent combinations before any training.
-
Design-space creation over three variable classes new
It builds a bounded search space over hyperparameters (layers, neurons, learning rate), physical resources (tables, compute/memory units — encoded as feasibility limits), and network constraints (line-rate throughput per topology position — also feasibility limits). Crucially, the resource and network variables SHRINK the space by disqualifying infeasible configurations rather than enlarging it.
-
Bayesian-optimization-guided search new
Model+mapping is treated as a black box: give it a configuration, get back F1, resource use, latency, throughput — no gradients, no internals. Bayesian optimization (HyperMapper, random-forest surrogate) builds a probabilistic model of that black box and picks the next configuration to try, balancing exploiting known-good settings against exploring new ones, converging in far fewer trials than grid search or a human could.
-
Train, generate code, test feasibility — in the loop new
For each suggested configuration, Keras trains and tests the model on the data; then Homunculus generates the actual hardware code (assembling parameterized templates for common ML operations — packet parsing, dot products, activations, reductions — into a full pipeline) and runs it through a cycle-accurate simulator (SARA for Taurus, Vivado for FPGA) to measure real resource use, latency, and throughput. Those verdicts feed back to the optimizer.
-
Model fusion and final code generation new
If two models learn from overlapping packet features, Homunculus tries to fuse them into one shared model — saving resources and inter-model communication. After a set iteration budget, the best constraint-compliant model is selected and its final P4 (for MAT switches, via IIsy) or Spatial/Verilog (for Taurus/FPGA) binary is generated and deployed.
The idea
Reframe a three-expertise craft as a compilation problem. The paper’s core move is to notice that everything the operator agonizes over — architecture design, hyperparameter tuning, resource fitting, code generation — is exactly the kind of iterative search-and-transform that compilers do, and none of it is what a NETWORK operator is actually good at. What they ARE good at is curating network data and stating performance goals. So Homunculus draws the line there: the human provides intent (data, objective, target), the compiler provides the mechanism (search, fit, generate). This is the declarative-over-imperative shift the site keeps meeting — say WHAT you want, not HOW — applied to a domain where the “how” required three disjoint doctorates. The Alchemy DSL is the interface that makes the split real: 30 lines expressing intent, zero lines of model or hardware code.
Make the hardware constraint PRUNE the search, not bloat it. The most elegant inversion is how Homunculus treats the switch’s resource limits. A naive AutoML system adds hyperparameters and watches its search space explode; adding hardware and network variables on top would seem to make it hopeless. Homunculus flips this: the resource budget and the line-rate requirement are FEASIBILITY constraints, so every variable they touch DISQUALIFIES configurations rather than multiplying them. A DNN too big for the tables is not a point to evaluate — it is a region to delete. The switch’s brutal scarcity, the very thing that made hand-design agonizing, becomes the search’s best friend: the tighter the hardware, the smaller the feasible space, the faster the optimizer converges. Constraints as accelerant, not obstacle.
Search a black box you cannot differentiate, with the model that fits systems. In-network ML has no smooth gradient to follow: change the neuron count and you get a discrete jump in F1, table usage, and latency, measured only by training-then-simulating an entire configuration (minutes to hours each). This is a textbook black-box optimization — expensive, noisy, non-differentiable — and Homunculus uses Bayesian optimization with a random-forest surrogate, precisely the tool for discrete, non-continuous systems objectives. The optimizer never sees inside the model; it proposes a configuration, reads back the metrics, updates its belief, and proposes again, wringing a good design from a tiny evaluation budget. It is the same manufactured-affinity discipline the site sees elsewhere — pick the search method whose assumptions match the problem’s shape — here matching Bayesian-over-random-forest to a lumpy, expensive, integer-valued landscape.
Turning a botnet detector from per-flow to per-packet
From an operator's 30-line script to a deployed switch model
Botnet detection: distinguish botnet P2P traffic from benign (uTorrent, Vuze) by packet-size and inter-arrival histograms. The hand-tuned baseline (Flowlens) waits for a whole flow; Homunculus searches a per-packet model.
Step 1 of 5
The operator declares intent, not architecture
The operator writes an Alchemy script: a DataLoader for the botnet/benign traces, a Model asking to maximize F1 with a DNN, and a Platform (Taurus) constrained to 1 GPkt/s line rate, 500ns latency, and a 16×16 compute grid. ~30 lines. They specify no layer counts, no neuron counts, no P4, no Spatial — only what they know: the data, the goal, the hardware.
the three inputs map exactly to a network operator's real expertise: data, objective, target compositional operators (>, |) would let them chain models, but here one model suffices
Why it works
- Model design, tuning, fitting, and code generation are all iterative search-and-transform → framing them as compiler stages lets a machine do them → the operator supplies only the intent they have expertise in (data, objective, target).
- Switch resources and line-rate demands are hard limits → encoding them as feasibility constraints DISQUALIFIES infeasible configurations → the search space shrinks with tighter hardware instead of exploding, speeding convergence.
- The objective is discrete, noisy, non-differentiable, and expensive to evaluate → Bayesian optimization with a random-forest surrogate models exactly this kind of black box → a good design emerges from a small evaluation budget without gradients.
- Botnet/benign traffic diverges after a few packets → an automated search unconstrained by human intuition finds a per-PACKET model → reaction time collapses from flow-duration to a single packet.
- Common ML operations recur across models → parameterized templates assembled per backend generate real P4/Spatial code → the search’s chosen design becomes a deployable binary, tested for feasibility in-loop.
What it costs
- Quality bounded by the search space and budget. The result is only as good as the algorithms in the library, the bounds set on the design space, and the iteration budget; a genuinely novel architecture outside the templated building blocks will not be discovered.
- Simulation-in-the-loop is the cost driver. Every candidate is trained AND run through a cycle-accurate simulator for feasibility — accurate but slow, so search time depends heavily on how expensive each evaluation is and how fast infeasible pruning trims the space.
- Backend and template engineering per platform. Each target (Taurus, Tofino/P4, FPGA) needs its own constraint model, code-generation templates, and simulator hookup; supporting a new platform is real integration work, not free.
- Accuracy/resource trade-offs are inherent, not eliminated. A higher-F1 model uses more resources and power; Homunculus finds good points on the frontier but cannot make the frontier disappear — on MAT switches it literally trades cluster fidelity for table count.
- Evaluation is a handful of applications on emulated Taurus. Three real tasks, a Tofino+FPGA emulation of a Taurus ASIC; breadth across the full zoo of in-network ML tasks and shipping silicon is future work.
The evaluation
Three real applications — anomaly detection (NSL-KDD), traffic classification (IoT device traces via IIsy), botnet detection (P2P/botnet traces via Flowlens) — generated by Homunculus and compared to hand-tuned baselines rewritten in Spatial, on a Taurus testbed (Tofino Wedge100BF + Xilinx Alveo U250 FPGA) and P4-SDNet FPGA / MAT backends, all at 1 GPkt/s line rate.
Building an in-network ML pipeline, three ways
| Property | Hand-crafted (P4/Verilog by an operator) | Prior compile-a-model tools (IIsy, N2Net, Taurus) | Homunculus |
|---|---|---|---|
| Who designs and tunes the model | |||
| How hardware limits are handled | Exposed as a fixed budget the operator must fit into | ||
| Code the operator writes | Full P4 / Verilog / Spatial model implementation | A model definition plus mapping directives | |
| Model quality | Baseline (limited by human search) | Baseline model, mapped | |
| Reaction time / flexibility | Whatever the operator hand-built (often per-flow) | Per-flow or per-packet as hand-designed |
Check yourself
Check your understanding
1. Prior systems like IIsy, N2Net, and Taurus already help run ML models on switches. Predict why they did not make in-network ML mainstream, and what Homunculus adds.
2. A naive AutoML system's search space explodes as you add hyperparameters. Homunculus adds hardware-resource and network variables on top, yet claims its search gets FASTER, not slower. Predict how.
3. Homunculus optimizes model design with Bayesian optimization treating the model as a "black box." Predict why gradient-based optimization (the standard ML tool) is unusable here, and why Bayesian optimization fits.
4. The hand-tuned botnet baseline waits for a whole flow (up to 3,600 seconds) before deciding; Homunculus finds a per-PACKET model. Predict what insight enables this, and why an automated search found it when human designers did not.