Interfaze 1 Lite: the mixture of architectures is ten public checkpoints and a tool loop

mdjsonmcpcopy↗ai

2026-10-06 · 17 min · ocr · document-parsing · open-weights · multimodal · tool-calling · calibration · asr

Interfaze announced interfaze-1-lite as "the first general open-weight model for deterministic work": OCR, speech-to-text, extraction and classification, with "confidence scores and metadata like bounding boxes on every run". The second post in the thread names the design: "Mixture of Architecture (MoA)", where "each specialist model is a dedicated architecture built to solely process a single task", and the whole thing runs on one H100.

That is a claim about structure, and structure is checkable. A Hugging Face repo is a list of files with sizes and SHA-256 hashes, every safetensors file starts with a JSON header naming each tensor's shape, and the routing code ships alongside because the model needs trust_remote_code=True. I read all of it without downloading the 44 GB of weights, then read the GitHub server that wraps it. No third-party code was executed.

What "mixture of architectures" means here

Start with what it is not. A mixture of experts is one network whose feed-forward layers are split into experts, with a learned router choosing a few per token, trained end to end. Nothing in interfaze-1-lite is trained jointly, and there is no learned router. The routing is a 27B vision-language model deciding which tools to call, the way any tool-calling agent does.

The model card says as much, plainly: "Interfaze 1 Lite is not one network. It is a reasoning core plus specialists, each chosen for the task it is best at, connected by tool calls." The launch blog draws it the same way.

expand

What the diagram does not say is where the specialists come from. The card's architecture table describes each by type only ("Vision-language model trained for page reading", "Encoder-decoder speech recognizer"). The configuration file goes further and says it on purpose: the capability-to-component mapping "is supplied by the deployment (COMPONENT_<CAPABILITY>), so this file declares which capabilities exist without naming what provides them."

The names are elsewhere, in three places that agree:

• The card's closing "Thank you" credits "inspiration from these models": Qwen3.8 27B, Chandra OCR 2, Whisper large-v3 turbo, pyannote's speaker-diarization-community-1, SAM 2.1, Llama Guard 3, TimesFM 2.5, and PaddlePaddle's PP-OCRv5 detection, PP-OCRv5 recognition and PP-DocLayout.
• The GitHub repo's components.env.example lists the defaults "the hosted interfaze-1-lite runs": COMPONENT_BRAIN=Qwen/Qwen3.8-27B-FP8, COMPONENT_OCR_VLM=datalab-to/chandra-ocr-2, COMPONENT_ASR_FALLBACK=openai/whisper-large-v3-turbo, and so on through COMPONENT_FORECASTER=google/timesfm-2.5-200m-pytorch.
• The bundle's own config files: brain/config.json declares Qwen3_5ForConditionalGeneration, asr_fallback/config.json declares WhisperForConditionalGeneration, the Paddle folders carry "model_name": "PP-OCRv5_server_det", "en_PP-OCRv5_mobile_rec" and "PP-DocLayout_plus-L", and segmenter/config.yaml builds a sam2.modeling.sam2_base.SAM2Base with a Hiera trunk of stages [2, 6, 36, 4].

"Inspiration" undersells it. The Hub API returns the LFS SHA-256 of every large file. I pulled the same listing for the ten upstream repos and compared hashes. 76 of the bundle's 79 LFS files are byte-identical to an upstream file (measured): 44.23 GB of the 44.27 GB of large files. The three that differ are the banner image and two tokenizer.json files; the document reader's is one byte longer than Chandra's. Every weight file is someone else's checkpoint, unmodified.

That is not a criticism of the engineering. It is a correction to the framing, and it has a licensing edge worth knowing. The repo is tagged Apache-2.0 and ships one LICENSE file, while Chandra OCR 2's card declares license: openrail and pyannote's diarization pipeline is gated on the Hub (measured, from the two file listings). The configuration docstring itself says bundled mode comes with "the obligation to carry every upstream licence"; read each upstream licence before you build on the bundle. "Each specialist model is a dedicated architecture built to solely process a single task" is true. It is also true that none of them was built by Interfaze.

Folder by folder

The bundle has one folder per component. Counting parameters from the safetensors headers takes two range requests per file: 8 bytes for the header length, then the header itself.

The numbers, with how each was obtained:

