The Lifecycle of LLMs
Industrial-scale to build, consumer-grade to own — why AI models break the product-lifecycle curve, and what that means for the enterprises betting on them.
I usually write about lifecycle management for physical products: industrial platforms, product architecture, configuration, engineering, manufacturing, service, and the long operating system required to turn product complexity into business value.
But the lifecycle of large language models is too interesting to ignore.
Partly because I have been experimenting and building with AI a lot myself. Partly because LLMs expose something that industrial leaders should recognize immediately: lifecycle economics matter even more when the clock accelerates.
Every product has a lifecycle.
For physical products, this is almost intuitive. You invest in development. You launch. You scale. If the product works, you enter maturity: the long, profitable harvest window where the early investment finally pays back. Eventually, decline arrives. Sometimes slowly. Sometimes brutally. But usually with enough warning to manage it.
LLMs have a lifecycle too.
But it runs on a different clock.
They compress the entire product lifecycle into months while keeping the capital intensity of heavy industry. That is the strange economic contradiction at the heart of today's AI boom: these models cost like industrial platforms, scale like software, commoditize like consumer electronics, and expire like fashion.
For enterprises building on AI, this is not a technical curiosity.
It is an operating condition.
The Inverted Curve
The classic industrial product lifecycle is patient.
A company invests heavily in product development, absorbs negative cash flow, manages introduction, then grows into maturity. Maturity is the prize. It is where the platform stabilizes, volumes improve, operational learning compounds, margins expand, and the business finally harvests the value created by the early investment.
In Maximizing Value Through the Product Lifecycle, I argued that lifecycle value is not created at launch. It is created by managing the full system around the product: development, introduction, growth, maturity, decline, and renewal. PLM matters because it connects data, people, processes, systems, and decisions across those stages.
LLMs break that curve.
The development cost is not smaller than a traditional industrial product. It is larger. Frontier models require massive data curation, architecture design, training infrastructure, specialized accelerators, high-end engineering talent, energy, evaluation, safety testing, and post-training. Training a frontier model is closer to a semiconductor fab, aircraft platform, or new vehicle architecture than to normal software development.
And yet the commercial shelf life is short.
A flagship model that took months of compute and tens or hundreds of millions of dollars to produce may have only six to twelve months of premium commercial life before it is overtaken, repriced, or deprecated. Often, the model is not killed by a competitor. It is killed by its own successor.
You spend like a heavy-industry manufacturer and harvest like a fashion label.
Figure 1 — The same five-stage lifecycle on two clocks: the LLM invests more deeply, harvests in months rather than years, and sees profit collapse while usage stays high.
Five Stages, One Short Clock
The LLM lifecycle still maps to familiar product lifecycle stages.
The distortion is not the sequence. It is the time compression and the economics inside each phase.
1. Pretraining: Development
Pretraining is the capital sink.
This is where the base model is created. The work includes collecting and filtering vast datasets, deduplicating content, selecting model architecture, defining parameter scale, training across thousands of GPUs or accelerators, and managing the brutal operational complexity of running large-scale compute for weeks or months.
Financially, this is pure negative cash flow.
There is no product revenue yet. There may not even be certainty that the model will be good enough. The team is converting capital, compute, data, and engineering judgment into a statistical machine that may or may not become commercially useful.
In industrial language, this is product development with extreme tooling cost and uncertain yield.
2. Fine-Tuning, Alignment, and Release: Introduction Preparation
The base model is not the product.
After pretraining, it must be fine-tuned, aligned, evaluated, and packaged into something useful, safe, and commercially deployable. A pretrained model can predict language, but that does not make it a dependable assistant, coding partner, reasoning engine, support agent, enterprise copilot, or embedded component.
This stage includes supervised fine-tuning, instruction tuning, reinforcement learning from human or AI feedback, safety work, red-teaming, benchmark testing, refusal behavior, policy tuning, tool-use integration, latency optimization, and product release preparation.
This stage used to look like a refinement layer. It is now a major source of differentiation.
The frontier is no longer just about who can train the biggest base model. It is about who can turn raw capability into a usable system. For enterprise adoption, that distinction matters.
Nobody buys a pile of parameters.
They buy dependable performance in a workflow.
3. Launch and Inference Scaling: Growth
When the model launches, the curve can turn almost vertical.
Unlike industrial products, distribution does not require factories, dealers, logistics networks, spare-parts programs, or field-service capacity. A model can reach millions of users through an API, app, or platform integration almost instantly.
But growth comes with a different cost burden.
Once adoption scales, the main economic pressure shifts from training to inference. Every prompt, completion, API call, agent step, image generation, code request, or embedded workflow consumes compute. The model may be "software" from the user's perspective, but every interaction has a marginal cost.
This is where the early profit picture becomes messy.
Revenue can scale quickly, but so can runtime cost. If demand spikes before optimization catches up, success itself becomes expensive. Growth is attractive, but not automatically profitable.
4. Optimization and Commoditization: Maturity, Compressed
Traditional maturity is when products become economically beautiful.
Volume stabilizes. Processes improve. Cost comes down. Quality improves. The business harvests.
LLMs also enter maturity, but the phase is compressed and unstable.
The engineering focus shifts from raw capability to efficiency: quantization, distillation, caching, routing, batching, smaller specialist models, context optimization, hardware utilization, and serving cost reduction. The objective is simple: deliver similar capability at lower cost and higher speed.
This can create a short window of strong economics. The model is proven, adoption is real, infrastructure is optimized, and unit cost falls.
But the same forces that improve margin also destroy defensibility.
Capability gets cheaper. Open-weight alternatives improve. Smaller models catch up. Competitors match performance. Pricing falls. Customers learn to switch. The model moves from frontier product to workhorse component.
That is the LLM maturity paradox: optimization creates profitability, but commoditization erodes it almost immediately.
5. Deprecation and Renewal: Decline
LLMs rarely decline because they physically degrade.
They decline because the market moves around them.
A newer model is more capable, cheaper, faster, safer, easier to fine-tune, better at tool use, better at reasoning, better at multimodal tasks, or simply better packaged. The older model becomes too expensive for its capability level. It may still work perfectly well, but it no longer deserves premium economics.
Eventually, the provider deprecates the model. API endpoints are retired. Customers are migrated. Weights are archived. Capabilities are distilled into the next generation.
This is decline without death.
The model does not vanish. It becomes part of the knowledge base of the portfolio. It may survive as a smaller derivative, a fine-tuned variant, an open-weight community model, an internal benchmark, or a teacher model for distillation.
In industrial terms, the retired model becomes both spare part and engineering memory.
Figure 2 — Five stages, one short clock: cost, revenue, risk, and management focus across the LLM lifecycle.
The Economics Run Backwards
The uncomfortable part is not just that LLMs move fast.
It is that the two main economic clocks move in opposite directions.
Training cost rises.
Inference price falls.
Public estimates put GPT-4 training compute at roughly $78 million and Gemini Ultra at roughly $191 million. Other analyses suggest that the cost of frontier training runs has been rising around two to three times per year, with the largest runs potentially crossing a billion dollars within the next few years.
At the same time, the price of achieving a fixed level of model capability is collapsing. Stanford's AI Index reported that the cost of querying a model at roughly GPT-3.5-level performance fell from about $20 per million tokens in late 2022 to about $0.07 per million tokens by late 2024.
That is not normal price erosion.
That is industrial-scale investment colliding with consumer-electronics depreciation.
This creates a scissor effect.
One blade moves upward: the cost of creating the next frontier model.
The other blade moves downward: the market price for a given level of capability.
Between those blades sits the harvest window.
And that window is shrinking.
In a traditional product lifecycle, the maturity phase is where the business earns back the investment. For LLMs, that phase is squeezed by constant capability jumps, rapid price erosion, open-weight competition, and self-cannibalization by the next model release.
The commercial logic is brutal: if you wait too long to replace your own model, someone else will do it for you. If you replace it too quickly, you cannibalize your own economics.
That is not a product lifecycle.
That is a treadmill with a balance sheet attached.
Figure 3 — Development cost rising ~2.4× per year against inference prices falling an order of magnitude per year.
The Counterargument: The Model Is the Wrong Unit
There is a fair counterargument.
Maybe the individual model is not the right unit of analysis.
In industrial companies, a single product variant rarely carries the entire business case. Value sits in the platform, architecture, product family, manufacturing system, supply base, service model, installed base, and renewal pipeline.
This is the same portfolio logic behind Maximizing Value Through the Product Lifecycle. Lifecycle value is not something you squeeze out of a single product. It is something you expand through the system around it: innovation, service, operational scaling, ecosystem expansion, and renewal.
The same is true for LLMs.
A single model may have a short commercial life, but the model family can compound value over time. Each generation benefits from the previous one. Data pipelines improve. Evaluation sets mature. Post-training methods get better. Infrastructure becomes more efficient. Distillation transfers capability forward. User behavior informs the next release.
Seen this way, the value does not disappear.
It migrates.
It moves from the individual model to the model factory.
This connects directly to the lifecycle argument I keep returning to: durable value rarely sits in one product release. It sits in the capability to keep renewing the portfolio while protecting the system around it.
For AI labs, that system is the frontier model pipeline.
For enterprises, it should be the AI operating model.
Decline Without Death
Traditional decline is often wasteful.
Old products are maintained reluctantly. Spare parts linger. Engineering knowledge fades. Platforms become legacy burden. Documentation becomes archaeology with nicer formatting.
LLMs decline differently.
A retired model can still contribute to the next generation. Its outputs can support synthetic data generation. Its behavior can inform evaluations. Its capabilities can be distilled into smaller, cheaper models. Its failures can become test cases. Its weights may remain available internally or, in open-weight ecosystems, continue living through fine-tunes and community variants.
This makes the LLM lifecycle more circular than linear.
Pretraining creates capability. Fine-tuning and alignment package it. Deployment tests it against reality. Optimization compresses cost. Deprecation transfers learning forward. Renewal begins again.
The loop is continuous.
The model dies commercially, but its capability does not fully die technically. It is absorbed into the portfolio.
This mirrors the renewal logic from Maximizing Value Through the Product Lifecycle: decline does not have to mean waste. Managed deliberately, it becomes a source of reuse, knowledge transfer, and the next cycle of innovation.
The sequence is familiar.
The speed is not.
Figure 4 — Decline without death: distillation feeds a retired model's capability into the next generation, while its weights pass into cold storage.
What This Means for Enterprises Building on AI
For enterprises, the conclusion is simple and uncomfortable:
Do not confuse the model with the system.
The model is a component. A powerful component, but still a component. It will improve, cheapen, expire, and be replaced. If your enterprise architecture treats today's model as a stable foundation, you are building rigidity into the fastest-moving layer of the stack.
The strategic question is not "Which model should we pick?"
That question matters, but only temporarily.
The better question is:
How do we build the capability to keep replacing models without breaking the business process around them?
Three implications follow.
1. Treat model selection as a sourcing decision, not a permanent architecture decision
A model should be selected like a critical supplier or technology component.
Match it to the workload. Understand its cost structure. Track performance. Monitor roadmap risk. Avoid unnecessary lock-in. Build abstraction layers. Keep switching costs visible. Do not hard-wire business logic to one model version unless you enjoy recreating single-supplier risk in digital form.
This is where the logic from Balancing Innovation and Execution across the Product Value Chain applies directly.
In that post, I described how different execution models, from Make-to-Stock to Engineer-to-Order, reflect different trade-offs between efficiency, flexibility, cost, lead time, and customization. The same logic applies to AI workloads.
Not every use case deserves a frontier model.
Some need a cheap classifier.
Some need low-latency summarization.
Some need private deployment.
Some need configurable domain adaptation.
Some need a fine-tuned specialist.
A few may justify a frontier reasoning model wrapped in strict workflow controls.
The point is not to use the most powerful model everywhere. The point is to match model capability to workload economics, risk, and business value.
The architecture should allow model substitution.
If replacing the model means rebuilding the process, the architecture is wrong.
2. Be a sophisticated integrator, not a frontier-model romantic
Most enterprises should not train frontier models.
That game belongs to a handful of players with extreme capital, talent, infrastructure, and risk appetite. For everyone else, the durable advantage is not the foundation model itself. It is the proprietary context around it.
The defensible assets are enterprise data, workflow knowledge, process integration, domain-specific evaluation, governance, user experience, change management, and the digital thread connecting decisions across the value chain.
This is also the central idea behind Balancing Innovation and Execution across the Product Value Chain: value is created, delivered, and sustained across a chain, not inside one isolated function. Product Portfolio Management, Sales & Quotation, Design & Engineering, Supply Chain Planning, Manufacturing, Service Operations, Retirement, and Renewal all create data and insights that fuel the next stage.
In AI, the equivalent system is made of data pipelines, prompts, tools, retrieval layers, workflow integrations, evaluation sets, guardrails, user feedback loops, and operating governance.
That is where AI becomes enterprise capability rather than a demo.
The model can summarize, reason, generate, classify, retrieve, and automate. But the business value comes from embedding those abilities into how products are developed, sourced, manufactured, serviced, renewed, and retired.
The value is not in owning the engine.
The value is in designing the machine around it.
3. Govern the lifecycle before your supplier governs it for you
Model deprecation will not wait for your steering committee.
Vendors will retire models on their own calendars. Pricing will change. API behavior will shift. Safety policies will evolve. Context windows will expand. Latency will improve. Tool-use patterns will change. Open-weight alternatives will appear. Regulators will catch up, slowly and then loudly.
Enterprises need a model lifecycle discipline.
That means maintaining a model inventory, knowing where each model is used, tracking versions, monitoring cost and quality, testing replacements, validating outputs, managing fallback logic, documenting risk, and planning migrations before deprecation notices arrive.
This is not IT hygiene.
It is operational resilience.
And it is the AI version of a broader PLM principle: if the lifecycle is not managed deliberately, it will still happen, just badly.
If AI becomes embedded in core workflows, model lifecycle management becomes part of enterprise lifecycle management.
The Management Discipline
The winners in enterprise AI will not be the companies that picked the best model in 2026.
That advantage will last about as long as a slide titled "AI Strategy Roadmap" remains accurate, which is to say not long enough to justify the slide.
The winners will be the companies that build the discipline to absorb model change continuously.
They will design modular AI architectures. They will separate business logic from model logic. They will use evaluation as a management system, not a lab exercise. They will treat prompts, context, tools, data pipelines, and workflows as managed assets. They will make model replacement normal rather than exceptional.
This is where AI strategy becomes less glamorous and more important.
The durable capability is not prompt writing.
It is lifecycle governance.
It is knowing which models are used where, why they are used, how they perform, what they cost, what risks they introduce, when they must be replaced, and how the enterprise can replace them without breaking the process.
In short, enterprises need to stop treating AI adoption as a one-time implementation and start treating it as lifecycle management.
Closing Thought
The model you build on today may be deprecated within a year.
That is not a risk to wait out.
It is the operating condition.
LLMs do not eliminate lifecycle management. They make it more important. They compress the clock, invert the economics, and force enterprises to separate what expires from what endures.
The model expires.
The system around it should not.
The winners in enterprise AI will not be the ones who picked the perfect model. They will be the ones who built the capability to keep replacing it without losing the value they created around it.
That is the same conclusion behind my earlier posts on lifecycle value and the product value chain: sustainable value comes from connecting innovation, execution, operations, service, retirement, and renewal into one managed system.
Lifecycle management is not an IT initiative.
It is a business discipline.
AI just made the clock run faster.