Every page is triaged at the edge. Only pages with no usable text layer cross
into the region, and only a page OCR cannot read reaches the vision model.
Nothing here calls anything else here — the edge hands results back to you,
and you decide what to send on. That is what makes the saving yours.
The servers
| Service | Where | Hardware | Models |
|---|
| liteparse-spin |
Akamai Functions, edge
01cb27a8….fwf.app |
WASM sandbox · 128 MiB, 30 s |
MiniLM-L6-v2 int8, for ?chunk=1 and /v1/embed-text; everything else is pdfium and Rust |
| liteparse-clip (edge) |
Akamai Functions, edge
4425cb59….fwf.app |
WASM sandbox · 128 MiB, 30 s
99.8 MiB peak |
MobileCLIP-S0 vision fp32, mounted not embedded |
| liteparse-ocr |
ocr.apps.sasriya.net |
g6-dedicated-8 · unthrottled CPU · 7 GiB |
PP-OCRv6 medium det + rec, PP-LCNet textline |
| liteparse-clip |
clip.apps.sasriya.net |
g6-dedicated-8 · 3 CPU · 5 GiB |
all-MiniLM-L6-v2, MobileCLIP-S0, Florence-2-base — all fp32 ONNX |
| liteparse-demo |
edgedoc.apps.sasriya.net |
shared pool · 1 CPU · 1 GiB |
none — orchestration and the index |
Two things this diagram is honest about
Everything here is CPU. No GPU is involved anywhere. That is the point:
the work that survives triage is small enough that ordinary machines finish it, and the
numbers on this page are what those machines actually did.
The vision model is shown, and not indexed. Florence-2 names a figure’s
shape reliably but invents its subject when the image carries no text — an unlabelled line
graph came back as “people who have been diagnosed with cancer”. Its output appears in
the pipeline so you can see the routing, and never enters the search index, where a confident
fabrication would be indistinguishable from a fact.