The situation
A product team building analytics on high-volume sensor telemetry wanted a foundation model. Not a forecasting feature, not a better model for one flagship site — a foundation model. The phrase had arrived before the requirements did.
The idea itself was sound: pre-train one backbone on years of multi-variate time series from a large population of physical assets, then adapt it cheaply to each new customer site instead of building a bespoke model per deployment. Real-time event detection for operations; probabilistic short-horizon forecasts for planning. A real product shape.
What was missing was a number. Leadership heard “foundation model” and priced it off frontier-lab headlines: GPU fleets, nine-figure training runs, a hiring plan they could not fund. Engineering heard the same phrase and could not say what it would cost either — because nobody had scoped what “foundation model” actually meant at this size, in this domain. The project was stuck in the worst possible place: too exciting to kill, too unpriced to fund.
This public version is deliberately anonymized. Client name, industry, exact data sources, commercial terms, and proprietary modeling choices are removed. The numbers shown are rounded and based on public cloud list prices.
Do you really need to pre-train — or will an adapted model do?
Before anyone buys a training cluster, the first filter is blunt. Most teams that say “foundation model” need one of the first two rows, not the third.
- Use an existing model as-is when a published time-series foundation model (the TimesFM / Moirai / Chronos family, or a well-tuned statistical baseline) already beats your current forecasts on your own held-out data. Prove it does not before spending further.
- Fine-tune someone else’s backbone when your domain is close enough to public pre-training corpora and your differentiation is the product around the forecast — alerting, planning, operational response — not the weights.
- Pre-train your own backbone only when your signal structure is genuinely unrepresented in public models, you have (or can assemble) a large domain corpus, and per-customer adaptation speed is itself the product.
This team had a legitimate claim on the third row: dense multi-variate telemetry with strong cross-channel physics that generic univariate models handle poorly — and a SaaS model where onboarding a new site in hours, not months, was the pitch. Fine. But “legitimate claim” and “priced decision” are different things. Our job was the second one.
What “foundation model” actually meant here
Here is the part that unlocked the whole engagement. Everyone in the room was pricing the phrase, not the artifact. So we sized the artifact.
| Everyone’s mental model | What the domain actually required |
|---|---|
| Tens of billions of parameters | ~85M parameters — a patch-based transformer encoder in the PatchTST / TimesFM lineage |
| Trillions of tokens, scraped at great expense | A few billion tokens, the large majority from public research archives and open sensor datasets |
| Months on a GPU megacluster | ~4 days on 32 A100s (four 8-GPU nodes, mixed precision, masked-patch pre-training objective) |
| Nine-figure CAPEX | A pre-training run in the low five figures. On-demand cloud list prices put the full run at roughly $13–15K — rerunnable from scratch for less than one month of a senior engineer |
| Expensive per-customer models | ~$3 per site. LoRA adapters (~1.2M trainable parameters against a frozen backbone) fine-tuned in under two hours on a single mid-range GPU instance |
| A permanent GPU fleet | Steady-state serving in the low thousands per month at initial fleet size: a small autoscaling real-time endpoint for event detection, an async endpoint for planning forecasts, and the surrounding data pipeline |
Read that table again, because it is the case study. The CAPEX fear was wrong by roughly four orders of magnitude — and in the opposite direction from the usual AI-infrastructure story. We have run the mirror-image engagement too, where a team casually proposed trillion-token-per-day inference without noticing they were describing a nine-figure annual operation. The disease is the same in both directions: pricing the vocabulary instead of the workload.
So why did the experiment stall?
Because pre-training was never the risk. Twenty-plus years of infrastructure work teaches you that compute is the most honest line item on any plan — it does what the invoice says. The dishonest line items are everywhere else, and they are what actually stopped this project:
Nobody owned the forecast heads. The architecture shipped two products in one model — real-time event detection and probabilistic planning forecasts. Which one paid the bills? Which SLA came first? Which customer segment was the design center? Those are product decisions, and no amount of encoder layers answers them.
The data the model needed most was the hardest to get. Public corpora carry the pre-training, but the per-site adapters — the entire commercial promise — depend on customer operational telemetry: access agreements, sensor quality, status flags that mean different things at different operators. The data plane was 80% of the real engineering and 0% of the excitement.
Evaluation had no owner. We specified the harness in detail — skill scores against persistence baselines, calibration metrics, event-detection F1 with hard promotion gates, shadow deployments mirroring production traffic. A quality gate without a named owner who can block a release is decoration.
“Foundation model” was doing organizational work, not technical work. The phrase was recruiting energy and board attention. Once we priced it at conference-booth money, it could no longer carry that weight — and the project had to stand on its product merits. That was uncomfortable, and clarifying.
The public architecture pattern
The anonymized view keeps the shape without client detail.
- A data plane that lands raw telemetry and external context signals into a versioned lake, with feature engineering and normalization stats stored where inference can reach them.
- One pre-trained backbone, versioned and registered — pre-training is an occasional, cheap, repeatable batch job, not a standing operation.
- Per-tenant adapters as the unit of customer onboarding: small, fast to train, isolated per customer, promoted only through evaluation gates.
- An evaluation harness on the release path — offline suite plus live shadow scoring against actuals — with thresholds that can halt a promotion without a meeting.
- Serving split by product semantics: a low-latency real-time endpoint for event detection, an async path for planning forecasts, batch transform for backtesting.
The CAPEX anatomy
The deliverable leadership actually used was one table: where the money goes, one-off versus recurring, and which line items scale with customers.
| Line item | Shape | Rough scale | Scales with |
|---|---|---|---|
| Backbone pre-training | One-off, rerunnable | Low five figures per run | Corpus size, rarely |
| Per-site adapter fine-tune | Per onboarding | Single-digit dollars | Customer count |
| Real-time + async serving | Recurring | Thousands per month | Traffic and fleet size |
| Data plane (ingest, ETL, storage) | Recurring | Hundreds to low thousands per month | Site count and signal density |
| Data engineering and integration | People | The dominant real cost | Every new telemetry vendor and feed |
| Evaluation, MLOps, on-call | People | The second dominant cost | Model and customer count |
The pattern generalizes: for domain foundation models, compute is a rounding error and people are the platform. Any plan that prices the GPUs to three significant figures and hand-waves the data engineering is a plan written to be approved, not executed.
What we’d tell you before you start
- Size the artifact, not the phrase. “Foundation model” spans six orders of magnitude of cost. Yours has a specific parameter count, corpus, and training bill — compute them before the board meeting, not after.
- Run the adapt-vs-pretrain bake-off first. A week of evaluating published time-series backbones against your held-out data is the cheapest de-risking you will ever buy.
- Name the owner of the evaluation gate before you name the model. If nobody can block a promotion, you do not have quality gates; you have dashboards.
- Budget the data plane as the main event. Model code was a fraction of this architecture; ingest, alignment, normalization, and per-customer data agreements were the bulk.
- Let a cheap answer kill the mystique. Once pre-training costs less than a team offsite, the project must justify itself as a product. That is a feature of the analysis, not a bug.
What this public version leaves out
The working material included the full model specification, hyperparameters, the exact corpus inventory, the distributed training configuration, the evaluation thresholds, per-service cloud sizing, and the staged roadmap with procurement lead times. Even the industry stays out. What remains is the pattern: a team paralyzed by an unpriced ambition, an artifact that turned out to be startlingly affordable, and the real costs living in data, evaluation, and ownership — exactly where nobody was looking.
Outcome
The experiment did not become a product, and we count the engagement a success anyway — because the team stopped burning quarters on an unpriceable idea. They left with a complete, costed reference architecture; a build-vs-adapt decision framework grounded in their own data; and a board-safe narrative that separated a five-figure training run from the six-figure-per-year operating commitment around it. Deciding not to build yet, with numbers, is a legitimate outcome. Deciding by exhaustion is not.
If you are facing a similar decision
If someone in your organization has said “foundation model” and nobody can attach a number to it — in either direction — this is the work we do: size the artifact, price the platform, and turn vocabulary into a decision.
- AI build — when the decision is made and you need the data plane, training pipeline, and serving built by people who have operated production ML.
- Architecture / fractional CTO advisory — when the question is whether to build at all, and the board needs numbers instead of headlines.
- Free first consultation — when the shape of the work is still open.
Bring what you know: your signals, your data access reality, your customer onboarding promise, and the forecast that actually earns revenue. We will tell you plainly whether an off-the-shelf model embarrasses your plan, whether fine-tuning covers it, or whether you are one of the rare teams that should own a backbone.