Search
K

FAQ

Performance Issues

Q: My generations feel slow. What’s going on?

Two common culprits:

  1. Latency from your server location. If your requests originate far from the model’s hosting region, inference will naturally feel slower. Running calls from a US-based server usually speeds things up.
  2. Extra, unnecessary API calls. The image URL returned in the response is already public. You can download the image directly. Making an additional request to “retrieve” the URL just adds delay.

Sync vs Async & Timeouts

Q: What does try-sync: true do?

A: try-sync: true → synchronous mode. The /predictions request waits until the result is ready and then returns the final payload directly (including generation_url).


Without try-sync (or with it set to false), you get a status URL, and you poll that /status endpoint until the prediction is succeeded, then you fetch the final result with the generation_url.

We recommend:

  • Async by default, especially for:
    • Video models
    • Anything that might sometimes be slow or queued
  • Sync is fine for fast models like p-image / p-image-edit in most use cases.

Q: What happens if I do a synchronous request and it takes like 2 minutes? Will it switch to async or time out?

A: In theory, the system should fall back to a safe behaviour — but in practice you can hit timeouts on long synchronous jobs.

  • For long-running models (especially video), use asynchronous: send the job, poll status, download result.
  • For p-image / p-image-edit, synchronous is usually fine.

Q: How often should we poll the status endpoint in async mode?

A: For fast image models (p family): → Poll ~every 1 second (they usually finish in < 1s once running)

For video models: → Poll every 2–5 seconds

There is a polling rate limit, but it’s deliberately high — normal polling won’t hit it.

Input Images – Base64

Q: Can we send input images as Base64? Or upload files directly?

A: No, Base64 is not currently supported. You have two options:

  1. Upload to Pruna via the upload endpoint:
  • Send the file
  • Receive a temporary URL
  • Use that URL in your prediction
  1. Use any public URL:
  • Any HTTPS-accessible image URL works

Temporary Pruna URLs are not permanent — they’re just for the generation/edit workflow.

Input Images – URLs

Q: Instead of the Pruna URL, can we use any public URL?

A: Yes — both options work:

  • Upload to Pruna → use the temporary URL
  • Use any publicly accessible image URL directly

The model just needs to be able to fetch the file.

Rate Limits

Q: The docs say ~150 requests/min. I may hit more. Problem?

A: Rate limits are per account, not global. Defaults are conservative to avoid accidental self-DDoS.

If you expect 300–400+ req/min, ask us — we can raise your limit. Goal: no surprise throttling in production.

Resolution & Dimensions

Q: Can I set explicit width/height instead of a fixed resolution?

A: Models are built around a megapixel budget and preferred aspect ratios, so resolution is usually fixed per ratio (portrait, landscape, square).

We can support explicit width/height case-by-case:

  • Allowed within sensible limits
  • Very high resolutions may change pricing or constraints

Reach out if you need something custom.

Seed

Q: Does seed exist? How do we avoid repetitive images?

A: Yes — the API supports a seed.

  • Fix the seed → reproducible outputs
  • Randomize the seed → more variation for users

LoRA Customization

Q: Can we use LoRA with p-image or p-image-edit?

A: Not at launch, but yes in principle.

LoRA complicates performance optimizations:

  • Requires dynamic architectures
  • Must avoid recompilation overhead

We chose a simpler, highly-optimized launch setup. PoCs for fast LoRA switching already exist.

Safety / NSFW

Q: Is there an NSFW/safety parameter?

A: Yes — an NSFW filter is integrated.

  • It’s an input parameter
  • You can enable/disable it depending on your platform’s policy

We don't enforce a single global rule.