Mät Mercury 3 från det att en uppgift börjar tills resultatet kan användas. Anteckna tiden till det första svaret, tiden till hela svaret och den totala tiden inklusive verktyg. Token per sekund beskriver en del av genereringen, men kan missa väntetiden innan utdata kommer och arbetet som krävs efter att modellen är klar.
Använd ett litet testunderlag med tydliga godkännandekriterier och dokumentera prompten, indatafilerna, verktygsmiljön och modellinställningarna. Det räcker för att fastställa grundläggande beteende och hitta flaskhalsar. Utöka testet bara när ett fel eller ett svårt beslut kräver mer underlag.
Vilka tidsstämplar bör jag samla in?
| Tidsstämpel eller tidsåtgång | Vad den visar |
|---|---|
| Begäran skickad | Startpunkten på klientsidan |
| Första innehållet mottaget | Upplevd svarstid, när strömning används |
| Hela svaret mottaget | Begärans totala varaktighet |
| Verktygen slutförda | Körtid utanför modellen |
| Artefakten godkänd | Tid tills uppgiften faktiskt uppfyller kraven |
Använd en monoton timer på klientsidan för att mäta tidsåtgång och anteckna om strömning är aktiverad. Håll villkoren för anslutningsinitiering och återanvända anslutningar konsekventa om du jämför leverantörer. Dra inga slutsatser om tiden till första token utifrån en begäran utan strömning.
Hur väljer jag en rättvis testprompt?
Välj en verklig, avgränsad uppgift: extrahera angivna fält från ett godkänt dokument eller gör en liten ändring i ett kopierat kodarkiv. Håll indata och önskat resultat identiska mellan körningarna. Anteckna modellens identifierare, inställningen för beräkningsnivå och utdata gränsen så att resultaten förblir tolkningsbara.
Översikten över Mercury 3 förklarar varför leverantörernas genomströmningstal inte ersätter mätningar på uppgiftsnivå.
Hur påverkar verktyg resultatet?
Skilj väntetid för modellen från verktygskörning. En långsam NAS-avläsning, sidnavigering eller extern sökning kan dominera en uppgift med flera steg. Räkna omförsök, felaktiga verktygsargument och upprepade filläsningar i stället för att bortse från tiden som misslyckade försök tar.
Använd checklistan för agentharness för att identifiera vilken komponent som orsakar varje fördröjning. Om modellkörningen bara står för en liten del av jobbet kan det vara viktigare att förbättra lagringsåtkomsten eller uppgiftsdesignen än att byta genereringsarkitektur.
Hur många körningar behöver jag?
En körning är användbar för att kontrollera anslutningen och upptäcka uppenbara problem med korrektheten. Några konsekventa upprepningar kan visa stora praktiska skillnader, men de räcker inte för att motivera precisa tillförlitlighetspåståenden eller stabila percentiler för svansen. Samla fler observationer endast om insatserna vid driftsättning eller ett jämnt prestationsbeslut motiverar det.
Se alltid till att misslyckanden är synliga. En snabb, lyckad körning som valts ut bland flera misslyckade försök är inte representativ evidens. Guiden för riktad kontroll av arbetsflödet beskriver ett enkelt tillvägagångssätt för godkännande.
Vad bör jag rapportera utöver latens?
Rapportera om resultatet godkändes vid granskningen, relevanta användningsavgifter, verktygsanrop och manuella korrigeringar. Ange miljö och datum. Om en körning nådde en timeout ska den registreras som en timeout, inte tilldelas ett lockande hastighetsresultat.
För NAS-filer bör du spara testdata och godkända resultat i separata kataloger. Använd jämförelsen av arkitekturer för att avgöra vad mätningarna betyder och guiden för filförberedelser för att begränsa pilotens dataexponering.
Vanliga frågor
Kan jag jämföra token per sekund direkt mellan olika tokeniserare?
Var försiktig med sådana siffror. Tokendefinitioner, utdata och mätförhållanden kan skilja sig åt mellan leverantörer.
Vad gör jag om API:et inte strömmar?
Mät tiden för hela svaret och om uppgiften slutfördes. Påstå inte att du har mätt tiden till första token om klienten inte kan observera den.
Bör misslyckade körningar uteslutas?
Nej. Registrera timeouter, omförsök och avvisade resultat, eftersom de påverkar den praktiska sluttiden och kostnaden.
Behöver jag ett stort benchmarktest före en pilot?
Nej. Börja med en liten, representativ uppgift och bredda mätningen först när en meningsfull osäkerhet kräver det.
Relaterad läsning
- Mercury 3 förklarat: varför diffusionsspråkmodeller är viktiga för snabba AI-arbetsflöden
- Diffusion kontra autoregressiva LLM:er: vad passar bäst för ditt personliga AI-arbetsflöde?
Källor
- Officiellt tillkännagivande och modelldokumentation – www.inceptionlabs.ai
- Teknisk dokumentation och referens – docs.inceptionlabs.ai
Omslag: Officiell lanseringsbild för Mercury 3. Bildkälla.
Support och tips
Mer att läsa

Så kontrollerar du minnes- och körtidskraven innan du kör LFM2.5-24B-A2B
Kontrollera LFM2.5-24B-A2B:s viktformat, minnesåtgång, runtimeversioner, kontext och verktygskompatibilitet innan du försöker distribuera modellen på en hemmaserver.

Så testar du Granite Speech 5.0 med engelska ljudfiler som lagras på din NAS
Testa Granite Speech 5.0 med en kort engelsk inspelning från din NAS. Kontrollera kontrollpunktsrevisionen, körtiden, samplingsfrekvensen, transkriberingens kvalitet och hanteringen av utdata.

Så förbereder du filer och behörigheter för ett Claude Duet-arbetsflöde
Förbered en Claude Duet-uppgift med valda filer, avgränsade anslutna konton, separata utkast, granskningsbara resultat och en tydlig plan för att ta bort anslutningen.

