Li Auto delivered 30,468 units in July: When 'spec stuffing' hits the power wall, chip engineers see more than just sales figures

Delivery volume itself isn't the issue. 30,468 units, positive YoY growth, cumulative 1.764 million units—these numbers are enough for Li Auto's PR department to make a pretty poster.

But the MoM decline is the key signal. People in the chip industry have a habit when looking at data—we don't look at YoY, we look at MoM; we don't look at total volume, we look at the slope. Li Auto's MoM decline this month, combined with last year's base, indicates the growth curve is flattening. This doesn't mean Li Auto is failing; it means the entire smart EV track is shifting from "stacking configurations" to "scrutinizing power consumption," and Li Auto happens to be the one stacking the most hardware.

I wrote an analysis of Microsoft's earnings last week, mentioning that Copilot's money isn't the problem—the process node is. The same logic applies to cars: What does 3 million deliveries mean? It means every Li Auto on the road is eating electricity, generating heat, and consuming the design margin of the cooling system.

You see traffic at an intersection; I see the junction temperature curve of the Orin or Thor chip inside the car computer.

Two Modes: Hardware Stacking vs. Energy Efficiency First

The EV industry currently faces an engineering fork in the road, which I call "Mode A" and "Mode B":

Mode A (Li Auto's current route)

1. Hardware priority: Dual Orin-X in L9, single Orin in L6, maxing out compute power.

2. OTA tuning comes later: Deliver hardware first, then converge power consumption via software.

Mode B (Route attempted by some new forces)

1. Chip definition first: Set compute budget, then define features, finally select SoC.

2. Sub-module fixation: Perception, planning/control, and cockpit use independent NPUs, no unified compute pool.

3. Hard power budget constraint: Total vehicle intelligent domain power consumption must not exceed 200W, otherwise thermal management costs explode.

Li Auto is currently walking Mode A. This mode works fine at 10k monthly sales, and is okay at 20k, but at a scale of 1.76 million cumulative and 30k+ monthly, the power wall becomes a system-level bottleneck.

For example: If L6's cockpit chip uses Qualcomm 8295, single-chip full-load power is 7-8W. But for the sake of cockpit experience, Li Auto typically turns on screens, audio, AR-HUD, plus preprocessing for multiple cameras and LiDARs. The actual power consumption of the car computer domain often hits 15-20W. This amount per vehicle seems negligible, but multiplied by 1.76 million vehicles, total power is 2.6-3.5GW. Even if only half are running simultaneously, that's an instantaneous load of 1.3-1.8GW—and that doesn't even count the AC compressor and motor drive.

Process Nodes Are Hard Constraints, Not Soft Parameters

From a chip design perspective, Li Auto's dilemma is typical: It's easy to stack compute power, hard to reduce power consumption.

Orin-X uses Samsung's 8nm process, with rated power already at 15W (actual full load might hit 20W+). Thor is more extreme, using TSMC's 4nm process, with packaged power rated at 200W—but that's ideal conditions. In a car cabin with limited cooling, once junction temperature exceeds 95 degrees, power consumption doubles directly—because leakage current rises exponentially with temperature. This is a physical property of MOSFETs; nobody can change it.

So rather than saying Li Auto is competing with rivals on sales, it's racing against the limits of thermal design. L9's cooling system is already huge, using air ducts, water cooling, and heat pipes, but physical limits are physical limits; you can't break through them with software OTA.

What Can Be Done Engineering-wise

Honestly, if I were Li Auto's chip system engineer, I would suggest three things:

1. Create a power budget table: List power consumption for all SoCs, sensors, and actuators in the vehicle to find the maximum power path. Currently, LiDAR preprocessing and cockpit display are the two biggest consumers. For the former, redundant frames can be cut; for the latter, screen refresh rate can be lowered or brightness dynamically adjusted.

2. Introduce Dynamic Power Management (DPM): Like smartphones, implement DVFS (Dynamic Voltage Frequency Scaling) in the car computer. When full-time L4 compute isn't needed, put one of the dual Orins into low-power sleep mode, or shut down some big cores in Thor. This requires modifying underlying drivers but is engineering-feasible.

3. Consider self-developed chips or custom SoCs: This is the most thorough solution, but long cycle and high cost. Tesla is already doing HW4.0 self-developed chips. If Li Auto wants to go far, it should use customized 7nm or 5nm automotive-grade SoCs on the next-gen platform, cutting power from 200W to 120W. This isn't showing off; it's a survival issue.

Conclusion

Pure vision solutions have obvious advantages in power consumption, but Li Auto doesn't want to give up LiDAR because it truly provides a safety net for the experience. This trade-off is reasonable, but the cost is that power consumption can never be suppressed.

In H2 2026, whether Li Auto introduces self-developed chips alongside Orin is more noteworthy than delivery figures.