BentoDiffusion: BentoML example services for the Stable Diffusion family

What BentoDiffusion actually is, and who it is for

The repository describes itself as "a series of BentoML example projects" that demonstrate how to deploy models in the Stable Diffusion family. That wording matters. It is not a single application with a plugin system. It is seven sibling directories, each holding its own service definition, and each aimed at one model or one technique: sdxl-turbo, sdxl-lightning, sd3-medium, sd3.5-large, sd3.5-large-turbo, flux-timestep-distilled and controlnet. The README walks through SDXL Turbo as the worked example and points elsewhere for the rest.

The audience follows from that shape. If you already serve models with BentoML and you want an image generation endpoint that behaves like your other services, with the same packaging and deployment commands, these examples give you a starting point you can copy. If you are looking for a standalone image generation tool with a browser interface, this is the wrong repository. There is no UI beyond the Swagger page that BentoML serves automatically, and no model download manager. The README states that a full list of BentoML example projects lives in the BentoML documentation, which is the honest framing: this is documentation sample code, published as a repository.

How the service is put together

Each subdirectory contains a service.py that defines a BentoML Service class. The README names the SDXL Turbo one explicitly: bentoml serve starts "service:SDXLTurboService" and listens on http://localhost:3000. That class is the unit of work. It loads a diffusion pipeline, exposes endpoints over HTTP, and BentoML handles the process management, the OpenAPI schema and the client generation.

The data flow is a request/response cycle, not a queue. A client posts JSON with a prompt and sampling parameters to an endpoint such as /txt2img; the service runs the pipeline on the GPU and returns the image bytes, which is why the curl example sets accept: image/*. There is no job store and no async polling in the example as documented. For a single image request against a turbo or lightning checkpoint this is fine, because those models are distilled to run in very few steps. The README's own curl example uses num_inference_steps: 1 and guidance_scale: 0, which tells you what kind of model it is targeting: one where a single denoising step is the intended mode of operation.

The deployment path is the other half of the architecture. Once the service runs, bentoml deploy pushes it to BentoCloud, and the README notes that for custom infrastructure you can use BentoML to generate an OCI-compliant image instead. That is the real design decision here: the same service definition can be run locally for testing, shipped to a managed platform, or baked into a container image you host yourself.

Installing and running the SDXL Turbo example

The README recommends an Nvidia GPU with at least 12GB VRAM to test the service locally, and recommends Python 3.11. Clone the repository and move into the subdirectory for the model you want. Dependencies come from that subdirectory's requirements.txt, not from a repository-wide file.

git clone https://github.com/bentoml/BentoDiffusion.git
cd BentoDiffusion/sdxl-turbo
pip install -r requirements.txt

Start the service from inside the project directory. The README shows the startup line the CLI prints, including the listening address and the name of the service class it loaded.

bentoml serve

You should see a line reporting that the BentoServer is listening on http://localhost:3000, followed by pipeline loading progress. Once it is up, the endpoint accepts JSON. The README's own example uses a single inference step and zero guidance scale, which is the mode SDXL Turbo is built for.

curl -X 'POST' \
  'http://localhost:3000/txt2img' \
  -H 'accept: image/*' \
  -H 'Content-Type: application/json' \
  -d '{
  "prompt": "A cinematic shot of a baby racoon wearing an intricate italian priest robe.",
  "num_inference_steps": 1,
  "guidance_scale": 0
}'

If you would rather stay in Python, the README gives a client that uses bentoml.SyncHTTPClient against the same URL and calls client.txt2img with the same parameters. That client is generated from the service schema, so it is a thin wrapper over the same HTTP call rather than a separate protocol.

Where the example model breaks down

The most concrete limitation is in the README itself: the 12GB VRAM figure is attached to the SDXL Turbo example specifically, and the larger checkpoints in the repository (SD3.5 Large, FLUX.1) are not given a VRAM figure at all. Anyone sizing a machine from this README alone is guessing for six of the seven directories. The documentation is silent on minimum memory for those models, and that silence is the thing to resolve before you provision anything.

The second limitation is hardware. Every instruction in the README assumes an Nvidia GPU. There is no mention of AMD, Apple Silicon or CPU-only serving. BentoML itself may support other runtimes, but this repository does not document them, so treat non-Nvidia as unsupported by the examples as written.

The third is scope. The repository topics include fine-tuning and LoRA, but the README describes no training or fine-tuning workflow. What it covers is serving. If your goal is to train a LoRA on your own images, this repository does not do that, and nothing in the README suggests it will. Similarly, there is no batching, queuing or request scheduling described for the example service; a burst of concurrent requests hits a single GPU-backed process with whatever concurrency BentoML applies by default, and the README does not discuss tuning that. For interactive single-image use that is acceptable. For a public endpoint with unpredictable load, it is a gap you have to close yourself.

BentoDiffusion compared with a model manager like ComfyUI

The nearest thing people compare this to is not another serving framework but a node-based image generation front end such as ComfyUI, which is what search traffic around Comfy-pack suggests. The difference in approach is fundamental. ComfyUI gives you a graph editor where the pipeline is assembled visually and the user is the operator. BentoDiffusion gives you a Python service class and an HTTP endpoint, and the user is a program.

That changes what you get. With a service, the prompt and parameters are an API contract, the output is bytes over HTTP, and the deployment artifact is an image or a cloud deployment you can version. You can call it from a backend, put it behind your own auth, and scale it with the same tooling as the rest of your stack. What you give up is the interactive loop: no canvas, no node graph, no quick visual iteration on a prompt. You also give up the ecosystem of community nodes and extensions that a front end accumulates.

If your team's problem is "we need an image generation endpoint in our product," the service shape is the right one and a desktop front end is a detour. If your problem is "I want to experiment with prompts and pipelines today," the front end wins and BentoDiffusion is overhead. Both are legitimate; they are just different jobs.

Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-07-14, which is recent enough that the examples track current model releases: the presence of SD3.5 and FLUX.1 directories indicates the collection is being extended rather than frozen. The repository has no published GitHub releases, so there is no tagged version to pin. That is a real cost. You consume the examples by cloning the default branch, which means an upgrade is a diff against main rather than a version bump, and a change to a shared pattern across subdirectories will not arrive as a numbered release you can review.

The practical upgrade burden sits in requirements.txt per subdirectory. Diffusion pipelines and their dependencies move quickly, and each directory pins its own set. Expect to re-resolve dependencies when you update, and expect the service class in service.py to be the file you actually maintain, since that is where the pipeline and the endpoint signature live.

The license is Apache-2.0, which is permissive and includes an explicit patent grant. The examples are sample code, so the license question that matters more is the one attached to the model weights each service downloads, which the README does not address and which varies by checkpoint. Check the model card for the specific checkpoint you deploy. This is a description of the license text, not legal advice.

Editorial conclusion

Adopt BentoDiffusion if you already run BentoML and want a diffusion endpoint behind the same packaging and deployment workflow as your other services, and if you have an Nvidia GPU with at least 12GB VRAM for the SDXL Turbo example. Do not adopt it if you want a model manager with a GUI, LoRA training, or support for AMD and Apple hardware; the repository is a collection of example services, not a product, and the README documents no training path and no non-Nvidia instructions. Verify first that the subdirectory you need matches your model, since each of the seven directories is a separate service, and confirm the Python version and requirements.txt of that directory before installing.

Frequently asked questions

Official sources

1. bentoml/BentoDiffusion on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README