Sdílet prostřednictvím

Optimalizace koncových bodů obsluhy modelů pro produkční prostředí

Zjistěte, jak optimalizovat koncové body obsluhy modelů pro produkční úlohy, které vyžadují vysokou propustnost, nízkou latenci a spolehlivý výkon.

Strategie optimalizace spadají do tří kategorií:

Kdy optimalizovat koncový bod

Pokud narazíte na některý z následujících scénářů, zvažte optimalizaci koncového bodu modelové služby:

  • Velký objem dotazů: Vaše aplikace odesílá do jednoho koncového bodu více než 50 tisíc dotazů za sekundu (QPS).
  • Požadavky na latenci: Vaše aplikace vyžaduje dobu odezvy pod 100 min.
  • Problémy s škálováním: Při špičkách provozu dochází ke frontám na koncových bodech nebo se vrací chyby HTTP 429
  • Optimalizace nákladů: Chcete snížit náklady při zachování výkonnostních cílů.
  • Příprava produkčního prostředí: Připravujete přechod z vývoje na produkční úlohy.

Optimalizace infrastruktury

Optimalizace infrastruktury zlepšují směrování sítě, chování škálování a výpočetní kapacitu.

Optimalizace tras

Optimalizace tras poskytuje nejvýznamnější vylepšení infrastruktury pro úlohy s vysokou propustností. Když povolíte optimalizaci tras na koncovém bodu, služba Databricks Model Serving zlepšuje síťovou cestu pro žádosti o odvozování, což vede k rychlejší a přímější komunikaci mezi klienty a modely.

Výhody výkonu:

Vlastnost Limit standardního koncového bodu Limit koncového bodu optimalizovaného pro směrování
Dotazy za sekundu (QPS) na pracovní prostor 200 50 000+ (pokud chcete získat vyšší limity, obraťte se na Databricks).
Souběžnost klientů na pracovní prostor 192–1024 (liší se podle oblastí) Žádný explicitní limit (omezený zřízenou souběžností)
Předem stanovená souběžnost koncového bodu na obsluhovanou entitu 1,024 1 024 (pokud chcete získat vyšší limity, obraťte se na Databricks)

Kdy použít optimalizaci trasy:

  • Úlohy vyžadující více než 200 QPS
  • Aplikace s přísnými požadavky na latenci (režijní náklady pod 50 m)
  • Produkční nasazení obsluhující více souběžných uživatelů

Důležité

Optimalizace tras je k dispozici pouze pro vlastní modely obsluhující koncové body. Rozhraní API základního modelu a externí modely nepodporují optimalizaci tras. Pro ověřování se vyžadují tokeny OAuth; osobní přístupové tokeny nejsou podporovány.

Pokyny k nastavení najdete v Optimalizace trasy na obsluhovacích koncových bodech a podrobnosti o dotazování v Dotazování na koncové body optimalizované pro trasu.

Předem definovaná souběžnost

Zřízená souběžnost řídí, kolik souběžných požadavků může koncový bod zpracovat. Nakonfigurujte zřízenou souběžnost na základě očekávaných požadavků na QPS a latenci.

Pokyny ke konfiguraci:

  • Minimální souběžnost: Nastavte dostatečně vysokou úroveň pro zpracování standardního provozu bez řazení do fronty.
  • Maximální souběžnost: Nastavte vysokou úroveň pro přizpůsobení špiček provozu při řízení nákladů.
  • Automatické škálování: Povolení automatického škálování k dynamické úpravě kapacity na základě poptávky

Výpočet požadované souběžnosti:

Required Concurrency = Target QPS × Average Latency (seconds)

Pokud je například vaším cílem 100 QPS s průměrnou latencí 200 m:

Required Concurrency = 100 × 0.2 = 20

Pomocí zátěžového testování můžete měřit skutečnou latenci a určit optimální nastavení souběžnosti.

Typy instancí

Vyberte typy instancí na základě požadavků modelu na výpočetní prostředky:

Typ instance Nejvhodnější pro Trade-offs
PROCESOR (malý, střední, velký) Jednoduché modely, jednoduchá logika odvozování Nižší náklady, pomalejší u modelů náročných na výpočetní výkon
GPU (malé, střední, velké) Velké modely, složité výpočty, zpracování obrázků a videí Vyšší náklady, optimální výkon pro hluboké učení

Návod

Začněte s instancemi procesoru pro vývoj a testování. Přepněte na instance GPU jenom v případě, že zaznamenáte vysokou latenci odvozování nebo váš model vyžaduje specializované výpočetní prostředky (například operace hlubokého učení).

Optimalizace modelů

Optimalizace modelů zlepšují rychlost odvozování a efektivitu prostředků.

Velikost a složitost modelu

Velikost a složitost modelu: Menší, méně složité modely obecně vedou k rychlejším odvozování a vyššímu QPS. Pokud je váš model velký, zvažte techniky, jako je kvantování modelu nebo vyřezávání.

Batching

Pokud vaše aplikace může posílat více požadavků v jednom volání, povolte zpracování šarží na straně klienta. To může výrazně snížit režii na predikci.

Optimalizace před zpracováním a po zpracování

Přesuňte komplexní předběžné zpracování a následné zpracování mimo obsluhy koncových bodů, aby se snížilo zatížení na infrastruktuře pro odvozování.

