Zátěžové testování pro obsluhu koncových bodů

Tento článek vás provede základním procesem zátěžového testování koncových bodů obsluhy modelu Mosaic AI, abyste zajistili, že dokážou efektivně zpracovávat produkční úlohy. Poskytuje také praktické příklady, analogie z reálného světa a podrobné pokyny s využitím frameworku pro zátěžové testování Locust, které demonstrují, jak měřit klíčové metriky výkonu, jako jsou požadavky za sekundu a limity souběžnosti, abyste mohli správně určit velikost koncových bodů a s jistotou nasadit modely pro vaše obchodní potřeby.

Návod

Zátěžové testování je základní součástí optimalizace výroby. Komplexní průvodce strategiemi optimalizace, včetně optimalizace infrastruktury, modelu a optimalizace na straně klienta, najdete v tématu Optimalizace koncových bodů obsluhy modelů pro produkční prostředí.

Co je zátěžový test?

Zátěžový test je test, který simuluje skutečné využití modelu Mosaic AI obsluhující koncové body, které zajišťují, že splňují vaše produkční požadavky, jako je latence nebo požadavky za sekundu. Zátěžový test měří výkon koncového bodu na různých úrovních provozu a pomáhá správně určit velikost koncového bodu, aby nezpůsobil zpoždění.

Představte si toto: Je 8:00 ráno pracovního dne a v srdci města právě otevírá oblíbená kavárna. Aroma čerstvé kávy naplňuje vzduch. Barista je připraven, stroje jsou zahřáté a řada kofeinově strádajících zákazníků se již tvoří.

Na první pohled to běží hladce. Pár zákazníků přistoupí, zadají své objednávky a barista začne připravovat jejich nápoje. Některé nápoje trvají 30 sekund, jiné trvají minutu – v závislosti na složitosti. Barista žongluje více objednávek s výbornou efektivitou.

Ale brzy přijde víc lidí. Deset zákazníků se změní na deset, a poté na dvacet. Každý zadává objednávku, čeká na svůj nápoj a možná si trochu promluví u pultu. Barista je teď pod tlakem. I když se zapojí druhý barista, systém se začne přetěžovat – fronta roste, objednávky se hromadí a zákazníci začnou čekat déle.

Teď si představte, že se snažíte měřit, kolik nápojů může kavárna obsluhovat za minutu, než zákazníci začnou odcházet frustrovaní. To je zátěžové testování.

V této analogii:

• Každý zákazník je klient , který odesílá žádost.
• Barista(y) představují váš server , který zpracovává odvozování modelu jeden po jednom nebo paralelně.
• Čas potřebný k přijetí objednávky a servírování nápoje je čas implementace modelu.
• Zpoždění při komunikaci, placení nebo hledání objednávky představují síťové přetížení.
• Více zákazníků přicházejících najednou představuje souběžnost klientů.
• Přidání dalších baristas nebo více počítačů je jako zvýšení souběžnosti serveru.

Stejně jako v každé dobré kavárně existuje omezení na to, kolik může personál zvládnout najednou. Pokud neplánujete dopředu – řekněme, že přivezete do špičky více baristaů – lidé odcházejí nešťastně. Totéž platí pro vaše systémy, které jsou zatížené. Zátěžové testování vám pomůže určit, kde jsou kritické body, kolik provozu dokáže váš systém zpracovat a jaké změny potřebujete k zajištění plynulejší služby.

Před spuštěním zátěžového testu na koncovém bodu musíte:

• Seznamte se s komponentami a koncepty souvisejícími s zátěžovém testováním.
• Rozhodněte a definujte požadavky na produkční prostředí.
• Vyhledejte reprezentativní datovou část pro architekturu zátěžového testování, která se má použít při srovnávacím testování vašeho koncového bodu.

Koncepty a definice zátěžového testování

Následující tabulka definuje koncepty související s zátěžového testováním:

