10 training runs · 2025-01 to 2026-12 ·
both treatments modelled side by side · synthetic data
Total training spend
$21.7M
10 runs, 2 abandoned
LTM EBITDA — expensed
$11.8M
LTM EBITDA — capitalized
$17.6M
Treatment difference
$5.8M
timing, not substance
Intangible NBV
$8.6M
24-mo useful life
The use case selects the framework, and it is assumed before
anything else: this model treats the trained model as
internal-use — it powers the company's own hosted service
and is never sold, licensed, or marketed as software. On that assumption,
ASC 350-40 applies: only application-development-stage cost qualifies, and
only once the architecture and training recipe are settled, management has
committed to completion and intends to deploy, technical feasibility is
established, and a determinable service life supports future benefit.
A different use case means a different framework, not a
different parameter. Software to be sold or marketed falls under
ASC 985-20, where capitalization runs only from technological feasibility to
general release — often a very short window that capitalizes far less.
Software used solely in R&D is expensed under ASC 730 with no
capitalization at all. And IFRS is not this arithmetic with another label:
IAS 38's six development criteria can produce a different qualifying cost
pool and a different capitalization start date than the US GAAP result.
The 35% of each run assumed to precede the
gates is expensed under both treatments; a run that never clears
them is expensed in full — which is what happens to the two abandoned runs
below. These are modelling assumptions stated so they can be argued with,
not accounting advice.
The identity that keeps both treatments
honest: over the full life of every run, expensing and
capitalizing charge exactly the same total to the P&L —
verified to the cent in --validate. Capitalization does not
reduce cost; it moves it later. That sentence is the entire defence
against capitalizing in order to improve EBITDA.
EBITDA under both treatments
The gap does not close — it widens, from
$1.8M over the first eight months to $3.2M over the
last eight. Amortization of older, smaller runs never catches up with
capitalization of newer, larger ones while spend is still accelerating, so
the flattering effect compounds instead of self-correcting. It reverses only
when training spend plateaus — which for a company at this stage means the
reversal lands in whichever year growth stops. (I predicted the opposite
when building this; the validation check disagreed, and the data was
right.)
Under capitalization this balance is an asset on the balance
sheet. It is also the exposure: if a model version is superseded faster than
its 24-month assumed life — routine in this field — the
remaining book value impairs. Two runs did exactly that here.
Training runs
Run
Started
GPU-hours
Total cost
$ / useful work unit
Status
v0.1-pretrain
2025-01
180,000
$0.89M
4.933
deployed
v0.2-pretrain
2025-04
240,000
$1.08M
3.877
deployed
v0.3-scaling
2025-07
410,000
$1.59M
2.908
deployed
v0.4-arch-probe
2025-09
190,000
$0.79M
2.902
abandoned
v0.5-pretrain
2025-11
620,000
$2.22M
2.312
deployed
v0.6-multimodal
2026-01
880,000
$3.01M
2.059
deployed
v0.7-longctx
2026-03
540,000
$1.88M
1.971
abandoned
v0.8-pretrain
2026-05
1,150,000
$3.80M
1.758
deployed
v0.9-distill
2026-07
320,000
$1.22M
1.919
deployed
v1.0-flagship
2026-09
1,640,000
$5.24M
1.523
deployed
Cost per run rises steadily while cost per unit of useful
work falls. Both statements are true, and quoting either alone is
misleading — the first is a budget conversation, the second is a capability
conversation, and they belong on different slides.