2025-10-22 · Bijgewerkt 2026-07-15

[!NOTE] Automatische vertaling Dit artikel is automatisch vertaald vanuit de oorspronkelijke Engelse versie.

LoRAX Serving Gids: Het beheren van meerdere LoRA adapters op Kubernetes

Eén basis model en meerdere LoRA adapters leiden tot een ongebruikelijk serving probleem. De basiseenheden weights worden gedeeld, maar elke aanvraag kan een ander scala aan adapter weights vereisen. Een conventioneel ontwerp waarbij er één deployment per variant wordt gebruikt, verspilt GPU geheugen wanneer de meeste varianten niet actief zijn.

LoRAX Het lost dit probleem op door adapters op vraag te laden, verzoeken voor verschillende adapters te bundelen, en de adapter weights heen en weer te verplaatsen tussen GPU- en CPU-geheugen. De aantrekkelijke kop luidt: “duizenden gefineerde models op één GPU.” De technische vraag is echter meer beperkt: profiteren uw actieve adapterset, het arriveringspatroon en het latency-doel voldoende van een geplande uitwisseling om nog een extra serving runtime te rechtvaardigen?

Deze gids beantwoordt die vraag, controleert API lokaal, en zet vervolgens het starter Helm-chart van het repository om in een duidelijk productieplan.

TL;DR. Kies voor LoRAX wanneer er veel compatibele LoRA adapters zijn die één gemeenschappelijke model delen en het verkeer schaars of langgerektd is. De capaciteit hangt af van het actieve werkgeheugen, en niet van de omvang van het catalogusbestand. Pin de runtime vast, authentificeer en voeg adapter-ID’s toe aan de allowlist, implementeer duurzame caching van artefacten en probes, stuur verkeer zo dat het gebruik maakt van cache-localiteit, en benchmark behandel koude en warme routes apart.

Het serving-probleem is het werkgeheugen

LoRA bevriest een basis model en leert lage-rangupdates voor geselecteerde weight matrices. De resulterende adapter is meestal veel kleiner dan een volledige checkpoint, maar zijn omvang hangt nog steeds af van de rang, de doelmodules, het aantal lagen en het datatype. Vaste beweringen zoals “elke adapter is 100 MB” vormen onnauwkeurige indicaties voor de capaciteit.

Voor serving dient men drie grootheden onderscheiden:

• Catalogusgrootte: elke adapter die een platform uit het opslagmedium kan ophalen
• Actief werkset: adapters die binnen het cachebehoudsvenster verzoeken ontvangen
• Gelijktijdig set: adapters die op hetzelfde moment in batches worden weergegeven

Een catalogus kan duizenden adapters bevatten zonder dat deze allemaal in VRAM passen. Belangrijk zijn de frequentie waarmee de actieve set verandert, de grootte van die adapters, en of verzoeken naar verschillende adapters bruikbare batches kunnen delen.

LoRAX combineert vier mechanismen:

1. De basis model blijft aanwezig voor alle compatibele adapters.
2. Een verzoek specificeert een adapter, die kan worden opgehaald uit Hugging Face, Predibase of een bestandsstelsel.
3. Het planningsmechanisme voor adapterwisseling prelaadt en verplaatst weights tussen de GPU- en CPU-geheugens.
4. Heterogene continuous batching-groepen verzamelen verzoeken die gericht zijn op verschillende adapters.

Het project rapporteert dat heterogene batchverwerking throughput en latency vrij constant houdt naarmate het aantal gelijktijdig gebruikte adapters in de benchmarks toeneemt. Beschouw dit als een hypothese voor uw werklast. De Prompt-lengte, de uitvoerlengte, de rang, de doelmodules, de bezetting van de batch, de cacheveranderingen en de generatie van GPU kunnen het resultaat beïnvloeden.

Wanneer LoRAX een haalbare optie is

LoRAX verdient een benchmark wanneer al deze voorwaarden gelden:

• De adapters zijn getraind op dezelfde ondersteunde basis model en tokenizer contracten.
• Er wordt veel verkeer spans door meerdere adapters verwerkt, met een significante lange staart.
• Het is beter om op demand een ‘koude’ adapter te laden dan om hiervoor een deployment in te reserveren.
• Er bestaat al een tenant of taak routing aan de rand van de applicatie.
• Het team kan een gespecialiseerde inference runtime en diens cachegedrag beheren.

