Underhållsprincip för AI-modeller

Denna sida beskriver modellunderhållspolicyn för Foundation Model API:erna pay-per-token, Foundation Model API:er som provisionerat genomströmning och batchinferens med ai_query erbjudanden.

För att fortsätta stödja de mest avancerade modellerna hanterar Databricks modeller genom en livscykel som går från legacy-status till avskrivning till slutlig pensionering.

• Legacy: När en modell är klassad som legacy rekommenderas den inte längre för nya arbetsbelastningar, men finns kvar i arbetsytor med befintlig användning av modellen. Arbetsytor som inte använder modellen när den går in i legacy-status har inte längre tillgång till modellen. Kunder som använder en sådan modell bör utvärdera nyare modeller och överväga migrering.
• Avskrivning: När en modell avvecklas meddelas ett pensionsdatum om 30 dagar eller 90 dagar framåt i tiden. Den rekommenderas inte för nya arbetsbelastningar, men finns fortfarande tillgänglig i arbetsytor med befintlig användning av modellen. Arbetsytor som inte använder modellen vid tidpunkten för avvecklingen har inte tillgång till modellen. Kunder som använder en sådan modell bör utvärdera nyare modeller och planera att migrera sina arbetsbelastningar innan pensionsdatumet.
• Pensionering: När en modell tas ur bruk är den inte längre tillgänglig och stödet för modellen upphör helt. All arbetsbelastning som använder modellen fungerar inte längre.

Modelllivscykelpolicy

Följande avsnitt sammanfattar modellens livscykelpolicy. Se Föråldrade modeller för en lista över föråldrade modeller och pensionsdatum.

Många faktorer beaktas vid fastställandet av pensionstidslinjen, inklusive modellens popularitet, lämplig ersättningsmodell och produktionsanvändning. Databricks meddelar pensionsdatum för modeller när de tas ur bruk, enligt de notifikationstidslinjer som anges nedan.

API:er för grundmodell

Följande tabell sammanfattar modellens livscykelpolicy för Foundation Model API:s produkter: pay-per-token, provisioned throughput och ai_query (batchinferens).

Princip för partnermodellens pensionering

Partnermodeller är modeller som tredjepartspartner – särskilt OpenAI, Anthropic och Google – tillhandahåller via Foundation Model-API:er. För dessa partnermodeller följer Databricks vanligtvis samma tidslinjer och principer för utfasning som beskrivs ovan.

Dock kan partners erbjuda pensionsdatum som är kortare än den enmånads övergångsperiod som Databricks publicerar. I dessa fall försöker Databricks överbrygga klyftan genom att tillfälligt omdirigera modeller till en liknande version, så att kunderna får hela övergångstiden.

Till exempel, om pensionering av en partnermodell meddelas med två veckors ledtid istället för en månad, omdirigerar Databricks modellen ytterligare två veckor för att förhindra omedelbar avbrott och ge tid för migrering. Förfrågningar misslyckas i slutet av hela enmånadsperioden.

Inaktuella och inaktuella modeller

I följande avsnitt listas modeller som är inaktuella (rekommenderas inte längre för nya arbetsbelastningar) eller som har dragits tillbaka (livslängden upphör och inte längre är tillgänglig). Pensionsdatum för föråldrade modeller meddelas minst en månad i förväg.

Api:er för foundation-modell dras tillbaka

Följande tabell visar modellavgångar, deras pensionsdatum och rekommenderade ersättningsmodeller som ska användas för Foundation Model API:er betala per token och etablerat dataflöde som betjänar arbetsbelastningar. Databricks rekommenderar att du migrerar dina program för att använda ersättningsmodeller före angivet slutdatum.

Om du behöver långsiktigt stöd för en viss modellversion rekommenderar Databricks att du använder Foundation Model-API:er provisionerat dataflöde för dina serving-arbetsbelastningar.

Hitta arbetsbelastningar som använder tillbakadragna modeller

Använd följande fråga för att hitta arbetsbelastningar som använder inaktuella modeller och identifiera sina ägare.

SELECT
   eu.requester,
   se.endpoint_name,
   se.entity_name,
   COUNT(*) AS request_count,
   SUM(eu.input_token_count) AS total_input_tokens,
   SUM(eu.output_token_count) AS total_output_tokens,
   MIN(eu.request_time) AS first_request,
   MAX(eu.request_time) AS last_request
 FROM system.serving.endpoint_usage eu
 JOIN system.serving.served_entities se
   ON eu.served_entity_id = se.served_entity_id
 WHERE LOWER(se.entity_name) LIKE '%<retired-model-name>%'
 GROUP BY eu.requester, se.endpoint_name, se.entity_name
 ORDER BY request_count DESC