§ 01 · The Wrong Cost Curve

The single most quoted statistic in the photonic-sensing industry is the LiDAR cost curve. A spinning Velodyne unit that ran $75,000 in 2015 has dropped to under $1,000 in commodity automotive packaging. Solid-state flash modules are targeting $200 at automotive scale. Defence-grade Geiger-mode systems still command six figures, but even those have seen meaningful unit economics improvements as InGaAs SPAD foundries have scaled. The headline conclusion every industry analyst draws from this trajectory is that LiDAR will become a commodity sensor over the next decade, the way image sensors did in the 2000s. That conclusion is probably correct as far as it goes.

The problem is that the LiDAR cost curve has stopped being the cost curve that matters. A modern autonomous vehicle company running multiple development fleets, large-scale simulation environments, neural network training pipelines, and high-definition map maintenance operations will spend more on cloud compute in a single quarter than it spends on photonic hardware in a year. A commercial mapping platform processing aerial LiDAR surveys for infrastructure clients will pay more for the GPU instances doing the photogrammetry and point cloud classification than it pays for the survey aircraft and the LiDAR units mounted on them. A digital twin company building city-scale 3D models from photonic and satellite data sources will spend the bulk of its operating budget on storage, training, and simulation compute — not on the sensors that produce the source data.

This shift has happened gradually enough that most coverage of the photonic sensing industry has not caught up to it. The trade press still treats LiDAR as a hardware story, with occasional gestures toward the AI software running on top of the data. The honest read of the industry in 2026 is that the photonic hardware has become the easy part. The hard part — the part that determines who actually wins in autonomous vehicles, in mapping, in defence ISR, in industrial automation — is the compute infrastructure underneath, the data pipelines that feed it, and the unit economics of running large-scale machine learning workloads on top of multimodal sensor streams. That layer has its own technology curve, its own supply chain, its own concentration risks, and its own emerging market dynamics. None of it gets adequately covered in the photonics trade press, which is what this article is trying to correct.

§ 02 · The Compute Stack Underneath Modern Photonic Sensing

A modern photonic sensing operation runs on an eight-layer compute stack that has accumulated over the past decade through hundreds of independent procurement decisions. None of it was designed as a coherent system. The layers interact with each other, interfere with each other, and fail in ways that none of the single-layer vendors will fully acknowledge. Understanding what is actually happening underneath requires a layer-by-layer read.

At the bottom of the stack sits the photonic hardware itself — the lasers, detectors, and optical assemblies that turn photons into electrical signals. This layer has been the focus of nearly all photonic sensing coverage. Above it sits the embedded compute layer that runs on the sensor itself or on the immediate platform — the FPGAs, the dedicated photonic SoCs, the small inference chips that handle real-time tasks like time-of-flight calculation, point cloud assembly, basic anomaly detection, and pre-classification before data leaves the sensor. This embedded layer is where the most interesting silicon work is happening right now, and where companies like Mobileye, Hailo, Ambarella, and a dozen others are quietly competing to define the architecture of next-generation perception modules.

Above the embedded layer sits the platform compute — the in-vehicle computer or the local edge node that aggregates data from multiple sensors, runs the perception stack, executes the control logic, and handles communication with the broader system. NVIDIA DRIVE platforms dominate this layer in automotive applications. Qualcomm Snapdragon Ride, NXP, and Renesas have meaningful positions. Tesla runs proprietary silicon. The platform layer is where the actual real-time decisions get made — whether to brake, whether to steer, whether to flag an object for further scrutiny — and the unit economics of this layer have become structurally tight as model complexity has grown.

Above the platform sits the data pipeline layer — the systems that ingest the firehose of sensor data, label it, store it, version it, and deliver it to wherever it needs to go for training. This is the layer where data engineering teams the size of small armies have been quietly built up at every serious autonomous vehicle company. Above it sits the training compute — the largest budget line for any modern photonic perception company — running on hyperscaler GPU clusters at scales that would have been considered science-fictional five years ago. Above the training layer sits the simulation compute, where companies generate synthetic sensor data to train and validate their perception stacks. And above all of it sits the deployment and observability layer that actually monitors the deployed systems in the field. Eight layers, three or four hyperscalers underneath all of them, and a set of unit economics that has stopped resembling the original photonics-hardware cost structure.

