NVIDIA H100 80GB HBM3 · 512 prompt tokens, 128 new · batch 1 · median of 10 runs after 3 warm-ups · measured 2026-09-28T17:45:00+00:00
Linnet 0.1.0, PyTorch 2.14.0, JAX 0.11.2, transformers 5.17.0, diffusers 0.40.0, ONNX Runtime 1.30.0, Python 3.12.3, driver 580.126.09
Linnet against the stack it replaces
Each side in its fastest configuration, on the same GPU and checkpoint. A speed-up is how many times the other's speed; an export is measured against the original checkpoint in the same engine.
- Linnet, XLA (StableHLO)292 tok/svLLM242 tok/s
- Linnet, CUDA graphs264 tok/stransformers, compiled177 tok/s
- vLLM on Linnet's export251 tok/svLLM242 tok/s
- linnet.serve, CUDA graphs6,668 tok/svLLM5,583 tok/s
- vLLM on Linnet's export5,587 tok/svLLM5,583 tok/s
- Triton, linnet.serve backend6,328 tok/sTriton, vLLM backend1,968 tok/s
Each row also carries its distance from reference: the largest absolute difference between its output and transformers (eager)'s on the same input. bf16 outputs differ by rounding (about 0.1 on logits near 16), so a small number is expected; it is there so that a fast wrong answer cannot look like a win.
Time to first token
ms, lower is better; the best bar is red.
Decode speed
tok/s, higher is better; the best bar is red.
Serving throughput
tok/s, higher is better; the best bar is red.
Serving time to first token
ms, lower is better; the best bar is red.
Load time
s, lower is better; the best bar is red.
Peak GPU memory
What the driver reports the process holding at its peak, in GiB; lower is better; the best bar is red. Not drawn, since theirs is a setting rather than a need: vLLM, vLLM, transformers, batched, Triton, vLLM backend, vLLM on Linnet's export, vLLM on Linnet's export (in the table).
Every number
| Method | Time to first token | Decode speed | Serving throughput | Serving time to first token | Load time | Peak GPU memory | Against the stack it replaces | Distance from reference | Notes |
|---|---|---|---|---|---|---|---|---|---|
| PyTorch | |||||||||
| transformers | 19.3 ms | 70.9 tok/s | – | – | 4.61 s | 8.14 GiB | 0 (the reference) | ||
| transformers, compiled | 12.4 ms | 177 tok/s | – | – | 2.68 s | 8.39 GiB | 0.156 | ||
| Linnet, generated PyTorch | 12.3 ms | 88.9 tok/s | – | – | 1.91 s | 8.20 GiB | 0.50× transformers, compiled | 0.266 | KV cache compiled for 768 positions |
| Linnet, inductor | 7.90 ms | 211 tok/s | – | – | 1.52 s | 8.19 GiB | 1.19× transformers, compiled | 0.141 | KV cache compiled for 768 positions |
| Linnet, CUDA graphs | 7.05 ms | 264 tok/s | – | – | 1.51 s | 8.31 GiB | 1.49× transformers, compiled | 0.141 | KV cache compiled for 768 positions |
| JAX | |||||||||
| Linnet, XLA (StableHLO) | 9.76 ms | 292 tok/s | – | – | 4.99 s | 8.27 GiB | 0.125 | KV cache compiled for 768 positions; peak memory is JAX's allocator peak; the driver shows its pool, which grows in whole regions | |
| Linnet, XLA (generated JAX) | 9.27 ms | 292 tok/s | – | – | 4.94 s | 8.27 GiB | 0.313 | KV cache compiled for 768 positions; peak memory is JAX's allocator peak; the driver shows its pool, which grows in whole regions | |
| ONNX Runtime and TensorRT | |||||||||
| Linnet, ONNX Runtime f32 | 31.7 ms | 75.2 tok/s | – | – | 0.37 s | 20.1 GiB | 0.134 | f32; ONNX Runtime's CUDA execution provider; first calls build the sessions; logits copied to the host each step for the argmax | |
| Linnet, ONNX Runtime f16 | 22.2 ms | 95.1 tok/s | – | – | 0.36 s | 10.7 GiB | 0.156 | f16; ONNX Runtime's CUDA execution provider; first calls build the sessions; logits copied to the host each step for the argmax | |
| Linnet, ONNX Runtime bf16 | 22.8 ms | 93.8 tok/s | – | – | 0.41 s | 9.79 GiB | 0.125 | bf16; ONNX Runtime's CUDA execution provider; first calls build the sessions; logits copied to the host each step for the argmax | |
| Linnet, TensorRT f32 | 30.3 ms | 50.1 tok/s | – | – | 0.39 s | 42.0 GiB | 0.138 | f32; ONNX Runtime's TensorRT execution provider; first calls build the sessions; logits copied to the host each step for the argmax | |
| Linnet, TensorRT f16 | 16.0 ms | 84.4 tok/s | – | – | 0.36 s | 22.1 GiB | 14.5 | f16; ONNX Runtime's TensorRT execution provider; first calls build the sessions; logits copied to the host each step for the argmax | |
| Linnet, TensorRT bf16 | 16.1 ms | 83.3 tok/s | – | – | 0.37 s | 21.6 GiB | 0.188 | bf16; ONNX Runtime's TensorRT execution provider; first calls build the sessions; logits copied to the host each step for the argmax | |
| LLM engines | |||||||||
| vLLM | 11.9 ms | 242 tok/s | – | – | 67.5 s | 66.8 GiB | not compared | reserves a KV-cache pool up front (gpu_memory_utilization 0.85), so its memory is a setting, not a need | |
| vLLM on Linnet's export | 12.0 ms | 251 tok/s | – | – | 50.3 s | 66.9 GiB | +3.5% from vLLM | not compared | linnet.hf.export (8 s), then vLLM on the exported checkpoint; reserves a KV-cache pool up front (gpu_memory_utilization 0.85), so its memory is a setting, not a need |
| llama.cpp on Linnet's GGUF | 16.8 ms | 231 tok/s | – | – | 27.9 s | 7.90 GiB | not compared | linnet.gguf.export, then llama-bench with every layer on the GPU; the first token is the prompt at llama-bench's prompt rate | |
| Serving many requests | |||||||||
| vLLM | – | – | 5,583 tok/s | – | 34.5 s | 68.4 GiB | not compared | 256 requests of 128-512 prompt tokens and 128 new tokens, at most 64 in flight; KV-cache pool at gpu_memory_utilization 0.85 | |
| linnet.serve, CUDA graphs | – | – | 6,668 tok/s | 2,131 ms | 4.80 s | 24.0 GiB | 1.19× vLLM | not compared | 256 requests of 128-512 prompt tokens and 128 new tokens, at most 64 in flight; 64 fixed cache rows of 640 positions |
| linnet.serve, XLA | – | – | 5,178 tok/s | 2,688 ms | 7.27 s | 26.0 GiB | 0.93× vLLM | not compared | 256 requests of 128-512 prompt tokens and 128 new tokens, at most 64 in flight; 64 fixed cache rows of 640 positions; peak memory is JAX's allocator peak; the driver shows its pool, which grows in whole regions |
| linnet.serve, ONNX Runtime | – | – | 3,526 tok/s | 4,344 ms | 0.26 s | 48.8 GiB | 0.63× vLLM | not compared | 256 requests of 128-512 prompt tokens and 128 new tokens, at most 64 in flight; 64 fixed cache rows of 640 positions |
| vLLM on Linnet's export | – | – | 5,587 tok/s | – | 32.6 s | 68.4 GiB | +0.1% from vLLM | not compared | linnet.hf.export (0 s), then vLLM (offline, continuous batching) on the exported checkpoint; 256 requests of 128-512 prompt tokens and 128 new tokens, at most 64 in flight; KV-cache pool at gpu_memory_utilization 0.85 |
| Triton, vLLM backend | – | – | 1,968 tok/s | 7,875 ms | 51.1 s | 68.8 GiB | not compared | 256 requests of 128-512 prompt tokens and 128 new tokens, at most 64 in flight; over HTTP, streamed, first tokens timed at the client | |
| Triton, linnet.serve backend | – | – | 6,328 tok/s | 2,124 ms | 290 s | 24.9 GiB | 3.22× Triton, vLLM backend | not compared | 256 requests of 128-512 prompt tokens and 128 new tokens, at most 64 in flight; over HTTP, streamed, first tokens timed at the client |
| transformers, batched | – | – | 521 tok/s | – | 2.37 s | 79.1 GiB | not compared | 256 requests of 128-512 prompt tokens and 128 new tokens, at most 64 in flight; paged|sdpa attention; reserves a paged KV-cache pool up front, so its memory is a setting, not a need; no per-request timestamps | |