ScaleDowns små modeller för rutinmässiga uppgifter i appen: klassificera, extrahera, sammanfatta

Den 13 oktober 2026 avtäckte ScaleDown tre små uppgiftsspecifika modeller som företaget säljer som en enda idé: Classify, Extract och Summarize, var och en byggd för det repetitiva arbete som omger ett produktions-LLM-anrop snarare än för konversation. Alla tre tar emot indata på 1 miljon tokens, alla tre accepterar text eller bilder, och alla tre nås via ScaleDowns eget API – och det är där prisfrågan blir intressant, eftersom de tre har helt olika kostnadsprofiler. Den fjärde modellen i familjen, ScaleDown Compress, listas i leverantörens dokumentation som ett verktyg för kontexttrimning snarare än som en av de nya tre. Det som följer är vad leverantören dokumenterar, hållet åtskilt från det som ingen ännu har reproducerat.

Vad som faktiskt släpptes den 13 oktober

ScaleDown har under en tid drivit en Decisions-endpoint — ett gränssnitt för strukturerad poängsättning som tar ett state-objekt plus en mappning av typade frågor och returnerar kalibrerade sannolikheter. Tillkännagivandet den 13 oktober är den punkt då företaget började sälja de underliggande modellerna som produkter i egen rätt i stället för som en enda endpoint, och då det började beskriva dem som generella komponenter för arbete i appar.

De tre modellerna och deras avtal, så som leverantören dokumenterar dem:

• ScaleDown Classify — tilldelar text till en uppsättning etiketter som anroparen tillhandahåller. Varje etikett har ett namn och en bedömningsmall, som dokumentationen kallar "en ja/nej-fråga som modellen använder för att poängsätta etiketten," och som dokumenten beskriver som den viktigaste delen av begäran. Enkel-etikettläge returnerar en softmax-fördelning som summerar till 1.0 plus en toppetikett; fleretikettsläge poängsätter varje etikett oberoende mot en tröskel som anroparen har angett.

• ScaleDown Extract — plockar ut strukturerade fält ur ostrukturerad text. I familjens dokumentation är detta modellen som omvandlar ett dokument till en post som din kod kan indexera.

• ScaleDown Summarize — korta abstraktiva sammanfattningar av långa indata, vilket är den uppgift som 1M-tokenfönstret uppenbarligen är mest avsett för.

Det gemensamma kontraktet för alla tre är den del som är värd att skriva ner. En miljon tokens indata per anrop är ungefär en storleksordning utöver vad vanliga medelstora API:er tar emot, och det är siffran som gör Summarize och Extract rimliga för arbete med hela dokument utan ett chunkninglager. Indata i form av text eller bild har särskild betydelse för just Extract: en skannad faktura eller en skärmbild av ett formulär går in, fält kommer ut, och inget OCR-steg ligger däremellan. Alla tre tillhandahålls från ScaleDowns eget API, vars dokumentation anger bas-URL:en som span>api.scaledown.xyz/span> och är tydlig med att span>api.scaledown.ai/span> inte är en API-värd.

Det enda numret som inte är som de andra

Prissättning är där dessa tre upphör att vara utbytbara. Classify listas till $0,05 per miljon indatatokens och $0 per miljon utdatatokens, och modellens listning i tredjepartskataloger visar samma pris med en kampanjrabatt som ibland tillämpas; rabatten är inte ett åtagande från ScaleDown och bör inte planeras utifrån. Nollpriset för utdata är inte ett marknadsföringsknep — en rubrikbedömd klassificerare avger etiketter och sannolikheter, inte genererad text, så det finns inget att fakturera för. Extract och Summarize genererar utdata, så deras kostnadsprofiler är inte jämförbara med Classifys och bör prissättas direkt från leverantören snarare än härledas från klassificerarens pris.

Classifys faktureringsdetaljer är svårare att resonera kring än det annonserade priset. I enetiketläge går varje etikett och dess bedömningsmall in i ett enda modellanrop, så varje etikett du lägger till ökar antalet fakturerade indatatoken; att be om en enradig förklaring av valet skickar dem igen till 2x, och dokumentationen säger tydligt att förklaringen genereras efter att toppetiketten har fastställts, så den motiverar svaret i stället för att ifrågasätta det. I fleretiketläge är varje etikett ett separat modellanrop, och varje chunk poängsätts separat. En taxonomi med sextio etiketter med resonemang aktiverat är därför inte en operation på 0,05 dollar per miljon token i den bemärkelse en läsare antar; det är den satsen multiplicerad med etikettuppsättningen, och sedan fördubblad om resonemang är aktiverat. De dokumenterade taken – 20 etiketter per begäran, 16 i fleretiketläge, 50 chunkar per batch – är de praktiska begränsningar man måste dimensionera mot.

Det finns ytterligare ett dokumenterat beteende som är viktigare än någon av dessa gränser. Klassificeraren "returnerar alltid en vinnare", även när ingen etikett passar. Konfidensfiltrering lämnas helt till anroparen. Vid en begäran med 10 etiketter kan en toppscore på 0,4 fortfarande vara rätt svar, eftersom poängen är relativa inom etikettuppsättningen snarare än absoluta. Varje produktionsanvändning av denna modell behöver en egen tröskelpolicy, och en uppsamlingsetikett — dokumentationen föreslår att man ger en namnet span>övrigt/span> — är inte valfri i praktiken.

Varför ett 1M-tokenfönster hos en klassificerare är det intressanta

