# F15 · 产品路线图与竞争演进
## Scope and evidence
Research the issuer's 1–3-year execution and 3–5-year competitive/product direction. Preserve F1–F14; Use F1–F15 consistently in the skill and on the website. Use this workflow for product strategy, generation transitions, long-range revenue durability and roadmap-driven valuation. Browse primary sources for current company facts.
Freeze an as-of date. Build a ledger from official product disclosures, investor days, filings, technical presentations, earnings Q&A and authorized reports; compare dated versions. Distinguish issuer statements, supplier/customer confirmation, third-party estimates and our assumptions. Two documents repeating one issuer claim are not independent corroboration. Never infer confidential specifications, customer wins or a launch date from rumors.

## Build the roadmap
For every generation record: product/segment; target workload/customer; commercial model; architecture/process/memory/interconnect/software; published date/window and status; source URL/locator/date; dependencies; competitors in the SAME future window; qualified capacity; customer adoption; recognition window; economics; unknowns; next milestone and revision trigger.
Keep announced → design/tapeout → sample → customer qualification → production/ramp → acceptance/deployment → revenue/cash separate. Adapt stages to IP/software/equipment rather than forcing a silicon sequence. Separate calendar and fiscal periods, availability and material revenue.
For 1–3 years, test execution, qualification, capacity, software migration, signed demand, cost/ramp, share and product replacement. For 3–5 years use bounded scenarios for workload shifts, technology, substitutes, ecosystem, make-versus-buy, regulatory exposure and business-model changes. Do not extrapolate market share or margin mechanically.
Compare service-qualified performance, power, TCO, compatibility and customer migration costs against contemporaneous competitors. Unknown competitor specifications remain unknown. Technical leadership is not automatically commercial share or profit.

## Close the economic model
R_t = sum_g Q_(g,t) × net ASP_(g,t), with mutually exclusive product/cohort boundaries.
Bound Q by applicable demand, qualified capacity, customer acceptance and recognition timing; avoid mixing annual capacity with half-year output. A bound is not a sales forecast.
Incremental EBIT = new-product gross profit − displaced old-product gross profit − incremental OpEx. Reconcile existing forecasts to avoid deducting cannibalization twice. Include yield, packaging, warranty, software/customer support and ramp cost where relevant; match depreciation to service dates.
Bridge EBIT to attributable earnings and diluted EPS; independently bridge working capital, cash/lease CapEx and cash collection to FCF. Adapt to IP/license/royalty economics and avoid adding royalty and whole-chip revenues for the same consolidated sale.
Build on-time, delayed and failed-adoption cases. Do not multiply correlated milestone probabilities as independent events. Evaluate valuation with the same earnings basis, dilution, time horizon and cash/EV boundary as F12. Do not automatically award multiple expansion for a launch.

## Required deliverable
Give an as-of product-generation table for both horizons; evidence/status ledger; same-window competitive comparison; dependency/bottleneck map; revenue/profit/cash scenarios; sensitivity and reversal boundary; strongest competing explanation; 3–5 observable milestones with dates or explicit missing dates. Separate delay from thesis failure. Record changes against the prior dated roadmap.
Connect F15 to F3/F4/F6/F7/F9/F10/F12/F14. Refresh roadmap evidence when material disclosures occur; a new research date alone is not new evidence.

## Training and assessment
Ask one question at a time: identify status/assumptions → quantify → defend → revise after a new constraint → validate → unseen-sector transfer. Use the F15 synthetic case in skill-graph.json. Do not reveal the solution before an attempt.
Score only observed evidence: provenance/chronology; same-window competition; dependency realism; net economic bridge including cannibalization; delay/reversal conditions; unseen transfer. Missing dimensions are not assessed. Reading a roadmap or model answer is not mastery.


# F15 strategic cases

## F15 · AI coding and erosion of software switching costs
Treat agentic coding lowering CUDA migration cost as a falsifiable hypothesis, not proof CUDA has no moat. Separate source/API translation, correctness/numerics, kernel tuning, distributed communication, libraries, tools, debugging, deployment reliability and ongoing maintenance. PyTorch is a framework using backends; Triton is a kernel programming/compiler layer; CUDA/ROCm/oneAPI are different platform stacks. A portable frontend does not guarantee equal backend coverage or performance. Primary references: https://rocmdocs.amd.com/projects/HIPIFY/en/latest/index.html (translation followed by debug/testing/tuning); https://docs.pytorch.org/docs/stable/notes/hip.html (HIP backend reuses torch.cuda interfaces); https://github.com/triton-lang/triton/blob/main/README.md (NVIDIA and AMD hardware support). These verify portability mechanisms, not measured agentic-coding savings or production parity.
Test a matched workload/model/precision/SLO at single GPU and cluster scale: engineer-hours to validated deployment with and without agents; end-to-end throughput; tail latency; failures; time to repair; ongoing retuning; compute/power/network/capacity TCO. Migration is justified when discounted operating savings exceed translation, validation, performance loss, outage risk, support and lost roadmap flexibility costs. Use human-reviewed correctness and baseline controls; line-count translated is not the outcome.
Synthetic exercise: annual savings $10m for 3 years, 10% discount -> PV about $24.87m. Translation $2m plus validation/tuning $8m plus PV of maintenance/performance penalties $12m -> migration NPV about +$2.87m. Halving translation cost adds only $1m; if that is the small term, coding automation alone barely changes the moat. If agents also reduce validated tuning and upkeep costs, quantify those separately. Figures are synthetic.
Do not equate lower chip purchase price with better service-qualified TCO. Model substitution through workload fit, adoption, vendor share, price and marginal profit. Hyperscaler internal silicon may replace merchant GPUs for some workloads while overall demand expands; separate workload share loss, unit demand, pricing pressure and market growth. Treat AWS Trainium/Inferentia as custom AI accelerators and Google TPU as a different architecture, not generic GPU brands. Ask how NVIDIA could respond with interconnect/software/platform openness, performance cadence and partner financing, and whether moat value migrates to another layer rather than disappears. Record dated 1–3-year migration milestones and 3–5-year ecosystem scenarios, with a no-change competing case.


