Private AI Image Generation and Editing Suite Deployed on DGX Spark

A private image generation and editing service was deployed to show how a visual AI model can move from a local model stack into a repeatable, gateway-accessible system that product and engineering teams can test safely.

The build uses Z-Image-Turbo with a FastAPI service layer and LiteLLM gateway routing. It supports standard image generation through an OpenAI-compatible API surface and adds custom routes for extended text-to-image generation, image-to-image editing, inpainting, upscaling, refinement, LoRA listing, upscaler listing, model preloading, and health visibility.

The result is a reusable private AI media pattern: one governed access layer, one stable service wrapper, clear endpoint behavior, queue controls, and documented performance/resource characteristics on NVIDIA DGX Spark.

Use case

Private image generation and editing API for visual AI experimentation, product mock-ups, and controlled media workflows.

Deployment style

Self-hosted image service on NVIDIA DGX Spark with gateway-managed access.

Core capability

Text-to-image, image-to-image, inpainting, upscaling, refinement, and LoRA-assisted visual generation.

Primary interface

FastAPI service exposed through OpenAI-compatible image routes and selected custom pass-through routes.

Model registrations

Five model entries: text-to-image, image edit, inpaint, refine, and upscale.

Operational controls

Health endpoint, model/asset preload route, queue depth control, rate limits, and memory/queue status visibility.

Technical outcome

A reusable private AI service pattern for image models that need both standard API compatibility and custom visual workflow routes.

Image generation models are often demonstrated as scripts, notebooks, or isolated web UIs. That is useful for experimentation, but it is not enough when teams need controlled access, repeatable API behavior, model discovery, queue handling, and a clean path for product integration.

The challenge was to package an image generation and editing model so it could be used as a private service without exposing internal deployment details or forcing every workflow into a single generic endpoint.

• Create a practical API layer for text-to-image and image editing workflows.
• Support both OpenAI-compatible image generation and custom routes for advanced operations.
• Expose the service through the same gateway pattern used across the broader GenAI Protos model catalog.
• Keep resource behavior visible, including memory footprint, loading behavior, queue depth, and health status.
• Document the system clearly enough for developers and operators to discover, test, and reuse it.

GenAI Protos built a private image generation and editing suite around Z-Image-Turbo. The model was served through a FastAPI application and registered inside the DGX Spark model catalog so it could be discovered alongside other GenAI Protos model services.

• A FastAPI service using diffusers pipelines for Z-Image text-to-image, image-to-image, and inpainting workflows.
• Five gateway-registered image model entries covering generation, edit, inpaint, refine, and upscale capabilities.
• OpenAI-compatible image generation support for easier integration with existing SDKs and orchestration tools.
• Custom pass-through routes for LoRA stacking, seeded generation, image-to-image edits, mask-based inpainting, 4K upscaling, and refinement.
• Health and preload routes for operational visibility and controlled model/asset readiness.
• Queue and rate-limit behavior suitable for controlled evaluation and early application integration.

The architecture separates the developer interface, gateway layer, image service, model pipelines, and output/operations layer. This keeps the public API story clear while allowing advanced image workflows to remain available through controlled routes.

Application or developer

Submits prompts, image files, masks, dimensions, seed values, LoRA configuration, or upscaling parameters.

LiteLLM gateway

Provides shared access control, model discovery, standard image route support, and pass-through routing for advanced operations.

Image API service

FastAPI service receives requests, manages queue behavior, routes to the right image pipeline, and returns image output.

Model runtime

Z-Image pipelines handle text-to-image, image-to-image, and inpainting. Upscalers are lazy-loaded when needed.

Output layer

Returns generated or edited images through URL or encoded response formats, depending on request type.

Operations lane

Health status, memory/queue status, LoRA listing, upscaler listing, and preload behavior support day-to-day operation.

The prompt-to-image workflow shows how prompts, images, masks, LoRA settings, and upscaling requests move through the gateway, queue, image pipelines, and output layer.

This section summarises how GenAI Protos packaged the image model into a governed visual AI service with standard routes, custom routes, queue control, resource visibility, and operator readiness.

Model serving

The model was wrapped behind a FastAPI service so it could behave like a private application endpoint rather than a local-only model setup.

Gateway integration

The image suite was registered under the GenAI Protos gateway pattern with both standard and custom routes.

Image workflows

The service supports text-to-image, image-to-image editing, inpainting, upscaling, refinement, and LoRA-driven visual style workflows.

Compatibility

Standard image generation can be called through an OpenAI-compatible route, while advanced workflows use custom pass-through routes.

Resource control

The always-on service has documented first-load behavior, GPU memory footprint, queue depth, and steady-state throughput.

Operator visibility

Health, memory status, queue status, LoRA listing, upscaler listing, and preload routes were documented for service operation.

The technical details below record the image model suite, serving stack, cached weights, GPU allocation, upscaler behaviour, first-load timing, throughput, queue policy, catalog registration, and route limits.

The value of the build is not only that it generates images. The stronger pattern is that a complex visual model was converted into a private, governed service with clear integration and operating behavior.

GenAI Protos delivered a working private AI image generation and editing service that can be discovered, called, monitored, and reused within the same gateway-oriented operating model used for the wider DGX Spark AI catalog.

This case study can be reused as a pattern for private visual AI systems where the raw model is useful but the repository alone is not enough for product teams.

• Model wrapper: package the image model behind a stable service layer.
• Gateway route: expose standard operations through compatible APIs and advanced operations through governed pass-through routes.
• Workflow design: support generate, edit, inpaint, upscale, refine, and style-control paths instead of treating image generation as one endpoint.
• Resource design: document memory footprint, load behavior, throughput, and queue limits.
• Operational design: expose health, status, and preload behavior before the service is presented as product-ready.