Snilld

Baidu lancerer Unlimited OCR: flad KV-cache til lange dokumenter

Ifølge MarkTechPost lancerede Baidu Unlimited OCR, en 3B MoE-OCR-model med Reference Sliding Window Attention, som ifølge forfatterne holder KV-cachen effektivt konstant og scorer 93,23 på OmniDocBench v1.5. Det er teknisk plausibelt og interessant for drift, men kræver uafhængige målinger før beslutninger.

25. juni 2026 Peter Munkholm

Ifølge MarkTechPost præsenterer Baidu Unlimited OCR, en 3 milliarder-parameter Mixture-of-Experts-model, hvor cirka 500 millioner parametre aktiveres ved inference. Hovedgrebet er Reference Sliding Window Attention, som ifølge forfatterne holder KV-cachen flad, når output bliver langt. Fint, hvis det holder. Kør tre målinger før POC-godkendelse: peak memory vs. T, ms per token over tid, og throughput ved 8 og 40 sider.

Pointen for drift er klar: lavere hukommelse og stabil step-tid kan gøre store PDF-bunker håndterbare. Hvis arkitekturen også leverer i praksis – det er her, testen begynder, ikke slutter.

Hvorfor KV-cache bider i halen

I en standarddecoder med multi-head attention gemmes keys og values for hver genereret token. Når outputlængden T stiger, vokser cachen og trækker både hukommelse og step-tid opad. Det ses som to kurver, der kravler: peak memory og tid per token. Lange end-to-end OCR-kæder på 40 eller 80 sider rammer muren her. Ikke magi, bare arkitektur.

Makrofoto af GPU‑heat‑sink og køleflade i en testrig med cyan/green kabelomslag; illustrerer hardware‑måling og hukommelsesbudget overvejelser.

Hvad Unlimited OCR påstår teknisk

Ifølge MarkTechPost bygger Unlimited OCR videre på DeepSeek OCR med en DeepEncoder foran et MoE-decoderdesign. Totalen er 3B parametre, og cirka 500M aktiveres per token, ifølge forfatterne. Der nævnes to encoder-tilstande: Base ved 1024×1024 til flersidet materiale og Gundam med dynamisk opløsning til enkeltsider.

DeepEncoder beskrives som en kaskade: en SAM-ViT under window attention og en CLIP-ViT under global attention, med 16× tokenkompression mellem dem. Ifølge MarkTechPost bliver et 1024×1024-input cirka 256 visuelle tokens, hvilket skærer i prefill-tiden før generering.

Banner

R-SWA uden pynt

Ifølge forfatterne lader R-SWA hvert genereret token se alle referencetokens (de visuelle tokens og prompten) plus de seneste n output-tokens, hvor n er 128 som standard. Ældre output fortrænges. Ifølge MarkTechPost beskrives cache-størrelsen som Lm + min(n, T). Det gør hukommelsesbudgettet forudsigeligt og – i teorien – fladt, når T bliver stor.

Det sigter også mod stabil per-step latenstid, fordi modellen ikke skal bære en voksende hale af gamle tokens. Visuelle tokens opdateres ikke undervejs, hvilket ifølge kilden undgår gradvis udvanding set i visse lineære opmærksomhedsformer.

Et tal-eksempel med plads til tvivl

Antag m = 2048 referencetokens og n = 128. Når T går fra 200 til 8.000, vokser cachen med T under standard-MHA. Med R-SWA holder den sig tæt på Lm + 128. For en flersidet PDF kan det være forskellen på at ramme out-of-memory sent i jobbet eller lande det på samme GPU. Tallene er illustrative; mekanikken følger MarkTechPost.

Teknikerens hænder ved en testplatform ved en scanner‑conveyor; et operationsøjeblik der viser at råmålinger er i gang.

Ydelse og benchmarks

Ifølge MarkTechPost scorer Unlimited OCR 93,23 på OmniDocBench v1.5 og slår DeepSeek-basen med 6,22 point. Det peger i den rigtige retning, men uden eval-scripts, seeds og detaljer om pre- og postprocessing er robustheden uklar. Små forskelle i pipeline kan flytte scoren markant.

Hvad flad hukommelse kan betyde i drift

Hvis R-SWA faktisk holder cachen flad, kan man planlægge mere aggressivt: flere samtidige jobs per GPU og færre sene fejl, fordi peak memory ikke kryber. I klynger kan det øge batch-udnyttelse. En jævn step-tid hjælper SLA’er på fakturaer, kontrakter og e-arkivering. Men total throughput afhænger også af MoE-routing og dens overhead – ifølge MarkTechPost mangler råtal her.