## F15 · NVIDIA: ecosystem boundary and selective openness
Compare owning/operating cloud capacity, cloud marketplace/partner distribution, capacity commitments/investment, and component/IP infrastructure supply. These can coexist; a partner program does not prove NVIDIA abandoned cloud operations. Distinguish neocloud infrastructure providers from frontier-model labs. NVIDIA's 18 May 2025 DGX Cloud Lepton announcement lists CoreWeave, Lambda and Nebius among partners: https://nvidianews.nvidia.com/news/nvidia-announces-dgx-cloud-lepton-to-connect-developers-to-nvidias-global-compute-ecosystem . This establishes marketplace participation, not permanent exclusive procurement, financing terms, marketplace take rate or elimination of owned services. Do not assert CoreWeave exclusivity without dated direct evidence.
NVLink Fusion official platform: https://www.nvidia.com/en-gb/data-center/nvlink-fusion/ . It describes custom CPUs/XPUs participating in NVIDIA infrastructure and a modular hardware/software portfolio. Separate NVLink scale-up, NVLink-C2C chip-to-chip and full-rack system integration; list which components can change and which NVIDIA IP, switches, software and validated configurations remain. Do not infer unrestricted third-party CPU+GPU interoperability or a contractual one-component requirement merely from a general product page. Verify exact platform/version/partner licensing and qualification requirements. An optimized Vera Rubin rack and selective third-party integration can coexist.
Editorial hypothesis: selectively opening substitutable components may grow the ecosystem while preserving interconnect/software/platform value capture. Profit is not guaranteed by adoption or product revenue; compare displaced proprietary component profit with incremental GPU, switch, IP and software contribution less partner enablement, support, financing and liability costs. Include control of interfaces, certification, switching costs and customer autonomy; component choice does not remove all ecosystem dependence.
For cloud, compare installed versus paid utilized capacity, capital owner, leases, counterparty credit, customer concentration and backstop obligations. Avoid double counting partner hardware sales and final cloud spending, or counting equity investments as operating revenue. For Fusion, test customer adoption, net attach, recognized economics and compatibility milestones. Synthetic challenge: giving up a CPU sale loses contribution 3; additional GPU/network/IP sales add 6; support costs 1 -> net +2. If adoption yields only 2 contribution -> net −2. Values are arbitrary teaching units, not NVIDIA figures. Transfer to ARM IP/CSS/silicon and AMD host diversification; locate the layer capturing incremental profit.


## F15 · Intel: capital-constrained portfolio choices
Use the user's Foundry-versus-AI-GPU question as a strategic scenario, not a confirmed new GPU launch or evidence that Intel has exited all GPU businesses. Distinguish client graphics, datacenter GPU and dedicated AI accelerators; do not merge their product/customer/software economics.
Compare Foundry-first, AI-GPU-first, simultaneous investment, staged milestone funding, and partner/license/acquisition options. Define genuinely shared cash, engineering, management, software and customer-support bottlenecks; avoid assuming fab equipment CapEx and GPU R&D draw on the same engineers. Strategic synergy (process access, packaging, learning) must be quantified along with customer neutrality and opportunity costs.
Evaluate period-by-period cash, not just terminal NPV: end cash = start cash + operating cash + contractually available financing/support − cash CapEx − incremental program cash costs − debt service and other obligations. Reconcile R&D already included in operating cash; do not deduct it twice. Model restrictions and conditions on subsidies/customer prepayments. Funding interest rates, dilution, runway and minimum operating reserves can make a positive terminal project infeasible. Never assume undisclosed liquidity or price financing as guaranteed.
GPU success needs service-qualified hardware, compilers/libraries/frameworks, developer tooling, migration, reliability, customer validation and repeated adoption. Model cumulative ecosystem/support spending, time-to-usable-software, customer conversion and competitive response; hardware launch is not monetization. Foundry success separately needs process/packaging qualification, yield, external customer demand, utilization and collected cash. Product failures are evidence to examine, not proof that every future attempt fails.
Synthetic staged-budget exercise: incremental available cash $10bn over 3 years before reserve; Foundry path needs $8bn, GPU path $4bn and mandatory reserve $2bn. Both together need $14bn including reserve, leaving a $4bn funding gap. Only Foundry plus reserve fits exactly; GPU plus reserve leaves $4bn. These arithmetic results do not decide the best strategy: compare dated cash flows, reversibility, commitments, customers, ecosystem milestones and option value. Delay or co-fund stages only with explicit cost/time effects; check quarterly runway even if 3-year totals fit.
Require stop/continue gates: qualified customer milestones and cash burn versus released budget; pre-register what merits the next tranche, a partnership, delay or termination. Transfer to a memory supplier choosing process conversion versus packaging, or a cloud provider choosing owned silicon versus leased capacity.


