ScaleDown's kleine modellen voor routinematige in-apptaken: classificeren, extraheren, samenvatten

Op 13 oktober 2026 onthulde ScaleDown drie kleine taakspecifieke modellen die het als één idee verkoopt: Classify, Extract en Summarize, elk gebouwd voor het repetitieve werk rondom een productie-LLM-aanroep in plaats van voor gesprekken. Alle drie nemen een 1M-tokeninvoer, alle drie accepteren tekst of afbeeldingen, en alle drie zijn bereikbaar via ScaleDowns eigen API — en daar wordt de prijsvraag interessant, omdat de drie volledig verschillende kostenprofielen hebben. Het vierde model in de familie, ScaleDown Compress, staat in de documentatie van de leverancier vermeld als een tool voor het trimmen van context, niet als een van de nieuwe drie. Wat volgt is wat de leverancier documenteert, gescheiden gehouden van wat nog niemand heeft gereproduceerd.

Wat er op 13 oktober daadwerkelijk is uitgeleverd

ScaleDown exploiteert al enige tijd een Decisions-endpoint — een interface voor gestructureerde scoring die een state-object plus een map met getypeerde vragen aanneemt en gekalibreerde waarschijnlijkheden retourneert. De aankondiging van 13 oktober is het moment waarop het bedrijf de onderliggende modellen als zelfstandige producten begon te verkopen in plaats van als één endpoint, en waarop het ze begon te beschrijven als algemeen inzetbare componenten voor werk in apps.

De drie modellen en hun contracten, zoals de leverancier ze documenteert:

• ScaleDown Classify — wijst tekst toe aan een labelset die de aanroeper aanlevert. Elk label heeft een naam en een rubric, wat in de documentatie "een ja/nee-vraag die het model gebruikt om het label te scoren" wordt genoemd, en die volgens de documentatie het belangrijkste onderdeel van het verzoek is. De modus met één label retourneert een softmax-verdeling die optelt tot 1,0 plus een toplabel; de modus met meerdere labels scoort elk label onafhankelijk aan de hand van een door de aanroeper ingestelde drempelwaarde.

• ScaleDown Extract — haalt gestructureerde velden uit ongestructureerde tekst. In de documentatie van de familie is dit het model dat een document omzet in een record dat je code kan indexeren.

• ScaleDown Summarize — korte abstractieve samenvattingen van lange invoer, wat de taak is waarop het 1M-tokenvenster het duidelijkst is gericht.

Het gedeelde contract voor alle drie is het deel dat het waard is om op te schrijven. Een miljoen tokens invoer per verzoek is ruwweg een orde van grootte meer dan wat gangbare middelgrote API's accepteren, en het is het getal dat Summarize en Extract haalbaar maakt voor werk met volledige documenten zonder een chunkinglaag. De invoer van tekst of afbeelding is specifiek van belang voor Extract: een gescande factuur of een screenshot van een formulier gaat erin, velden komen eruit, en er zit geen OCR-stap tussen. Alle drie worden aangeboden via de eigen API van ScaleDown, waarvan de documentatie de basis-URL aangeeft als span>api.scaledown.xyz/span> en expliciet vermeldt dat span>api.scaledown.ai/span> geen API-host is.

Het ene getal dat anders is dan de andere getallen.

Prijsstelling is waar deze drie ophouden inwisselbaar te zijn. Classify staat vermeld voor $0,05 per miljoen inputtokens en $0 per miljoen outputtokens, en de vermelding van het model in catalogi van derden toont datzelfde tarief, soms met een promotiekorting toegepast; de korting is geen toezegging van ScaleDown en er moet niet op worden gerekend. De nulprijs voor output is geen marketingtruc — een rubric-geëvalueerde classifier geeft labels en waarschijnlijkheden uit, geen gegenereerde tekst, dus er is niets om voor te factureren. Extract en Summarize genereren wel output, dus hun kostenprofielen zijn niet vergelijkbaar met die van Classify en moeten rechtstreeks bij de leverancier worden geprijsd in plaats van te worden afgeleid uit het tarief van de classifier.

