Automate the boring 80%, with an LLM that never bills per token
Most companies' first LLM project is a chatbot. Most companies' highest-ROI LLM project is nobody talking to anything at all, a scheduled job that reads every document, ticket, and spreadsheet row that came in overnight and does the boring part before a human ever opens it.
Chat is the demo. Batch is the business case.
A chat interface makes a good demo because a person is in the loop, typing, watching it think. But most operational work isn't a conversation, it's a queue. Invoices arrive. Contracts get uploaded. Support tickets pile up overnight. Reports need writing every Monday. Someone, somewhere, is currently reading these one at a time and typing a summary or a category into a field.
That's the work an LLM does without getting tired, without needing a UI, and without anyone in the loop for the first pass, as long as two things are true: the model can run over the entire volume, not a sampled slice, and the documents don't have to leave the building to get there.
Six patterns that pay for the machine by themselves
- Document classification & routing. Inbound email, uploads, or scanned mail sorted into categories (invoice, contract, complaint, spam, urgent) and routed to the right queue or person, before a human triages anything.
- Invoice & contract extraction. Pull line items, totals, dates, parties, and clauses into structured JSON for your ERP or accounting system, replacing manual re-keying or brittle OCR-plus-regex pipelines.
- Support-ticket triage and draft replies. Classify severity and topic, tag the right team, and draft a first-pass response for a human to edit and send, the model does the blank-page problem, not the judgment call.
- Report generation. Turn raw logs, metrics exports, or form submissions into a written weekly summary or status report, on a schedule, without anyone assembling it by hand.
- Translation at volume. Batch-translate product catalogs, support documentation, or incoming correspondence, run over thousands of items overnight instead of paying per word or per call.
- Data cleaning & normalization. Standardize free-text fields, addresses, company names, product descriptions, into consistent structured values across every row of a database, including the ones nobody ever got around to fixing.
None of these need a chat window. Every one of them is a script that reads a row or a file, calls a model, and writes a result, the kind of job that's been possible since regex, except now it understands the document instead of pattern-matching it.
The marginal token is free
Per-token API pricing is built for a chat product: a human types a question, waits, reads an answer. It quietly breaks down the moment you point it at a queue of ten thousand documents, because now the bill scales with volume, and "run the model over everything" becomes a line item someone has to approve.
Rough, generic numbers to make the shape of it visible, actual API pricing varies by provider and model class, so treat these as ballpark ranges, not quotes:
| Per-token API (generic range) | Flat-rate dedicated Spark | |
|---|---|---|
| Pricing basis | ~$0.15–$3 per million tokens, varies by model tier | $1,490/mo reserved, or $2.90/hr, fixed regardless of volume |
| 10,000 docs/day, ~1,500 tokens each (in+out) | ~15M tokens/day → roughly $70–$1,300/mo depending on model tier | $1,490/mo flat, whether you process 100 docs a day or the full 10,000 |
| Cost of processing the whole backlog, not a sample | Scales linearly, the safe move is to sample and skip most of it | Zero marginal cost, running it over everything is the default |
| Where the data goes | Every document leaves your network to a third-party API | Stays on hardware in the EU, or in your own building |
| Rate limits / throttling | Provider-imposed, tightens under batch load | None, it's your GPU, your queue depth |
The number that matters isn't the per-document cost at either end, at low volume, per-token APIs are genuinely cheaper than renting a machine. It's the shape of the curve. A per-token bill punishes you for using the model more, which means someone always ends up deciding what not to run it on. A flat-rate machine has the opposite incentive: once it's paid for, the cheapest thing to do with idle GPU overnight is run it over everything you've got. There is still a ceiling: a 32B model on one Spark sustains roughly 10–15M tokens a day under batched load, which is what the 10,000-documents-a-day row above assumes. Past that you add nodes. At real document volumes, tens of thousands a month, that crossover comes fast, and the compliance angle (nothing leaves the network) is the part a spreadsheet doesn't capture at all.
A practical architecture
You don't need a platform team to build this. The whole thing is: a scheduler, a queue of documents, and an OpenAI-compatible endpoint.
# serve a capable model with an OpenAI-compatible API, see our vLLM guide # /dgx-spark/guides/serve-qwen3-vllm pip install vllm vllm serve Qwen/Qwen3-32B-AWQ --host 0.0.0.0 --port 8000 # any workflow tool or script now treats it like OpenAI curl http://spark.local:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model":"Qwen/Qwen3-32B-AWQ","messages":[{"role":"user","content":"Classify this invoice: ..."}],"response_format":{"type":"json_object"}}'
From there, two shapes cover most real deployments:
- n8n (self-hosted). Point n8n's OpenAI-compatible credential at
http://spark.local:8000/v1, build a workflow that watches an inbox, S3 bucket, or database table, calls the model node per item, and writes structured output back, no code, and it's the same n8n whether the backend is OpenAI or your own Spark. - Cron + a plain script. For anything that doesn't need a visual workflow: a Python script that pulls the day's unprocessed rows, calls the endpoint per row with a fixed JSON schema in the prompt, writes results back, and logs failures. Run it from cron at 2am. This is often less to maintain than a workflow platform for a single well-defined job.
Either way, the pattern is the same: batch the requests, use structured output (JSON mode or a strict schema in the prompt) so downstream systems can consume it without parsing prose, and let the job run unattended overnight against hardware that doesn't care how long the queue is.
Where automation quality isn't there yet
Be honest with yourself about what this replaces. It's very good at first-pass work and consistently mediocre at final judgment calls.
- Extraction errors compound downstream. A misread invoice total that flows straight into accounting is worse than a slow human doing it right. High-stakes extraction needs a validation step, schema checks, sanity ranges, a confidence flag, before it touches a system of record.
- Edge cases need a human, not a bigger prompt. Classification and triage models do well on the common 80% and poorly on the unusual 20%, the ambiguous contract clause, the ticket that's really three issues. Route low-confidence outputs to a review queue instead of trying to prompt your way to 100%.
- Drafted replies are drafts. A model-written customer response should go through a human before it's sent, at least until you've measured error rates on your own data for a while. Treat "draft" as a literal instruction to the workflow, not a formality.
- Start with a human-in-the-loop version, then tighten it. Run the automation alongside the existing manual process for a few weeks, compare outputs, and only remove the human step for the categories where the model's track record earns it.
None of that is an argument against automating, it's an argument for automating the parts that are actually mechanical (reading, extracting, sorting, drafting) and keeping a person on the parts that require judgment. That split alone is usually enough to eliminate most of the manual grind.