Typische gevallen omvatten assistenten die specifiek zijn voor een bepaalde gebruiker, talrijke varianten per domein, en online experimenten die een gemeenschappelijke basis delen checkpoint.

Het is een minder geschikte oplossing wanneer enkele adapters het verkeer domineren, models geen gemeenschappelijke basis delen, harde latency doelwitten koude lasten niet kunnen verdragen, of wanneer de platform niet veilig kan bepalen welke artefacten de server moet laden. In zulke gevallen kan een standaard vLLM of TGI deployment met een vaste set adapters eenvoudiger zijn.

Gebruik Kubernetes niet alleen omdat de catalogus groot is. Bewijs eerst de compatibiliteit van runtime en de adapter op één GPU.

Controleer één basis en twee adapters lokaal

Het LoRAX README raadt aan om de vooraf opgebouwde container te gebruiken. In een echte omgeving dient u een immuuble image digest te gebruiken; main Het wordt hier alleen weergegeven omdat het de door het repository gedocumenteerde quick-start-tag is.

mkdir -p data

docker run --rm --gpus all --shm-size 1g \
    -p 8080:80 \
    -v "$PWD/data:/data" \
    ghcr.io/predibase/lorax:main \
    --model-id mistralai/Mistral-7B-Instruct-v0.1

Het gedocumenteerde minimale vereiste zijn Linux, Docker, een Ampere-of-nieuwer NVIDIA GPU, en CUDA-compatibele stuurprogramma’s versie 11.8. Licenties van Model en gecodeerde repositories kunnen eveneens een Hugging Face token vereisen.

Begin met de basis model:

curl http://127.0.0.1:8080/generate \
    -H 'Content-Type: application/json' \
    -d '{
      "inputs": "[INST] Give one reason to measure cold-adapter latency. [/INST]",
      "parameters": {"max_new_tokens": 64}
    }'

Stuur dan een compatibele adapter:

curl http://127.0.0.1:8080/generate \
    -H 'Content-Type: application/json' \
    -d '{
      "inputs": "[INST] Solve: Natalia sold 48 clips in April and half as many in May. What is the total? [/INST]",
      "parameters": {
        "max_new_tokens": 64,
        "adapter_id": "vineetsharma/qlora-adapter-Mistral-7B-Instruct-v0.1-gsm8k"
      }
    }'

De eerste aanvraag kan de adapter downloaden en laden; latere aanvragen kunnen gebruikmaken van opgeslagen artefacten en de residente weights. Noteer beide paden. Eén enkele ‘warm’ aanvraag zegt weinig over het gedrag bij zeldzame gevallen.

Gebruik de huidige OpenAI-client

LoRAX biedt een chat-eindpunt dat compatibel is met OpenAI. De model Het veld identificeert de adapter:

from openai import OpenAI


client = OpenAI(
    api_key="EMPTY",
    base_url="http://127.0.0.1:8080/v1",
)

response = client.chat.completions.create(
    model="alignment-handbook/zephyr-7b-dpo-lora",
    messages=[
        {"role": "user", "content": "Explain cache locality in two sentences."},
    ],
    max_tokens=100,
)

print(response.choices[0].message.content)

De server vereist standaard geen API-sleutel. Dit is handig voor localhost, maar onveilig als configuratie voor gebruik op het internet. Plaats authenticatie, autorisatie van gebruikers, quota’s en een lijst met toegestane adapters vóór deze sleutel.

Een compatibiliteitspoort definiëren

Voordat een adapter in de catalogus wordt opgenomen, moet u ten minste controleren:

• Gedeclareerde basis model en revisie
• tokenizer en compatibiliteit met chat-templates
• LoRA rang en doelmodules die worden ondersteund door de runtime
• Artefactformaat en tensorvormen
• Licentie, herkomst en integriteitsdigest
• Een klein setje gedrags- en regressietests

Wees onverenigbare artefacten tijdens het registratieproces af, in plaats van bij de eerste aanvraag van een gebruiker.

Begrijp de residentie-eisen voordat u het model implementeert