The cost dynamics at each layer move differently. The aggregate effect is that the bottom layers commoditise while the upper layers absorb a rising share of the unit economics.

§ 03 · Simulation Is Where The Compute Actually Goes

The single most under-discussed cost line in the modern photonic perception industry is simulation compute. Every serious autonomous vehicle company, every commercial mapping platform, and every defence ISR contractor now runs large-scale simulation environments that generate synthetic sensor data at volumes far exceeding what their physical fleets could produce in a lifetime. The reason is straightforward: training a perception model on real-world data alone is impossibly slow, dangerous, and expensive. Edge cases — the rare scenarios that determine whether a system handles a one-in-a-million event correctly — are by definition rare. Generating them artificially in simulation is the only way to expose a perception model to enough variation to be trustworthy.

The compute economics of simulation are punishing. A high-fidelity sensor simulation that accurately models photonic behaviour — the way a real LiDAR pulse bounces off wet asphalt at a particular angle, the way a real camera handles direct sunlight through a windshield, the way a real radar return is corrupted by rain on a metal sign — is computationally expensive in a way that a simple game-engine visualisation is not. Companies like Waymo, Cruise, Wayve, Aurora, and Mobileye have spent the better part of a decade building proprietary simulation stacks specifically because off-the-shelf game engines do not produce sensor-accurate synthetic data, and the synthetic data is only useful for training if it accurately represents what the real sensor would have measured.

The result is that simulation compute has become one of the largest single line items in autonomous vehicle company budgets, second only to direct training compute and ahead of physical fleet operating costs at most companies past Series C. NVIDIA DRIVE Sim, AWS RoboMaker, CARLA, the open-source ecosystem, and the major proprietary platforms collectively burn an enormous amount of GPU time. The standard industry practice has shifted toward running simulation on the same hyperscaler infrastructure as training, partly for data-locality reasons and partly because the workload patterns are similar enough that the same reserved GPU capacity can be amortised across both. None of this shows up in the headline cost-curve narratives the photonic sensing trade press tends to tell. All of it shows up in the actual operating expenses of every company in the industry.

The same dynamics apply with different specifics to commercial mapping platforms processing aerial and satellite LiDAR data. Photogrammetry, point cloud classification, change detection, and object extraction are all GPU-intensive workloads, and the volume of source data being processed has grown roughly with the cube of sensor resolution improvements over the past five years. A national LiDAR mapping programme that produced a few terabytes of point cloud data in 2018 now produces tens of petabytes annually, and every byte of that needs to pass through processing pipelines that are themselves significant cloud compute consumers. The compute layer is not a side cost of the photonic sensing industry. It is the industry, viewed through the operating-expense lens.

§ 04 · The Real Cost Economics of an AV Company in 2026

The interesting way to read autonomous vehicle company financials is to look at where the cloud spend actually goes. Public disclosures are limited, but a combination of leaked numbers, hyperscaler partnership announcements, and industry-standard estimation models produces a fairly consistent picture across the well-funded companies in the category. Training compute typically runs 35 to 50 percent of total cloud spend at well-funded AV companies. Simulation compute runs another 20 to 30 percent. Data pipeline storage and processing absorbs 15 to 25 percent. Observability, OTA infrastructure, and miscellaneous workloads make up the rest. The aggregate cloud bill at a top-tier AV company runs from the low tens of millions of dollars per quarter to nine figures annually for the largest players, with significant year-over-year growth as model complexity and fleet sizes both expand.

