Cybersecurity glossary
What is Model Denial of Service?
Learn what model denial of service is, how attackers stall or saturate LLM inference with heavy prompts and pathological decoding, how it relates to unbounded consumption, and which capacity and request controls keep assistants available.
Definition
Model denial of service is an availability attack against LLM inference: crafted or voluminous requests occupy GPUs, blow context windows, trigger pathological decoding, or exhaust worker pools so legitimate users cannot get completions in time—or at all.
Why model denial of service matters
GPUs are scarce and generations are long. Model denial of service uses that physics. An attacker does not need to crash the process. They only need to keep every worker busy with worst-case prompts until your chat, copilot, or agent times out for everyone else.
This is classic DoS with an LLM-shaped cost function: tokens and steps, not only packets per second. Availability is now a security property of the inference path.
How inference gets pinned
Reach the inference API
Public demos, leaked keys, or shared internal endpoints without per-tenant isolation.
Submit heavy work
Maxed context, huge output limits, or recursive agent plans.
Hold the worker
Attention and decoding occupy a GPU for seconds to minutes per request.
Multiply
Concurrency and retries fill the pool faster than it drains.
Queue explodes
Legitimate requests wait past client timeouts and look like an outage.
Cascade
Retries from honest clients make the backlog worse; dependent tools time out too.
Availability attack shapes
Context stuffing
Near-limit inputs on every call so each request is maximally expensive.
Output stretching
Instructions to generate until the stop limit, occupying the decoder.
Pathological payloads
Inputs that stress tokenizers, parsers, or safety models in front of the LLM.
Noisy-neighbor tenants
One customer’s batch job starves interactive users on a shared cluster.
Model DoS versus unbounded consumption
| Question | Model denial of service | Unbounded consumption |
|---|---|---|
| What breaks first? | Latency, errors, empty worker pool | Invoice, quota, downstream API limits |
| Success for the attacker? | Your assistant is down | You overpay or hit a hard budget stop |
| Shared root cause | No caps on work per request or per tenant | The same missing caps |
| Extra control | Load shedding, isolation, capacity SLOs | Spend alerts and denial-of-wallet budgets |
- Authenticate inference; anonymous demos get tiny caps and aggressive shedding.
- Enforce max input tokens, max output tokens, and wall-clock timeouts per request.
- Isolate tenants with fair scheduling so one flood cannot take the whole pool.
- Cap concurrency per key and per org; reject overflow with a clear 429.
- Watch GPU utilization, queue depth, and p99 latency as security-relevant SLOs.
- Load-test with worst-case contexts before launch; know when the service kneels.
- Harden pre-model parsers and classifiers against ReDoS-like inputs.
- Pair availability caps with [unbounded consumption](/glossary/unbounded-consumption) budgets so you do not trade an outage for a surprise bill.
The practical takeaway
Model denial of service takes an LLM offline by occupying inference, not by inventing a new cryptographic break. Long prompts and unbounded loops are availability weapons.
Cap work, isolate tenants, shed load, and treat queue depth as an incident. If anyone can hold a GPU without a budget, they can hold your product’s uptime.
Related security terms
Unbounded Consumption
Cost-focused sibling risk; the same flood can empty both wallet and queue.
Denial of Service (DoS)
The general availability-attack class this specializes for models.
Resource Exhaustion
CPU, memory, and worker starvation patterns that apply to inference too.
Rate Limiting
Necessary but insufficient if each request can hang a GPU.
Large Language Model (LLM)
The scarce, expensive component being exhausted.
Frequently asked questions
What is model denial of service in simple terms?
Someone keeps the model so busy—or so stuck—that nobody else gets an answer. The ‘weapon’ is expensive prompts, not necessarily a network flood of tiny packets.
How is this different from unbounded consumption?
Unbounded consumption stresses cost and quota (denial of wallet). Model DoS stresses availability. One request pattern often causes both.
What makes a prompt expensive?
Long inputs, long max-output, many parallel tool calls, huge retrieval, or sequences that hit worst-case attention or decoding behavior.
Can ReDoS-like bugs exist in tokenizers?
Unusual inputs can stress tokenizers, JSON parsers, or safety classifiers in front of the model. Treat those as part of the inference path.
Is a queue backup DoS?
Yes for users. If attackers occupy all workers, legitimate latency goes to timeout even if the process did not crash.
Do WAFs stop this?
They help against dumb floods. They do not understand that a single 100k-token JSON body is a logical bomb. Application caps still required.
How do you defend?
Authenticate, cap tokens and time, isolate noisy tenants, autoscale with a max, shed load, and cache. Watch queue depth like an SLO.
References
Explore authoritative guidance and frameworks related to model denial of service.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.