Classify's factureringsdetail is moeilijker te beredeneren dan het tarief in de kop. In enkel-labelmodus gaan elk label en zijn rubric in één modelaanroep, dus elk label dat je toevoegt verhoogt het aantal gefactureerde invoertokens; als je om een uitleg van één zin vraagt bij de keuze, worden ze opnieuw verzonden tegen 2x, en de documentatie zegt duidelijk dat de uitleg wordt gegenereerd nadat het bovenste label is vastgesteld, dus het rechtvaardigt het antwoord in plaats van eraan te twijfelen. In multi-labelmodus is elk label een afzonderlijke modelaanroep, en elk chunk wordt afzonderlijk gescoord. Een taxonomie van zestig labels met redenering aan is daarom geen operatie van $0,05 per miljoen tokens in de zin die een lezer aanneemt; het is dat tarief vermenigvuldigd met de labelset, en vervolgens verdubbeld als redenering aan staat. De gedocumenteerde plafonds — 20 labels per verzoek, 16 in multi-labelmodus, 50 chunks per batch — zijn de praktische beperkingen waarmee je rekening moet houden bij het ontwerpen.

Er is nog een gedocumenteerd gedrag dat belangrijker is dan al deze limieten. De classifier "geeft altijd een winnaar terug", zelfs wanneer geen enkel label past. Het filteren op confidence wordt volledig aan de aanroeper overgelaten. Bij een aanvraag met 10 labels kan een topscore van 0,4 nog steeds het juiste antwoord zijn, omdat de scores relatief zijn binnen de labelset in plaats van absoluut. Elk productiegebruik van dit model heeft zijn eigen drempelbeleid nodig, en een catch-all-label — de documentatie stelt voor er een te noemen, namelijk span>overig/span>

Waarom een 1M-tokenvenster op een classifier het interessante deel is

Classificatiemodellen nemen conventioneel korte inputs. De reden is mechanisch: een op rubrieken gebaseerde classifier moet de hele input afwegen tegen de ja/nee-vraag van elk label, en de kosten van het scoren van een document van honderdduizend tokens tegen twintig rubrieken zijn twintig volledige doorgangen over dat document. Het antwoord van ScaleDown is het 1M-venster plus de batchlaag — tot 50 chunks die in één verzoek tegen één gedeeld profiel worden gescoord — en de bewering van de leverancier is dat de kalibratie per chunk hetzelfde is of je nu één chunk of vijftig verstuurt, met als enige verschil dat het gedeelde profiel één keer per verzoek wordt gefactureerd.

Die bewering is degene die je moet testen voordat je erop voortbouwt. Het is ook de bewering die het model interessant maakt: de hele reden om binnen de applicatie te classificeren in plaats van aan de edge is dat de beslissing de volledige context kan zien — de hele supportthread, het volledige contract, het volledig opgehaalde document — in plaats van een afgekapt venster. Als het venster van 1M standhoudt bij jouw invoergroottes, verdwijnt de architectuurvraag ("heb ik een chunking- en stemschema nodig?") grotendeels. Als dat niet het geval is, heb je een heel goedkope classifier voor korte invoer en een tweede probleem om op te lossen.

De claims die een second opinion nodig hebben

De marketing van ScaleDown stelt dat taakspecifieke kleine taalmodellen frontiermodellen verslaan op kosten, snelheid en nauwkeurigheid voor repetitief werk met een hoog volume, en noemt cijfers, waaronder een model met ongeveer een half miljard parameters dat 91,7% bereikt bij een eenvoudige classificatietaak tegenover 88,6% voor een model met 72 miljard parameters. Dat zijn de eigen cijfers van de leverancier en ze zijn niet onafhankelijk gereproduceerd: ScaleDown Classify staat momenteel zonder score op de openbare leaderboards, zonder dat er benchmarkrijen van derden zijn gepubliceerd. Behandel het nauwkeurigheidsargument als een hypothese met een plausibel mechanisme — het verschil in steekproefefficiëntie tussen een doelgericht getraind klein model en een groot model voor algemene doeleinden op een smalle taxonomie is reëel en goed gedocumenteerd — niet als een vastgesteld resultaat.

