Tessera

A LoRA (Low-Rank Adaptation) adapter is a small set of additional weights layered on top of a base dense language model (not MoE) that changes its behavior without retraining or modifying the base model. Instead of updating billions of parameters, it typically adjusts a few million, capturing a specific skill, tone, or domain context, then loads alongside the base model at inference time.

Speed, efficiency, and throughput. A targeted adapter improves time-to-first-token and time-per-output-token versus a fully fine-tuned model, uses a fraction of the memory footprint, and lets you serve many domain-specific adapters on one base model without resource usage exploding. For most real workloads, those gains matter more than a marginal accuracy improvement.

Agentic workflows burn enormous numbers of tokens across long chains of tool calls. Every bit of latency compounds across hundreds or thousands of calls in a single session, not just once. Reducing per-step cost and latency is worth more here than a 1-2% accuracy bump, because the workload is defined by volume, not a single response.

Without an adapter, a cold vLLM serve typically takes about 50-200ms to produce its first token, since the model has to process the full prompt context before it can start responding. With a Tessera adapter pre-loaded, that drops to roughly 15-30ms. The reason is not just raw speed: the adapter has already encoded your session context into the model weights, so the model does not spend its first tokens orienting itself to who you are, what domain you are in, or what the task requires. It starts already conditioned. Domain-conditioned weights also shift the token probability distributions toward domain-relevant vocabulary, so the model becomes more likely to produce the tokens that actually matter at every generation step.

This is the most underappreciated advantage of per-session adapters. A fully fine-tuned domain model duplicates the entire base model for every domain you support. Serving 80 domain variants of Mistral-7B the traditional way means 80 × 14GB, over 1.1TB of GPU memory, just to keep them all resident. LoRAX-style hot-loading changes the equation entirely: the base model sits in GPU memory once, about 14GB, and each LoRA adapter is a small delta on top of it. At rank 16, a Tessera adapter is roughly 524KB. Serving 80 domain adapters on that same single base model requires 14GB plus 80 × 0.0005GB, about 14.04GB total. The adapter overhead is essentially zero.

No. Generation runs on standard compute. A GPU is only needed for low-latency, always-warm hosted serving, which the Enterprise tier provides.

An adapter already resident in memory on a live serving instance, so requests hit it with zero cold-start delay. Free-tier adapters spin up on request instead, trading a few seconds of latency for zero idle cost.

Yes. Hosted adapters serve through an OpenAI-compatible endpoint; point your existing OpenAI-client code at the endpoint URL with no other code changes needed.