• brain/: Qwen3.8-27B-FP8, 27.78B parameters (measured from 66 headers: 64 per-layer shards, outside.safetensors and mtp.safetensors). Of those, 24.70B are FP8 E4M3 with 128x128 block scales and 3.08B stay BF16. 0.46B are the vision encoder and 0.43B the multi-token-prediction layer. 30.89 GB on disk. My sum is 27,781,427,952, exactly the figure the Hub's metadata gives for Qwen/Qwen3.8-27B-FP8.
• ocr_vlm/: Chandra OCR 2, 5.30B parameters, BF16, 10.61 GB (measured). Its config is the same Qwen3.5-family hybrid as the brain at half the width: 32 layers, hidden size 2560.
• asr_fallback/: Whisper large-v3 turbo, 0.81B, FP16, 1.62 GB (measured). 32 encoder layers, 4 decoder layers.
• segmenter/: SAM 2.1 Hiera-Large, 0.90 GB; 224M parameters per its upstream repo's metadata (reported).
• layout/, line_detector/, line_recognizer/: PaddlePaddle inference files, about 32M, 22M and 1.9M parameters (reasoned: .pdiparams bytes divided by 4 for float32).
• diarizer/: pyannote's segmentation and embedding models plus a PLDA transform, about 8M parameters together (reasoned, same way).

The brain is 70% of the bundle by bytes (reasoned). Its text stack is Qwen3.8-27B's hybrid design, the one Cinference's speed claim turns on: 64 layers, of which layer_types marks 48 as linear attention and 16 as full attention, one full layer in every four (measured from brain/config.json). That is what the card means by "hybrid-attention decoder", and why it warns that without flash-linear-attention, "generation slows to minutes per page".

Two specialists are not in the bundle

config.json sets "bundle_weights": true, and the loader's docstring says what that means: "component weights live in this repo under the prefixes below." The configuration code lists eleven capabilities, guard and forecaster among them. The file listing has no guard/ folder and no forecaster/ folder (measured). moderate() needs Llama Guard 3 1B and forecast() needs TimesFM 2.5; neither ships.

