Introduction
AI accelerators compete across silicon architecture, memory, networking, packaging, systems, compilers, libraries, frameworks, orchestration and developer support. Public filings describe competition based on performance, energy efficiency, integration, ease of use, workload optimisation, software ecosystems, roadmaps and supply [6-16]. MLCommons benchmark rules show why comparison requires defined models, scenarios, accuracy constraints, system descriptions and availability status [1-5]. A single peak specification cannot capture this operating system.
The transaction problem is therefore economic and technical. A buyer needs to know which workloads the target can run, at what latency and throughput, with what accuracy, power, memory and engineering burden, and whether those results can be reproduced by customers. It must also know whether the software stack supports new models, whether customers can migrate from incumbent platforms, whether deployments can scale across clusters and whether the business can deliver its roadmap through supply and capital constraints.
This paper is designed for strategic buyers, private-equity investors, corporate-development teams, founders, lenders and investment committees. It provides a system for diligence, valuation, deal terms and integration. It does not provide engineering, legal, tax, accounting, regulatory or investment advice. Each transaction requires current specialist review of products, contracts, benchmarks, source code, intellectual property, supply arrangements, security, export controls and customer evidence.
1 Define the acquisition perimeter before pricing the platform
An accelerator target may own processor architecture, chiplets, memory interfaces, boards, systems, compiler technology, kernels, runtime software, model-serving tools or vertical applications. The legal entity may control only part of the product customers use. The buyer should map the full system while identifying the assets and obligations that will transfer at closing.
The asset map should connect patents, design files, verification environments, firmware, compilers, libraries, model integrations, benchmark scripts, telemetry, customer contracts, cloud images, supply agreements and trained teams. Each asset should have an owner, revision, dependency and evidence of use. A performance demonstration can show potential. It should remain distinct from a reproducible customer deployment with contracted economics.
The acquisition perimeter should also distinguish products from services. Engineering support, model conversion, kernel optimisation and deployment assistance can accelerate adoption while hiding software gaps. Revenue that depends on bespoke engineering has different durability and margin from revenue generated through a stable platform. The model should identify the labour, tooling and customer-specific work required for every material deployment.
Proposed diligence architecture; value depends on conversion from controlled technology to accepted customer economics.
| Value layer | Claimed asset | Minimum evidence | Principal transaction risk |
|---|---|---|---|
| architecture | processor, memory and interconnect design | controlled design, verification history, measured silicon and ownership map | benchmark advantage depends on an unreleased configuration |
| software | compiler, runtime, kernels and libraries | source control, release history, test coverage and workload support | customer performance depends on manual optimisation |
| systems | boards, racks, networking, cooling and orchestration | qualified bill of materials, telemetry and support records | component bottlenecks erase chip-level advantage |
| adoption | design wins, cloud availability and production use | contracts, usage, acceptance and renewal evidence | evaluations are counted as recurring demand |
| economics | price, service burden, margin and cash | invoice, cost, credits, support hours and collection | hardware revenue conceals uneconomic enablement work |
Proposed diligence structure; technical claims should reconcile to controlled repositories and customer records.
2 Benchmark customer workloads rather than peak specifications
Peak operations per second describe a theoretical rate under defined precision and conditions. Customer value depends on the workload, model, batch size, sequence length, accuracy target, latency requirement, concurrency, memory footprint and software configuration. A benchmark should therefore be treated as a controlled experiment, not a universal statement about product value.
MLCommons separates system types, availability categories, benchmark models and deployment scenarios [1-5]. Its documentation describes accuracy validation, latency tracking, load generation and result review. These controls provide a useful diligence pattern. The buyer should preserve the complete system description, benchmark code, compiler flags, model version, data, power boundary, run logs and result checks for every claimed advantage.
The test plan should include representative customer workloads. Training, batch inference, interactive inference, retrieval, recommendation, vision and scientific computing can stress different resources. Performance may change with model size, sparsity, precision, memory bandwidth, communication pattern and requested service level. A target that leads one workload can remain commercially valuable, but the valuation should follow the relevant addressable workload rather than extrapolate across the whole AI market.
Benchmark reproducibility is a governance question. The buyer should rerun material claims on controlled systems, compare vendor-optimised and portable implementations, and test sensitivity to software versions. It should document warm-up, caching, quantisation, batching and excluded failures. Results should be presented as a range with the conditions required to reproduce them.
Benchmark provenance should extend to the underlying models and data. The diligence team should record whether weights are public, licensed or customer-controlled; whether the model was modified; which accuracy or quality tests were applied; and whether preprocessing or postprocessing work is included in the measured interval. It should retain container images, dependency manifests, firmware, drivers, compiler versions and machine configuration. A result that cannot be recreated after a routine software update is weak transaction evidence. The buyer should also test a neutral implementation where practical. Vendor-tuned code can show the platform's attainable performance, while a portable implementation can reveal the engineering burden required to reach it. Both views matter because customer economics depend on the path from ordinary deployment to optimised production.
3 Reconstruct performance under load and over time
AI serving systems operate across a curve. High concurrency may improve aggregate throughput while increasing per-user latency. Low latency may require underutilised capacity. Long prompts, large models, retrieval steps and variable outputs can change the balance. MLCommons Endpoints describes measurement across throughput, interactivity, time to first token and concurrency [3]. A transaction model should connect this curve to customer service levels and realised price.
Management assumes an illustrative system delivers 118 thousand equivalent tasks per hour at a high-throughput operating point. It assumes a 15% reduction for customer model mix, a further 11% reduction for latency commitments, 8% for operational availability and 6% for software and data overhead. The resulting saleable throughput is approximately 76 thousand equivalent tasks per hour. These assumptions demonstrate the method and do not describe an identified company.
Volumes and conversion rates are management assumptions used solely to demonstrate the method.
| Evidence state | Required evidence | Valuation treatment | Common overstatement |
|---|---|---|---|
| specification | published architecture and supported precision | technical context only | peak rate treated as application throughput |
| laboratory run | controlled system, code, logs and accuracy | evidence for the tested configuration | selected run treated as normal production |
| reproducible benchmark | independent rerun across relevant scenarios | workload-specific performance range | one model applied across the addressable market |
| customer pilot | target workload, service level and operating record | programme option after remaining work | proof of concept counted as recurring use |
| accepted production | contracted use, telemetry, invoice and collection | evidenced operating value | booked capacity treated as consumed demand |
Proposed classification; the buyer should use target-specific workloads, systems and service levels.
The buyer should test degradation as the system ages and software evolves. New model architectures can expose unsupported operators, memory limitations or communication overhead. Driver and framework updates can improve performance while introducing regression risk. Performance evidence should therefore be dated, versioned and connected to the product roadmap.
Operational availability should include maintenance, failures, deployment errors and recovery. A system with high benchmark speed can deliver weak economics when utilisation is interrupted or support demands are high. The model should reconcile scheduled capacity, successful jobs, billable units, service credits and collections.
4 Price performance per dollar, per watt and per rack
Customers buy useful work within constraints. Performance per dollar captures acquisition or rental price. Performance per watt captures energy cost and power availability. Performance per rack captures facility density, networking and cooling. Each measure can change the preferred platform. The buyer should identify which constraint governs each customer segment and location.
The cost boundary should include accelerators, CPUs, memory, networking, storage, chassis, power conversion, cooling, software, support and migration. A lower-priced chip can create a higher system cost when it requires more nodes, engineering or networking. A high-priced platform can produce strong customer economics when utilisation, software coverage and time to deployment are superior. The valuation should be based on total delivered economics rather than component list price.
| Item | Central case | Downside case | Diligence focus |
|---|---|---|---|
| realised platform revenue | USD 46,000 | USD 39,000 | contract duration, usage and price resets |
| silicon, memory and board cost | USD 20,500 | USD 22,800 | yield, allocation, mix and warranty |
| networking, software and support | USD 9,200 | USD 12,700 | system content, licences and engineering burden |
| migration and deployment allowance | USD 3,300 | USD 5,800 | model conversion, tuning and customer acceptance |
| contribution before fixed cost | USD 13,000 | negative USD 2,300 | sustainable utilisation and service intensity |
All values are management assumptions per annual equivalent deployed accelerator and demonstrate the method only.
Power should be measured at the relevant boundary. Chip power, board power, server power and facility power are different measures. Cooling, networking and idle capacity can materially affect cost. The buyer should examine metered evidence and the operating point at which it was recorded. It should also test whether performance improvements rely on aggressive power settings that customers cannot sustain.
Facility constraints can create strategic value. An accelerator that delivers more accepted work inside an existing power envelope can defer data-centre capital. That value depends on workload reproducibility, system availability and integration. It belongs partly to the customer or buyer and should not automatically be capitalised into the target's stand-alone value.
5 Value compiler maturity and software reach as operating assets
NVIDIA describes CUDA and a broad set of libraries, frameworks, SDKs and APIs as part of its technology stack [6-10]. AMD describes ROCm, customer support and an expanding data-centre portfolio [11-14]. OpenXLA, LLVM, ONNX and major frameworks illustrate the importance of compiler infrastructure, model representation and portability [21-25]. These sources show the dimensions of software value. They do not prove equivalent maturity across platforms.
Compiler diligence should cover front ends, intermediate representations, graph optimisation, code generation, kernel selection, debugging, profiling, numerical correctness and hardware scheduling. The buyer should review supported operators, model coverage, release cadence, regression history and time required to enable new architectures. It should identify which performance comes from reusable compiler capability and which comes from hand-tuned customer work.
Software reach includes documentation, installation, cloud images, containers, orchestration, security updates, observability and support. Developer adoption should be evidenced through active production use, releases, issue resolution, contributor quality and customer retention. Download counts, repositories and community activity can provide context. They should not be treated as recurring economics without customer evidence.
Proposed evidence chain; each layer should be tested for portability, reproducibility and customer use.
Software maturity should enter valuation through measurable economic effects. It can improve time to deployment, utilisation, customer conversion, support cost and renewal. The model should avoid a broad platform premium unsupported by programme evidence. It should link each software capability to a customer cohort, remaining investment and observable outcome.
Source-code diligence should examine architecture, maintainability, testing, security, release automation and third-party obligations. The buyer should identify code that is owned, permissively licensed, restrictively licensed, customer-provided or dependent on confidential interfaces. Build reproducibility should be tested from a clean environment. Critical components should have named maintainers, review history and recovery plans. Technical debt can be economically material when each new model or chip requires extensive manual intervention. The valuation should distinguish remediation required to sustain current revenue from discretionary investment intended to expand the platform. Open-source participation can strengthen adoption and recruitment, while creating compliance, disclosure and governance obligations that need separate review.
6 Measure migration cost before assuming customer conversion
Migration involves more than recompiling code. Customers may need to convert models, replace unsupported operations, retune kernels, change precision, validate accuracy, rebuild containers, modify schedulers, retrain teams and redesign monitoring. They may also need to duplicate infrastructure during transition. The buyer should measure this burden by workload and customer.
The migration plan should start with an inventory of models, frameworks, custom operators, data pipelines, serving systems, security controls and service levels. Each item should receive a portability assessment, remediation plan, responsible owner, test and acceptance gate. The cost model should include customer engineering, target support, delayed use and parallel operation.
Switching cost can support retention while limiting growth. A target may have strong customers because it solves a valuable problem or because leaving is expensive. The buyer should distinguish product advantage from dependency. It should also assess whether acquisition by a platform owner changes customer trust, neutrality or willingness to share workloads.
Migration incentives should be treated as acquisition cost when they are required to win business. Free engineering, credits, hardware discounts and capacity guarantees can accelerate adoption while reducing realised price. The revenue bridge should show gross bookings, incentives, accepted use and collected cash.
Migration capacity should be modelled as a constrained delivery system. Specialist engineers, access to customer models, validation environments and production windows may limit the number of programmes that can move at the same time. A large pipeline can therefore convert slowly even when customers express interest. The buyer should estimate engineering hours, elapsed time, acceptance cycles and support intensity by workload type. It should identify reusable tools and learning that reduce later migration cost. The forecast should cap conversion at the demonstrated delivery capacity until funded hiring, automation or partner support is available. This approach prevents a sales pipeline from being converted into revenue faster than the target can technically deliver and customers can operationally accept.
7 Test design wins, customer concentration and usage quality
An accelerator design win can mean technical evaluation, approved-vendor status, reserved capacity, initial deployment or committed volume. The diligence vocabulary should assign a defined evidence requirement to each state. A press release or memorandum of understanding can support strategic context. It should not be valued as contracted cash.
The buyer should reconcile pipeline records with contracts, orders, telemetry, invoices, credits and collections. It should identify the customer entity, workload, product version, deployment site, service level, price, minimum commitment, cancellation rights and acceptance conditions. Forecast volume should be separated from installed, available, consumed and billable capacity.
Concentration should be measured across customers, workloads, cloud channels, system partners and common economic parents. Several programmes can depend on one hyperscaler or one model family. A customer can also have leverage through qualification, capacity funding or software contribution. The valuation should test the loss, delay or repricing of each material relationship.
| Programme state | Evidence | Valuation treatment | Required protection |
|---|---|---|---|
| evaluation | test plan, system access and responsible teams | limited option value | cost cap and decision date |
| technical selection | written selection and remaining conditions | programme option after migration cost | objective acceptance gates |
| deployment | installed system, telemetry and support plan | probability-weighted operating value | capacity and service obligations |
| accepted use | service-level compliance, invoice and collection | evidenced cash-flow value | renewal and pricing controls |
| scaled renewal | recurring use across periods or workloads | durable customer value after concentration test | continuity and change-of-control plan |
Proposed framework; probabilities and conversion periods require target-specific evidence.
Usage quality matters. A deployment may run below planned utilisation because models, data or customer demand are delayed. It may run at high utilisation with weak margins because support and power costs are underpriced. The investment committee should receive customer-level unit economics rather than a single installed-capacity figure.
8 Map fabrication, memory, packaging and networking dependencies
Accelerator performance depends on fabrication, packaging, HBM, substrates, networking, system integration and power delivery. Open Compute Project specifications illustrate modular accelerator and system interfaces [26]. UCIe, memory and interconnect standards provide additional context [27-29]. Public foundry and packaging disclosures describe continuing investment and technical complexity [30-32]. The target's roadmap should be tested against these dependencies.
The buyer should inspect wafer agreements, packaging allocation, memory supply, board manufacturing, component qualification, change control, priority, pricing, minimum purchase, warranty and second-source status. A supplier name on a plan does not establish accessible capacity. The model should use executed rights, dated readiness and demonstrated yield.
Networking and communication can become the system bottleneck as clusters scale. The test plan should measure collective operations, congestion, failure recovery and workload scaling. A chip-level advantage can disappear when software or fabric overhead rises. The valuation should therefore include system-level performance and the capital required for the promised configuration.
Supply commitments can create both value and liability. Prepayments and take-or-pay obligations may secure capacity while consuming liquidity if demand moves. Customer-funded capacity can reduce capital needs while creating priority, refund or exclusivity terms. The buyer should show each commitment by product, period, counterparty and change-of-control consequence.
9 Value the roadmap as a sequence of evidence gates
Accelerator roadmaps move through architecture, simulation, tape-out, first silicon, bring-up, software enablement, system qualification and customer acceptance. Each gate has different probability, remaining cost and timing. A roadmap slide should not receive full operating value before evidence supports conversion.
The buyer should maintain one integrated hardware and software roadmap. Silicon delivery without compiler, framework and system readiness can delay revenue. Software may mature after launch and improve performance. The forecast should state the version required for each customer programme and the resources needed to deliver it.
Roadmap value can be modelled as a set of programme options. Each option should have a defined product, workload, customer cohort, expected cash, probability, remaining investment and earliest decision date. Shared costs and dependencies should be allocated once. The model should prevent the same future capability from appearing in both terminal growth and separate option value.
Terminal value should reflect the capability to deliver successive products, not one favourable generation. The buyer should assess architecture reuse, team continuity, verification assets, software portability, supplier access and customer trust. A rapid cadence can support value when prior gates have been achieved with controlled cost and quality.
10 Build the valuation from accepted workload economics
The stand-alone valuation should begin with customer-level cash flows. Revenue should be driven by accepted deployments, consumed or contracted units, realised price and renewal. Costs should include silicon, memory, systems, software, support, migration, warranty, capital and working capital. Scenario analysis should combine performance, utilisation, price, power and roadmap timing.
Management assumes five accepted customer cohorts with a present value of USD 890 million, four scaled deployment options worth USD 430 million, four technical selections worth USD 220 million and four roadmap options worth USD 180 million. It then deducts USD 190 million for customer concentration, USD 120 million for migration support and USD 270 million of remaining roadmap capital. A platform allowance of USD 540 million produces the assumed stand-alone enterprise value of USD 1.68 billion. All amounts are management assumptions.
All amounts are management assumptions in USD millions and do not describe an identified company.
| Programme state | Cohorts | Illustrative probability | Average present value per cohort | Probability-weighted value |
|---|---|---|---|---|
| accepted use | 5 | 100% | USD 178m | USD 890m |
| scaled deployment | 4 | 80% | USD 134m | USD 430m |
| technical selection | 4 | 50% | USD 110m | USD 220m |
| roadmap option | 4 | 25% | USD 180m | USD 180m |
| gross programme value | 17 | mixed | mixed | USD 1,720m |
Values and probabilities are management assumptions for method demonstration only.
Market multiples can provide a reasonableness check after comparability is established. Revenue quality, hardware content, software maturity, gross margin, capital intensity, customer concentration and roadmap risk differ materially across accelerator businesses. A platform multiple should not be applied merely because the target uses AI terminology.
The model should separate stand-alone value from buyer-specific value. Distribution, supply access, cloud reach, system integration and software optimisation may create synergy. Their value depends on buyer resources, implementation cost, customer response and competition constraints. The seller should not receive full payment for synergy that only the buyer can produce.
Financing analysis should reflect the volatility and capital needs of the platform. Debt capacity should be based on recurring, accepted cash flow after supply commitments, warranty, support and roadmap investment. Backlog, reservations and customer forecasts should be classified by enforceability and cancellation rights. A lender may require liquidity for tape-outs, inventory, capacity deposits and customer migration before revenue is collected. The downside case should combine delayed deployment, weaker realised price, higher support cost and continued roadmap spending because these pressures can occur together. Acquisition finance should include covenant headroom and funding for the integration plan rather than assuming that headline EBITDA is immediately distributable.
11 Build buyer-specific synergy with accountable delivery plans
Synergy can arise from procurement, packaging allocation, networking, cloud distribution, software integration, customer access and reduced duplicated cost. Each initiative should have a baseline, owner, resources, timing, dependency and measurable cash outcome. A label such as ecosystem leverage is insufficient for valuation.
Technical synergy should be tested through defined workloads. Combining a target accelerator with a buyer compiler, interconnect or system can improve performance, utilisation or deployment time. The model should include integration cost and the risk that customers reject a closed or changed platform. Results should be measured against the signing baseline.
Revenue synergy requires customer evidence. A buyer channel may expand access while creating conflicts with customers that compete with the buyer. The model should identify customers, offers, sales cycles, migration support and capacity. Broad percentage uplifts should remain outside the central case unless supported by programme plans.
Cost synergy should preserve critical capability. Removing duplicated engineering without understanding compiler, verification, support and customer dependencies can damage the platform. The integration plan should distinguish removable corporate cost from product work required for roadmap and reliability.
12 Choose a transaction structure that matches evidence maturity
A full acquisition can support integrated product and distribution decisions while concentrating roadmap and customer risk at closing. A staged acquisition can link ownership and consideration to silicon, software or customer gates. A minority investment can secure learning and commercial rights while preserving neutrality. A joint venture can combine complementary assets while creating governance complexity. A licensing or supply agreement can provide access without acquiring the company.
| Structure | Suitable evidence state | Buyer control | Principal protection | Principal limitation |
|---|---|---|---|---|
| full acquisition | accepted use, durable rights and integration plan | high | conditions, indemnity, retention and covenants | upfront exposure to roadmap and concentration |
| staged acquisition | strong technology with remaining customer or software gates | high after milestones | milestone consideration and call or put mechanics | future pricing and governance complexity |
| minority investment | developing platform with learning value | limited | information, consent and participation rights | limited authority over capital and execution |
| joint venture | complementary silicon, software or distribution assets | shared | contribution, field, funding and deadlock rules | divided authority and IP leakage risk |
| licence or supply agreement | need for access with limited ownership rationale | contractual | scope, service levels, continuity and audit | supplier remains responsible for execution |
Proposed decision framework; legal, tax, accounting and regulatory consequences require specialist advice.
Contingent consideration can bridge uncertainty when the metric is measurable and buyer control is addressed. Relevant gates may include benchmark reproducibility, compiler coverage, accepted deployment, usage, gross margin or roadmap delivery. The agreement should define configuration, evidence, measurement period, customer changes, capital commitments, accounting, audit and dispute resolution.
Governance should protect the asset before full control. Information rights, funding obligations, roadmap decisions, IP use, customer neutrality and related-party transactions should match the structure. The buyer should avoid receiving competitively sensitive customer information beyond its legitimate rights.
13 Address competition, interoperability and platform neutrality
The US Merger Guidelines discuss transactions involving platforms, complements, interoperability and access to inputs [37-39]. An accelerator acquisition can affect developers, cloud providers, customers, system partners and competing hardware. The buyer should identify where the target supports multi-platform use and whether the transaction could change incentives to maintain that support.
Competition diligence should examine market definition, customer alternatives, switching cost, roadmap timing, supply access, developer tools and data. A small current revenue base does not remove forward-looking issues when the target could reduce dependence on an established platform. The analysis should be led by qualified counsel using current law and facts.
Remedies or commitments can affect value. Requirements concerning interoperability, licensing, information separation, supply, customer neutrality or non-discrimination can limit planned integration or synergy. The valuation should include the cost, delay and strategic effect of credible outcomes rather than treating approval as a binary event.
Platform neutrality can itself be an asset. Customers may value a compiler, orchestration layer or model tool because it supports several accelerators. Acquisition by one hardware supplier can weaken that proposition. The buyer should test retention with customers and partners and preserve governance where neutrality supports cash flow.
Data, security and export controls can shape the integration perimeter. Customer workloads may contain confidential models, training methods, personal data or regulated information. Benchmark artefacts and telemetry may be contractually restricted. Source repositories can contain controlled technical information, cryptographic material or third-party code. The buyer should map where these assets are stored, who can access them, how they cross borders and which approvals apply. Integration plans should preserve least-privilege access, logging, segregation and incident response. Any planned transfer of teams, tools or technology should be reviewed against current export and sanctions rules. Costs and delays arising from required controls belong in the transaction model and closing plan.
14 Reconcile capital expenditure, working capital and support obligations
Accelerator development requires design, verification, tape-out, software, systems, inventory, qualification and support. The buyer should separate maintenance, committed roadmap, discretionary growth and customer-funded investment. Announced capital should be reconciled to purchase orders, contracts, milestones, payments and usable output.
Inventory risk can rise during generation transitions. Chips, boards and systems may become less valuable when software, customer schedules or new products move. The diligence team should classify inventory by version, customer, qualification, recoverability and cancellation rights. Purchase commitments and supplier deposits should be tested under central and downside demand.
Working capital should include receivables, credits, warranties, support commitments, prepayments and capacity reservations. Hardware shipment does not always equal final acceptance. The cash-flow model should reflect installation, acceptance, usage, service credits and collection.
Capitalised software and development costs require accounting review. The buyer should reconcile economic life with product cadence and customer use. Purchase accounting should identify acquired technology, customer relationships, contracts and goodwill using current standards [43-47]. Accounting classifications do not replace the operating valuation.
15 Protect customer trust and engineering continuity through integration
Integration should preserve roadmaps, release quality, customer confidentiality, security, supply and accountable decision rights. Customers may worry that a strategic buyer will favour its own products, change pricing, reduce portability or access sensitive workloads. Communication should address continuity, support, interoperability and governance using commitments the combined company can deliver.
Key-person risk extends beyond executives. Architecture, verification, compiler, kernel, framework, support and customer knowledge may sit with small teams. Retention should be connected to role, authority, roadmap and knowledge transfer. Documentation should include design decisions, source history, build systems, benchmark artefacts, test coverage and known defects.
| Workstream | Required evidence | Day-one control | First-hundred-day outcome |
|---|---|---|---|
| customers | contracts, workloads, service levels and communication map | named relationship owner and confidentiality protocol | verified programme baseline and retention plan |
| engineering | architecture, source, releases, defects and roadmap | protected teams, repositories and release authority | integrated roadmap with funded gates |
| benchmarks | configurations, code, logs, accuracy and power boundaries | frozen definitions and independent rerun plan | reproducible customer-relevant performance dashboard |
| supply | wafer, packaging, memory, systems and purchase commitments | accountable owner for each critical dependency | renewed rights and tested contingency plan |
| value | signing model, migration cost, synergy and integration funding | one controlled baseline and change log | measured accepted use, cost and net synergy report |
Proposed control plan; timing should be adapted to transaction approvals and customer obligations.
Integration sequencing should follow customer and release risk. Immediate changes to compiler, drivers, repositories, build systems or telemetry can create regressions. The buyer should establish which systems can change at day one, which require controlled testing and which should remain separate until a product or customer gate.
16 Use a signing-to-accepted-deployment control model
The interval between signing and accepted customer use can contain substantial value movement. Product schedules, software releases, benchmark results, supply allocation and customer programmes continue to change. The control model should cover the final diligence cut through closing, integration and at least the first audited cycle of accepted deployments and collections.
The model should begin with a frozen signing baseline. It should state each programme, workload, configuration, benchmark, service level, price, supply route, required staff, capital and forecast cash. Changes should be recorded against the baseline. A software regression, delayed tape-out, lower supply, customer redesign or price reset can affect value before it appears in reported revenue.
Interim covenants should protect material assets and programmes while preserving lawful operating responsibility. The seller should maintain teams, source repositories, release controls, supply rights, customer relationships and ordinary-course capital. Material IP grants, exclusivity, roadmap changes, cancellations or unplanned commitments may require consent, subject to applicable law and negotiated thresholds.
Closing readiness should include tested access to repositories, build systems, signing keys, benchmark artefacts, support systems, supplier contacts and customer escalation. The buyer should know which credentials and data can transfer, which require consent and which must remain segregated. Every unresolved dependency should have an owner and dated action.
17 Translate diligence findings into price, terms and integration actions
Diligence creates value when findings change a decision. Every material finding should be classified as a price adjustment, structural item, closing condition, contractual protection, integration action or monitored risk. The classification should identify evidence, financial exposure, timing, owner and decision.
A price adjustment can address weaker accepted use, unsupported performance, migration cost or required capital. A closing condition can address a customer approval, supply consent or financing. A representation, indemnity or escrow can address an identified exposure. A covenant can preserve teams, repositories, release discipline or supply. An integration action can fix a controllable weakness after closing.
Proposed decision map; position and treatment should be calibrated to target-specific evidence.
Representations and warranties should match the nature and duration of the risk. They can cover IP ownership, open-source compliance, benchmark statements, customer contracts, supply rights, security, export controls and financial statements. Insurance can support some contractual risks. It does not replace technical testing, customer evidence or a funded integration plan.
The final investment paper should reconcile headline price, net debt, working capital, contingent consideration, retention, transaction cost and integration funding. It should present stand-alone value, buyer-specific value and consideration on the same basis. It should show how each major diligence finding changed the model or terms.
Conclusion
AI accelerator transactions combine semiconductor, software, system, customer and platform economics. A credible valuation follows a reproducible chain from controlled rights and supply through measured silicon, mature software, customer deployment, accepted use and collected cash. Peak specifications and selected benchmarks provide context. They require workload, accuracy, latency, power and system evidence before they support operating value.
The strongest platform delivers useful work economically across relevant customer conditions. It combines reproducible performance, compiler and library maturity, manageable migration, reliable supply, customer trust and a funded roadmap. Its premium derives from repeatable adoption and durable control rather than one test result or product cycle.
The transaction discipline is practical. Define the asset. Reconstruct performance under load. Price complete-system economics. Test software reach and migration. Verify customer use. Map supply and roadmap dependencies. Value programmes from accepted cash. Separate buyer synergy. Choose terms that match evidence maturity. Maintain one controlled baseline through closing and accepted deployment.
Sources
- MLCommons, MLPerf Inference Benchmark Suite, Read the primary source
- MLCommons, MLPerf Inference Submission Guide, Read the primary source
- MLCommons, MLPerf Endpoints benchmark, Read the primary source
- MLCommons, MLPerf Inference power measurement, Read the primary source
- MLCommons, MLPerf Inference v5 language-model benchmarks, Read the primary source
- NVIDIA, 2026 Annual Report on Form 10-K, Read the primary source
- NVIDIA, 2026 annual report and proxy materials, Read the primary source
- NVIDIA, fiscal 2026 fourth-quarter results, Read the primary source
- NVIDIA, CUDA platform documentation, Read the primary source
- NVIDIA, TensorRT documentation, Read the primary source
- Advanced Micro Devices, 2025 Annual Report on Form 10-K, Read the primary source
- Advanced Micro Devices, ROCm documentation, Read the primary source
- Advanced Micro Devices, data centre and Instinct product disclosures, Read the primary source
- Advanced Micro Devices, annual reports and filings, Read the primary source
- Intel, 2024 Annual Report on Form 10-K, Read the primary source
- Intel, Gaudi accelerator documentation, Read the primary source
- Google Cloud, TPU documentation, Read the primary source
- Amazon Web Services, Trainium documentation, Read the primary source
- Microsoft, Maia AI accelerator overview, Read the primary source
- Meta Engineering, MTIA accelerator programme, Read the primary source
- OpenXLA, compiler project documentation, Read the primary source
- LLVM Project, compiler infrastructure documentation, Read the primary source
- ONNX, open model exchange documentation, Read the primary source
- PyTorch, compiler documentation, Read the primary source
- TensorFlow, XLA documentation, Read the primary source
- Open Compute Project, OCP Accelerator Module Base Specification, Read the primary source
- UCIe Consortium, specification resources, Read the primary source
- PCI-SIG, Compute Express Link resources, Read the primary source
- JEDEC, high-bandwidth memory standards resources, Read the primary source
- Taiwan Semiconductor Manufacturing Company, 2025 Annual Report, Read the primary source
- Amkor Technology, annual reports and filings, Read the primary source
- ASE Technology Holding, annual reports, Read the primary source
- National Institute of Standards and Technology, AI Risk Management Framework, Read the primary source
- National Institute of Standards and Technology, AI standards engagement plan, Read the primary source
- US Department of Commerce, CHIPS for America, Read the primary source
- US Bureau of Industry and Security, export administration regulations, Read the primary source
- US Department of Justice and Federal Trade Commission, 2023 Merger Guidelines, Read the primary source
- US Department of Justice, Guideline 6 on entrenching or extending a dominant position, Read the primary source
- US Department of Justice, Guideline 9 on multi-sided platforms, Read the primary source
- Federal Trade Commission, Hart-Scott-Rodino premerger notification programme, Read the primary source
- European Commission, horizontal merger guidelines, Read the primary source
- European Commission, Digital Markets Act, Read the primary source
- IFRS Foundation, IFRS 3 Business Combinations, Read the primary source
- IFRS Foundation, IAS 38 Intangible Assets, Read the primary source
- IFRS Foundation, IAS 36 Impairment of Assets, Read the primary source
- IFRS Foundation, IFRS 13 Fair Value Measurement, Read the primary source
- Financial Accounting Standards Board, Topic 805 Business Combinations, Read the primary source
- World Intellectual Property Organization, IP valuation, Read the primary source
- OECD, competition in the digital economy, Read the primary source
- MLCommons, benchmark working groups and governance, Read the primary source