For comparison, a typical modern AV development fleet of two hundred vehicles, each fitted with multiple LiDAR units, cameras, radars, and IMUs, represents a hardware bill of perhaps fifteen to twenty million dollars all-in. The annual cloud bill at the same company will frequently exceed that number by a factor of five or more. The hardware is essentially a one-time capital expense; the cloud bill is a recurring operating expense that scales with development velocity, model size, and simulation complexity. Compounded across the industry, the photonic sensing supply chain produces somewhere on the order of a few billion dollars in annual hardware revenue, and the autonomous vehicle development industry pays multiples of that to the major hyperscalers every year just to make use of what those sensors produce.

The cost dynamics inside commercial mapping platforms are different in detail but similar in shape. A commercial aerial mapping company operating a fleet of survey aircraft will have hardware costs concentrated in the aircraft, the LiDAR and imaging payloads, and the ground equipment for survey planning and aircraft maintenance. The processing of the resulting data — photogrammetric reconstruction, point cloud classification, semantic labelling, integration with existing GIS platforms — is overwhelmingly cloud-based and represents a larger share of the company’s total operating cost than the physical assets themselves. Defence ISR contractors face similar economics, with the additional complication that classified workloads cannot run on commercial cloud infrastructure and have to be supported on government-cloud equivalents at significantly higher unit costs.

Composite ranges based on industry estimation models, leaked figures, and hyperscaler partnership announcements. Specific company allocations vary significantly based on fleet size, simulation strategy, and proprietary infrastructure investment.

§ 05 · Three Hyperscalers Underneath Almost Everything

The compute infrastructure underneath the photonic sensing industry is concentrated to a degree that surprises people new to the space. Roughly three quarters of all autonomous vehicle development workloads run on one of three hyperscalers: Amazon Web Services, Microsoft Azure, or Google Cloud Platform. The remainder is split between proprietary infrastructure built by the largest players (Waymo running primarily on Google Cloud given the corporate parent, Tesla running substantial proprietary hardware), Oracle Cloud for specific workloads with regulatory or pricing advantages, and a long tail of specialised GPU-cloud providers like CoreWeave, Lambda, and Crusoe that have grown rapidly during the AI infrastructure buildout.

Each hyperscaler has positioned itself differently for the photonic perception workload. Google Cloud has emphasised its tensor processing units and its native integration with Google’s extensive geospatial data assets, making it a natural fit for mapping-heavy workloads. AWS has emphasised its breadth of GPU instance types, its RoboMaker simulation service, and its mature data pipeline infrastructure, making it the default choice for many AV companies that prioritise operational tooling. Microsoft Azure has emphasised its OpenAI partnership, its enterprise compliance posture, and its strong defence and government cloud presence, making it well-suited to ISR and dual-use applications. The differences matter at the margin, but the structural reality is that any photonic perception company at scale ends up running on one of the three, often on more than one of them simultaneously, and increasingly with multi-cloud architectures designed to manage concentration risk.

The concentration produces a specific set of operational dynamics that are worth understanding. The hyperscalers offer significant discounts in exchange for prepaid annual commitments — reserved instances, committed use discounts, or enterprise agreements that lock in pricing in exchange for spend guarantees. A photonic perception company committing to fifty million dollars of annual GCP spend gets materially better effective per-instance pricing than one paying month-to-month. The discount math creates pressure to forecast spend optimistically and over-commit in order to qualify for the largest discount tier, which produces a different problem at the end of the commitment period: companies routinely end the year sitting on significant unused commitment balances that cannot be carried forward or refunded by the hyperscaler.

This dynamic is becoming meaningful enough at the industry level that it has produced its own emerging market response. Marketplaces have begun to appear that match buyers and sellers of unused cloud commitments directly, allowing companies with leftover capacity to recover value that would otherwise expire and allowing companies running into their commitment ceiling to buy google cloud credits at a discount to retail pricing. The economic logic is the same as in any other secondary market for prepaid enterprise services: when a meaningful percentage of contracted capacity routinely goes unused while another segment of the market is paying full retail at the margin, a marketplace will emerge to clear the inefficiency. For photonic perception companies running tight unit economics on simulation and training compute, the secondary credit market has become a real procurement consideration alongside the standard hyperscaler negotiation cycle.

