Connected
Containers that phone home
The standard containers are not licensed to run without connecting to Azure for metering: an Azure resource, a key, and a billing endpoint are prerequisites for on-premises processing.
Why Private AI · Leaving Azure Document Intelligence
Document AI that answers to no meter.
Azure Document Intelligence is capable, and it is rented: metered by the page, connected for billing even in its containers. LM-Kit runs the same class of document work on your infrastructure, offline from day one.
On-premises, with an asterisk.
Microsoft ships Document Intelligence containers, and is clear that your document content stays local. What the fine print adds is everything around them.
Gated
Offline by application only
Truly disconnected containers exist behind a request form, an annual commitment plan, and a minimum of 100,000 pages per month. Air-gap is an enterprise program, not a download.
Metered
Economics by the page
Per-page pricing means every reprocessing run, every pipeline retry, and every experiment has a marginal cost that compounds exactly when document volume grows.
Facts from Microsoft's public container documentation at publication; check their docs for the current terms. Corrections are welcome through contact.
The same jobs, owned outright.
Capability by capability, where the workloads land when they move inside your walls.
| Capability | LM-Kit | Azure Document Intelligence |
|---|---|---|
| OCR | On-device OCR engines plus VLM-driven OCR, tuned for business documents | Read model, in the cloud or a connected container |
| Layout and structure | Deterministic layout understanding, tables, reading order, Markdown output | Layout model with tables and selection marks |
| Field extraction | Schema-driven extraction with per-field confidence; declare fields in code, no training run | Prebuilt models for invoices, receipts, and IDs; custom models trained in Azure |
| Adapting to your documents | Edit the schema and rerun; iteration is a code change | Custom model lifecycle: labeling, training, and versioned deployments |
| Where it runs | Inside your .NET process, or on your own server; offline from day one | Cloud, containers connected for metering, or gated disconnected containers |
| Cost model | No page meter: free to build and evaluate, Professional for larger production use | Per 1,000 pages, plus commitment tiers for disconnected use |
| Beyond extraction | Classification, splitting, redaction, digital signatures, PDF/A, and search with citations on the same engine | Focused on reading and extraction; adjacent work is other services |
| Form factor | Embedded SDK (LM-Kit.NET) or REST server (LM-Kit One), one engine | REST service with SDKs |
The custom model, without the training run.
Extraction here is a schema you declare, not a model you label, train, and redeploy. Confidence comes back per field.
ExtractInvoice.cs
using LMKit.Data; using LMKit.Extraction; var extractor = new TextExtraction(model); extractor.Elements = new() { new("Vendor", ElementType.String, "Supplier name."), new("Invoice Date", ElementType.Date, "Date of issue."), new("Total", ElementType.Double, "Grand total due."), }; extractor.SetContent(new Attachment("invoice.pdf")); var result = extractor.Parse(); foreach (var element in result.Elements) { Console.WriteLine($"{element.TextExtractionElement.Name}: {element} ({element.Confidence:P0})"); }
A fair way to decide.
One question settles most cases: can your documents, and your economics, depend on a metered connection?
Stay on Azure DI
The Azure estate fits
Your documents already live in Azure, per-page pricing suits the volume, and the prebuilt models cover the exact document types you process.
Move to LM-Kit
The documents stay home
Compliance, air-gap, or economics rule out a metered cloud dependency, and you want extraction, redaction, signatures, and archival on one private engine.
Private Document Intelligence