Posted by plurby 23 hours ago
1) Could a cloud-delivered LLM figure out how to drive this route, based on those input data and given access to those output actuators? Looks like yes. Sure.
2) Could this work in the real world? Absolutely not. Three reasons: latency, latency, and latency.
openpilot's driving model updates the target curvature and acceleration at 20Hz. Every millisecond of the round trip time through every piece of its entirely-local driving stack is well-understood, extremely consistent, and tightly optimized. It has to be, otherwise you can't react to even minor bumps or wind gusts, much less rapidly-developing traffic situations.
Adding even a single speed of light RTT to a cloud service is meaningfully bad, and you'll need a whole lot more to encode and upload camera imagery to even start the time-to-LLM-response clock, and then send the response back down. By then the world around the car has moved on.
There's a reason Tesla and every other self-driving manufacturer need the compute hardware in the car.
-Aditya, Tobias, Simon
My only point is to say this sort of experiment is where it ends. Neither Anthropic nor OpenAI will be coming out with a "drive your car from the cloud" subscription until we have FTL communication, meaning never.
That and also the fact that (in spite of their usefulness) LLMs still so often do incredibly dumb shit without thinking of the consequences that the idea of having them drive in public is absurd.
Recently was using claude code/opus 5 to diagnose an intermittent wi-fi connection problem and one of the first things it did was to bring the adapter down. The wi-fi adapter was the only way the system was communicating with the outside world so claude effectively disconnected its own brain as step 1 in figuring out what was going wrong. Things did not progress well from there. Easy enough to clean up its mess in this case, but luckily it wasn't driving a heavy killing machine at the time.
Do you mean restarting it? IDK, that would have been my first step too.
I'm far from neuroscience, but humans don't need to operate at 20Hz to drive a car. And human reaction latency (event to measurable action) is often over 1s (under 1Hz).
From what I understand about AV (as a non-expert!), all three of those steps happen at different clock rates, ie you have a planner that’s updating continuously with observations from sensors at one rate, that planner then issues actions that get picked up by the actuators at another rate.
In that sense 20hz should really be compared to human reflexes without perception and planning; in scenarios where one is anticipating an action, response time can be as low as 150ms. in that context, I think 50ms/20hz is plenty reasonable for an automated driver.
Though you can't convert between hz and latency, all 20hz tells us is that it adjusts 20 times a second, not how long it takes from sensor input to be fed into a particular choice of adjustment, there could be (and actually almost certainly are) multiple adjustments in flight simultaneously with the adjustment actually being applied being calculated from old data (both in humans and automated substitutes).
This is not a helpful statement unless you can claim what speed human sensors do work at. And it's going to be faster than the latency of $(sensor + server round trip) Hertz, not getting into LLM processing time.
In humans, it's about 200–250 ms for a visual cue where you already know how to respond and you're ready, but you don't know exactly when it'll happen. It can be a fair bit longer if you need to identify what you see and choose how to respond. Typical perception to reaction time estimates for drivers when there's an unexpected hazard on the road are 1-2 seconds.
I mean, consider competitive video games. Humans who play a lot and pay attention respond to stimuli much faster than 250ms.
There are a lot of reasons people could sometimes react faster (for example, if they anticipate the hazard, or if they're just above average in reaction speed), but one to two seconds is the reaction speed we find most of the time.
The fastest human reactions aren't to unexpected road hazards. We have a much faster reaction speed in tests where you just have to click the mouse each time the screen flashes. Our reactions are fastest when you know in advance the event is about to happen. But this isn't relevant for road safety.
Like just running a first pass sanity analysis on the 1-2sec timeline fails because if it were true in practice all those idiots who screech about how normal traffic doesn't keep following distances worthy of semi trucks to the traffic ahead would be proven right as every braking event would cause a pile up. So either humans react much faster to the unexpected (not likely, we've measured) or humans have a huge "context window" for what to expect that makes the 1-2sec number not relevant in the base case.
This is so self evidently false, I struggle to believe you think it is true. How could anyone catch a ball even?
it works because 99% of the time you don't need fast latency because you can accurately predict things.
that's why a standard recommendation is to drive 2+ seconds (time not distance) behind the car in front of you. also why experienced drivers instinctively move their hands/feet into position during tricky moments when they need to cut the latency.
fun exercise, try taking your foot off the gas and hitting the break - slower than you think!!
https://arstechnica.com/cars/2026/09/aftermarket-driver-assi...
There sure are a lot of those at ground level though.
The drones mostly fly themselves, the operators are just telling them the path, what to look at, and what to shoot at.
Well, if the massive cloud models that are generalized and have a world model that's good enough, you can just distill them into smaller models. As a point of reference, the current gen of Tesla FSD models only have 1B params. They are tiny by LLM/VLM standards.
Maybe if latency can be improved _and_ it can run local inside the vehicle.
SpatialBench - https://x.com/spicey_lemonade/status/2096365630190698516
ZeroBench - https://zerobench.github.io/
Robot Arms - https://openai.robocurve.org/gpt-6-astra/
https://x.com/victormustar/status/2102707412704919910 horse galloping pixel art
https://x.com/LexnLin/status/2102133072585965759 moving train pixel art animation
https://x.com/jkeatn/status/2102441348075057539 painting with code
https://x.com/LCSlates/status/2102503027340988559 video, very detailed prompt though
https://x.com/aj_dev_smith/status/2102504509637587339 generated song/music with code
https://x.com/aj_dev_smith/status/2102575577563570450 another song
Stuff like: - https://x.com/iam_zachi/status/2095992132620136677
Puzzles, games, painting software, robotic control and now driving. I haven't seen any other model fire on all cylinders like that.
It’s mostly a latency problem at this point. The models are too big to run locally, but given that open-weight models like Qwen already exist, an open-weight, low latency equivalent to Astra can’t be too far out.
There's also a very tangible limitation of the bitter lesson.
If, over time, compute climbs, and so compute-bound data-driven general architectures beat bespoke architectures (this is the bitter lesson), then it is not necessarily true that the most general architecture now beats all available bespoke architectures now (or even in the near/mid future - the crossover point is "eventually").
Bitter lesson is most tangible for long-running research directions. Sometimes you need something working as best as possible now.
This is more generalised.
But also since there’s a huge volume of data it’s too expensive to just keep scaling compute up (per car overhead) so there are necessary tricks involved.
I do think having a large model that can do this means that a small specialised model could be distilled form it though. Which is probably the most feasible path to production IMO.
I wouldn't let him loose on the road though.
I think, at the very least, the guardrails would have to deterministic, ideally with super human senses, for people to accept self driving cars on the road.
What's your ARR, anyway?
Unless you mean "a typical AI with all the computation constrained sufficiently to always unfold the same exact way, given the same input". In practice, that just kicks the can to "given the same input" street.
The noise in the system is going to come from the input plane. Which is, I remind you, facing the real world. It's full of noise.
And they've demonstrated adding a sidecar LLM to it as well, mostly for these kinds of "read these 3 street signs, what should i do next?" sort of situations.
Not sure that counts as phenomenally well.
Fifteen crashes - though not to be trivialized - is not a damning number at all in this context. What's more, per the article it's unconfirmed that the crashes are related, so it's hardly fitting to dismiss Tesla's approach based on this.
I think it's great that serious efforts are being made in different approaches to autonomous driving - and in this thread's context, it seems possible that Tesla's approach might eventually be revealed as the optimal approach given modern AI.
And the true third party validation is that insurance companies are starting to offer lower premiums the more you use FSD. So their risk models are showing enough improvement that they're putting their money where their mouths are.
The idea that Tesla's FSD is not ready for the mainstream is quite outdated, given that tons of Tesla owners are already using it daily, not just your early adopter types.
Per mile inside cities or other difficult scenarios are what may get close to an actually meaningful metric. That's why Tesla is very misleading and waymo is much more legit.
This is such an insane take I see all the time from self-driving boosters
If a self driving car glitches out and crashes in some edge case pathological scenario we don't just accept that as totally fine because its hidden under big statistics
The reason why a crash happened does matter, its not just about aggregate statistics
As a thought experiment if I have a perfect self driving system but I add some code that purposefully crashes 1 in 10 million rides are you ok riding in it since the aggregate statistics look good?
Do I know about the purposefully added harmful code? If yes, I would demand you remove it, because why not. If I don't know about the code, I would be OK with it, since it's clearly still more safe than the alternative and apparently cannot be made even better.
You're making it sound like the obvious answer is the irrational one.
Maybe, but the opacity level of models is not acceptable for cars. "Why did it drive under the semi?" "Model said to." "Why did the model say to?" "shrug"
That depends on actual performance of the model. I would prefer an opaque model with clearly superhuman driving abilities to a human, or to a non-opaque model with worse performance.
https://knowyourmeme.com/memes/a-computer-can-never-be-held-...
No self-driving cars that aren't transparent about exactly how they work. (Ideally, no anything that isn't transparent about exactly how it works.)
In our scenario (self-driving), the one who would be ultimately "held accountable" would not be the computer, or the company, but the person who died after singing a waiver/EULA and getting into a statistically superhuman autonomous car, then having a stroke of incredibly bad luck. Such events will happen, but they will be very rare.
Not to mention construction, infrastructure, agriculture, manufacturing, logistics...
--
AI hype cycle? It's working today.
It's optimizing ML model graphs for me while I type this, and it already cut inference time from 30s to 18s.
--
Some people act like there was no way for the AI labs to make back the $800B being invested in data center construction this year.
If we look at global GDP, it's $126T, and even a 5% productivity gain would correspond to $6T.
Is that impossible? Is it guaranteed to all crash? I don't think so.
The only thing DCs will still be need for is training, everything else will be done locally on your own hardware.
This bubble will burst and it will be ugly.
Is this a serious question? Use your imagination...
Also to do the things humans don't even want to do.
It will surely not devolve into the ultimate class war like Elysium and similar.
The robot loses an arm because your factory is unsafe? vs a human losing an arm?
What we're not ready for is replacing GDP as the important metric. There have long been known problems with GDP, and robots are only going to make that worse. A robot maid, purchased once, saves, say 20/hrs a week in household chores. That's a meaningful quality of life upgrade, but doesn't result in the GDP bump that getting a raise and hiring a service to clean your house does.
But this is a bit of a ridiculous take, no?
You don't need Astra for self-driving. Astra is able to build complex 3D worlds, do your taxes, shop for you, and, apparently, drive a car. A self-driving car just needs to be able to drive a car. By the time you trim down Astra to just have the minimum capabilities needed to drive a car, you'll be looking at the same models these self-driving car companies already use. Then you get to deal with the actual hard problems, like handling failure cases (which will still be present with Astra).
>The vision stack, 3D maps, lane selection grammar, occupancy networks, it’s maybe all about to give way to a single GPT looking at camera feeds and predicting the next steering wheel adjustment.
Self-driving cars have been able to do this for a long time. The problem is that it isn't robust enough given the context. I mean, if Astra can drive a car with a single camera, then presumably Astra can drive the car even better with multiple cameras, and even better than that with 3D maps, etc. And when you start to consider the expectation of performance of these systems, you realize that these features really can't be omitted. If you're a company producing self-driving cars, then you do not want to face a lawsuit for you car killing someone because it physically would have never been able to see what it was doing because it lacked a camera.
I think the real gain here is that something like Astra can be used to help build these autonomous stacks. If it is able to drive itself, then it is able to generate novel data, analyze large quantities of data, and use context that isn't typically available when processing this data to make improvements to the actual autonomy stack which is ultimately responsible for driving the car. But thinking that these car companies are going to run an LLM in a car and call it a day is just naive.
Regardless of how the AI is architected, you aren't going to be able to use a generic LLM like Qwen to perform reliable self-driving, you need a highly optimized, highly specific AI.
And the disinclination of these companies to push the weights of their cutting edge models into people’s cars where they can be dumped.
When the models stop improving, we will get model-specific ASICs that are much more power-efficient.
Soo, never? Granted Cerebras is a thing, if the process can be commoditized.
At the moment the area of edge inference at speed seems pretty bleak though.
This is hilarious, and good: Those who were too lazy/stubborn/arrogant to adapt, get disrupted and buried.
https://arstechnica.com/cars/2026/09/aftermarket-driver-assi...
It is easy to make car driving *demos*.
I thought it was because my smaller town was overrun after COVID by transplants, but I'm hearing similar complaints from other places I was considering relocating to.
Perhaps the solution will be robocars where, if there's a potential road rage scenario, the passengers can duke it out in a VR headset session.
https://www-fars.nhtsa.dot.gov/Main/index.aspx
No numbers since 2024 though, so I will assume the best case scenario of zero accidents in 2025 and 2026.
- Aditya, Tobias, Simon
Also, to the extent that the model reasons and thus learns something, if you blindly truncate the front, you will lose that knowledge. In the OP, the LLM that actually navigated the course successfully only did it on the second try. It it forgot the first failed try, it might not have succeeded :)
