Quick answer: SIE runs the same engine both ways. Put public filings on SIE Cloud, where you pay for what you use and Superlinked runs the GPUs. Self-host that engine on your own GPUs for client, portfolio and internal documents, with the same SDK and model IDs. Open weights, Apache 2.0, one API for OCR, extraction, embeddings and reranking.
A team spends a quarter building a self-hosted GPU cluster so that its 10-K processing never touches a third party. The cluster works. The 10-Ks are safe. Then someone notices that the portfolio notes and client memos, the documents nobody outside the firm should see, go to a hosted API through a different service that predates the cluster. The team had carefully encrypted documents the SEC publishes for free, and sent the confidential ones out the side door.
The mistake is common because "financial documents" sounds like one category. It is at least three. Public filings are public data. Client and portfolio documents carry obligations to someone else. Internal analysis carries your own competitive interest. Each class sets different requirements for where inference can run, and the cost and operations trade-offs only make sense once you know which class a workload belongs to.
The five steps below decide between self-hosted and managed inference for document workloads in finance, one class at a time. The guide makes no regulatory claims; the argument here is deployment control, cost and operations. Legal confidentiality, a vertical-neutral cost model and the step-by-step VPC deployment each have their own guide in this series.
Step 1: Classify documents before choosing infrastructure
Start with an inventory of what flows through the pipeline, grouped by who is entitled to see it:
Add volume per class and which tasks each class uses: OCR, extraction, embedding, reranking, generation. The table usually shows that public filings dominate the volume and private documents dominate the risk. Those two facts pull in different directions, which is why a single answer for the whole pipeline is often the wrong one.
Be precise at the boundaries. A public 10-K becomes client material once it is annotated with a client's position in that company. The document is public. The annotation is not.
Step 2: Work out what each class actually requires for privacy
For public filings, the privacy requirement for the document text is close to nothing. The SEC publishes them, EDGAR's full-text search covers electronic filings since 2001, and the data.sec.gov APIs serve the structured data without authentication. What may still be sensitive is the query pattern: which companies you are analysing, and when. Decide whether that matters to you. For many teams it does not. For a research firm it often does: the watchlist is the edge, and a log of queries against a handful of mid-cap filings in the week before a position is built says more about the book than any internal note.
For client and internal documents, the question is what you have promised and to whom. Read your client agreements and internal data policies, not general regulation, and write down the answer in plain terms: may these documents be processed by a third-party provider, in which regions, and under what terms? That answer, not the word "finance", decides whether managed inference is acceptable for that class.
This guide does not tell you what your obligations are. It tells you to find out per class, because the answer is rarely the same for all three.
Step 3: Compare cost on utilisation, not list prices
Managed and self-hosted inference are priced in different units, so compare them on the same workload:
Managed: you pay per unit processed, such as tokens, pages or pairs. Idle time costs nothing.
Self-hosted: you pay for GPUs by the hour, whether they are busy or not, plus the cluster around them. The effective cost per unit falls as utilisation rises.
Filings workloads are seasonal. Annual reports arrive in waves after fiscal year-ends, with 10-K deadlines of 60, 75 or 90 days depending on filer size, and quarterly reports follow 40 or 45 days after each quarter. Between waves, a self-hosted cluster sized for peak sits mostly idle unless it scales down.
A worked example. Every number here is invented for illustration; none is a Superlinked price, benchmark or customer result:
Self-hosted, always on: 2 GPUs × $2.50 per hour × 730 hours = $3,650 a month, busy or idle.
Actual load: 360,000 pages in the filing-season weeks plus 90,000 in the quiet weeks = 450,000 pages a quarter, or 150,000 a month. Effective cost: $3,650 / 150,000 = about $0.024 per page.
Managed at a hypothetical $0.01 per page: 150,000 × $0.01 = $1,500 a month. Self-hosting only matches it above 365,000 pages a month, before counting engineering time.
Change the inputs and the answer moves. A cluster that scales to zero between waves shrinks line 1; steady year-round volume raises line 2. Put your own volumes, GPU rates and utilisation into the same three lines, add the engineering time to run the cluster, and the crossover depends entirely on how steady your load is.
Step 4: Decide who is on call
Operations is the cost that spreadsheets leave out. Self-hosting means your team owns:
- GPU capacity and quotas in your cloud account
- Kubernetes, autoscaling and node pools
- model upgrades, rollbacks and security patches
- monitoring, alerting and incident response when inference stops during filing season
Managed inference moves those to the provider. What stays with you is integration, evaluation and the decision about what to send. Be honest about whether your team has the platform capacity to run a GPU service well. Running one badly is often worse than not running one, because failures arrive at the busiest time of the quarter.
Step 5: Design the hybrid
For many finance teams building document products, the answer after Steps 1 to 4 is a split:
- public filings on managed inference, where usage pricing absorbs the seasonal peaks
- client and internal documents on self-hosted inference, where your agreements require it
- one routing layer that assigns each document to a path based on its class, not on who wrote the calling code
- the same models, model IDs and client code on both paths, so results are comparable and a workload can move between paths without rework
- a periodic review of the split as volumes and agreements change
The fourth item is the one that decides whether the hybrid is cheap to run or a permanent source of drift. Two different stacks produce two different sets of answers, two evaluation runs and two sets of bugs.
Where SIE fits
SIE, from Superlinked, runs the same engine in both modes, which is what makes the hybrid in Step 5 practical. On SIE Cloud, Superlinked runs the GPUs: per the Cloud page, there are no idle GPUs and you pay for what you use, with SOC 2 Type 2 and US or EU data residency per Superlinked. Self-hosted SIE is Apache 2.0 and runs in your own VPC, which your team operates: it deploys to AWS, GCP or Azure with Terraform and Helm, and on Kubernetes (not plain Docker) scales to zero between jobs through KEDA. Scale-to-zero has its own cost. The first request after an idle spell waits while a GPU node comes up and the model weights load, so keep a warm minimum through filing season and let it drop to zero between waves. The self-hosting guide also covers air-gapped installs from mirrored model snapshots.
Both modes use the same SDK and model IDs, so the routing layer changes only the base URL:
from sie_sdk import SIEClient
public_path = SIEClient(api_key="sk-sie-…", base_url="https://api.superlinked.com")
private_path = SIEClient("http://sie.internal:8080") # your self-hosted cluster
client = private_path if doc.cls in ("client", "internal") else public_path
result = client.extract("docling", {"document": doc.payload})
The third mode is local: for development, the same models run on your own machine with pip install "sie-server[local]" and sie-server serve.
Honest take: SIE is built for this split. One API covers OCR, extraction, embeddings and reranking, and the same open weights run on SIE Cloud and on a self-hosted cluster. On Cloud, Superlinked runs the GPUs, you pay for what you use, and public filings can go there with US or EU data residency. Self-host the Apache 2.0 engine on your own GPUs, in your own VPC, for client and internal documents; prompts and documents stay on your infrastructure, and the model IDs match Cloud. Local mode runs the same models on a workstation while you develop. The choice of path stays reversible because both sides are the same engine.
FAQs
Does a managed provider see our documents?
Yes, in the sense that a managed service processes them. With SIE Cloud, documents are processed in Superlinked's environment, with US or EU data residency per Superlinked, and the Cloud page states SOC 2 Type 2 for the managed service. For public filings that is rarely a concern. For client and internal documents, check your agreements. If they rule out third-party processing, run those documents on self-hosted SIE, where prompts and documents stay in your own infrastructure.
At what utilisation does self-hosting start to pay?
There is no universal number, and anyone who quotes one without your workload is guessing. Compute it: take your monthly volume per task, the managed price per unit, your GPU hourly rate, and the utilisation you can actually sustain across the quarter, including the quiet weeks. Add the engineering time to run the cluster. Steady, high, predictable load favours self-hosting. Seasonal filing waves favour usage pricing, unless your cluster scales to zero between them.
Can we start managed and move later?
Yes, if you choose a stack that runs the same way in both places. Starting managed gets a product in front of users without building GPU infrastructure first, and the usage bill gives you real volume data for the self-hosting calculation. The risk is lock-in to an API that has no self-hosted equivalent. With SIE, Cloud and self-hosted share the same engine, SDK and model IDs, and the open-source repository is there to evaluate before you need it.
Put each class on its own path
The privacy argument in finance is real, but it belongs to client and internal documents, not to filings anyone can download. Classify first, compare cost on utilisation, decide who owns operations, and split the workload where the classes differ. The public-filings side can go on SIE Cloud this quarter, and the private side can follow later onto your own cluster with the same SDK and model IDs.
Top comments (0)