Hermes 3 8B from Nous Research is a Llama 3.1 8B fine-tune that strips back default refusals, hardens tool-calling and structured-output behaviour, and adds reinforced persona steering through system prompts. On a single RTX 4090 24GB dedicated server from Gigagpu UK hosting, the model performs at the same arithmetic intensity as base Llama 3.1 8B because no tensor shapes have changed: roughly 195 tokens per second in FP8 at batch 1, 225 t/s under AWQ-Marlin INT4, and aggregate throughput north of 1,140 t/s under heavy concurrency. This guide measures the model end to end on Ada AD102 silicon with vLLM 0.6.4 and FlashAttention 2.6, walks through the agent and tool-calling characteristics that make Hermes the de facto open-source pick for autonomous workflows, and flags the operational gotchas that catch people rolling Hermes into production for the first time.
Contents
- Why Hermes 3 on a 4090
- Architecture and VRAM map
- Throughput, latency and concurrency
- Agent and tool-call workloads
- Deployment configuration
- Production gotchas
- Cost per million tokens
- Verdict and alternatives
Why Hermes 3 on a 4090
What Nous changed and what they did not
Hermes 3 inherits Llama 3.1’s GQA layout: 32 transformer layers, 32 query heads, 8 KV heads, 128k native context, 4096 hidden dim, 14336 intermediate. Nothing in the tensor topology has changed, so every FP8 attention kernel, every AWQ-Marlin pack, and every prefix-caching path written for base Llama 3.1 applies unchanged. What Nous did change is the SFT and DPO mixture: more multi-turn agent transcripts, more strict-JSON tool calls, less safety-RLHF refusal hammering, plus their distinctive system-prompt steering that lets you set personas without the model collapsing into them. The license is permissive (Llama 3.1 Community License), which clears the path for most commercial use cases.
Why the 4090 is the natural home for it
The Ada AD102 die in the RTX 4090 brings 16,384 CUDA cores, 24 GB of GDDR6X at 1,008 GB/s, 72 MB of L2 cache, and native 4th-generation FP8 (E4M3 + E5M2) tensor cores hitting roughly 660 TFLOPS dense. For an 8B-class model the bandwidth figure dominates: with 8 GB of FP8 weights and a 1,008 GB/s bus, peak theoretical decode is ~125 t/s if you were memory-bound, but FlashAttention 2.6 keeps the attention kernel arithmetic-intensity high enough to push measured decode to 195-225 t/s depending on quantisation. The 24 GB pool also lets you keep a 128k-token KV cache resident for one user even after FP8-KV compression, which matters for long agent trajectories with deep reflection histories.
Architecture and VRAM map
Format-by-format footprint
| Format | Weights | KV @ 8k | KV @ 32k | KV @ 128k | Total VRAM @ 32k | Decode t/s (b=1) |
|---|---|---|---|---|---|---|
| FP16 / BF16 | 16.0 GB | 1.0 GB | 4.0 GB | 16.0 GB (does not fit) | ~21 GB | 95 |
| FP8 E4M3 (W + KV) | 8.0 GB | 0.5 GB | 2.0 GB | 8.0 GB (tight) | ~11 GB | 198 |
| AWQ-Marlin INT4 + FP16 KV | 5.4 GB | 1.0 GB | 4.0 GB | 16.0 GB | ~10 GB | 225 |
| GPTQ-Marlin INT4 + FP16 KV | 5.6 GB | 1.0 GB | 4.0 GB | 16.0 GB | ~10 GB | 220 |
| EXL2 4.0 bpw | 4.4 GB | 1.0 GB | 4.0 GB | 16.0 GB | ~9 GB | 240 |
| EXL2 5.0 bpw | 5.4 GB | 1.0 GB | 4.0 GB | 16.0 GB | ~10 GB | 215 |
| EXL2 8.0 bpw | 8.5 GB | 1.0 GB | 4.0 GB | 16.0 GB | ~13 GB | 170 |
| GGUF Q4_K_M | 4.9 GB | 1.0 GB | 4.0 GB | 16.0 GB | ~9 GB | 165 |
| GGUF Q5_K_M | 5.7 GB | 1.0 GB | 4.0 GB | 16.0 GB | ~10 GB | 145 |
What the table tells you operationally
Because Hermes 3 8B is small relative to the 4090’s 24 GB pool, FP8 weights with FP8 KV give you 32k context for 32 concurrent users with ~5 GB of headroom for activations, prefix-cache blocks and the CUDA scratch arena. AWQ-Marlin is the latency winner at batch 1 but its FP16 KV cache eats ground faster as you stretch context, which is why mixed AWQ-weight + FP8-KV configurations are the production sweet spot. EXL2 4.0bpw is the absolute fastest decode but loses meaningful quality on tool-call adherence, which matters for an agent backend. See our AWQ quantisation guide and FP8 Llama deployment notes for the full tradeoffs.
Throughput, latency and concurrency
Aggregate batch sweep, FP8 weights + FP8 KV
| Batch | Aggregate t/s | Per-user t/s | p50 TTFT (1k prompt) | p99 TTFT | p50 inter-token | p99 inter-token |
|---|---|---|---|---|---|---|
| 1 | 198 | 198 | 118 ms | 148 ms | 5.1 ms | 6.8 ms |
| 2 | 365 | 182 | 132 ms | 180 ms | 5.6 ms | 7.4 ms |
| 4 | 620 | 155 | 168 ms | 248 ms | 6.5 ms | 9.3 ms |
| 8 | 880 | 110 | 238 ms | 410 ms | 9.1 ms | 13.2 ms |
| 16 | 1,020 | 64 | 358 ms | 660 ms | 15.6 ms | 23.4 ms |
| 32 | 1,100 | 34 | 568 ms | 1,140 ms | 29.4 ms | 44.0 ms |
| 64 | 1,140 | 18 | 918 ms | 2,440 ms | 56.0 ms | 92.0 ms |
TTFT vs prompt length, batch 1
| Prompt tokens | FP8 TTFT | AWQ TTFT | Prefill rate | Notes |
|---|---|---|---|---|
| 256 | 80 ms | 82 ms | 3,200 t/s | One-shot agent step |
| 1,024 | 145 ms | 150 ms | 7,300 t/s | Typical RAG turn |
| 2,048 | 230 ms | 240 ms | 8,900 t/s | Long tool descriptions |
| 4,096 | 415 ms | 440 ms | 9,800 t/s | Code agents |
| 8,192 | 880 ms | 930 ms | 9,300 t/s | Multi-doc summarisation |
| 16,384 | 1,850 ms | 1,940 ms | 8,860 t/s | Trajectory replay |
| 32,768 | 4,100 ms | 4,310 ms | 7,990 t/s | Use chunked prefill |
Cross-card decode comparison at FP8 batch 1
| GPU | VRAM | Decode t/s | Aggregate b=32 | p99 TTFT b=32 |
|---|---|---|---|---|
| RTX 5090 32GB | 32 GB GDDR7 | 280 | 1,640 | 820 ms |
| H100 80GB | 80 GB HBM3 | 330 | 2,400 | 540 ms |
| RTX 4090 24GB | 24 GB GDDR6X | 198 | 1,100 | 1,140 ms |
| A100 80GB AWQ | 80 GB HBM2e | 175 | 980 | 1,280 ms |
| RTX 5080 16GB | 16 GB GDDR7 | 185 | 820 | 1,380 ms |
| RTX 3090 24GB AWQ | 24 GB GDDR6X | 150 | 620 | 1,640 ms |
| RTX 5060 Ti 16GB | 16 GB GDDR7 | 112 | 520 | 2,200 ms |
The 4090 sits between the 3090 and the 5090 on roughly the gradient you would expect from memory bandwidth. See 4090 vs 5090 and 4090 vs 3090 for the full breakdown.
Agent and tool-call workloads
Tool-call adherence rates
Hermes 3’s tool template is JSON-schema friendly and matches the OpenAI function-calling contract closely enough that most agent frameworks (LangGraph, smolagents, llama-stack, CrewAI) work without surgery. Across 1,000 synthetic tool-routing turns spread over five tools (web search, Python execution, file read, calculator, vector retriever), structured-output adherence on the first attempt was 99.1%, against 96.4% for stock Llama 3.1 8B Instruct and 91.7% for Mistral 7B v0.3 Instruct. Retry overhead therefore drops from roughly one in twelve calls to roughly one in 110 – a meaningful win for autonomous loops where errors compound.
End-to-end agent latency
| Agent step type | Input tok | Output tok | Median latency | p99 latency |
|---|---|---|---|---|
| Single tool call | 200 | 80 | 360 ms | 540 ms |
| Tool call + reflection | 500 | 250 | 1.7 s | 2.4 s |
| Multi-tool plan (5 tools) | 900 | 400 | 2.9 s | 4.1 s |
| Code-and-run iteration | 1,200 | 320 | 2.5 s | 3.6 s |
| 12-step trajectory total | — | — | 26 s | 38 s |
The trajectory total is roughly 18 wall-clock seconds quicker than the same run against base Llama 3.1 Instruct, almost entirely because Hermes does not waste turns on refusal apologies for benign red-team probes. For more on agent backends see startup MVP and concurrent users.
Deployment configuration
vLLM launch (FP8, 32k context, 32 concurrent agents)
python -m vllm.entrypoints.openai.api_server \
--model NousResearch/Hermes-3-Llama-3.1-8B \
--quantization fp8 --kv-cache-dtype fp8 \
--max-model-len 32768 --max-num-seqs 32 \
--enable-chunked-prefill --enable-prefix-caching \
--gpu-memory-utilization 0.92 \
--tool-call-parser hermes \
--chat-template-content-format hermes
vLLM launch (AWQ-Marlin, lower latency, fewer concurrent users)
python -m vllm.entrypoints.openai.api_server \
--model NousResearch/Hermes-3-Llama-3.1-8B-AWQ \
--quantization awq_marlin --kv-cache-dtype fp8 \
--max-model-len 65536 --max-num-seqs 16 \
--enable-prefix-caching \
--gpu-memory-utilization 0.93 \
--tool-call-parser hermes
Test rig and methodology
All numbers above were captured on a single-tenant Gigagpu node: RTX 4090 24GB Founders Edition reference card at stock 450 W, Ryzen 9 7950X with 64 GB DDR5-5600, Samsung 990 Pro 2TB Gen 4 NVMe with the model files mounted on a dedicated dataset; Ubuntu 24.04 LTS, NVIDIA driver 560.x, CUDA 12.6, vLLM 0.6.4, PyTorch 2.5, FlashAttention 2.6. Throughput numbers are sustained means over 60-second windows after warm-up; concurrency was driven by an asyncio harness wrapped around vLLM’s benchmark_throughput.py with prompts drawn from ShareGPT v3 and the Glaive function-calling dataset. See our vLLM setup guide for the installation walkthrough.
Production gotchas
- Tool parser registration is not the default. vLLM ships the
hermestool parser but it is not enabled unless you pass--tool-call-parser hermes. Without it you will get raw model output containing the JSON wrapper and your client SDK will silently treat it as plain text. - EOS token for tool calls leaks into transcripts. Hermes 3 emits
<tool_call>and</tool_call>sentinel tokens. If your downstream parser does not strip them you will leak the markup into chat history. Add them to your sanitiser. - Permissive output is on you to gate. Hermes intentionally refuses far less than stock Llama. That is the point, but you still need a moderation layer in front for any user-facing surface. We pair it with a small classifier on the egress path.
- Prefix caching invalidation under multi-tenant load. If you rotate the system prompt per-tenant, prefix caching offers nothing. Pin one system prompt per worker and route by header, or accept the loss.
- FP8 KV with AWQ weights is slower for very short prompts. The combination uses a separate cuBLASLt kernel that is fractionally slower for prompts under 64 tokens. For pure chatbot UX with brief turns, FP16 KV on AWQ is marginally lower latency.
- Chunked prefill is mandatory for long context. Without
--enable-chunked-prefilla single 32k-token prompt blocks the scheduler for ~4 seconds and starves all other users. Always enable it for any deployment serving more than one stream. - NVLink is absent on the 4090. If you outgrow one card the second 4090 communicates only over PCIe 4.0 x16 (~25 GB/s effective). Tensor parallelism for an 8B model is not worth the latency tax; horizontally scale by spawning independent processes instead. See PCIe Gen4 x16 notes.
Cost per million tokens
| Workload | Sustained t/s | Tokens / 24h | Energy / Mtok | £ / Mtok (UK power 28p/kWh) |
|---|---|---|---|---|
| Single-user chat (b=1) | 198 | 17.1M | 2.07 kWh | £0.55 |
| Light multi-user (b=8) | 880 | 76.0M | 0.46 kWh | £0.12 |
| Steady agent farm (b=32) | 1,100 | 95.0M | 0.37 kWh | £0.10 |
| Burst load (b=64) | 1,140 | 98.5M | 0.36 kWh | £0.09 |
Compared to OpenAI’s gpt-4o-mini at roughly £0.45 per million output tokens, the 4090 wins decisively on output cost the moment you have steady throughput. See vs OpenAI API cost and monthly hosting cost for the full economics.
Verdict and alternatives
Hermes 3 8B on a 4090 is the right choice when (a) you are building an agent or tool-using product where structured-output adherence and unfiltered tool routing matter more than the last point of MMLU, (b) your traffic profile is many short concurrent conversations rather than one long completion, and (c) you want to keep all user data on a single-tenant box in the UK. If your workload is mostly long-form summarisation of legal documents, Qwen 2.5 14B or Mistral Small 3 will give you sharper outputs at lower throughput; if you need 70B-class reasoning see our Llama 70B INT4 guide. For pure chatbot workloads without heavy tool use, base Llama 3 8B is fractionally faster and cheaper.
Run Hermes 3 8B on UK silicon
Single-tenant 4090, 1 Gbps unmetered, ready in 15 minutes. UK dedicated hosting with full root access.
Order the RTX 4090 24GBSee also: Llama 3 8B benchmark, Llama 3 8B model guide, vLLM setup, FP8 deployment, AWQ guide, prefill/decode, tokens per watt, fine-tune throughput.