Myyntipuhe kuulostaa vakuuttavalta: vuokraa tai osta kiihdyttimet, aja avoimen painon mallia ja korvaa vaihteleva rajapintalasku. Mallit eivät kuitenkaan ole automaattisesti keskenään vastaavia, näytönohjaimet eivät pysy täydessä käytössä ja palvelupinosta tulee sinun tietoturva- ja luotettavuusvastuusi.
Tämä on kustannusmallinnuksen opas, ei vertailumittaus. Käy läpi nykyinen vLLM-dokumentaatio, vLLM:n tietoturvaohjeistus, SGLang-dokumentaatio ja Hugging Face TGI -dokumentaatio ennen palvelimen valintaa. Mittaa tuetut versiot kohdelaitteistolla.
Todellisuus on monimutkaisempi. Itseisännöinti on aidosti edullisempi tietyissä mittakaavoissa, mutta toisissa ylläpitokustannukset ylittävät päättelystä saatavan säästön moninkertaisesti. Kannattavuusraja vaihtelee työkuorman, mallin koon, viivevaatimusten ja tiimin osaamisen mukaan.
Artikkeli käsittelee laskelmia, käytännön vastuita ja niitä piirteitä, jotka erottavat itseisännöintiin sopivat tiimit niistä, joille se ei sovi. Lähtökohtana on vakavasti harkittu päätös, joka edellyttää konkreettisia lukuja.
Milloin itseisännöinti kannattaa
Piirteitä, jotka puoltavat itseisännöintiä:
Mittakaava ja käyttöaste. Jatkuva ja ennustettava kysyntä voi kuolettaa varatun kapasiteetin. Käytä mitattua tuntikohtaista kuormajakaumaa; pelkkä kuukausittainen rajapintalasku ei ole kannattavuustesti.
Ennustettava työkuorma. Tasainen ja ennakoitava käyttö. Itseisännöinti vaatii kapasiteettisuunnittelua. Voimakkaasti vaihteleva kuorma joko tuhlaa kapasiteettia hiljaisina aikoina tai ylikuormittaa järjestelmän huippuina.
Tietosuojaa ja vaatimustenmukaisuutta koskevat vaatimukset. Aineisto, jota ei voi lähettää pilvipalveluntarjoajille, esimerkiksi säännellyillä toimialoilla, tietyissä julkishallinnon sopimuksissa tai vain sisäiseen käyttöön tarkoitetuissa järjestelmissä.
Räätälöidyt mallit. Hienosäädöt, mukautetut arkkitehtuurit tai erikoistuneet variantit, joita hallinnoidut palveluntarjoajat eivät tarjoa.
Viiveen hallinta. Käyttäjiä lähempänä isännöinti ja niputuksen hallinta voivat auttaa viiveessä, mutta verkko, jonotus, mallin koko, kehotteen pituus ja kuorma ratkaisevat silti eniten. Mittaa tavoitepersentiili.
Kutsukohtainen kustannus kannattavuusrajan alapuolella. Kun laskelmat on tehty ja itseisännöinti voittaa aidosti.
Kun useimmat näistä pätevät, itseisännöintiä kannattaa harkita tosissaan.
Milloin itseisännöinti ei kannata
Toinen puoli. Piirteitä, jotka puoltavat hallinnoituja rajapintoja:
Pieni tai vaihteleva mittakaava. Joutokäyvä kapasiteetti ja huippujen varalta hankittu teho voivat syödä näennäisen säästön tokenin hinnassa. Hallinnoitu päättely voi sopia paremmin, mutta laske molemmat mallit.
Piikikäs kuorma. Suuret erot huippujen ja hiljaisten jaksojen välillä voivat jättää varatun kapasiteetin joutilaaksi tai pakottaa kalliiseen huippumitoitukseen.
Tarve suljetun mallin ominaisuuksille. Osa nykyisistä malleista, syöte- ja tulosmuodoista, turvallisuusjärjestelmistä ja isännöidyistä työkaluista on saatavilla vain palveluntarjoajan kautta. Jos työkuorman arviointi edellyttää jotakin niistä, ota palveluntarjoajan ratkaisu ja sen sopimusehdot mukaan vertailuun sen sijaan, että korvaisit sen arvioimattomalla avoimella mallilla.
Pieni tiimi. Itseisännöity päättely vaatii käytännön ylläpito-osaamista. Ilman siihen varattua kapasiteettia järjestelmä jää helposti hoitamatta.
Nopea kehitystahti. Useiden mallien, määritysten ja tarjoajien kokeileminen on API-palveluissa helppoa, mutta itseisännöinnissä jokainen muutos on uusi käyttöönotto.
Useita alueita ja maailmanlaajuiset käyttäjät. Itseisännöinti voi vaatia aluekohtaista kapasiteettia, reititystä, tiedonsiirtoa ja palautumisen suunnittelua. Hallinnoidut API-palvelut voivat vähentää osaa infrastruktuurivastuusta, mutta alueellinen saatavuus, tietojen sijainti, vikasietoisuus ja verkkoviive on silti varmistettava.
Näissä tapauksissa hallinnoidut rajapinnat voivat olla vähäriskisempi tai vähemmän omaa vastuuta vaativa vaihtoehto, vaikka niiden suora käyttökustannus olisi korkeampi.
Kustannuslaskenta (huolellisesti)
Rakenna kolme ajantasaista ja laadultaan vastaavaa vaihtoehtoa: suljetun mallin API-palvelu, avoimen painon mallin hallinnoitu ajo ja itseisännöinti. Älä vertaa malleja ennen kuin ne läpäisevät saman tehtäväkohtaisen arvioinnin.
Laske jokaiselle skenaariolle:
monthly total = metered inference or dedicated capacity + storage + network + observability + support + security/compliance + engineering + expected incident loss
Käytön mukaan laskutettavissa API-palveluissa päättelykustannus muodostuu laskutettavasta välimuistiin tallentamattomasta syötteestä, välimuistin kirjoitus- ja lukukerroista, vastaus- ja päättelytokeneista, työkaluista, eräajoista ja uudelleenyrityksistä. Itseisännöidyssä tai hallinnoidussa varatussa kapasiteetissa kiihdyttimien kokonaiskustannukseen on laskettava käytetty, joutokäyvä, varalle jätetty, käyttöönottoon tarvittava sekä vika- ja varareittikapasiteetti. Älä lisää erillistä ”päättelymaksua”, ellei sopimuksessa ole aidosti erillistä ja toisensa poissulkevaa laskutusperustetta. Kohdista kapasiteettikustannus työkuorman yksiköille mitattujen, vaaditulla viiveellä ja saatavuudella käsiteltyjen pyyntöjen perusteella, ei toimittajan ilmoittaman huippuläpimenon mukaan.
Tee herkkyysanalyysi käyttömäärästä, huippu- ja keskikuorman suhteesta, mallin laadusta, kiihdyttimen hinnasta, käyttöasteesta, henkilöstön ajasta ja siirtymäkustannuksesta. Kannattavuusraja on kohdassa, jossa laadultaan vastaavien vaihtoehtojen nettokustannukset kohtaavat uskottavalla oletusten vaihteluvälillä.
Operatiivinen kustannus
Pelkän päättelykustannuksen lisäksi tulee itseisännöinnin operatiivinen kustannus.
Alkuvaiheen käyttöönotto:
- Oikean päättelypalvelimen valinta (vLLM, TGI, SGLang).
- Konfigurointi omalle mallille ja laitteistolle.
- Näytönohjainten infrastruktuurin pystytys (pilvessä tai omana).
- Verkko, tietoturva, havainnoitavuus.
- Kvantisointi ja optimointi.
Arvioi alkuvaiheen työ rajatun tehtäväerittelyn, laitteiston tai toimittajan toimitusajan, tietoturvakatselmuksen, mittausmatriisin, saatavuussuunnitelman ja tiimin mitatun työnopeuden perusteella. Tässä artikkelissa ei anneta organisaatiosta toiseen siirrettävää arviota tarvittavista insinöörityöviikoista.
Jatkuva ylläpito:
- Valvonta (viive, läpimeno, virheet, näytönohjainten käyttöaste).
- Kapasiteettisuunnittelu.
- Päivitykset (uudet malliversiot, päättelypalvelimen päivitykset, tietoturvapaikkaukset).
- Häiriöiden hoito (näytönohjainten viat, muistin loppumisesta johtuvat kaatumiset, ohjelmistoviat).
- Skaalaus (lisää näytönohjaimia kuorman kasvaessa).
Kirjaa todellinen vastuunjako alusta-, ML-, tietoturva- ja päivystystyön osalta. Oletus osa-aikaisesta henkilötyövuodesta ei siirry organisaatiosta toiseen.
Piilokustannukset:
- Näytönohjainten hintavaihtelu.
- Pilven ulosliikenteen kustannukset hybridiratkaisussa.
- Erikoisosaaminen (CUDA, kvantisointi, optimointi).
- Oman laitteiston korvaus- ja vikakustannukset.
Käytä organisaation työn kokonaiskustannusta sivukuluineen sekä vaihtoehtoiskustannusta. Tokenin hinnasta saatu säästö ei ole nettosäästö ennen kuin operatiivinen vastuu on laskettu mukaan.
Päättelypalvelimet
Jos aiot itseisännöidä, päävaihtoehdot ovat:
vLLM. Avoimen lähdekoodin palvelinmoottori, jossa on jatkuva niputus ja laaja, versiosta riippuva mallituki. Käsittele sen tietoturvaohjeistusta pakollisena luettavana.
TGI (Text Generation Inference). Hugging Facen palvelinprojekti. Varmista nykyinen ylläpitotilanne ja mallituki sen sijaan, että luottaisit tämän artikkelin hetkelliseen kuvaan.
SGLang. Aktiivisessa kehityksessä oleva mallipalvelu- ja ohjelmointikokonaisuus. Mittaa vaaditut mallit, rakenteisten vastausten toteutuspolku ja ylläpitotyökalut.
LMDeploy. Toinen palvelinvaihtoehto, jonka malli-, kvantisointi- ja laitteistotuki riippuu versiosta; mittaa se samoilla hyväksymistesteillä.
llama.cpp ja Ollama. Vaihtoehtoja paikalliseen ajoon ja joihinkin palvelintyökuormiin. Tuettu laitteisto, rinnakkaisuus, tietoturvaraja, ylläpidon hallintatoimet ja tuotantokelpoisuus on testattava. Kumpikaan nimi ei sinänsä merkitse pienempää läpimenoa tai takaa tuotantovalmiutta.
Hallinnoidut omistetut päätepisteet. Hugging Face ja muut tarjoajat myyvät hallinnoituja päätepistetuotteita, joiden moottorit, laskutus, eristys ja vastuunjako muuttuvat ajan myötä. Varmista palvelun nykytila sen sijaan, että olettaisit sen ajavan TGI:tä tai käyttävän yhtä laskutusmallia.
Hallinnoidut näytönohjain- tai päättelyalustat. Ne voivat vähentää osaa kapasiteetti- ja palvelintyöstä, mutta integraatio-, tietoturva-, arviointi- ja toimittajariippuvuudet jäävät. Vertaa nykyisiä tarjouksia ja vastuita; älä oleta kiinteää hintasuhdetta omaan operointiin.
Ota jatkoon vain ne projektit, jotka tukevat tarkkaa mallia, kiihdytintä, kvantisointia, API-sopimusta ja tietoturvakontrolleja. Toistettava kuormitustesti ratkaisee niiden välillä.
Laitteistovalinnat
Näytönohjainkysymys:
Kiihdytinsukupolvet, muistikapasiteetit ja vuokrahinnat muuttuvat nopeasti. Hanki ajantasaiset tarjoukset vaaditulle alueelle ja sitoutumisajalle.
Vertaa muistikapasiteettia ja -kaistaa, tuettuja lukumuotoja, laitteiden välistä yhteyttä, ohjelmistoyhteensopivuutta, kiintiöitä, alueellista saatavuutta, vikakäyttäytymistä ja hintaa. Spot- eli keskeytettävissä oleva kapasiteetti kuuluu malliin vain, jos keskeytysten käsittely ja mitattu palautumispolku ovat olemassa.
Kvantisointi
Kvantisointi on yksi kapasiteetti- ja suorituskykyvaihtoehto. Sen kompromissit riippuvat mallista, formaatista, ytimestä, laitteistosta ja tehtävästä:
FP16/BF16-luokan vertailutarkkuus. Käytetään usein vertailun lähtötasona tuetuille malleille ja laitteistoille; se ei automaattisesti ole mallin alkuperäinen tai ”täyslaatuinen” formaatti.
INT8 / FP8 (8-bittinen). Voi pienentää painojen muistintarvetta tai parantaa tuettuja suorituspolkuja; laatu- ja nopeusvaikutukset vaihtelevat.
INT4 (4-bittinen). Voi pienentää painojen muistintarvetta edelleen. Mittaa laatu ja laskentaytimen suorituskyky juuri kyseiselle malliversiolle.
AWQ, GPTQ, GGUF. Eri kvantisointiformaatteja, joilla on eri kompromissit.
Pelkkä parametrimäärän laskutoimitus on vain alaraja-arvio; ajonaikaiseen muistiin kuuluvat myös KV-välimuisti, aktivaatiot, työmuisti, pirstoutuminen ja replikat. Käytä palvelinmoottorin profilointityökalua ja kuormitustestiä. Arvioi tulosteen laatu tuotantotehtävällä, ei pelkällä yleisellä vertailumittauksella.
Läpimeno ja kapasiteettisuunnittelu
Keskeinen suunnittelukysymys: kuinka monta tokenia sekunnissa tarvitset?
Mittaa aika ensimmäiseen tokeniin, tokenien välinen viive, kokonaisviive, läpimeno, jonotusaika, virheosuus ja muistin varakapasiteetti eri kehote- ja vastauspituuksilla sekä rinnakkaisuustasoilla.
Kapasiteettisuunnittelua varten:
- Arvioi rinnakkaisten pyyntöjen huippumäärä.
- Arvioi pyynnön keskimääräinen pituus.
- Laske tarvittava kokonaismäärä tokeneita sekunnissa.
- Lisää kuormituspiikeistä, vioista ja käyttöönotoista johdettu varakapasiteetti.
Luotettavuus ja varareitit
Itseisännöinti tarkoittaa, että luotettavuus on sinun vastuullasi.
Kuntotarkistukset. Valvo palvelun kuntoa jatkuvasti ja käynnistä toimimattomat palveluinstanssit uudelleen.
Ylikuormituksen käsittely. Käytä rajattuja jonoja, kuormituksen vastaanoton hallintaa, vastapainetta ja testattua palvelutason alentamis- tai hylkäyskäytäntöä. Pyyntöjen rajaton odottaminen voi pahentaa ylikuormaa ja rikkoa viivetavoitteet.
Varareitti rajapintoihin. Hallinnoitu varareitti voi vaimentaa osan katkoista tai huipuista, mutta vain jos mallin laatu, datakäytäntö, sopimukset, kutsurajat, tila ja vikatilanteen käyttäytyminen ovat yhteensopivia ja testattuja. Se lisää monimutkaisuutta ja voi pettää samaan aikaan.
Vikakapasiteetti. Mitoita varakapasiteetti tai vaihtoehtoinen polku saatavuustavoitteesta ja testatuista vikatiloista; jokainen kiihdytin voi vikaantua, mutta omistettu joutokäyvä laitteisto ei ole ainoa mahdollinen ratkaisu.
Useita alueita. Monista palvelu eri alueille maailmanlaajuisia käyttäjiä varten tai käytä etäisillä alueilla hallinnoituja API-palveluja.
Päivitysstrategia. Suunnittele malliversioiden ja palvelinohjelmiston päivitykset. Käytä esimerkiksi rinnakkaista blue-green-käyttöönottoa katkojen välttämiseksi.
Jokainen näistä on insinöörityötä, jonka hallinnoidut rajapinnat tekevät puolestasi.
Kaksi laadittavaa päätösdokumenttia
Älä keksi anonymisoitua lopputulosta. Laadi auditoitavat päätösdokumentit ajantasaisista tarjouksista ja mittausaineistoista.
Itseisännöintiehdokkaan dokumentti:
- mallitiedosto, versio, lisenssi, kvantisointi, palvelinohjelmiston versio, kiihdytin, alue ja käyttöönottoarkkitehtuuri,
- kuormajakauma ja laatuarviointi nykyistä isännöityä lähtötasoa vasten,
- kuormitustestin komento, aineisto, viive- ja läpimenotulokset, kyllästymispiste ja palautumiskäyttäytyminen,
- investointi- tai vuokrakustannus, käyttöaste, insinöörityö, tietoturvatyö ja odotettu häiriökustannus,
- kannattavuusrajan vaihteluväli herkkyysanalyysillä sekä irtautumiskriteeri.
Hallinnoidun vaihtoehdon dokumentti:
- palveluntarjoaja, mallin tai version käyttäytyminen, alue, hinnaston päiväys, kiintiöt ja sopimusehdot,
- näyttö vastaavasta laadusta, viiveestä, kutsurajoista, katkoista ja datarajoista,
- siirtymätyö ja yhteen toimittajaan keskittymisen riski,
- ehdot, jotka laukaisisivat uuden itseisännöintiarvioinnin.
Milloin päätös kannattaa ottaa uudelleen käsittelyyn
Päätös ei ole pysyvä. Palaa siihen säännöllisesti:
Volyymin muutokset. Merkittävä kasvu: itseisännöinti houkuttelevampi. Merkittävä lasku: vähemmän houkutteleva.
Hinnoittelun muutokset. Suljetut rajapinnat halpenevat tai kallistuvat. Hallinnoitu avoin halpenee. Laitteisto halpenee.
Mallien kehitys. Uusia avoimen painon tai lähdekoodiltaan saatavilla olevia ehdokkaita, jotka täyttävät kuorman tavoitteen, tai uusia suljettuja malleja, jotka muuttavat laatuvertailua. Varmista lisenssit ja todellinen saatavuus.
Operatiivinen kapasiteetti. Tiimin ML- ja operointiosaaminen kasvoi tai kutistui.
Tietosuoja- ja vaatimustenmukaisuusmuutokset. Uudet vaatimukset, jotka pakottavat itseisännöintiin.
Aseta tarkistusrytmi sopimusten, hintojen, mallien, työkuorman, tietoturvan ja kapasiteetin vaihtelun mukaan ja lisää muutoksiin perustuvat tarkistusajankohdat. Neljännesvuosittainen tarkistus on vain esimerkki, ei yleispätevä oletus.
Yleiset virheet
Toistuvia kuvioita itseisännöintipäätöksissä:
Virhe 1: Kustannuslaskenta ilman operatiivista kustannusta. Raportoidaan säästö tokeneissa tai kiihdyttimissä, mutta insinöörityö, päivystys, tietoturva ja häiriökustannukset jätetään pois.
Virhe 2: Liian aikainen itseisännöinti. Insinöörityötä käytetään itseisännöintiin, vaikka kuorma on pieni. Ennenaikaista optimointia.
Virhe 3: Erilaatuisten vaihtoehtojen vertailu. Valitaan halvempi malli osoittamatta, että se täyttää kuorman laatu-, turvallisuus- ja viivevaatimukset.
Virhe 4: Ei suunnitelmaa vikatilanteisiin. Itseisännöity infrastruktuuri kaatuu ilman testattua heikennys-, jonotus-, hylkäys- tai varareittipolkua. Myös hallinnoidut rajapinnat voivat kaatua; vertaa molempia arkkitehtuureja samaan saatavuustavoitteeseen.
Virhe 5: Ensimmäistä palvelinmääritystä pidetään tehokkaana ilman näyttöä. Tuettuja kvantisointi-, niputus-, rinnakkaisuus-, kehotepituus- ja palvelinasetusvaihtoehtoja ei käydä toistettavasti läpi, joten kapasiteettimalli perustuu varmistamattomaan määritykseen.
Virhe 6: Laadun ajautumisen sivuuttaminen. Itseisännöity malli on heikentynyt suhteessa nykyiseen suljettuun. Asiakkaat huomaavat, tiimi ei.
Virhe 7: Päätöstä ei arvioida uudelleen. Kun itseisännöinti on kerran valittu, sitä ei enää kyseenalaisteta. Päätös saattoi olla oikea kaksi vuotta sitten ja väärä nyt.
Virhe 8: Spot-kapasiteetti ilman hallittua keskeytysten käsittelyä. Alennettua kapasiteettia mallinnetaan ottamatta huomioon keskeytysten tiheyttä, palautumisaikaa, kahteen kertaan tehtyä työtä tai varareitin kustannusta.
Päätöksenteon tarkistuslista
Jotta päätös syntyy harkiten:
- Onko laadultaan vastaavat isännöidyt ja itseisännöidyt vaihtoehdot mitattu?
- Onko kuorma tasainen ja ennustettava?
- Onko tiimillä MLOps- ja päättelyosaamista tai mahdollisuus rekrytoida sitä?
- Onko olemassa asianmukaisesti lisensoitu avoimen painon tai lähdekoodiltaan saatavilla oleva ehdokas, joka täyttää kuorman laatu- ja turvallisuustavoitteen?
- Ovatko viivevaatimukset yhteensopivia itseisännöinnin kanssa?
- Onko kustannuslaskenta tehty yksityiskohtaisesti operatiiviset kustannukset mukaan lukien?
- Onko varasuunnitelma olemassa?
- Jättävätkö vaatimustenmukaisuus- ja tietosuojavaatimukset molemmat polut avoimiksi?
- Onko dokumentoitu katselmusrytmi ja tapahtumapohjaiset laukaisimet olennaisille malli-, hinta-, sopimus-, kuorma-, tietoturva- tai kapasiteettimuutoksille?
Älä tiivistä tätä rastien lukumääräksi. Tietoturva, mallin laatu tai operatiivinen vastuu voi kaataa päätöksen, vaikka jokainen taloudellinen luku näyttäisi suotuisalta.
Yhdistelmäratkaisut
Valinnan ei tarvitse olla joko-tai. Mahdollisia yhdistelmäratkaisuja:
Itseisännöinti suurelle perusmäärälle, API-palvelut vaikeisiin tapauksiin. Luokittelu ja yksinkertainen tekstintuotto hoidetaan itseisännöitynä ja vaativa päättely suljettujen API-palvelujen kautta.
Itseisännöinti tasaiselle kuormalle, rajapinnat piikkeihin. Itseisännöinti hoitaa perus kuorman; rajapinnat vaimentavat huiput.
Itseisännöinti arkaluonteiselle aineistolle, API-palvelut yleiselle aineistolle. Arkaluonteinen aineisto käsitellään itseisännöidyssä ympäristössä ja yleiset kyselyt API-palveluissa.
Itseisännöinti hienosäädöille, rajapinnat perusmalleille. Räätälöidyt mallit ajetaan itse; valmismallit rajapinnoista.
Yhdistelmäratkaisu lisää reititykseen, tietokäytäntöihin, arviointiin, havainnoitavuuteen, sopimuksiin ja vikatilanteisiin liittyvää monimutkaisuutta. Ota se käyttöön vain, kun testit osoittavat jaon parantavan nimenomaisesti määriteltyä tavoitetta.
Päätä ajantasaisen näytön perusteella
Itseisännöinti on toimiva arkkitehtuuri, kun tuettu malli täyttää työkuorman laatutavoitteen ja organisaatio pystyy vastaamaan mallipalvelun koko elinkaaresta.
Kannattavuusraja ei ole yleispätevä kuukausisummaa. Se muuttuu mallin laadun, kysyntäjakauman, käyttöasteen, kiihdyttimien ja palveluntarjoajien hintojen, saatavuuden, tietojen käsittelyrajojen ja henkilöstökustannusten mukana.
Itseisännöintipäätöstä tukevan näytön pitää osoittaa, että:
- Laskelmat on tehty huolellisesti operatiiviset kustannukset mukaan lukien.
- MLOps-kyvykkyys on olemassa tai rakennettavissa.
- Toiminta on riittävän suurta perustelemaan investoinnin.
- Kuormat ovat tasaisia.
- Vain suljetuissa kärkimalleissa saatavia ominaisuuksia ei tarvita.
- Luotettavuus, valvonta ja päivitykset on suunniteltu.
Hallinnoitua palvelua puoltavaa näyttöä voi olla:
- Pienempi mittakaava.
- Piikikkäät kuormat.
- Nopean iteroinnin tarve.
- Pienet tiimit ilman operointikapasiteettia.
- Suljettujen kärkimallien ominaisuuksien tarve.
Oikea vastaus riippuu työkuormasta. Tee laatu-, kuormitus-, vika-, tietoturva- ja kustannusvertailut ja arvioi ylläpitokapasiteetti. Suosi vähiten omaa ylläpitovastuuta vaativaa vaihtoehtoa, joka täyttää pakolliset vaatimukset. Se voi olla hallinnoitu, itseisännöity tai niiden yhdistelmä.
Kun itseisännöinti valitaan, kirjaa mitattu hyöty, oletukset, omistaja, irtautumiskriteerit ja seuraavan katselmuksen laukaisin. Tee sama hallinnoidulle päättelylle; kumpikaan polku ei ole oikea ilman ajantasaista näyttöä.
