WhisperX på SageMaker AI: talerlabels

At gå fra en lydoptagelse til en brugbar transskription med talerlabels har historisk krævet flere separate trin, og jeg har selv bygget den slags kæder: talegenkendelse med en Whisper-model, derefter forced alignment for at få ordniveau-tidsstempler, og til sidst speaker diarization for at afgøre, hvem der talte hvornår. Hver komponent har typisk sine egne afhængigheder, sine egne modelvægte og sin egen GPU-konfiguration. At holde de tre trin synkroniseret er i sig selv en driftsopgave, jeg har brugt unødig tid på.

Det nye SageMaker AI-image pakker alle tre trin i ét container-image, klar til at køre på GPU-instanser i SageMaker. Det betyder, at et team ikke længere skal orkestrere tre separate services eller batch-jobs for at nå fra rå lyd til en struktureret transskription med talerlabels. Hele pipelinen deler samme runtime, samme model-cache og samme GPU-ressource, hvilket reducerer både latenstid og den mængde infrastrukturkode, der skal skrives og vedligeholdes, noget jeg altid ser som den reelle omkostning i den slags projekter, ikke selve modellen.

For virksomheder, der allerede har talegenkendelse i drift, er det denne konsolidering, jeg vil kigge først på. Den fjerner en stor del af det limkode, som ellers binder Whisper, alignment-modellen og diarization-modellen sammen, og den gør det muligt at behandle pipelinen som én deploybar enhed i stedet for tre.

WhisperX er valgt som kernen i pipelinen, fordi det løser et specifikt problem, som ren Whisper-inferens ikke gør: Whisper giver gode transskriptioner, men dens indbyggede tidsstempler er ofte upræcise på ordniveau, og den har ingen indbygget måde at skelne mellem talere. WhisperX lægger et forced alignment-lag ovenpå Whisper-outputtet, som binder hvert ord til et nøjagtigt tidsinterval i lydsporet, og kombinerer det med en diarization-model, der klynger stemmesegmenter efter, hvem der taler.

Resultatet er en transskription, hvor hver linje bærer tre informationer samtidig: teksten, det præcise tidsinterval og et talerlabel som "Speaker 1" eller "Speaker 2". Det er den datastruktur, jeg selv leder efter, når jeg vurderer, om en talegenkendelsesløsning reelt kan bruges i produktion, uanset om formålet er at generere undertekster, søge i et mødereferat efter, hvem der sagde en bestemt ting, eller bygge et compliance-system, der skal kunne dokumentere præcis hvornår en rådgiver gav et bestemt råd i en telefonsamtale.

Det er også her, GPU-behovet kommer ind. Forced alignment og diarization er begge beregningstunge trin, og at køre dem sekventielt efter Whisper-inferensen på samme GPU-instans, i stedet for at flytte data mellem separate services, er det, der gør den samlede pipeline hurtig nok til produktionsbrug frem for kun til eksperimenter.

SageMaker AI-imaget understøtter både real-time inference endpoints og asynkron batch-behandling, og det er et arkitekturvalg, jeg beder alle mine kunder tage stilling til, før de skriver en linje deployment-kode.

Real-time endpoints giver mening, når latenstiden skal holdes lav, for eksempel i et live transskriptionsværktøj under et møde eller en kundeserviceopringning, hvor talerlabels skal fremgå næsten øjeblikkeligt. Her betaler man for, at en GPU-instans står klar og lytter, hvilket er en løbende omkostning uafhængigt af, hvor meget lyd der reelt behandles.

Asynkron batch-behandling er den rigtige model, når opgaven er at behandle store mængder optaget lyd, som ikke skal returneres med det samme. Et arkiv af kundeserviceopkald, der skal transskriberes til analyse, eller en samling podcastepisoder, der skal have undertekster, hører hjemme her. Her kan man skalere GPU-instanser op og ned efter behov, og betale for beregning frem for standby-tid.

Mit råd til teams, der planlægger en implementering, er at afklare dette valg først, før man vælger instanstype og skaleringsstrategi. Jeg har set begge fejl begået: at bygge til real-time, når behovet faktisk er batch, hvilket betyder unødige standby-omkostninger, og at bygge til batch, når brugerne forventer live talerlabels, hvilket betyder en løsning, der ikke leverer det, den skal.

Et af de mest konkrete driftsråd, der følger med denne type opsætning, er at fastlåse GPU-AMI-versionen i stedet for at lade instanserne automatisk hente den nyeste tilgængelige version. Det lyder som en detalje, men det er den forskel, jeg har set afgøre, om en produktionspipeline er stabil eller uforudsigelig.

GPU-drivere og CUDA-biblioteker opdateres løbende, og selv små versionsskift kan ændre, hvordan en model performer, eller i værre tilfælde introducere inkompatibilitet med de specifikke modelvægte, som WhisperX-pipelinen bruger. Hvis en instans automatisk opgraderer AMI-versionen ved genstart, kan man opleve, at en pipeline, der virkede perfekt i går, pludselig fejler eller giver anderledes resultater i dag, uden at nogen har ændret en linje kode.

Jeg behandler altid infrastrukturversioner som en del af selve softwareversioneringen, og det er den samme regel, jeg sætter for Agent Enterprise' egne systemer. En fastlåst GPU-AMI hører til i samme kategori som en fastlåst Python-afhængighed eller en fastlåst modelversion: det er noget, der skal testes eksplicit, før det opgraderes, og aldrig noget, der skal ske automatisk i baggrunden på en produktionsworkload.

For talegenkendelse med talerlabels er konsekvensen af en uventet driveropgradering særligt alvorlig, fordi fejlene ofte ikke er tydelige. En diarization-model, der subtilt ændrer, hvordan den grupperer stemmer, giver ikke en fejlmeddelelse, den giver bare forkerte talerlabels, og det kan gå ubemærket hen, indtil en kunde eller en revisor opdager det. Det er præcis den slags fejl, jeg mener bør kunne opdages i en log, ikke først når nogen klager.

GPU-instanser er den dyreste ressource i denne type pipeline, og det gør skalering til et direkte omkostningsspørgsmål frem for kun et performancespørgsmål. Med det samlede image kan man skalere efter belastning i stedet for at holde faste instanser kørende hele tiden, hvilket er særligt værdifuldt for arbejdsbelastninger, der svinger meget, som kundeservicecentre med markant flere opkald i dagtimerne end om natten.

Den praktiske strategi, jeg selv bruger, er at kombinere autoskalering med en klar forståelse af, hvor lang tid en enkelt transskriptionsopgave typisk tager. Hvis en gennemsnitlig samtale på 20 minutter tager 2 minutter at behandle på en given GPU-instans, giver det et konkret grundlag for at dimensionere, hvor mange instanser der skal være tilgængelige ved forskellige belastningsniveauer, i stedet for at gætte.

Det er også her, valget mellem real-time og asynkron for alvor slår igennem på bundlinjen. Asynkrone batch-jobs kan lægges i kø og behandles, når GPU-kapacitet er billigst eller mest tilgængelig, mens real-time endpoints kræver, at kapacitet står klar konstant. Jeg har set en virksomhed bygge sin talegenkendelse som real-time, når batch ville have været tilstrækkeligt, og betale for standby-tid, den aldrig fik værdi af.