5.4 The Batch Pipeline: Serial Production
One image at a time is a hobby. The economics of this business — twenty to thirty variations a week for brand work (2.6), three to five posts a week minimum for the account — require producing in batches.
A One production run, sized from the survival rate rather than from ambition. pipeline has four properties: a single reference drives many outputs, the operations run in a fixed order, the ordering discipline is respected, and the Generation spend divided by frames passing QA; the metric that makes tier changes comparable. is known.
The node graph
Whatever tool you use — a The node-graph engine the book uses as a production engine, callable by an orchestrator. workflow, a hosted batch feature, or a script — the shape is the same:
[face sheet] ─┐
[body sheet] ─┼─→ [reference conditioning] ─┐
[outfit ref] ─┤ │
[location ref]─┘ ▼
[prompt list: 40 variants] ──────────→ [batch generator] ─→ [raw frames]
│
[edit / inpaint]
│
[crop + upscale]
│
[skin detail pass]
│
[export set]
Two things about this graph matter more than the tooling.
The reference inputs are nodes, not uploads. Chapter 5.1's rule. Wire them in once; every generation in the batch inherits them.
The The maintained set of forty reusable prompt variants, refilled in the weekly review slot. is a file, not a form. One line per output. The generator consumes it; you review the results, not the process. That file is what makes a batch reproducible — the same manifest plus the same references produces the same set, which is what chapter 7.1's automation needs.
Batching by tool tier
Three tiers, each with a different practical batch size. [AS OF 2026-10] Specifications change; verify current limits.
Hosted consumer tools with batch modes. Some cap around 40 generations per run. Convenient and opaque: you do not control the The algorithm walking from noise to image, such as Euler or a DPM++ variant., and the same prompt can produce visibly different results across runs. Use for volume where consistency is already handled by the reference layer.
Hosted API and node-based workflows. Effectively unlimited batch size, subject to rate limits and credit balance. This is the tier where batch size becomes a cost question rather than a technical one. A graph with the reference wired in, a prompt-list node, and a save node is the whole pipeline, and chapter 7.2 covers the engine.
Scripted clients. A small script that reads the prompt list, calls an API, and saves outputs. No graph editor, fully reproducible, version-controllable. The right choice once your process stabilizes, and the entry point to chapter 7.3's orchestration.
Cost per output, and why the headline number is misleading
Two figures from the current market illustrate the gap. [AS OF 2026-10]
| Route | Cost per image | What that buys |
|---|---|---|
| Subscription plan, high-volume use | ~$0.006 | Marginal cost inside an already-paid quota |
| Per-image aggregator / API | ~$0.36 | Pay-per-use, no commitment, no waste |
A factor of roughly sixty between them, and the comparison is incomplete in both directions. The subscription figure assumes you consume the quota — unused capacity costs the full subscription at any volume, and prepaid credit that expires is chapter 1.5's fourth failure pattern. The per-image figure ignores the iteration that this work requires: the cost you actually pay is cost per usable frame.
The number to track is the rejection rate. If one frame in three survives QA (5.6), the real cost of an image is three times the headline. If one in fifteen survives a picky brand brief, it is fifteen times. This is why the rejection rate belongs in your cost model rather than in your feelings, and why improving your reference layer is a financial decision and not only an aesthetic one.
A worked estimate for a week, on the subscription route:
| Item | Count | Cost |
|---|---|---|
| Generated frames | 150 | ~$0.90 at $0.006 |
| Usable after QA (≈1 in 3) | 50 | |
| Posts published | 4 | |
| Cost per published post | ~$0.23 + subscription share |
And the same week on the per-image route: 150 frames at $0.36 is $54 for the same four posts. Both figures are only meaningful with the subscription's monthly cost amortized and the rejection rate applied — which is what chapter 7.4's cost architecture does properly.
The ordering rule
All edits first, post-processing last — and never iterate on a post-processed frame.
The reason is arithmetic and quality, in that order.
Arithmetic. Raising resolution on pixels rather than latents, so it runs after composition, identity, and repair. multiplies pixel count and every subsequent operation's cost. A 4-megapixel frame upscaled to 16 megapixels makes every inpaint, A face-detail operation run last at final resolution and low denoise; over-detailing reads as synthetic., and re-generation four times more expensive in time and often in credits. Editing at the smallest size that shows the problem is cheaper.
Quality. Each stage degrades the image slightly: the upscaler invents detail, the detailer sharpens what it finds, and repeated cycles compound. Iterating on an upscaled frame stacks inventions on inventions, which is how a face acquires the waxy quality audiences notice without being able to name.
The consequence for workflow: if a frame needs a fix after post-processing, go back to the raw generation and fix it there, then run the chain again. The chain is fast and reproducible; patching its output is neither.
The operation order
| Step | Operation | Why here |
|---|---|---|
| 1 | Generate from prompt list | Cheap, high volume, low precision |
| 2 | Edit / inpaint | Fix hands, jewellery, background, wardrobe errors |
| 3 | Crop and compose | Framing per platform (2.5) |
| 4 | Upscale | Once, at the end of geometry changes |
| 5 | Skin detail pass | Last, at final resolution, so it is not undone |
| 6 | Export | Per-platform profiles |
Two notes. The skin detailer runs after upscaling because a detailer applied before an upscale has its work partially overwritten — the upscaler re-smooths what the detailer sharpened. And crop before upscale for the same reason as edits: you should not pay to upscale pixels you are about to discard.
Rate limits and credits
Batch production meets metered billing, and the failure is organizational rather than technical.
Know your ceiling before you start a batch. A 150-frame batch that hits a rate limit mid-run leaves you with an incomplete set and an unclear state. Generate in chunks within your known limit.
Prefer pay-as-you-go at your real volume. Chapter 1.5's credit-expiry pattern: bulk prepayment is a bet that your future production matches your purchase, with an expiry date on the loss. Buy capacity slightly ahead of need.
Keep a small reserve. A trend arrives, a brand asks for variations today. Ten percent of your monthly capacity held back converts that from impossible to an hour's work.
Log consumption per batch. Frames requested, frames returned, frames usable, credits spent. After three batches you will know your real cost per usable frame, which is the number 7.4 needs and no vendor publishes.
Diagnosing a bad batch
When a batch comes back worse than usual, five checks locate the cause, in order of likelihood.
1. Every face drifts slightly. The reference is not being applied. Check that the conditioning node actually received the sheet — a silent failure mode, because the batch runs and produces plausible images with the wrong person in them.
2. The output is repetitive. The prompt list is stale or the sampler is reusing one The random starting point; the same seed with the same settings reproduces the same image.. Check the manifest: forty variants should produce forty distinguishable scenes.
3. Hands fail across the whole batch. The pose set is bad. Fix it in the One prompt-and-settings combination inside a batch, tracked so its survival can be measured. list — the fix belongs one layer up, not in 150 Regenerating only a masked region; the surgical tool for a hand, an eye, or one bad detail. sessions (5.5).
4. Cost per usable frame jumped. Either the rejection rate rose (check QA) or credits are being consumed by retries. Compare consumption against the manifest's expected frame count.
5. Two runs of the same manifest differ visibly. Expected with hosted consumer tools, and a reason to move tiers if reproducibility matters to you. A node-based or scripted route with a fixed seed and a recorded model version is the only configuration where the same manifest means the same output.
The pattern across all five: a bad batch is nearly always a pipeline diagnosis, not a bad day for the model. Recording the manifest and the reference versions for every batch is what makes the diagnosis possible three weeks later.
Scaling the batch
Three increases, in the order that is safe:
More prompts in the list. The cheapest increase. Forty variants to eighty costs only the writing time.
More reference layers. Adding outfit and location references increases consistency and variety simultaneously, which is why 5.3 is worth doing before 5.4.
More identity versions in parallel. The expensive one. Each identity is a separate adapter, dataset, and QA cycle. This is chapter 12.6's scaling question, and the answer is always "after the first one has revenue."
Where this goes wrong
Generating one image at a time. The cost is not the credits; it is that every image is a fresh decision.
Uploading references per generation. One forgotten upload produces an off-identity frame.
Post-processing before editing. You have upscaled the problems.
Iterating on an upscaled frame. Compounded invented detail.
A batch without a prompt manifest. Not reproducible, and not automatable.
Measuring cost per generated frame. The metric that matters is cost per usable frame.
Prepaying for capacity you have not demonstrated. Expires, and the loss is total.
The gate
- Can one reference set drive a whole batch without manual re-upload?
- Is your prompt list a file, suitable for reuse and automation?
- Are edits complete before any upscaling or detail pass?
- Do you know your cost per usable frame, with the rejection rate applied?
- Do you know your rate ceiling, and do you reserve capacity?
What you leave with
A A saved generation workflow expressed as connected nodes, runnable from an API or script. where references are inputs rather than uploads and the prompt list is a manifest, three tool tiers with their tradeoffs, the sixty-fold cost spread and the metric that makes it comparable — cost per usable frame with the rejection rate applied — the ordering rule with its arithmetic and quality arguments, the six-step operation order, rate-limit and credit discipline, three safe ways to scale a batch, and the reason 5.3 comes before 5.4.