Het opgegeven invoeraantal van 1M tokens is eveneens afkomstig van de leverancier. Catalogusvermeldingen van derden voor het model geven de contextlengte weer als niet van toepassing in plaats van het miljoen-token-aantal te herhalen, wat een catalogusbeperking is en geen tegenstrijdigheid, maar het betekent wel dat het venster niet is bevestigd buiten de documentatie van ScaleDown.

Waar dit past als je al een pipeline draait

Het patroon waarop deze drie modellen zijn gericht is een lus, geen enkele aanroep: een document ophalen, het classificeren, velden extraheren, het samenvatten en de samenvatting vervolgens doorgeven aan een generatief model dat het antwoord schrijft. Stap vier is de dure stap op tokenbasis, en het is de stap die OrcaRouter dekt — meer dan 200 modellen achter één OpenAI-compatibele sleutel tegen de lijstprijs van de provider, doorgegeven met 0% markup, met automatische failover wanneer een serveerpad verslechtert. We hosten ScaleDown Classify, Extract of Summarize niet; ze staan niet in onze catalogus en zijn geen doelwit voor chat-completions, en de routeringslaag hier is de generatiehelft van het patroon, niet de scoringhelft.

Dat onderscheid is het waard om duidelijk te benoemen, want de kostenvergelijking waar mensen naar grijpen, is misleidend. Een op een rubric beoordeelde classifier tegen een paar cent per miljoen inputtokens en een generatief model tegen een paar dollar per miljoen zijn geen concurrenten; het zijn verschillende kostenposten, en de reden om een klein model op de classificatiestap te zetten, is dat je daardoor een beter model kunt veroorloven voor de stap die daadwerkelijk iets schrijft.

Wat zou deze beoordeling veranderen?

Drie dingen, in volgorde van hoeveel ze het beeld zouden veranderen. Een onafhankelijke evaluatie van de classificatietaak met rubric-scores op een publieke benchmark zou het nauwkeurigheidsargument veranderen van een claim van de leverancier in een gegeven. Een gepubliceerd latentiecijfer — de leverancier documenteert kostenfactoren maar geen serveerlatentie — zou beslissen of het venster van 1M bruikbaar is bij doorvoer of alleen bij batch. En een reproductie door een derde partij van de kalibratieclaim per chunk zou beslissen of een batch van vijftig chunks een kostenoptimalisatie is of een ander model. Totdat ten minste één daarvan er is, is de eerlijke samenvatting dat ScaleDown drie modellen heeft uitgebracht met ongewoon duidelijke contracten en ongewoon grote invoerlimieten, tegen prijzen die een op drempels gebaseerde classificatiestap goedkoop genoeg maken om te overwegen, en dat de cijfers die ze ondersteunen van de leverancier zelf zijn.

De korte versie

Als je een hoogvolume-classificatie- of extractiefase hebt met een stabiele taxonomie en tekst- of beeldinvoer, zijn de drie modellen van ScaleDown deze week de moeite waard om op je eigen data te benchmarken, omdat het contract eenvoudig is en de invoerlimiet royaal is. Begroot de labelvermenigvuldiging en de 2x redeneertoeslag voordat je je aan een taxonomie vastlegt, en reken erop dat je je eigen betrouwbaarheidsdrempel moet schrijven. Als je taak open-ended generatie is, is niets hiervan op jou gericht.

Modelkeuzes zijn ook een kwestie van wat er eerder is misgegaan: de gedocumenteerde AI-incidenten en agentfouten achter modellen in deze klasse zijn verzameld in het OrcaRouter AI Incident Archive, waar elke vermelding zijn eigen bronnen, ernst, betrouwbaarheidsgraad en betwistingsmarkering heeft.