Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Important
Objekt som har markerats som förhandsversioner i den här artikeln är för närvarande i förhandsversion. Den här förhandsversionen tillhandahålls utan ett serviceavtal och Microsoft rekommenderar det inte för produktionsarbetsbelastningar. Vissa funktioner kanske inte stöds eller kan vara begränsade. Mer information finns i Kompletterande villkor för användning av Microsoft Azure-förhandsversioner.
En adapterdistribution tillhandahåller en LoRA-adapter (low-rank adaptation) i en kompatibel distribution av hanterade beräkningsmål i Microsoft Foundry. Adapterdriftsättningar kräver inte ytterligare beräkningsresurser. De delar de beräkningsresurser som tillhandahålls av distributionen av basmodellen, som kallas för måldistributionen. Även om adapterdriftsättningar inte kräver ytterligare beräkning har de sitt eget distributionsnamn, vilket gör att du kan dirigera inferensbegäranden via inferensslutpunkten för Foundry-kontot.
Flera kompatibla adaptrar kan dela en måldistribution. Den här konfigurationen kallas multi-LoRA-servering.
Den här artikeln gäller endast LoRA-adaptrar som produceras som utdata från finjustering i Foundry. Du kan ännu inte importera dina egna adaptrar.
Hur LoRA-adaptrar specialiserar en basmodell
Lågranksanpassning är en finjusteringsteknik som tränar en liten uppsättning ytterligare parametrar i stället för att uppdatera varje parameter i basmodellen. Den resulterande LoRA-adaptern är en enkel uppsättning inlärda ändringar som specialiserar modellen för en uppgift eller domän.
En LoRA-adapter kan inte köras av sig själv. Vid inferensen kombinerar serveringskörningen adaptern med den kompatibla basmodellen. Den exakta basmodellen och versionen spelar roll eftersom adapterns inlärda ändringar gäller för den modellens arkitektur och vikter.
Resurser i en adapterdriftsättning
Adapterservering använder relaterade modell- och distributionsresurser. Varje resurs har ett eget ansvar.
| Term | Meaning |
|---|---|
| Basmodell | Den underliggande modellen och versionen som används för att skapa adaptern. En målmiljö måste använda en kompatibel basmodell i rätt version. |
| Registrerad LoRA-adapter | Modelresursen som skapats från utdata från en Foundry-finjustering. Registreringen gör adaptern tillgänglig på Build > Models, men ger inte åtkomst till beräkningskapacitet eller gör adaptern anropsbar. |
| Distribueringsmall | En namngiven, versionshanterad resurs som definierar hur en modell körs, inklusive konfigurationen för serveringskörning och accelerator. För adapterhantering väljer du en mall som stöder LoRA. |
| Målinstallation | En hanterad beräkningsdistribution som kör den kompatibla basmodellen med hjälp av en LoRA-aktiverad distributionsmall. Den äger de acceleratorer, kapacitet, repliker och inferensslutpunkter som dess adaptrar delar. |
| Driftsättning av adapter | En driftsatt anslutning mellan en registrerad LoRA-adapterversion och en måldistribution. Den har ett eget driftsättningsnamn, men den tillhandahåller inte separata beräkningsresurser, kapacitet, repliker eller en ändpunkt. |
| Multi-LoRA-driftsättning | Två eller flera kompatibla adapterdistributioner som använder samma måldistribution. Varje adapter behåller sitt eget driftsättningsnamn och särskilda beteende samtidigt som den delar måldistributionens infrastruktur. |
En måldistribution med namnet qwen-prod kan till exempel vara värd för adapterdistributioner med namnet qwen-support och qwen-finance. Båda adaptrarna använder basmodellen, beräkning och slutpunkten som tillhandahålls av qwen-prod. Deras separata driftsättningsnamn visar vilket finjusterat beteende ett program väljer.
Så här fungerar multi-LoRA-delning
Målutrullningen är den delade grundplattformen för drift. Dess distributionsmall för distribution avgör om körningen stöder LoRA och definierar acceleratortyp, modellinstanser och annan körningskonfiguration.
Att ansluta en adapter skapar inte någon annan modellinstans eller ökar måldistributionens kapacitet. Varje adapter på målsystemet drar från samma serverkapacitet. Om du skalar mål-distributionen ändras kapaciteten som är tillgänglig för basmodellen och alla anslutna adaptrar.
Hur slutsatsdragning väljer en adapter
Adaptern måste slutföra provisioneringen innan den kan hantera begäranden. En lyckad distribution rapporterar ett Succeeded etableringstillstånd.
Anta att qwen-prod är basmodellens målimplementering och qwen-support och qwen-finance är dess adapterimplementeringar. Skicka begäranden till Foundry-kontots /openai/v1/chat/completions slutpunkt. Ange model till det driftsättningsnamn som du vill anropa:
model, värde |
Markerat beteende |
|---|---|
qwen-support |
Basmodell med stödadaptern. |
qwen-finance |
Basmodell med finansadaptern. |
Följande begäran väljer supportadaptern. Kopiera slutpunkten för kontot från distributionsinformationen för adaptern i portalen. För Microsoft Entra ID autentisering hämtar du en åtkomsttoken för scopet https://ai.azure.com/.default.
POST {account-endpoint}/openai/v1/chat/completions
Authorization: Bearer {access-token}
Content-Type: application/json
{
"model": "qwen-support",
"messages": [
{
"role": "user",
"content": "How do I reset my account password?"
}
]
}
Om du vill anropa finansadaptern ändrar du model till qwen-finance och använder en prompt för dess uppgift. Tjänsten löser adapterns måldriftsättning internt.
Anvisningar för autentisering och testning finns i Testa en adapter med chat completions.
Kompatibilitets- och kapacitetskrav
Foundry validerar adaptern och måldistributionen innan adaptern tillhandahålls. Konfigurationen måste uppfylla följande krav:
- Adaptern är ett registrerat utdata från ett Foundry-finjusteringsjobb.
- Målmiljön kör en kompatibel basmodell och kompatibel version.
- Målresursen använder en distributionsmall som stöder LoRA.
- Adaptern ryms inom mallens antal adaptrar som stöds, LoRA-rangordning och tillgängligt minne.
- målet har tillräcklig hanterad beräkningskvot och kapacitet för sin acceleratorfamilj och region.
Adapterlivscykel och beroenden
En adapterdriftsättning och dess registrerade LoRA-adapter är separata resurser. Följande regler beskriver hur distributionsändringar påverkar adaptern och måldistributionen.
En befintlig adapterdriftsättning refererar till en fast version av den registrerade LoRA-adaptern, inte basmodellen. Om du vill driftsätta en annan adapterversion skapar du en ny adapterdistribution eller tar bort och återskapar den befintliga distributionen.
Du kan flytta samma adapterkälla till en annan kompatibel målimplementering genom att uppdatera namnet på målimplementeringen. Vänta tills uppdateringen har slutförts innan du dirigerar begäranden till det nya målet.
Om du tar bort en adapterdistribution tas inte dess registrerade modellversion eller måldistribution bort. Det påverkar inte heller andra adaptrar som delar målenheten.
Ta bort beroende adapterdistributioner innan du tar bort en registrerad adaptermodellversion eller måldistribution. Den här ordningen förhindrar att en adapterdistribution refererar till en källa eller ett mål som inte längre finns.
Fakturering, kvot och gränser
Måldriftsättningen faktureras per timme per accelerator. Kvot för hanterad beräkning allokeras per acceleratorfamilj och region, separat från Azure-kvot för virtuella datorer. Mer information finns i Hanterad compute-fakturering och kvoter.
Adapterdriftsättningar har inga separata priser. Faktureringen gäller för måldriftsättningens beräkningsresurser.
För gränsen för antal adapter, se Distribuera adapter i portalen.
Aktuella hanterade beräkningsfrekvenser finns i priskalkylatorn för Azure.
Nästa steg
Distribuera och testa en eller flera registrerade LoRA-adaptrar i en kompatibel målmiljö för driftsättning.