LoRA Adapter Registry and Fleet Command
A dozen specialised models from a single base, distributed like container images.
Context: Sókrates deploys finetuned Gemma 4 31B Dense on DGX Spark appliances. LoRA (Low-Rank Adaptation) enables specialised fine-tunes as lightweight adapter files rather than full model copies. This page describes how Fleet Command manages a registry of domain-specific adapters and distributes them to edge deployments.
Why This Works
A full Gemma 4 31B model in bf16 occupies ~62 GB. A LoRA adapter — the delta between the base model and a specialised variant — is typically 100-500 MB depending on rank and target modules. This means:
- A dozen specialised models fit in the space of one. The base weights are shared. Each adapter adds a fraction of a percent to storage.
- Hot-swapping is instant. Loading a different adapter means swapping a small set of low-rank matrices, not reloading 62 GB of weights. On DGX Spark’s unified memory architecture, this takes seconds.
- Training is cheap. Each adapter trains in hours on DGX Spark. The base model is frozen — only the adapter weights are updated. Memory overhead is minimal because gradients only flow through the low-rank matrices.
- Distribution is trivial. A 300 MB adapter file transfers over the network in seconds. Fleet Command pushes adapter updates the way a container registry pushes image layers — only the delta ships.
There is no technical reason this can’t work. The infrastructure patterns are well-established: container registries (OCI), model registries (MLflow, HuggingFace Hub), and artifact stores (S3, GCS) all solve the same distribution problem. The LoRA adapter registry is the same pattern applied to model specialisation.
Architecture
Fleet Command (Central)
The Fleet Command server (future DGX Station GB300, currently cloud-hosted) maintains:
- The base model — Gemma 4 31B Dense, the shared foundation across all deployments.
- The adapter registry — a versioned store of LoRA adapters, tagged by domain, version, and training corpus metadata.
- The routing table — maps customer deployments to their active adapter set, based on connected systems and customer profile.
- The training pipeline — produces new adapters from the OpenAPI corpus (see OpenAPI Corpus for Gemma Fine-Tuning) and from customer deployment feedback.
Edge Deployments (Customer Sites)
Each DGX Spark deployment:
- Stores the base model locally (one copy, ~62 GB).
- Pulls adapters from Fleet Command as needed. Multiple adapters can be stored locally (total overhead: a few GB for a dozen adapters).
- Selects the active adapter based on the current task. The Sókrates Agent knows which adapter to load based on the domain of the query — an ERP schema question routes to the ERP adapter, a CRM question routes to the CRM adapter.
- Reports performance signals back to Fleet Command — classification accuracy, edge mapping correctness, enrichment quality — which feed into the next training cycle.
The Registry Protocol
The adapter registry follows the OCI (Open Container Initiative) distribution pattern:
fleet.sokrates.is/adapters/
├── fintech/
│ ├── v1.0.0/ (adapter.safetensors, metadata.json)
│ ├── v1.1.0/ (adapter.safetensors, metadata.json)
│ └── latest → v1.1.0
├── erp/
│ ├── v1.0.0/
│ └── latest → v1.0.0
├── hr/
│ └── ...
├── crm/
│ └── ...
└── generalist/
└── ... (fallback adapter for domains without specialisation)
Each adapter ships with metadata:
- Training corpus — which specs were used, domain distribution, quality metrics.
- Evaluation scores — held-out accuracy on classification, edge mapping, and enrichment tasks.
- Compatible base model version — ensures adapters aren’t loaded on incompatible base weights.
- Target modules — which transformer layers the adapter modifies (attention, MLP, or both).
- Rank — the low-rank dimension (typically 16-64 for this scale).
Planned Adapter Catalogue
| Adapter | Training Domain | Target Customers | Key Capabilities |
|---|---|---|---|
| fintech | Plaid, Stripe, Square, banking APIs, payment processors | FinTech cluster (beachhead) | Transaction classification, account relationship mapping, compliance pattern detection |
| erp | SAP, Dynamics, Navision, manufacturing APIs | Manufacturing, logistics, retail | Purchase order flows, BOM structures, inventory relationships, supply chain topology |
| hr | Workday, BambooHR, Personio, payroll APIs | Companies with complex org structures | Department hierarchies, approval chains, employee lifecycle patterns, tenure analysis |
| crm | Salesforce, HubSpot, Zoho, Pipedrive | Sales-driven organisations | Customer journey mapping, pipeline stage classification, activity-to-outcome correlation |
| project | Jira, Asana, Monday, Linear, GitHub | Tech companies, agencies | Sprint topology, dependency mapping, bottleneck detection, velocity pattern analysis |
| legal | Legal document schemas, contract APIs, compliance frameworks | Regulated industries | Clause classification, obligation tracking, regulatory cross-referencing |
| generalist | Full OpenAPI corpus (all domains) | Default fallback | Broad schema understanding, reasonable classification across any domain |
The generalist adapter is always available as a fallback. Domain-specific adapters are loaded when the customer’s connected systems match the training domain. Multiple adapters can be active simultaneously — the Sókrates Agent selects per-query.
Adapter Composition and Stacking
LoRA adapters can be composed. A customer in FinTech with a complex HR setup could load both the fintech and hr adapters simultaneously. Two approaches:
- Sequential application — apply adapters in priority order. The primary adapter handles most queries; the secondary activates for its specific domain. Inference overhead is minimal (each adapter adds a small matrix multiplication per layer).
- Merged adapters — for stable combinations, adapters can be arithmetically merged into a single adapter (LoRA weight addition). This eliminates per-query routing but loses the ability to update components independently.
Fleet Command can pre-compute common combinations (fintech+hr, erp+crm, etc.) and distribute them as merged adapters for simplicity.
Training Cycle
The adapter registry is not static. Fleet Command runs a continuous improvement cycle:
- Corpus growth — new public OpenAPI specs are crawled and added to the training corpus. Customer deployments contribute anonymised structural patterns (with consent).
- Evaluation — existing adapters are evaluated against new specs in their domain. Performance degradation triggers retraining.
- Retraining — new adapter versions are produced from the expanded corpus. Training on DGX Station GB300 (748 GB memory) handles the full corpus in hours.
- Staged rollout — new adapter versions deploy to a subset of edge deployments first. Performance is monitored for regression.
- Promotion — once validated, the new version becomes
latestand rolls out fleet-wide.
This is CI/CD for models. The same patterns (versioning, staged rollout, rollback, monitoring) that work for software deployments work for adapter deployments.
Economics
- Storage per adapter: 100-500 MB. A registry of 12 adapters: 2-6 GB total. Negligible.
- Distribution cost: Pushing a 300 MB adapter update to 100 edge deployments: ~30 GB transfer. At commodity bandwidth, this costs under $1.
- Training cost per adapter: LoRA fine-tuning Gemma 4 31B on 3,000-5,000 examples takes 2-4 hours on DGX Spark. On DGX Station GB300, sub-hour. Compute cost per adapter: $5-20.
- Total registry maintenance: Training and distributing 12 adapters monthly costs under $300 in compute and bandwidth. This is a rounding error against customer retainer revenue.
The economic insight: LoRA adapters turn model specialisation from a capital expense (train and deploy a full model per domain) into an operational expense (train and distribute lightweight deltas). Fleet Command’s job is not model serving — it is adapter lifecycle management.
Relationship to the Product Ladder
The adapter registry enhances each tier of the Product Ladder and Market Entry Strategy:
- Tier 1 (Managed Claude): Not directly relevant — Tier 1 uses Claude, not Gemma.
- Tier 2 (Eidos via MCP): The hosted Eidos instance uses domain-appropriate adapters for semantic enrichment and classification. The customer benefits from specialised reasoning without knowing adapters exist.
- Tier 3 (On-Premises): The edge deployment pulls its adapter set from Fleet Command. Adapter selection is part of onboarding — connect ERP systems, get the ERP adapter. The customer’s model is specialised for their domain from day one, not trained from scratch over months.