BentoML vai Ray Serve? Autoskaalauksen mittarit

Ray Serve ja BentoCloud kasvattavat mallipalvelun kapasiteettia eri kuormasignaalien perusteella. Ray Serven autoskaalausohjeen mukaan palvelu seuraa keskeneräisiä pyyntöjä ja jonoa; automaattiasetuksessa tavoitteena on kaksi keskeneräistä pyyntöä replikaa kohti, replikakohtainen enimmäismäärä on viisi ja replikakatto sata. Käsin määritetyssä autoskaalauksessa replikakaton oletus on kuitenkin yksi, joten yläraja on asetettava erikseen.

BentoML:llä rakennettu palvelu skaalautuu BentoCloudissa samanaikaisuuden perusteella, kun palvelulle annetaan concurrency-arvo. BentoCloudin autoskaalausohje kertoo, että ilman sitä skaalaus perustuu vain suorittimen käyttöön; ulkoinen jono puolestaan pidättää rajan ylittävät pyynnöt ja voi lisätä viivettä. Valinta riippuu siksi siitä, miten oma malli käyttäytyy kuormassa ja missä vaiheessa pyyntö alkaa odottaa.

Samat sanat, eri kuormasignaali

Ray Serven target_ongoing_requests on keskimääräinen keskeneräisten pyyntöjen tavoite replikaa kohti. Keskeneräisiin kuuluvat sekä käsittelyssä olevat että replikan jonossa odottavat pyynnöt. Erillinen max_ongoing_requests rajoittaa, montako pyyntöä reititin antaa replikalle; loput voivat odottaa reitittimen puolella. Tavoite vaikuttaa siis replikatarpeeseen, kun taas enimmäismäärä vaikuttaa siihen, mihin ruuhka sijoittuu ennen uuden kapasiteetin valmistumista.

BentoCloudin concurrency kuvaa replikan tavoiteltua samanaikaista käsittelykykyä. BentoML:n liikenneasetuksissa se erotetaan max_concurrency-asetuksesta, joka on palveluesiintymän kova samanaikaisuusraja. Kun ulkoinen jono on käytössä, BentoCloud ei päästä palveluun concurrency-arvon ylittäviä pyyntöjä, eikä max_concurrency tällöin tule vastaan. Pelkkä sama lukuarvo Rayn tavoitteessa ja BentoCloudin asetuksessa ei siis kuvaa samaa jonotus- tai kapasiteettitilannetta.

Tasainen kuorma kertoo yhden replikan kapasiteetin

Oletetaan ehdollinen koe, jossa sama malli, päättelymoottori ja laitteisto palvelevat tasaista pyyntövirtaa. Jos yksi replika täyttää vasteaikatavoitteen neljällä yhtäaikaisella pyynnöllä, neljä on kokeen oletettu lähtöarvo eikä yleinen suositus. Ray Servessä target_ongoing_requests kannattaa kokeilla tämän tason tuntumassa ja asettaa max_ongoing_requests sitä suuremmaksi. BentoCloudissa concurrency asetetaan saman käsittelykyvyn perusteella; min_replicas ja max_replicas pidetään vertailussa samoina.

Vertaa tämän jälkeen toteutunutta replikamäärää, läpimenoa ja vasteaikojen jakaumaa samalla saapumisnopeudella. Jos Rayn replikoilla kasvaa keskeneräisten pyyntöjen määrä, tavoite on voinut jäädä mallin todellista kapasiteettia suuremmaksi. Jos BentoCloud lisää replikoita, vaikka nykyisten suorituskyky riittää, concurrency voi olla liian pieni suhteessa mitattuun kapasiteettiin. Molemmissa tapauksissa pelkkä prosessorin tai kiihdyttimen käyttöaste kertoo vain osan tilanteesta: pyyntö voi odottaa myös reitityksessä tai palvelun omassa jonossa.

Kuormapiikki siirtää odotusta eri paikkaan

Toinen ehdollinen koe nostaa liikenteen nopeasti tasaiselta tasolta moninkertaiseksi. Ray Servessä säilytä ensin mitattu tavoite ja nosta replikakatto kuormakokeen sallimaan kapasiteettiin. Seuraa erikseen reitittimessä odottavia pyyntöjä ja replikalle jo annettuja keskeneräisiä pyyntöjä. Jos max_ongoing_requests on hyvin suuri, suuri osa piikin pyynnöistä voi päätyä vanhoille replikoille ennen kuin uudet ovat käytettävissä, jolloin häntäpään vasteajat kasvavat.

