LoRAs from the operator's perspective: build, host, or ignore

Many production AI products support no LoRAs at all. They give the customer access to a base model (or a few base models), let them promptPromptThe text description you provide to a model to specify what you want it to generate. and refine, and that is it. This is the simplest possible architecture and has the lowest operational overhead. It is the right choice if your customer base is doing one-off creative tasks where the base model's outputs are good enough, or if your product is consumer-facing and your users would never want to train their own models. Most consumer-facing image apps fall into this bucket.

The downside is that you lose the entire space of customers who need consistent identity across generations. If your customer is a brand that needs to use the same character across an entire campaign, or a creator with a signature style, the base model alone cannot serve them. They will leave your product and find one that supports custom training.

Several products (Pika, Higgsfield, CivitaiCivitaiA community website for sharing Stable Diffusion and FLUX models, LoRAs, and embeddings.'s training service, Krea's recently added training tool, and many others) let customers upload reference images and train custom LoRAs through the product. The customer sees: 'upload 20 photos of yourself, wait 20 minutes, now you can generate images of yourself in any style.' Behind the scenes, the product is running a LoRALoRA (Low-Rank Adaptation)A fine-tuning technique that adapts a base model to a specific style or concept using a small additional file. The standard way to customize open-source models. training pipeline on borrowed GPUGPU (Graphics Processing Unit)The parallel processor that runs image and video models. Its speed and memory largely determine what you can generate and how fast. time and storing the resulting LoRA on the customer's account.

The economics of this are subtle. A LoRA training run for SDXL or FLUX takes 15 to 40 minutes on a single A100 or H100 GPU. At cloud GPU prices that is roughly $1 to $5 of compute. You can charge customers $5 to $20 per LoRA training run and have margin. The hidden cost is storage, each LoRA is 50 to 200 megabytes, and if you have a million customers training an average of 3 LoRAs each, you are storing 300 terabytes of LoRA files. That is significant but manageable. The operational cost is the training infrastructure, you need a queue, a GPU pool that can scale up and down with demand, monitoring for failed runs, and a way to handle the inevitable cases where customer-uploaded data violates content policies.

The marketplace model is what CivitaiCivitaiA community website for sharing Stable Diffusion and FLUX models, LoRAs, and embeddings. has built. Users upload their trained LoRAs, the platform hosts them, other users discover and use them, and the platform takes a cut (or makes money from advertising and premium tiers). This is operationally heavier than the training-as-a-service model because you are hosting user-generated content at scale, with all the associated content moderation and legal exposure problems. Civitai's history of struggling with non-consensual deepfakeDeepfakeA synthetic image, audio, or video of a real person or event made to look genuine, a category the EU AI Act now requires be disclosed. content and copyrighted character training data is a cautionary tale.

If you build a marketplace, you need: aggressive content moderation (both at upload time and reactive), a clear ToS about what kinds of LoRAs are permitted, a takedown process for IP claims, and some mechanism for paying creators (which Civitai has done through a 'buzz' currency that gets converted to cash, with the cash conversion being a frequent source of friction).

The simplest way to support custom LoRAs without doing the training or hosting yourself is to let users upload their own LoRALoRA (Low-Rank Adaptation)A fine-tuning technique that adapts a base model to a specific style or concept using a small additional file. The standard way to customize open-source models. files and use them with your inferenceInferenceRunning a trained model to produce output. The fast, cheap part of the model lifecycle, in contrast to training.. This is what fal and Replicate do at the APIAPI (Application Programming Interface)The programmatic endpoint you call to run a hosted model from your own code instead of a web interface. level, and what some products do at the user level. It avoids the storage and moderation problems (the user manages their own LoRAs) but it requires that your users be technical enough to train LoRAs elsewhere first. For a developer-facing product this is fine; for a consumer product it is not.

Approach

Best for

Operational complexity

Margin profile

No LoRAs

Consumer one-off use

Lowest

Low margin, high volume

LoRALoRA (Low-Rank Adaptation)A fine-tuning technique that adapts a base model to a specific style or concept using a small additional file. The standard way to customize open-source models. training as a service

Prosumer, creators, agencies

Medium

Mid margin, recurring

Marketplace of community LoRAs

Hobbyist community, content creation

High

Low margin, ad-supported

BYO LoRA upload

Developer-facing APIAPI (Application Programming Interface)The programmatic endpoint you call to run a hosted model from your own code instead of a web interface.

Low

High margin per call

Train, host, and curate

Enterprise brand workflows

Highest

Highest margin, long sales cycles

The right choice depends entirely on your customer. A consumer photo-editing app does not need LoRAs. A B2B brand asset platform absolutely needs them. A creator tool for AI artists is roughly required to support both training and BYO. The wrong choice in either direction is expensive, overinvesting in LoRA infrastructure for customers who do not care wastes engineering time, and underinvesting for customers who do care drives them to competitors.