LLM-inferenciához optimalizált autoscaling metrikákat vezet be a Together AI

A GPU-kihasználtság megtévesztő lehet az LLM-inferencia során, mivel a kérések torlódhatnak, miközben a rendszer egészségesnek tűnik. Az új replikák bemelegedése pedig percekig is eltarthat.

A Together AI új autoscaling-stratégiája erre kínál megoldást, dedikált inferencia-platformján olyan metrikákat használva, mint a futó kérések száma (in-flight requests), az első token várakozási ideje (TTFT), vagy a token-átviteli sebesség (token throughput). A rendszer lehetővé teszi a replikák számának beállítását, a célmetrikák meghatározását, valamint az autoscaling ablakok finomhangolását.

Túl- és alul-provisionálás költségei

A dedikált inferencia esetén minden replika-perc után fizetni kell, ami a kapacitástervezést két hibaforrás közötti egyensúlyozássá teszi. A túl-provisionálás azt jelenti, hogy a GPU-k alacsony, például 15%-os kihasználtság mellett is futnak, csak hogy a csúcsforgalmat kezelni tudják, ami szinte sosem életképes a jelenlegi GPU-hiányos környezetben.

Az alul-provisionálás viszont azt eredményezi, hogy a p95-ös késleltetés drámaian megnő, amint a forgalom meghaladja a replikák batch-kapacitását. Az LLM-kiszolgálás késleltetése nemlineárisan romlik: egy replika a kapacitási határán nem csak „kicsit lassabb” lesz, hanem elkezd sorban állni, és a TTFT 200 ms-ról akár 15 másodpercre is nőhet.

Az autoscaling kihívásai LLM-eknél

A klasszikus autoscaling-megoldások, amelyek főleg CPU-metrikákra támaszkodnak, nem működnek jól az LLM-kiszolgálásnál. A GPU-kihasználtság 60%-ot is mutathat, miközben a kérések már feltorlódtak, mert a metrika az aritmetikai intenzitást, nem a nyomást méri. A rossz jelre történő skálázás azt eredményezi, hogy a rendszer nem a valós problémára reagál.

Emellett az új replikák bemelegedése, ami a súlyok betöltését és a VRAM inicializálását jelenti, több percet is igénybe vehet. Ez azt jelenti, hogy nem lehet egy hirtelen forgalmi csúcsra reagálni, mert mire a replika elkészül, a csúcs már el is múlt. Egy jó autoscalernek ezért korán kell reagálnia a vezető jelekre.

Az autoscaling működése és ablakai

A Together AI platformja rugalmas autoscaling-politikát kínál, amely replikahatárokat, skálázási metrikákat célokkal, valamint időablakokat tartalmaz. A vezérlőhurok folyamatosan értékeli a forgalmat: a megfigyelt metrika alapján kiszámítja a kívánt replikaszámot (például a cél 8 in-flight kérés/replika, és 16 van megfigyelve, akkor a rendszer dupla replikát szeretne), majd az időablakok finomhangolják a reakciót, mielőtt a határokhoz igazítaná.

A scale_up_window-t röviden kell tartani, hogy a rendszer gyorsan reagáljon a csúcsokra; a scale_down_window-t (alapértelmezetten 5 perc) pedig hosszabbra, hogy elkerüljük a felesleges újraindításokat. Ez az aszimmetrikus megközelítés – gyors felfelé skálázás, lassabb lefelé – kulcsfontosságú a késleltetés és a költségek optimalizálásához.

Milyen metrikát válasszunk?

A platform nyolc különböző metrikát kínál. A inflight_requests, mint vezető jel, jó alapérték. A ttft (p95) vagy más SLO-vezérelt metrikák akkor ideálisak, ha konkrét késleltetési célokat kell tartani, de ezek csak streamelt forgalom esetén működnek. A gpu_utilization vagy token_utilization hatékonyságvezérelt metrikák, amelyek a hardver maximális kihasználását célozzák, de figyelni kell a p95-ös grafikonokat, mert a magas kihasználtság nem feltétlenül jelent alacsony késleltetést. A választás attól függ, mit szeretnénk védeni: a késleltetést, a költségeket, vagy a válaszidőt.

A beállítások között szerepel a minimális és maximális replikaszám, valamint az autoscaling ablakok időtartama. A min_replicas és max_replicas azonos értékre állítása kikapcsolja az autoscalingot. A scale_up_window 60 másodpercre, a scale_down_window pedig 300 másodpercre állítható, a ttft p95 metrikával és 500 ms-os céllal.