---
title: "frequently-asked-question"
url: "https://docs.api.pruna.ai/faq"
image: "https://docs.api.pruna.ai/_og/d/c_Ocean.takumi,title_frequently-asked-question,props_eyJ0aGVtZSI6eyJtb2RlIjoibGlnaHQiLCJjb2xvcnMiOnsicHJpbWFyeSI6IiM3YzNhZWQifX19,p_Ii9mYXEi,s_HevMil2IIwZKEUAc.png"
---

# FAQ

---

### [Performance Issues](#performance-issues)

#### [Q: My generations feel slow. What’s going on?](#q-my-generations-feel-slow-whats-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](#sync-vs-async-timeouts)

#### [Q: What does `try-sync: true` do?](#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?](#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?](#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](#input-images-base64)

#### [Q: Can we send input images as Base64? Or upload files directly?](#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

2.  **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](#input-images-urls)

#### [Q: Instead of the Pruna URL, can we use any public URL?](#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](#rate-limits)

#### [Q: The docs say ~150 requests/min. I may hit more. Problem?](#q-the-docs-say-150-requestsmin-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](#resolution-dimensions)

#### [Q: Can I set explicit width/height instead of a fixed resolution?](#q-can-i-set-explicit-widthheight-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](#seed)

#### [Q: Does `seed` exist? How do we avoid repetitive images?](#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](#lora-customization)

#### [Q: Can we use LoRA with `p-image` or `p-image-edit`?](#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](#safety-nsfw)

#### [Q: Is there an NSFW/safety parameter?](#q-is-there-an-nsfwsafety-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.

---