De basis model neemt het grootste deel van de vaste GPU geheugencapaciteit in beslag. Adapteren weights, KV cache, batchwerkruimtes en runtime kernels concurreren om de resterende ruimte. CPU RAM kan opgeslagen adapteren ondersteunen, terwijl /data Sla de gedownloade artefacten op.

Dit zijn geen onderling uitwisselbare niveaus. Een schijf- of hub-artefact moet eerst worden gelezen en gematerialiseerd voordat het kan worden omgevormd tot een CPU- of GPU-resident adapter. Meet de overgangen apart:

Capacity planning moet de werkelijke populariteitsverdeling van adapters weergeven. Uniform willekeurige adapter-ID’s leiden tot een ander opslagprobleem dan een werklast die lijkt op die van Zipf.

Zorgvuldig de repository-chart implementeren

De repository bevat charts/lorax,Dus het herhaalbare uitgangspunt is een vastgepinde repository-revisie en een lokale diagram:

git clone https://github.com/predibase/lorax.git
cd lorax
git checkout <reviewed-commit-or-release>

helm dependency update charts/lorax
helm template lorax charts/lorax -f values.production.yaml
helm upgrade --install lorax charts/lorax \
    --namespace inference \
    --create-namespace \
    -f values.production.yaml

Zoals gecontroleerd op 15 juli 2026, verdienen de standaardgrafieken attention:

• de image-tag is latest
• /data is een emptyDir, waardoor het vervangen van de pod de gedownloade artefacten wordt weggegooid
• De liveness- en readiness-probes zijn leeg
• De Hugging Face token wordt gemodelleerd als een letterlijke omgevingswaarde
• Er wordt standaard één GPU aangevraagd

Dat maakt de grafiek een nuttig hulpmiddel, en geen productiebeleid.

Begin met de werkelijke waardestructuur van het diagram

De grafiek plaatst de runtime-configuratie als onderdeel van deploymentDe launcher-argumenten vormen een lijst van naam/waarde-paren. Een minimale overlay ziet er als volgt uit:

deployment:
    replicas: 1

    image:
        repository: ghcr.io/predibase/lorax
        tag: "<tested-tag>" # Prefer an immutable digest in rendered manifests.

    args:
        - name: "--model-id"
          value: "mistralai/Mistral-7B-Instruct-v0.1"
        - name: "--max-input-length"
          value: "2048"
        - name: "--max-total-tokens"
          value: "3072"
        - name: "--max-batch-total-tokens"
          value: "8192"
        - name: "--max-batch-prefill-tokens"
          value: "4096"

    resources:
        requests:
            nvidia.com/gpu: "1"
        limits:
            nvidia.com/gpu: "1"

    readinessProbe:
        httpGet:
            path: /health
            port: http
        periodSeconds: 5
        failureThreshold: 600

service:
    serviceType: ClusterIP
    port: 80

De hierboven genoemde limieten voor token zijn voorbeeldwaarden als uitgangspunt, en geen aanbevelingen voor het bepalen van de omvang. Bepaal ze op basis van representatieve prompts-gegevens, de verwachte gelijktijdigheid, de beschikbare GPU-geheugenruimte en load tests.

Vul de gaten expliciet op

Het huidige diagramtemplate bevat vaste waarden. emptyDir volumes en gewone omgevingswaarden. Een versterkte deployment vereist daarom een gecontroleerde configuratie fork, een patch na renderen, of een hoger niveau van manifestlaag om de volgende elementen toe te voegen:

• een PersistentVolumeClaim of een op de node geïnstalleerde cache voor artefacten /data
• Een geheime referentie voor de Hub-credentials
• Een startproef voordat een intensieve liveness-proef wordt uitgevoerd
• Beleid voor onderbrekingen van pods en topologische spreiding voor meerdere replicas
• NetworkPolicy, beperkingen voor service accounts en een geverifieerde gateway
• Pinnen van image digests en controles op de integriteit van artefacten

Plaats een Hub token nooit rechtstreeks in een gefixeerde values-bestand. Ga er niet van uit dat twee replicas een bruikbare hoge beschikbaarheid bieden zodra beide in staat zijn de basis model te laden en de router kan voorkomen dat alle ‘cold adapters’ naar beide pods worden gestuurd.

Route voor cache-localiteit