## F15 · Anticipate strategy before announcement: Arm and AMD
Infer possible strategic direction from profit-pool constraints, customer needs and feasible value-chain expansion; do not infer a specific secret project from valuation pressure alone. Arm's 24 March 2026 AGI CPU launch (https://newsroom.arm.com/news/arm-agi-cpu-launch) establishes expansion from IP/CSS into Arm-designed silicon and Meta co-development. The official launch and https://newsroom.arm.com/blog/introducing-arm-agi-cpu describe parallel CSS/silicon paths. These checked documents do not verify a 2023 project start or that the entire IP market is saturated. Keep those as user hypotheses until independently sourced. Growth alternatives include royalty rates, CSS penetration, market share, workload expansion and own silicon; higher revenue is not automatically higher EPS/FCF.
Train a 3–4-year pre-announcement prediction: freeze the information set actually available at prediction date, record alternative strategies and earliest discriminating hiring, partner, software, capital or product signals, then compare later milestones without hindsight. Arm hypothesis: greater gross-profit dollars captured per deployment may justify owning silicon after development, manufacturing, channel conflict and working-capital costs. AMD hypothesis: changed GPU economics may justify host diversification by 2030; test compatibility, partner sourcing and own-CPU investment separately. Neither 2030 nor a GPU/CPU revenue crossover establishes necessity or timing. Evaluate discounted incremental cash returns versus retaining the current model, including failure and delay branches.


## F15 · AMD: surrender CPU attach to expand GPU deployments
Treat the user's 2030 Arm-host idea as a hypothesis, not an announced roadmap. Separate (A) support other vendors' x86 hosts, (B) support third-party Arm hosts, (C) design/license AMD-owned Arm silicon, and (D) retain an optimized EPYC rack while also offering other host choices. These options differ in R&D, software, qualification and value capture. A reference rack using EPYC does not prove all Instinct deployments require EPYC.
Dated primary sources: AMD/Meta announcement https://ir.amd.com/news-events/press-releases/detail/1279/amd-and-meta-announce-expanded-strategic-partnership-to-deploy-6-gigawatts-of-amd-gpus (first deployment described with MI450-based GPU and Venice EPYC; schedule is a company claim, not verified delivery). ROCm 7.1 system requirements https://rocm.docs.amd.com/projects/install-on-linux/en/docs-7.1.0/reference/system-requirements.html discusses AMD Zen and Intel Haswell PCIe atomics; this is a technical prerequisite, not certification of every host/server. AMD AAI2026 https://ir.amd.com/news-events/press-releases/detail/1294/aai-2026-amd-delivers-full-stack-compute-for-the-agentic-ai-era describes Zen8 Ravenna for 2030; it does not establish an Arm-host commitment. Check exact current platform support before recommending a configuration.
Decision model (editorial): delta profit = additional accepted GPU units × GPU incremental contribution/unit − displaced EPYC units × EPYC incremental contribution/unit − incremental engineering/support/qualification costs + measured system synergy. Keep R&D and variable costs from double counting; include inventory/cash and discounted timing. Revenue crossover GPU>CPU is neither necessary nor sufficient: marginal profit, customer conversion and opportunity costs set the boundary. Also test whether a cheaper host frees customer budget but demand or power still caps GPUs.
Synthetic exercise: extra 20,000 GPUs, contribution $8,000/GPU; displaced 10,000 CPUs, contribution $1,500/CPU; extra annual costs $30m; zero synergy. Delta EBIT proxy=$115m; break-even extra GPUs=5,625 at constant coefficients. New constraint: budget/power/software qualification limits extra accepted GPUs to 3,000; proxy turns to −$21m. Contributions are synthetic and after variable costs, before the stated annual fixed costs; not AMD disclosures or forecasts.
Ask: What would prove EPYC attach is a sales constraint? Which lost CPU sales actually belong in the counterfactual? Is an Arm host better on matched workload/SLO/TCO? Why own the Arm CPU rather than qualify a partner? What experiment resolves conversion uplift? Observe supported hosts, validated software, customer choices, cross-host performance, accepted GPU volume and segment profit evidence; do not infer product-specific earnings from aggregated Data Center revenue.
Transfer: proprietary networking bundled with servers, or software suite bundling. Compare protected attach profit with net new platform profit, not revenue totals.