Start with the platform that can deploy your exact base model and adapter artifact. Choose Fireworks or Together when the managed training-to-serving workflow fits. Compare Hugging Face Inference Endpoints or Baseten when you need control over the inference engine and artifact loading. Use Replicate or Modal when a custom package and its own serving code are a better fit than a catalog endpoint.
This comparison covers serving language-model adapters. Image-generation adapters have different pipelines and are outside this guide. We checked documentation rather than running deployments or timing model calls.
Compare deployment and billing boundaries
| Platform | Documented path | Cost basis to verify |
|---|---|---|
| Fireworks | Deploy a trained model or attach supported adapters to a base deployment | On-demand capacity, minimum replicas and adapter limits |
| Together AI | Train and deploy fine-tuned models in the managed workflow | Serving mode available for the artifact, token or instance billing |
| Hugging Face Inference Endpoints | Configure vLLM with LoRA or supply a custom container | Instance size, replica count and billed runtime |
| Baseten | Use Truss to package the engine or custom inference code | Hardware, replica minimum, scaling and support |
| Replicate or Modal | Package your own serving logic | Compute, initialization, idle behavior and maintained code |
Fireworks and Together for a managed model path
Fireworks documents deployment of trained models, including its LoRA deployment path. Before using an endpoint, check whether you need a deployment per adapter or can attach multiple adapters to one supported base deployment. Test how the API identifies an adapter, what is logged, and whether requests can cross between tenants when an adapter ID is missing or wrong. A public base model in the catalog does not establish eligibility for your adapter or the same billing mode.
Together describes fine-tuning and hosted inference. Its open-weight inference overview also describes bringing custom models. Ask for the path for your actual artifact, especially if it was trained outside Together. Test a model revision and a failed rollout before assuming that training output promotion is sufficient for release management. Get confirmation of which configurations support serving without committing a whole instance.
Hugging Face and Baseten when you own more of the runtime
Hugging Face’s vLLM endpoint guide explains engine arguments and shows enabling LoRA. Turning on that flag is only part of the work. Specify how the adapter is loaded, how its revision is pinned and how inference requests select it. Its custom container path is an option when the default image lacks the architecture or preprocessing you need. A custom image adds ownership of versioning and patches.
Baseten Truss can package a chosen serving engine or your custom prediction logic. That helps when adapter routing belongs in the model service, for example if requests require a tenant-specific template or preprocessing step. Ask whether the managed configuration supports the exact multi-adapter behavior you need. Otherwise, make the code and its operational cost explicit in your comparison.
Replicate and Modal for packaging flexibility
Replicate’s custom deployment guide uses Cog to package a model and describes dedicated deployments. Modal’s inference platform is another route for custom runtimes. Compare both against the amount of service code you will maintain. If your training tooling can safely merge the adapter into an allowed checkpoint, test that artifact too. It may simplify the serving path at the expense of storage and sharing the same base across adapters. For Cerebras, request confirmation of your exact base, import and adapter support before adding it to the same shortlist.
Validate a single adapter and two concurrent tenants
- Save the base model revision, tokenizer, chat template, adapter format, rank and target modules. Test the same evaluation examples against the reference implementation and deployment.
- Use two adapters with visibly different expected behavior. Mix their requests under load. Verify routing, isolation, cache behavior and what happens on an invalid identifier.
- Observe cold starts, adapter load or swap latency, and time to first token. Test at the context lengths you serve. A model loading quickly on an empty GPU says little about a concurrent workload.
- Roll out a new adapter, then revert. Confirm what clients see and whether the same result is reproducible from retained revisions.
- Compare spend at the expected workload, including warm replicas, idle capacity, data transfer and a second region if needed. Get export and artifact-retention terms in writing.
Exercise the change process with a base model security update as well. A new base revision can change which adapters load or how they behave. Keep a compatibility record and define whether teams must retest or retrain their adapters before promoting the new base.
My take
Choose the lowest-maintenance path that passes the two-adapter test. A single stable model can be easier to operate as one deployed checkpoint. For many small adapters on the same base, a documented multi-adapter runtime can avoid a separate full replica for every tenant. Pay for isolation when the security or latency requirement justifies it, and benchmark with the adapter mix you expect to run.
Related Articles
- Fine-tuning a local language model
- Fine-tuning Gemma with LoRA
- Serverless versus dedicated GPU inference
- Benchmarking LLM inference
- GPU memory planning
FAQ
Does a LoRA file contain the whole model?
Usually it contains adapter weights or related configuration. Use the compatible base and tokenizer, or explicitly produce and validate a merged checkpoint.
Does multi-LoRA mean adapters are isolated?
It describes a serving capability. Verify request routing, access controls and failure behavior independently.
Can I keep using serverless token pricing after fine-tuning?
That depends on the platform, artifact and deployment type. Ask for the billing mode for the actual adapter endpoint before comparing per-token prices.
Should I merge before deployment?
Benchmark both paths if both are supported. A merged checkpoint can simplify a single-model rollout, while separate adapters may share a base and enable easier per-tenant updates.