Genomströmning för inferens med skalmodell

Öka modelltrafiken genom Unity Gateway gradvis när du startar en arbetsbelastning eller byter modell. Denna vägledning gäller proprietära modeller och modeller med öppna vikter som tillhandahålls av Azure Databricks och modeller som nås via anslutna externa leverantörer.

Öka trafiken gradvis

Tillgänglig kapacitet beror på modell, leverantör, region och driftsläge. Förfrågningar kan stöta på tillfälliga kapacitetsfel även när trafiken håller sig inom de konfigurerade frekvensgränserna. En kvotökning ensam reserverar inte serveringskapacitet.

För att öka genomströmningen:

1. Kontrollera de konfigurerade hastighetsbegränsningarna för tjänsten och gränserna för modellen eller den externa leverantören. Uppskatta in- och utmatningstokenhastigheter samt samtidiga förfrågningar, inklusive representativa prompt- och svarsstorlekar.
2. Börja på en känd stabil trafiknivå. För en ny arbetslast bör du börja med en liten representativ last.
3. Öka trafiken i små steg. Håll varje nivå stabil medan du övervakar förfrågningarnas lyckandefrekvens, latens, tokenanvändning, ködjup och strypnings- eller kapacitetsfel. Öka igen endast när arbetsbelastningen är stabil och uppfyller applikationens driftmål.
4. Om strypning, kapacitetsfel eller latens ökar utöver applikationens tolerans, pausa upptrappningen och återgå till den senaste stabila trafiknivån. Minska samtidighet och lägg i kö eller skjut upp arbete med lägre prioritet.

Välj stegstorlekar och observationsperioder baserat på din arbetsbelastning och vägledningen för modellen eller leverantören. Upprepa denna validering när du byter modell, region eller betjäningskapacitet.

Hantera strypning och kapacitetsfel

Inspektera både HTTP-statusen och felkroppen från API:et du anropar. Felkoder och meddelanden kan skilja sig mellan enhetliga och leverantörs-native API:er.

Response	Betydelse och handling
429 Too Many Requests	En konfigurerad gräns för begärandefrekvens eller nedströms begränsning förhindrar begäran. Vissa leverantörer begränsar också kraftiga ökningar av trafiken. Identifiera gränsen från felkroppen, minska förfrågningsfrekvensen och öka trafiken gradvis. Om felet kräver en kvot- eller faktureringsändring, åtgärda det innan du försöker igen.
503 Service Unavailable	Tjänsten eller modellen kan tillfälligt inte hantera begäran. Detta kan ske vid en trafikökning, även under de konfigurerade frekvensgränserna. Försök igen inom en begränsad budget och pausa upprampningen om felen kvarstår.
Andra leverantörsöverbelastningsfel	Vissa leverantörs-API:er använder andra svar, såsom 529, för tillfällig överbelastning. Följ felvägledningen för den leverantör och det API du använder.

Ett kapacitetsfel i sig fastställer inte att autoskalning pågår eller indikerar när kapacitet blir tillgänglig.

Konfigurera återförsök

• Respektera headern Retry-After när svaret innehåller den. Annars, försök igen efter tillfälliga begränsnings- och kapacitetsfel med exponentiell backoff och slumpmässig jitter.
• Begränsa totala försök och förfluten tid för att passa applikationens latensbudget. Om felen kvarstår, minska trafiken istället för att lägga till fler försök.
• Kontrollera SDK:ns återförsöksbeteende innan du lägger till applikationsåterförsök. Ta hänsyn till omförsök över skikt så att de inte multiplicerar belastningen.
• Hantera fel efter att ett strömmande svar startat i strömkonsumenten. Att spela upp en begäran efter att ha mottagit utdata kan duplicera utdata eller arbete.

För ihållande fel, kontakta ditt Databricks-kontoteam med förfrågnings-ID:n, tidsstämplar, modell- och leverantörsnamn, observerade tokenhastigheter, samtidighet och trafikrampens tidslinje. För anslutna externa leverantörer, kontrollera även leverantörens tjänstestatus och kontogränser.

Batch-slutsatsdragning

För stora offline-arbetsbelastningar med stödda modeller, använd AI Functions, som hanterar parallellisering, omförsök och skalning. Följ deras batch-inferensinstruktioner istället för att tillämpa en separat loop för nya försök på varje rad.