Koncepce	Popis
Souběžnost klientů (počet klientů)	Celkový počet klientů, kteří souběžně odesílají požadavky do koncového bodu. V předchozím příkladu jsou to vaši zákazníci v kavárně. Produkce: Celkový počet klientů, kteří odesílají provoz na předávací bod modelu. Zátěžový test: V Locustu to je počet vytvořených uživatelů, kteří odesílají provoz do modelu pro obsluhu koncového bodu, jenž je testován pro zatížení.
Souběžnost koncových bodů	Počet procesů odvozování nebo instancí modelu, které mohou zpracovávat příchozí požadavky. Dá se také vyjádřit jako počet požadavků, které může koncový bod zpracovávat současně. Jedná se o počet baristaů v předchozím příkladu. Obsluha modelů AI Mosaic: Koncové body pro obsluhu modelů lze nakonfigurovat pro škálování výpočetní kapacity. Například při použití Small velikosti koncových bodů procesoru se na koncovém bodu vytvoří čtyři instance modelu.
Oneskorení přenosu	Doba (v milisekundách) potřebná pro dokončení celé zpáteční žádosti. Míra celkového času po odeslání požadavku klientem do přijetí odpovědi včetně doby běhu koncového bodu a latence sítě.
Latence PXX (P50,P90,P99)	Latence (v milisekundách), pro kterou se xx percentil požadavků dokončil rychleji než Například P90 z 30 ms znamená, že 90% všech požadavků bylo dokončeno za 30 m nebo méně.
Žádosti za sekundu (RPS)	Počet dokončených žádostí za sekundu. Dokončeno znamená, že odpověď se vrátí z koncového bodu klientovi.

Požadavky na latenci

Na základě vašich obchodních a zákaznických požadavků definujte ideální výkon vašeho systému. U koncového bodu obsluhujícího model zahrnuje latence dobu odezvy, kterou klient zaznamená při odesílání dat pro odvozování. To zahrnuje latenci sítě a také dobu odvozování. Je důležité zajistit, aby vaše požadavky byly reálné. Například, pokud váš model potřebuje 15 ms, aby provedl inferenci, když je nahrán do paměti, je třeba zohlednit dodatečný čas pro latenci sítě při poskytování na koncovém bodu pro poskytování modelu.

Jak souvisí RPS, latence a souběžnost?

Firma má určitá definovaná kritéria pro úspěch systému. Pro systémy ML jsou obchodní kritéria obecně vysoce kvalitní výsledky, nízká latence a vysoká propustnost. Kvalita výsledků souvisí konkrétně se samotným modelem, zatímco koncová latence a propustnost jsou vlastnosti obsluhujícího systému. Kompletní latence se skládá z doby provádění modelu a režijních nákladů na síť. Propustnost (nebo požadavky či dotazy za sekundu) je nepřímo úměrná latenci a přímo souvisí se souběžností.

• Čím větší souběžnost je vyšší propustnost.
• Čím vyšší je latence, tím nižší je průchodnost.

Obecně platí, že existuje optimální poměr souběžnosti na straně klienta a souběžnosti na straně serveru pro libovolnou danou aplikaci. Například "kolik burgerů může kuchař u linky připravit současně". Vzhledem k tomu, že v procesu vaření může být mnoho sdílených kroků, může být line chef schopen optimálně vařit čtyři hamburgery najednou, a ne vařit jen jeden najednou. U této paralelizace existuje omezení, v určitém okamžiku se při provádění mnoha paralelních aktů zvyšuje příliš velká latence, například pokud kuchař potřebuje přidat sýr na 1 000 burgerů.

Jedním z hlavních cílů zátěžového testu je určení optimálního poměru pro vaši aplikaci. Optimální poměr maximalizuje RPS, splňuje vaše požadavky na latenci a vyhněte se řazení do front. Tento poměr lze použít k přesné velikosti koncového bodu tak, aby splňoval vaše nejnáročnější zatížení.