BentoCloudissa aja sama piikki ensin määritetyllä concurrency-arvolla ja sitten myös ulkoisen jonon kanssa. Ulkoinen jono pitää ylimääräiset pyynnöt odottamassa ennen palvelua ja antaa jonon pituuden vaikuttaa skaalaamiseen. Se suojaa replikaa ylikuormitukselta, mutta jonon ylimääräiset I/O-vaiheet lisäävät palvelun viivettä. Erota siksi mittauksessa aika ennen palveluun pääsyä mallin varsinaisesta suoritusajasta; sama kokonaisvasteaika voi syntyä aivan eri kapasiteettiongelmista.

Replikakatto ei kerro skaalausviivettä

Ray Serven tarkempi skaalausohje kuvaa erikseen mittareiden keruun, tarkasteluikkunan ja upscale_delay_s-asetuksen; jälkimmäisen oletus on 30 sekuntia. Päätöksen jälkeen replika tarvitsee vielä sopivat klusteriresurssit ja mallin käynnistyksen. Siksi korkea max_replicas ei yksin takaa lyhyttä vastausta äkilliseen piikkiin. Rayn max_ongoing_requests kannattaa säätää suhteessa tavoitearvoon, jotta vanhoihin replikoihin ei kerry tarpeettoman pitkää jonoa.

BentoCloudin vastaava viive näkyy siinä, kuinka kauan pyyntö odottaa kapasiteetin vapautumista tai uuden replikan valmistumista. Myös skaalauksen vakautusikkuna voi vaikuttaa päätöksen ajoitukseen. Vertailussa alkutilan pitää olla sama: lämmin replika kummassakin tai oma koe, jossa min_replicas sallii nollaan skaalautumisen. Nollasta käynnistymisen viivettä ei pidä yhdistää lämpimän palvelun tuloksiin, koska ensimmäiset pyynnöt joutuvat odottamaan myös palvelun käynnistystä.

Vanha läpimenomittaus rajaa väitteen tarkasti

EMNLP 2024 -tutkimuksessa verrattiin Llama 3 -mallien palvelua NVIDIA A800 -klusterilla; 8 miljardin parametrin mallin replikakokeissa käytettiin 10 ja 50 yhtäaikaista pyyntöä. Tutkijoiden Ray Serve -kokoonpanon läpimeno kasvoi useilla replikoilla lähes lineaarisesti, kun heidän BentoML-kokoonpanonsa skaalautui heikommin. Mittaus koskee paperissa rakennettuja kokoonpanoja ja läpimenoa, ei nykyisten versioiden autoskaalausviivettä.

Tutkimuksessa mitattiin keskimääräistä kokonaisviivettä ja tuotettuja tokeneita sekunnissa, mutta nämä luvut eivät yksin erottele jonotusta, ensimmäisen tokenin viivettä ja replikan käynnistymisaikaa. Tutkijat arvioivat vertailussa myös omaa Xinference-järjestelmäänsä. Replikamäärän mukaan tehty läpimenokoe ei mittaa sitä, kuinka nopeasti uusi replika alkaa palvella kuormapiikissä. Mallin, päättelymoottorin, ohjelmistoversion ja laitteiston vaihtuminen vaatii siksi samalla työkuormalla tehdyn uuden mittauksen.

Oma koe ratkaisee vasteen ja läpimenon vaihtokaupan

Pidä malliversio, päättelymoottori, syötteiden pituus, tulosteen enimmäispituus, laitteisto ja replikakatto vakioina. Mittaa ensin yhden replikan kyky käsitellä samanaikaisia pyyntöjä ilman, että valittu vasteaikatavoite rikkoutuu. Aja sen jälkeen sama tasainen kuorma ja sama nopea kuormapiikki kummassakin ympäristössä. Tallenna Rayn tavoite ja replikakohtainen raja sekä BentoCloudin concurrency, ulkoisen jonon tila ja skaalauksen vakautusasetukset, jotta tulos voidaan toistaa.

Kirjaa aika ensimmäiseen tuotettuun tokeniin eli TTFT, kokonaisvasteaika, tuotettujen tokenien määrä sekunnissa, odotusaika ennen mallin suoritusta, toteutunut replikamäärä ja aika kuorman noususta uuden replikan ensimmäiseen vastaukseen. Tarkastele myös hitaita pyyntöjä keskiarvon rinnalla. Jos käyttäjä odottaa ensimmäistä tokenia pitkään vain piikin alussa, tarkista jonon sijainti ja uuden replikan valmistuminen. Jos taas tasaisen kuorman läpimeno jää heikoksi, tutki ensin yhden replikan käsittelykyky ja samanaikaisuuden rajat; lisää replikoita vasta sen jälkeen, kun pullonkaula on tiedossa.

Lue myös: