Automate the boring 80%, with an LLM that never bills per token

The LLM project that pays back fastest usually has no chat window. It is a scheduled job that reads every document, ticket and spreadsheet row that came in overnight and does the boring part before a person opens it. Most companies start with a chatbot anyway.

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. Most operational work is a queue, not a conversation. 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.

An LLM can do that first pass unattended and without a UI, as long as two things hold: the model can run over the entire volume, not a sampled slice, and the documents can go to it without landing in an AI vendor's API.

Six batch jobs worth automating first

• 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 solves the blank page; the person makes 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: thousands of items overnight, without 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 rows nobody got around to fixing.

None of these need a chat window. Each is a script that reads a row or a file, calls a model and writes a result. Scripts like that have existed since regex; the difference is that the model reads the document instead of pattern-matching it.

The marginal token is free

Per-token API pricing is built for chat: a person types a question, waits and reads an answer. Point it at a queue of ten thousand documents and the bill scales with volume, so "run the model over everything" becomes a line item someone has to approve.

Rough, generic numbers to show the shape. API pricing varies by provider and model class, so treat these as ballpark ranges, not quotes:

At low volume, per-token APIs are cheaper than renting a machine. What matters is the shape of the curve. A per-token bill grows every time you use the model more, so someone ends up deciding what not to run it on. A flat-rate machine reverses that: once it is running, the cheapest use of idle GPU time overnight is to run it over everything you have.

There is still a ceiling. My planning figure is that 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 assumes; measure your own workload before relying on it. Past that you add nodes. At real document volumes, tens of thousands a month, the crossover comes fast. The spreadsheet also misses the data question: your documents go to your own model, not to an AI vendor's API, so no vendor retention or training policy applies.

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, and 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 the workflow is the same whether the backend is OpenAI or your 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.

Keep a human on judgment calls

Be honest about what this replaces. A model is 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.

So automate the mechanical parts (reading, extracting, sorting, drafting) and keep a person on the parts that need judgment. That split alone usually removes most of the manual grind.