Customer attributions reflect known historical relationships and publicly disclosed partnerships. Most photonic perception companies at scale operate multi-cloud architectures rather than committing exclusively to a single provider.

§ 06 · The Dual Cost Curve: Edge Inference vs. Cloud Training

The most important architectural decision in any modern photonic perception system is which workloads run on the edge and which run in the cloud. The trade-off is not subtle. Edge inference — running the perception model directly on the in-vehicle compute platform — has the obvious advantages of low latency, no network dependency, and no per-inference cloud cost. The disadvantages are equally obvious: the model running at the edge is necessarily smaller, less capable, and more expensive per unit of silicon than the equivalent model would be running in the cloud. Cloud-based perception — sending sensor data over a network to be processed remotely — allows for arbitrarily complex models running on optimal hardware, but introduces latency, network dependency, and recurring operating cost.

Most production autonomous vehicle systems split the workload along functional lines that have stabilised over the past several years. Real-time safety-critical perception — the sub-100ms decisions about whether to brake, steer, or accelerate — runs on edge silicon, because the latency budget makes anything else infeasible. Higher-level reasoning — route planning, behavioural prediction over multi-second horizons, traffic flow analysis — can sometimes run partially in the cloud, particularly for L4 robotaxi systems operating in geofenced areas with reliable connectivity. Training, simulation, fleet learning, and map updates run almost entirely in the cloud because the compute requirements simply cannot be supported at the edge.

The interesting cost dynamic is that both ends of this split are running into capacity walls simultaneously. Edge silicon is hitting the limit of what current automotive-qualified processors can run within thermal and power budgets — the next generation of perception models is genuinely larger than the previous generation, and silicon scaling has not kept pace with model size growth. Cloud compute is hitting the limit of what enterprise budgets can absorb — the major AV companies have all reported that cloud spend is now a significant operating cost discussion at the board level, and the discount tiers that used to cushion this cost have already been negotiated to their floors. The industry is entering a phase where neither the edge nor the cloud can simply absorb model complexity growth at the current trajectory, and architectural creativity will determine which companies handle the transition gracefully.

Several approaches to the dual cost curve have emerged. Model distillation — training large cloud models and then producing smaller specialised versions for edge deployment — has become standard practice. Mixed-precision inference and quantisation reduce edge compute requirements at modest accuracy cost. On-device caching of inference results for repeated scenarios reduces the actual rate of model evaluation. Federated learning and on-device personalisation distribute some of the training workload to the edge, although the privacy and data governance implications make this approach suitable only for specific use cases. None of these techniques has fully solved the problem. All of them are part of the operational architecture that any serious photonic perception company has to invest in if it intends to scale.

§ 07 · What The Photonics Trade Press Is Missing

The first thing the photonics trade press is missing is the magnitude of the spend shift. Most coverage of the industry treats photonic hardware as the centre of gravity, with software and compute as supporting layers. The financial reality has inverted: in autonomous vehicles, in commercial mapping, in defence ISR, and in industrial automation, the compute layer now absorbs more capital than the hardware layer. Coverage that does not reflect this is, increasingly, describing the wrong industry. The interesting questions about photonic sensing in 2026 are mostly about the compute infrastructure underneath, not the photonic hardware on top.

The second thing missing is the concentration risk in the underlying supply chain. The photonic hardware industry has historically discussed supply chain risk in terms of GaAs wafer availability, InGaAs SPAD foundry capacity, and high-power 1550nm laser sources. Those risks remain real. But the more consequential supply chain risk facing the industry is the concentration of GPU compute capacity at a small number of hyperscalers, all of whom are themselves competing for capacity from a single dominant chip vendor. A photonic perception company that has secured its laser supply, its detector supply, and its silicon supply is still one hyperscaler-pricing-decision away from having its unit economics rewritten unilaterally. That risk does not show up in conventional supply chain analyses because conventional supply chain analyses treat cloud compute as a service rather than as a critical input.