Omkostning, kort fortalt

Ifølge kilden aktiveres omkring 500M af 3B parametre per token, hvilket lyder billigere end at køre alle lag hver gang. Det kan sænke prisen per side, især når cache ellers ville eksplodere hukommelse og latenstid. Men MoE koster: router, eksperter og risiko for kø- eller hotspot-variance. Uden målinger forbliver TCO et gæt.

Nærbillede af cyan gulvmarkeringslinje med slidspor, symboliserer en stabil workflowbane i drift.

Testprotokol der kan bruges i morgen

Kør en lille, skarp pakke og gem rådata:

  • Peak memory vs. T: mål ved T = {256, 1024, 4096, 8192}. Forvent plateau under R-SWA efter et kort opsving.
  • Latenstid pr. 100/1000 tokens: kurven bør være flad efter opstart, ikke stigende.
  • ms per token: A100 80GB og H100 80GB, batch 1 og 4. Arbejdsmål: under 10 ms/token på A100 og under 6 ms/token på H100 ved batch 1 på lange outputs. Mål variation over 10 kørsler.
  • Throughput: batch = 1, 2, 4 på 8- og 40-siders dokumenter. Rapporter tokens/s, job/s og standardafvigelse.
  • MoE-variance: fordeling af experts per lag samt hotspots over N=20 runs på samme input.

De tal mangler i MarkTechPost, så de skal frem ved uafhængig kørsel.

Banner

Integration uden overraskelser

Start med mikrobenchmarks på egen hardware og plot step-tiden gennem hele genereringen. Test både Base og Gundam, da opløsning og kompression påvirker prefill og kvalitet. Gå derefter end-to-end på jeres dokumenttyper: flerspalte, tætte tabeller, dårlige scanninger. Registrér fejltyper og feltnøjagtighed.

Her snubler mange: felt-udfyldning ved sidebrud og krydshenvisninger. Et kort bagudvindue kan misse lange afhængigheder i outputstrømmen. Afprøv segmentering per side med overlap og forankr vigtige felter i referencetokens (for eksempel via layout-anchoring), så modellen ikke kun skal huske bagudvinduet.

Arkitektur og dataplacering

Planlæg prefill-strategier og tokenisering, så bagudvinduet bruges effektivt. Overvej sidevis segmentering med overlap for færre blindvinkler. Aftal tidligt om drift må ske i privat sky eller on-prem af hensyn til compliance. Hvis modellen kun findes som cloud-tilbud, kan det spænde ben for visse kunder.

Huller i materialet

Ifølge MarkTechPost er der ingen offentlige weights nævnt, ingen eval-scripts til OmniDocBench v1.5, og ingen rå målinger af hukommelse og latenstid. Der mangler også detaljer om træningsdata og MoE-routingens driftspåvirkning. Det øger risikoen for at planlægge på antagelser og opdage problemer sent.

R-SWA har desuden et indbygget tradeoff: alt ældre end n tokens kasseres i outputstrømmen. Længere krydshenvisninger kan glide. Hvor meget det rammer, afhænger af dokumenttypen – det måles, ikke antages.

Alternativer og tradeoffs

Ifølge MarkTechPost fungerer DeepSeek-basen som reference i den rapporterede score. Andre tilgange lever: simpel chunking med overlap er robust og nem at drifte, men kan misse krydsreferencer; recurrent memory og lineære varianter skalerer bedre, men kan kæmpe med nøjagtighed og stabilitet. R-SWA afviger ved enkelhed: fast bagudvindue og konstant adgang til kilden. Prisen er mulig tab af meget lange afhængigheder i output.

Næste skridt

Før produktion: 1) kør en uafhængig OmniDocBench v1.5-evaluering med dokumenteret setup, 2) byg en POC på et repræsentativt korpus og mål peak memory vs. T, latenstid vs. T samt fejltyper pr. layout, 3) gennemfør en sikkerheds- og deploymentscreening for dataplacering og logging. Bed samtidig Baidu om råmålinger, MoE-logs og adgang til model- eller eval-artefakter. Ellers flyver man i tåge.

Konklusion

Unlimited OCR adresserer et reelt problem på en teknisk plausibel måde. Ifølge MarkTechPost holder R-SWA KV-cachen flad og leverer en stærk OmniDocBench-score. Lovende, ja. Men de hårde kurver mangler. Mål først – beslut bagefter.

Kilder

    Gør brugeroplevelsen bedre.
    Hvilket firma arbejder du for?