Reading _repo(), a bundled load of either asks snapshot_download for guard/* or forecaster/*, gets an empty pattern match, and hands the path to from_pretrained. I expect that to fail, but I did not run it, so treat it as unverified. The Docker path in the GitHub repo avoids the question: it pulls each component from its upstream repo and requires an HF_TOKEN because, in its own words, "the diarization and guard models are gated". The card's "Self-contained. One repository, one GPU, runs offline" holds for OCR, speech, detection and chat. It does not hold for the two capabilities whose weights are gated or absent.

One more thing is optional. The config keeps a list of "the 25 languages the fast recogniser TDT v3 covers", and components.env.example names nvidia/parakeet-tdt-0.6b-v3 behind ENABLE_FAST_ASR=1. Off by default, so the default speech path is Whisper alone.

The orchestration is the product

If the weights are borrowed, the work is the Python around them: 4,552 lines in the bundle's nine .py files and 9,329 in the GitHub server's package (measured, wc -l). Some of it is careful.

The tool loop. chat() runs agent.run: the brain sees the user's files as ref-0, ref-1, … and four tools, ocr, stt, object_detection and gui_detection. It gets up to six tool-calling turns. If a file is attached and the brain answers without calling anything, it is reminded once ("answered by eye, the text is invented"). The images themselves are shown to the brain only after a tool has read them: "shown an image first, the model transcribes it by eye and invents text." Every tool's full result goes back to the caller as precontext, next to the answer.

Direct calls skip the brain. ocr(), transcribe(), moderate() and forecast() never load the 27B core; components load lazily on first use, so "a caller who only wants OCR never pulls the 28 GB brain." For the deterministic jobs the announcement leads with, the reasoning core is not in the loop at all.

Detection is the brain, segmentation is SAM. detect() prompts the brain to write boxes as text on a 0-1000 grid, parses them, and passes each box to SAM 2.1 for an outline. ground() is the brain alone, tiling large screenshots. RefCOCO's 83.8 (reported) is therefore a Qwen3.8 score with a prompt and a parser around it (reasoned: ground() and detect() boxes come from the brain alone).

Speech is Whisper with its own guards. Audio past 120 s is cut at quiet points into windows of at most 30 s and decoded 16 at a time; the card reports a 95-minute recording in about 90 seconds. Speaker labels come from pyannote, with each word assigned to the turn it overlaps most. The comments are worth reading: greedy decoding alone "looped '5-5-5' for 60 s of a card number", so the code restores Whisper's reference-decoder fallbacks. The site's piece on Whisper's hallucinations covers why those guards exist, and Nemotron 3 Diarization covers the speaker side.

OCR: two readers, one page

OCR is where the design earns its keep, and it is the one place the confidence claim is fully backed. Three jobs run on every page at once: Chandra OCR 2 reads the page, the PP-OCRv5 detector and recognizer find and read every line, and PP-DocLayout labels the blocks.

expand

The division of labour, from the stitch() docstring: "the reader owns the page's text -- reading order, tables, structure -- and the detector owns every box and confidence." Chandra emits HTML with data-bbox attributes, but the code does not trust those boxes: on portrait pages they "came back squeezed toward the left", and matching by position "dropped 62 of a memo's 98 lines". So lines are matched by what they say. For each detector line, PageText.read searches the reader's flattened text with rapidfuzz.partial_ratio_alignment, widens the hit to whole words, and accepts it at a fuzzy score of 88 or more (100 for lines of four characters or fewer). Best matches claim their span first, so three near-misses cannot all take the same "Dependent 1". A line with no match keeps the recognizer's own text.

There are pragmatic guards on top. A page whose mean line confidence falls below 0.75 is re-read at a denser pixel budget, up to about 8.4 MP; images under about 2.1 MP are read at twice their size, after a phone photo of a receipt came back with "EARBUDDS" and "DIL" for OIL. These are numbers measured by the authors on their own documents and written into comments (reported).

Where the confidence comes from

The confidence on each OCR line is the PP-OCRv5 recognizer's rec_score for its own reading of that line crop (measured from line_runtime.py and _detect_text_lines). That is a legitimate, roughly calibrated signal; it is what made classic OCR pipelines gateable. It comes from a recognizer with about 1.9M parameters.

Two details follow from the code, and both matter if you gate on it.

First, the score is for the recognizer's text, and the line shows the reader's text. When the stitcher replaces a line's words, it keeps average_confidence=line.average_confidence. A long line is accepted at a fuzzy-match score of 88 out of 100, so the two readings can disagree on several characters and the line still carries the recognizer's score for its own version. A reply under the launch post made this point; it is correct as written.

Second, in the released code, word scores are not per-word. split_words() divides the line's box among its words by character count and gives each word confidence=confidence, the line's own value. That applies to stitched lines and to the detector's raw lines alike. The launch blog's worked example shows something richer, so try the two views:

In the blog's output (reported, from the hosted API), the withdrawal line's words score 0.99, 0.99, 0.92, 0.99 and 0.42. Their mean is 0.862 (reasoned), which rounds to the line's 0.86, and the gate at 0.9 sends that one row of ten to a person. The row-level gate works the same with the open code. The per-word explanation does not: run locally, all five words would read 0.86 (measured from split_words, not run). The hosted service may compute word scores differently; the GitHub server's package has the same split_words and I found no other source of word scores in it.

Confidence elsewhere

"Confidence scores … on every run" is an OCR claim. Elsewhere in the code:

• transcribe() returns timestamps and no confidence. Its language_detected carries "confidence": 1.0, hard-coded.
• detect() and ground() return boxes with no score; SAM's mask scores are read into _scores and dropped.
• forecast() keeps TimesFM's point forecast and discards the quantiles in the same way.
• moderate() is the exception: it computes unsafe_probability from the guard's softmax over the words "safe" and "unsafe" and only blocks at 0.8 or above, because plain file requests "came out unsafe S8 at 0.59-0.73".

How "deterministic" is meant

The blog's definition is about the task, not the arithmetic: work "where there's one right answer", with outputs read by an if statement rather than a person. Its table puts "Same input, same output" under consistency.

The code does decode greedily. Every generate() call on the brain and the guard passes do_sample=False, and the vLLM path sends "temperature": 0.0 to the document reader. That is despite brain/generation_config.json shipping Qwen's sampling defaults (do_sample: true, temperature 1.0, top-k 20), which the code overrides. The brain also runs with enable_thinking=False.

Greedy is not the same as bitwise reproducible. Floating-point reductions depend on batch composition and kernel choice, so the same input in a different vLLM batch can flip a near-tie token; a reply under the launch post asked exactly this and got no answer. And Whisper's guards are a temperature ladder, (0.0, 0.2, 0.4, 0.6, 0.8, 1.0): a window that looks like a loop or scores below a log-probability of -1.0 is re-decoded with sampling, which varies run to run unless seeded (reasoned). "Deterministic" here means typed outputs, greedy decoding and a schema. It is not a reproducibility guarantee, and nothing in the repo claims one.

The benchmarks

expand

All of these are reported: Interfaze scored Lite itself "with each benchmark's official scorer" and took every other model's score from its own leaderboard. I re-ran none of them. Two things are worth knowing before you quote them.

The comparison set changes between documents. The model card compares against Claude-Sonnet-4.6 and Gemini-3-Flash; the blog compares against Claude-Sonnet-5 and Gemini-3.7-Flash. On olmOCR-Bench, the card's best rival is Grok-4.3 at 81.9, and the blog's is Claude-Sonnet-5 at 83.5. Lite's own numbers are the same in both. The context window also varies: 131k tokens in the card, 128k in the blog, and max_context: 262144 in config.json.

Since the weights are public, the fair baseline is each component alone. On the olmOCR leaderboard, Interfaze lists Chandra OCR 2 by itself at 84.3% and Lite at 83.8% (both reported, same page). Lite's OCR is Chandra OCR 2 plus the Paddle stitcher, and the stitched pipeline scores half a point below its own document reader. By category, Lite gains on tables (88.8 against 87.9) and old scans (51.3 against 49.2), and loses on headers and footers (90.0 against 92.5), long tiny text (91.9 against 93.9) and multi-column pages (80.1 against 81.3). Datalab's own card reports Chandra 2 at 85.8 ± 0.8 in its harness (reported). The stitcher is not there to raise the text score; it is there to attach boxes and scores, and on this benchmark that costs a little.

The same reading applies to the reasoning rows. Lite's GPQA Diamond of 85.9 comes from byte-identical Qwen3.8-27B-FP8 weights; Qwen's card reports 89.2 for Qwen3.8-27B (reported). The gap is plausibly the enable_thinking=False setting I found in the transformers path, but the evaluation harness is in a separate repository I did not read, so that is a guess (reasoned). And VoxPopuli's 3.01% WER is Whisper large-v3 turbo's number with long-form windowing.

Jina-OCR-v1 is the other OCR release I have taken apart at the header level; the difference is that its new piece was a trained speculative-decoding head, and here there are no new weights at all.

What it costs to run

The card's hardware line is one 80 GB GPU with compute capability 8.9 or newer. The loader's comments put numbers on that. Through transformers, the FP8 brain is dequantized to BF16 because the FP8 kernels "computed nonsense" on a receipt question, "for about 54 GB of memory" (reported). 27.78B parameters at 2 bytes is 55.6 GB (reasoned), so that checks out. Add the 10.6 GB document reader and a chat that touches both holds about 66 GB of weights before activations or KV cache (reasoned). It fits; it is not roomy, and the card itself warns that large PDFs "can spike in significant use of CUDA memory". The vLLM path in the GitHub repo keeps the brain in FP8 and is the one to use for throughput.

The API alternative is priced at $0.85 per million input tokens and $1.50 per million output tokens (reported).

What I'd take from it

The useful idea here is old and sound: let a general model plan and write, and let small specialist models do the perception, because the specialists already produce the metadata a pipeline needs. A 1.9M-parameter line recognizer gives you a per-line score that a 27B VLM does not. Interfaze's stitcher, which matches text by content rather than trusting a VLM's boxes, is a good piece of engineering with honest comments about what broke.

What it is not is a new model. "Mixture of Architecture" names a deployment: ten public checkpoints, eight of them in one repo, wired together by a tool loop and a few thousand lines of careful glue. If you want the confidence scores, call ocr() directly, gate on the line score, and remember whose reading that score belongs to.

Sources, read on 2026-10-06: interfaze-ai/interfaze-1-lite (model card, config.json, every component config, modeling_interfaze_lite.py, contracts.py, agent.py, guard.py, and the safetensors headers of brain/, ocr_vlm/ and asr_fallback/ via HTTP range requests); InterfazeAI/interfaze-1-lite (components.env.example, docker-compose.yml, README.md); the Hub file listings of Qwen/Qwen3.8-27B-FP8, datalab-to/chandra-ocr-2, openai/whisper-large-v3-turbo, facebook/sam2.1-hiera-large, PaddlePaddle/PP-OCRv5_server_det, PaddlePaddle/en_PP-OCRv5_mobile_rec, PaddlePaddle/PP-DocLayout_plus-L, pyannote/speaker-diarization-community-1, meta-llama/Llama-Guard-3-1B and google/timesfm-2.5-200m-pytorch; the launch blog, the leaderboards and the olmOCR board. Figures are reproduced for commentary from Interfaze's launch blog and thread; the two interactives are original.