Round-robin-balancing kan ertoe leiden dat elke replica wordt omgevormd tot een ‘cold cache’. Een nuttige router zorgt er namelijk voor dat een bepaalde adapter-ID op een specifieke replica wordt toegewezen, door middel van hashing of een andere vorm van affiniteit, waardoor er nog steeds een failover-pad beschikbaar blijft wanneer die replica niet beschikbaar is.

De routing-sleutel moet afkomstig zijn uit de geverifieerde toepassingsstate, en niet uit een willekeurige parameter van een publieke URL. Anders kan een aanroeper gedwongen downloads uitvoeren, caches leegmaken of proberen privé-adapters te identificeren.

LoRAX of vLLM?

De huidige vLLM kan LoRA-modules die bij het opstarten zijn gedefinieerd verwerken, en deze ook dynamisch laden via endpoints of resolver-plugins. De eigen documentatie waarschuwt dat het updaten van de runtime-adapter risico’s voor de beveiliging met zich meebrengt en dat deze daarom niet in productieomgevingen buiten een geïsoleerde, betrouwbare omgeving mag worden gebruikt.

De nuttige vergelijking is operationeel van aard en niet numeriek:

Vermeed regels als “LoRAX voor 1.000 adapters, vLLM voor tien.” De omvang van de catalogus alleen bepaalt de prestaties niet. Benchmark, zowel wanneer er sprake is van dezelfde basis, adapters, prompts, rangen, tijdstippen van aankomst trace, als van hardware.

Een productieacceptatietest

Voordat u de catalogus uitbreidt, voer een replay uit die het volgende omvat:

1. Een vaste hotset om throughput en latency op te zetten.
2. Een long-tail-verdeling om CPU en het aantal hits op de artifact-cache te meten.
3. Een plotselinge toename van eerder ongeziene, maar in de whitelist opgenomen adapters.
4. Vervanging van pods om de hersteltijd van de basiscomponenten en adapters te meten.
5. Eén niet beschikbare of corrupte adapter om isolatie en fallback-mechanismen te testen.
6. Meerdere gelijktijdige gebruikers om authenticatie, quota’s en metrieklabels te controleren.

Houd de verzoeksnelheid, wachttijd, tijd tot de eerste token, inter-token latency, totale latency, laadtijd van de adapter, cache-hit klassen, GPU en CPU geheugenverbruik, gedownloade bytes en fouten op basis van oorzaak bij. Zorg ervoor dat adapter-ID’s niet worden opgenomen in oneindige metrieklabels; map ze in plaats daarvan naar gecontroleerde dimensies of geëvalueerde traces.

Definieer de acceptatienormen al vóór het testen. Voorbeelden hiervan zijn een maximale foutkans bij het koude pad, een gewenst P99-waarde voor het warme pad, een doelwaarde voor cachehits gebaseerd op de waargenomen populariteitsverdeling, en een doelstelling voor de hersteltijd na het verlies van een pod.

Conclusie

LoRAX transformeert vele compatibele fine-tunings van een vloot aan base-model exemplaren in een probleem dat zich richt op de plaatsing van adapters. Dit kan een sterke benadering zijn voor workloads met een lange staart, maar het zorgt per definitie niet voor een constante kostenstructuur of latency. De actieve werkset, de uitwisselingsroute, de batchcombinatie en de opslaglaag bepalen nog steeds het uiteindelijke resultaat.

Test die mechanismen eerst op één GPU. Neem Kubernetes daarna serieus: bevestig de artefacten, behoud de cache, bescherm de credentials, autoriseer de adapters, stuur verkeer via lokale bronnen en meet elke mogelijke route. Als LoRAX een huidige vLLM configuratie onder dezelfde omstandigheden overtreft, dan heeft de deployment beslissing een gedegen onderbouwing.

Referenties

• LoRAX-repository en README — ondersteunde functies, vereisten, APIs, en Helm-chart
• LoRAX-grafiekwaarden en Deployment sjabloon — huidige standaardinstellingen en gedrag bij hoge volumes vLLM LoRA adapters — statische en dynamische adapter serving
• LoRA artikel — methode voor adaptatie met lage rangorde Hugging Face PEFT documentatie — adapterformaten en integratie van het trainingsproces