The third thing missing is the role of secondary markets in managing cloud commitment risk. The combination of optimistic forecasting, prepaid commitment discounts, and end-of-period unused balances has created a real inefficiency that the industry has only recently started to address through marketplace mechanisms. The photonics trade press, fixated on hardware narratives, has not yet noticed that procurement teams at major photonic perception companies now routinely participate in cloud credit secondary markets as part of their cost management process. The marketplaces themselves are still small, but the structural dynamic that supports their existence is large and growing. Coverage that ignores this misses one of the more interesting commercial developments at the intersection of photonic perception and infrastructure economics.

The fourth thing missing is the regulatory dimension. As autonomous vehicles approach broader deployment, defence ISR systems become more capable, and digital twin platforms accumulate detailed records of urban environments, the regulatory frameworks governing what photonic systems can do, what data they can retain, and how that data can be processed are becoming binding constraints on system design. The compute infrastructure decisions that look purely technical — where data is stored, what regions it is processed in, which classifications of data can run on which clouds — are increasingly regulatory decisions in technical clothing. The photonics trade press, more comfortable with optical engineering than with data governance law, has been slow to integrate this dimension into its coverage. The industry would benefit from journalism that does.

§ 08 · What Comes Next For the Compute Layer

The compute layer underneath photonic sensing is going to keep absorbing capital faster than the hardware layer for the foreseeable future. Every major trend in the industry — larger perception models, more comprehensive simulation, multi-modal sensor fusion, fleet learning at scale, real-time map updates, autonomous defence platforms — pushes compute requirements upward. The trend lines in semiconductor performance, in algorithmic efficiency, and in cloud unit pricing are all moving in the right direction, but none of them are moving fast enough to offset the demand growth from the workloads themselves. Net spend per company has been rising and is likely to keep rising through at least 2028.

The structural implications are worth thinking through. First, the competitive moat in the photonic perception industry is increasingly the compute moat, not the hardware moat. Companies that have figured out how to run training and simulation efficiently — through architectural choices, vendor negotiations, secondary market participation, or proprietary infrastructure investment — have a real cost advantage that compounds over multiple model generations. Second, the consolidation pressure on the industry will be driven by compute economics as much as by sensor economics. Smaller AV companies and mapping platforms will run out of money on cloud bills before they run out of money on hardware, and the M&A landscape will reflect that. Third, the next generation of breakout companies in photonic perception will probably look more like infrastructure plays than like pure photonics plays. The companies that own the compute layer will own the industry.

None of this is a reason for pessimism about the photonics industry as a whole. The sensing capability is real, the addressable markets are large, and the underlying technology trajectory is one of the most impressive in any segment of advanced manufacturing. The point is that the centre of gravity has moved. The next decade of photonic perception will be defined less by who builds the best LiDAR sensor and more by who can run the most useful operation on top of the data that LiDAR sensors collectively produce. The trade press, the analyst community, and the investment community would all benefit from coverage that reflects where the industry actually is rather than where it was five years ago.

The post The Compute Layer Underneath: How Cloud Spend Ate Photonic Sensing appeared first on Princeton Lightwave.

The post The Compute Layer Underneath: How Cloud Spend Ate Photonic Sensing appeared first on Princeton Lightwave.

How LiDAR Works: From Pulse to Point Cloud

What a LiDAR Point Cloud Can Generate

Why LiDAR Can See Through a Forest Canopy

The Main Types of LiDAR Systems

Where LiDAR Is Actually Being Used

LiDAR vs. Radar: Two Different Jobs

Point Classification and the ASPRS Standard

The post A Complete Guide to LiDAR: How Light Detection and Ranging Works appeared first on Princeton Lightwave.

The post A Complete Guide to LiDAR: How Light Detection and Ranging Works appeared first on Princeton Lightwave.