Optimalizace na straně klienta

Optimalizace na straně klienta zlepšují způsob interakce aplikací s obsluhou koncových bodů.

Sdružování připojení

Sdružování připojení znovu používá stávající připojení místo vytváření nových připojení pro jednotlivé požadavky, což výrazně snižuje režii.

  • Použijte sadu Databricks SDK, která automaticky implementuje osvědčené postupy sdružování připojení.
  • Pokud používáte vlastní klienty, implementujte sdružování připojení sami.

Zpracování chyb a strategie opakování

Implementujte robustní zpracování chyb pro řádné zpracování dočasných selhání, zejména při událostech automatického škálování nebo přerušení sítě.

Optimalizace velikosti zátěže

Minimalizujte velikosti datových částí požadavků a odpovědí, abyste zkrátili dobu přenosu sítě a zlepšili propustnost.

Měření a zlepšení výkonu

Monitorování výkonu

Monitorování výkonu koncového bodu pomocí nástrojů poskytovaných obsluhou modelu Mosaic AI:

Ukazatel Co měří Target Akce při překročení
Latence (P50, P90, P99) Doba odezvy pro žádosti Závislý na aplikaci (obvykle <100–500 ms) Kontrola front, optimalizace modelu nebo klienta
Propustnost (QPS) Počet dokončených žádostí za sekundu Pravděpodobně závislé na zátěži Povolení optimalizace tras, zvýšení předem nastavené souběžnosti
Míra chyb Procento neúspěšných požadavků <1% Zkontrolujte protokoly služby a zkontrolujte problémy s kapacitou.
Hloubka fronty Požadavky čekající na zpracování 0 (bez front) Zvýšení zřízené souběžnosti nebo povolení automatického škálování
Využití procesoru nebo paměti Využití zdroje <80% Zvětšete typ instance nebo zvyšte paralelismus

Podrobné pokyny k monitorování najdete v tématu Monitorování kvality modelu a stavu koncového bodu a pokyny pro sledování a export metrik stavu koncového bodu do služby Prometheus a Datadog najdete v tématu Sledování a exportování metrik zdraví koncového bodu na nástroje pro sledování.

Zátěžové testování

Zátěžové testování měří výkon koncového bodu za realistických dopravních podmínek a pomáhá vám:

  • Určení optimálního zřízeného nastavení souběžnosti
  • Určení kritických bodů z hlediska výkonu
  • Ověření požadavků na latenci a propustnost
  • Vysvětlení vztahu mezi souběžností klienta a souběžností serveru

Podívejte se na Zátěžové testování obslužných koncových bodů.

Řešení běžných potíží s výkonem

Queuing

Obsluha modelů podporuje automatické škálování pro úpravu kapacity na základě vzorů provozu. Náhlé nárůsty provozu však můžou způsobit řazení front, protože automatické škálování vyžaduje čas ke zjištění zvýšeného zatížení a zřízení další kapacity. Během tohoto období můžou příchozí požadavky dočasně překročit dostupnou kapacitu, což způsobí, že se požadavky zařadí do fronty.

Ke frontě dochází v případě, že frekvence požadavků nebo souběžnost překročí aktuální kapacitu zpracování koncového bodu. K tomu obvykle dochází při prudkém nárůstu provozu, nárůstu zatížení nebo v případě, že koncový bod nemá dostatečnou souběžnost. Obslužné koncové body modelu umožňují dočasné zařazení do fronty k zvládnutí nárůstů, ale nad stanovenou prahovou hodnotu koncový bod vrací chyby HTTP 429 (Příliš mnoho požadavků), které chrání stabilitu systému.

Řízení front zvyšuje latenci, protože požadavky zařazené do fronty čekají před zpracováním. Minimalizace front:

  • Nastavte minimální zřízenou souběžnost dostatečně vysokou pro zpracování standardního provozu a typických nárůstů
  • Povolení optimalizace tras pro vyšší limity kapacity
  • Implementace logiky opakování s exponenciálním zpomalováním v klientských aplikacích

Úzká místa externího rozhraní API

Modely často volají externí rozhraní API pro rozšiřování dat, načítání funkcí nebo jiné úlohy během odvozování. Tyto externí závislosti se mohou stát úzkými místy výkonu:

  • Latence: Změřte dobu odezvy každého externího volání rozhraní API. Vysoká latence v těchto voláních přímo zvyšuje celkovou latenci obsluhy a snižuje propustnost.
  • Omezení propustnosti: Externí rozhraní API můžou uplatňovat omezení rychlosti nebo omezení kapacity. Překročení těchto limitů může způsobit škrcení, chyby a degradaci výkonu.
  • Chybové míry: Časté chyby z externích rozhraní API můžou aktivovat opakování a zvýšit zatížení vašeho koncového bodu obsluhy.
  • Ukládání do mezipaměti: Implementujte ukládání do mezipaměti pro často přístupná data z externích rozhraní API, abyste snížili počet volání a zlepšili dobu odezvy.

Monitorujte tyto faktory, abyste identifikovali kritické body a implementovali cílené optimalizace pro úlohy s vysokou propustností.

Dodatečné zdroje

  • Last updated on