Pokud koncový bod nedokáže zpracovat požadavky dostatečně rychle, začne se vytvořit řádek. Tomu se říká fronta. Vytvoření fronty obvykle vede k mnohem delší latenci mezi koncovými body, protože teď je ještě více času, kdy každá žádost stráví čekáním před zpracováním. Pokud žádosti stále přicházejí rychleji, než je možné zpracovat, fronta roste, což dále zvyšuje latenci. Z tohoto důvodu je důležité pochopit, jaký druh špičkové zátěže může koncový bod zažít, a zajistit, že jeho kapacita je správně nastavena pomocí zátěžového testu.

Příklady scénářů zátěžového testu

V zátěžovém testování i v reálných systémech je vztah mezi souběžností klientů, souběžností serverů a latencí dynamický a vzájemně závislý. Podívejme se na tuto relaci s jednoduchým příkladem:

Scénář 1: Jednoduché nastavení

V tomto nastavení odešle jeden klient požadavky postupně – před vydáním dalšího požadavku čeká na odpověď. Vzhledem k tomu, že celková doba na požadavek je součet výkonu modelu a latence režie (40 ms + 10 ms), měřená koncová latence je 50 ms.

• Počet klientů: 1
• Zřízená souběžnost: 1
• Režijní latence: 10 ms
• Doba provádění modelu 40 ms

V důsledku toho klient dokončí jeden požadavek každých 50 ms, což odpovídá 20 žádostem za sekundu nebo dotazy za sekundu.

Scénář 2: Zvýšení přidělené souběžnosti

V tomto případě máte dvojnásobnou přidělenou souběžnost a jediný klient provádí požadavky sekvenčně. To znamená, že celková latence je stále 50 ms (40 ms + 10 ms) a systém zobrazuje pouze 20 požadavků za sekundu (QPS).

• Počet klientů: 1
• Zřízená souběžnost: 1–> 2
• Režijní latence: 10 ms
• Doba provádění modelu 40 ms

Scénář 3: Přidejte do systému dalšího klienta.

Teď máte dva klienty, kteří provádějí požadavky na koncový bod s konfigurovanou souběžností. V takovém případě je možné požadavek každého klienta nezávisle zpracovat koncovým bodem současně (za předpokladu dokonalého vyrovnávání zatížení). Zatímco celková latence je stále 50 ms (40 ms + 10 ms), systém sleduje 40 požadavků za sekundu, protože každý klient odesílá 20 qps.

• Počet klientů: 1 –> 2
• Předem nastavená souběžnost: 2
• Režijní latence: 10 ms
• Doba provádění modelu 40 ms

Zvýšení přidělené souběžnosti a zvýšení počtu klientů, kteří vytvářejí požadavky, zvyšuje celkový počet QPS pozorovaných ve vašem systému, aniž by došlo k ovlivnění latence.

Scénář 4: Snižme zřízenou souběžnost

V tomto posledním scénáři je počet klientů větší než předem zajištěná souběžnost. Toto nastavení zavádí v systému další proměnnou, řazení do fronty a její vliv na QPS a latenci.

• Počet klientů: 2
• Zřízená souběžnost: 2 –> 1
• Režijní latence: 10 ms
• Doba provádění modelu: 40 ms

Tady máte dva klienty, kteří současně vytvářejí požadavky. Koncový bod ale může zpracovat pouze jeden požadavek najednou. Tím se vynutí, aby druhý požadavek čekal, než bude zpracován první požadavek. Čekání nebo správně řazení do fronty druhého požadavku může nepříznivě ovlivnit latenci systému. Za předpokladu, že server umožňuje řazení do fronty (ve výchozím nastavení je povoleno ve službě Databricks Model Serving), druhý klient bude mít latenci 90 ms: 10 ms (síťové režie) + 40 ms (doba čekání ve frontě) + 40 ms (doba provádění modelu). To je výrazně horší než 50 ms pozorovaných dříve.