Real Alpha
Watch mode

Lex Fridman Podcast · 2 min instead of 2 h 26 m · Mar 23, 2026

Test every plan against the speed of light, not continuous improvement

Jensen Huang

Co-founder & CEO, NVIDIA

  • Lex FridmanHost · Host, Lex Fridman Podcast

    Robotics and AI researcher at MIT; started the show in 2018.

About this segment

Jensen describes his speed-of-light method: compare each process to what physics allows, then work backward. Teams strip a 74-day process back to zero and often find a six-day version is possible.

From “Jensen Huang: NVIDIA - The $4 Trillion Company & the AI Revolution | Lex Fridman Podcast #494”, Mar 23, 2026. Watch the full episode

“I'd rather strip it all back to zero and say, first of all, explain to me why it's 74 days in the first place.”
Jensen Huangat 58:42 · Lex Fridman Podcast58:42

Takeaways

  1. Set the physical limit first, then explain the gap to today's process
  2. Rebuild from scratch instead of trimming a 74-day process to 72
  3. Knowing the ideal makes the compromise conversation far more effective
Watch 2:17 from 57:20

In this episode

Full episode
  1. 11:26Putting CUDA on GeForce nearly sank NVIDIA, but install base won4:13

  2. 57:20Test every plan against the speed of light, not continuous improvement2:17

  3. 47:23The power grid sits mostly idle, and data centers could use that slack2:49Up next

Transcript

Transcribed by machine (Whisper) from the episode’s audio, so a word may be off here and there.

  1. 57:25

    separately. And then when you consider it together, you know you have to make compromises because a system that achieves extremely low latency versus a system that achieves very high throughput are architected fundamentally differently. But you want to know what's the speed of light of a system that achieves high throughput? What's the speed of light of a system that achieves low latency? And then when you think about the total system, you could make trade-offs.

  2. 57:53

    And so I force everybody to think about what's this. What the first principles, the limits, the physical limits for everything before we, you know, before we do anything and we test everything against that. And so that's a good frame of mind. I don't love the other methods, which is continuous improvement. the problem with continuous improvement it first of all you should engineer something from first principles at the speed you know with speed of light thinking limited only by physical limits and and physics limits and um after that of course you would improve it over time um but i don't like going into a problem and somebody says hey you know it takes 74 days to do this today, right now, and we can do it for you in 72 days. You know, I'd rather strip it all back to zero and say, first of all, explain to me why it's 74 days

  3. 58:53

    in the first place. And let's know, let's think about what's possible today. And if I were to build it completely from scratch, you know, how long would it take? Oftentimes you'd be surprised might come to six days. Now the rest of the six days to 74 could be very well-reasoned and compromises and cost reductions and all kinds of different things, but at least you know what they are. And now that you know that six days is possible, then the conversation from 74 to 6 is surprisingly much more effective.

  4. 59:28

    In such incredibly complex systems that you're working with, is simplicity sometimes a good heuristic