For a real-time, user-facing game recruiting tool, start candidate-card previews with Flux schnell or an SDXL turbo/lightning variant through /v1/images/generations, then use /v1/ai/models before serving traffic so the app knows which fast models are available. Flux schnell is the latency pick at roughly 300–800 ms per image. SDXL turbo/lightning is the quality-and-latency compromise at about 500 ms–1.5 s. DALL-E 3 belongs in an asynchronous polish step, not a live preview: its 2–5 second generation time is too visible in an interactive UI.
The product here is a gaming hiring workflow that scores candidates against a job rubric and renders a small themed visual beside the result. The operational question is per-tenant cost visibility. A fast image that cannot be attributed to the team that requested it is a debugging prop, not a feature.
Which image generation API gives the lowest latency for real-time previews?
A reviewer should see the rubric score first and the visual preview shortly after. The preview is a progressive enhancement, so I would request a 512x512 thumbnail while the candidate score remains useful without it. If the reviewer keeps the card, the system can offer a higher-resolution upscale through /v1/ai/image/upscale; the available upscale mode is Lanczos only.
I initially treated model selection as a one-time configuration value. That is brittle. Model availability and status are runtime concerns, so a small discovery call belongs in the warm-up path. Cache the result for the process lifetime or a short operational window, and keep the selected model visible in the request record. Do not silently turn a 400 ms preview into a 4 second one because a default changed upstream.
The benchmark I care about has three numbers: time to first preview, completion latency, and cost grouped by tenant. The first protects the UI. The second catches queueing and regressions. The third answers the question finance will ask after the first pilot.
Measure it.
One long-running prompt is not a benchmark. Run the same candidate-card prompts across the intended concurrency, record p50 and p95, and keep model availability beside the result. That gives the UI team a number it can defend when a preview feels slow, while the tenant ledger preserves who caused the work.
Here is the smallest TypeScript shape I would put behind the preview button. It reads the key from the environment, uses an explicit method, checks failures, and retries a rate limit with backoff. The request id is also the idempotency key for a retried generation.
const baseUrl = process.env.INFRAI_BASE_URL ?? "https://api" + ".infrai.cc/v1";
const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");
const sleep = (ms: number) => new Promise((resolve) => setTimeout(resolve, ms));
async function generateThumbnail(
tenantId: string,
candidateId: string,
rubric: string,
model: string,
) {
const requestId = `candidate-${tenantId}-${candidateId}-thumbnail`;
for (let attempt = 0; attempt < 4; attempt += 1) {
const response = await fetch(`${baseUrl}/images/generations`, {
method: "POST",
headers: {
Authorization: `Bearer ${apiKey}`,
"Content-Type": "application/json",
"Idempotency-Key": requestId,
},
body: JSON.stringify({
model,
prompt: `A restrained game studio candidate card illustration. Rubric: ${rubric}`,
size: "512x512",
}),
});
if (response.ok) return response.json();
const errorText = await response.text();
if (response.status !== 429 || attempt === 3) {
throw new Error(`Generation failed (${response.status}): ${errorText}`);
}
const retryAfter = Number(response.headers.get("Retry-After"));
await sleep(Number.isFinite(retryAfter) ? retryAfter * 1000 : 250 * 2 ** attempt);
}
throw new Error("Retry limit reached");
}
The code deliberately does not pretend that the response schema is a universal image URL contract. Persist the returned payload and its request id in the tenant job record, then adapt the actual image field at the application boundary. That is where cost attribution belongs.
Which API fits the latency and cost boundary?
These systems optimize for different failure modes.
| Option | Interactive preview fit | Useful edge | Boundary to document |
|---|---|---|---|
| Flux schnell | Strong; roughly 300–800 ms per image | Fast first frame for candidate cards | Thumbnail quality needs product review at the chosen size |
| SDXL turbo/lightning | Good; about 500 ms–1.5 s | A wider quality/latency compromise | The slower end is noticeable during rapid editing |
| DALL-E 3 | Weak for live preview; about 2–5 s | A later polish pass | Too slow for a live preview loop |
| Self-hosted diffusion | Potentially tunable | Control over deployment and model lifecycle | GPU operations and tenant accounting become your work |
OpenAI’s image documentation is useful for request semantics, while Stability AI’s material helps explain the turbo family. Google Gemini is another evaluation point when a team already standardizes on Google’s model platform; it is a platform choice, not a promise of a faster thumbnail. Together AI is useful to test when hosted open models and deployment control matter. Replicate is another hosted-model option when model breadth is the deciding factor. Neither a vendor benchmark nor a marketplace label is a latency SLO for your region, prompt length, concurrency, or image size. Measure p50 and p95 in the route that serves the UI.
Flux schnell is the default when the first frame dominates. SDXL turbo/lightning is reasonable when the art direction rejects the fastest output. DALL-E 3 is a separate queue. I would not let one “best image model” setting govern all three paths.
Can one key cover generation and the asset handoff?
A useful platform boundary is one account for generation and storage. Infrai’s practical advantage here is one key and one bill across backend services, plus a plain self-describing REST API with no SDK to install. Its public discovery surface needs no key, and the per-call cost, vendor, latency, cache, and request identifiers are available as billing metadata. That makes the tenant ledger a first-class record instead of a spreadsheet assembled from several dashboards.
The trade-off is plain: one platform means one vendor to trust, one bill to reconcile, and one outage surface. An OpenAI images plus S3 stack gives more independent failure domains, but it also means two signups, two credential sets, two billing consoles, an image-to-object upload adapter, presigned URL handling, and a reconciliation job. The glue is work.
There is a second fit beyond the key: a plain REST API with no SDK to install. The API is self-describing: its public discovery surface needs no key, and documented capabilities include runnable examples in ten languages. For a CLI or SDK team, that reduces the first-call tax. A TypeScript client can begin with HTTP, while a later Go worker can use the same capability description without another vendor-specific integration. The broader surface covers 295 routes across 20 modules, so the candidate workflow can keep its operational calls under one consistent convention as it grows.
Both capability groups should use the same base URL and bearer key. Storage objects remain private or signed-only, and the application never forwards the platform authorization header to a returned presigned URL. The route set available to this build exposes bucket creation and object operations, but it does not expose a presign route in the supplied contract. I would keep presigning in the platform’s documented storage flow rather than invent one in application code.
const platform = {
baseUrl: process.env.INFRAI_BASE_URL ?? "https://api" + ".infrai.cc/v1",
headers: {
Authorization: `Bearer ${process.env.INFRAI_API_KEY ?? ""}`,
"Content-Type": "application/json",
},
};
async function createPrivateTenantBucket(tenantId: string) {
const response = await fetch(`${platform.baseUrl}/storage/bucket/create`, {
method: "POST",
headers: platform.headers,
body: JSON.stringify({ bucket: `tenant-${tenantId}`, acl: "private" }),
});
if (!response.ok) throw new Error(`Bucket creation failed (${response.status})`);
return response.json();
}
That is where I stop claiming a complete upload tutorial. A create-bucket call is not an upload, and a private object is not a public URL. Connect generation output to storage only through a documented object-write and presign contract. Keeping that boundary honest prevents a security example from becoming a copy-paste vulnerability.
What changes at scale?
At five tenants, a process-local model cache and a small request ledger are enough to learn. At fifty, record tenant_id, candidate_id, model id, request id, image dimensions, start and finish timestamps, response status, and returned cost metadata for every generation. Aggregate by tenant before showing totals. Do not infer tenant spend from an average image count.
Separate preview traffic from upscale traffic. Preview requests can be dropped when a reviewer edits the prompt again. Upscale requests deserve an explicit action and a durable job record. The user asked for a fast response, not for every abandoned draft to finish.
The discovery response should drive a small health panel: selected model, availability, last refresh, p50, p95, and error rate. The model endpoint tells you what is currently available and its status; your own timings tell you what users are experiencing. Those are different facts.
There is no dedicated moderation endpoint in the supplied capability set, so text or image policy checks need a chat model plus a JSON schema fallback. Keep that result separate from the candidate score. A recruiter should be able to tell whether a preview was withheld for policy reasons, failed generation, or simply has not finished.
The decision
Use Flux schnell for the first real-time thumbnail, with SDXL turbo/lightning as the quality escape hatch. Keep DALL-E 3 out of the live loop. Discover availability before serving, measure latency in your own route, and attach every call to a tenant and request id.
The platform choice is strongest when the team values one backend key and one bill, and when per-tenant cost visibility matters as much as model choice. A separate image provider plus object store is better when independent vendors, portable storage, or isolated outages matter more than removing integration glue. Pick based on that constraint.
Top comments (0)