Klassificeringsmodeller tar konventionellt korta indata. Anledningen är mekanisk: en klassificerare som poängsätts med en bedömningsmatris måste väga hela indata mot varje etiketts ja/nej-fråga, och kostnaden för att poängsätta ett dokument med hundratusen token mot tjugo bedömningsmatriser är tjugo fullständiga genomgångar av det dokumentet. ScaleDowns svar är 1M-fönstret plus batch-lagret — upp till 50 chunkar som poängsätts mot en delad profil i en enda förfrågan — och leverantörens påstående är att per-chunk-kalibrering är densamma oavsett om du skickar en chunk eller femtio, med den enda skillnaden att den delade profilen faktureras en gång per förfrågan.

Det påståendet är det man bör testa innan man bygger vidare på det. Det är också påståendet som gör modellen intressant: hela anledningen till att klassificera inne i applikationen i stället för vid kanten är att beslutet kan se hela kontexten — hela supporttråden, hela avtalet, hela det hämtade dokumentet — i stället för ett avkortat fönster. Om 1M-fönstret står sig vid dina indatastorlekar försvinner arkitekturfrågan (”behöver jag ett schema för chunkning och röstning?”) till stor del. Om det inte gör det har du en mycket billig klassificerare för korta indata och ett andra problem att lösa.

De påståenden som behöver en andra åsikt

ScaleDowns marknadsföring hävdar att uppgiftsspecifika små språkmodeller slår frontiermodeller i kostnad, hastighet och noggrannhet för högvolymigt repetitivt arbete, och citerar siffror, bland annat en modell med ungefär en halv miljard parametrar som når 91,7 % på en enkel klassificeringsuppgift mot 88,6 % för en modell med 72 miljarder parametrar. Det är leverantörens egna siffror och de har inte reproducerats oberoende: ScaleDown Classify ligger för närvarande utan poäng på de offentliga resultattavlorna, utan publicerade benchmarkrader från tredje part. Behandla noggrannhetsargumentet som en hypotes med en rimlig mekanism — gapet i sample-effektivitet mellan en ändamålstränad liten modell och en stor modell för allmänna ändamål inom en snäv taxonomi är verkligt och väl dokumenterat — inte som ett etablerat resultat.

Siffran för indata på 1M token är på samma sätt angiven av leverantören. Katalogposter från tredje part för modellen visar kontextlängden som ej tillämplig i stället för att upprepa siffran på en miljon token, vilket är en begränsning i katalogen snarare än en motsägelse, men det innebär att kontextfönstret inte har bekräftats utanför ScaleDowns dokumentation.

Var det här passar in om du redan kör en pipeline

Mönstret som dessa tre modeller är avsedda för är en loop, inte ett enskilt anrop: hämta ett dokument, klassificera det, extrahera fält, sammanfatta det och lämna sedan sammanfattningen till en generativ modell som skriver svaret. Steg fyra är det dyra per token, och det är steget som OrcaRouter täcker – fler än 200 modeller bakom en OpenAI-kompatibel nyckel till leverantörens listpris som förs vidare med 0 % påslag, med automatisk failover när en serveringsväg försämras. Vi hostar inte ScaleDown Classify, Extract eller Summarize; de finns inte i vår katalog och är inte ett mål för chat-completions, och routningslagret här är mönstrets genereringshalva snarare än bedömningshalvan.

Den uppdelningen är värd att säga rakt ut, eftersom den kostnadsjämförelse som folk kommer att ta till är missvisande. En klassificerare som poängsätts enligt en bedömningsmall för några cent per miljon indatatoken och en generativ modell för några dollar per miljon är inte konkurrenter; de är olika poster, och anledningen till att sätta en liten modell på klassificeringssteget är att det gör att du har råd med en bättre modell i steget som faktiskt skriver något.

Vad skulle förändra den här bedömningen?

Tre saker, i ordning efter hur mycket de skulle förändra bilden. En oberoende utvärdering av den bedömningsmatrispoängsatta klassificeringsuppgiften på ett offentligt benchmark skulle förvandla noggrannhetsargumentet från ett leverantörspåstående till en datapunkt. En publicerad latenssiffra – leverantören dokumenterar kostnadsdrivkrafter men ingen serveringslatens – skulle avgöra om 1M-fönstret är användbart vid genomströmning eller bara vid batchkörning. Och en tredjepartsreproduktion av påståendet om kalibrering per chunk skulle avgöra om en batch på femtio chunkar är en kostnadsoptimering eller en annan modell. Tills åtminstone en av dessa har fallit på plats är den ärliga sammanfattningen att ScaleDown har släppt tre modeller med ovanligt tydliga kontrakt och ovanligt stora indatagränser, till priser som gör ett tröskelbaserat klassificeringssteg tillräckligt billigt att överväga, och att siffrorna som stöder dem är leverantörens egna.

Den korta versionen

Om du har ett högvolymsteg för klassificering eller extrahering med en stabil taxonomi och text- eller bildindata är ScaleDowns tre modeller värda ett benchmark på dina egna data den här veckan, eftersom kontraktet är enkelt och indatagränsen generös. Budgetera för etikettmultipliceringen och 2x-tillägget för resonemang innan du bestämmer dig för en taxonomi, och räkna med att behöva skriva din egen konfidenströskel. Om din uppgift är öppen generering är inget av detta riktat till dig.

Modellval är också en fråga om vad som har gått fel tidigare: de dokumenterade AI-incidenterna och agentfelen bakom modeller i den här klassen samlas i OrcaRouter AI Incident Archive, där varje post har egna källor, allvarlighetsgrad, konfidensgrad och omstridd flagga.