Comment by jyoung8607
4 days ago
I'm not an expert in the LLM space, but I'm an external contributor to comma.ai's openpilot project and I'm and quite familiar with how its controls work, so I looked from that perspective. There's two questions here:
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.
Great point! Yeah latency was one of the biggest issues here. To cope with that (and for safety reasons) the cars are driving at extremely low speeds. They also get timestamps with every tool call output etc so they can, in theory, "in context learn" about their own latency and choose motion durations and control how fast their iteration loop is to some extent. But yeah, this is just sort of a fun benchmark to see how good frontier LLMs are out-of-the-box at driving a real car, and probably not actually practical any time soon.
-Aditya, Tobias, Simon
To clarify my parent comment, I think it was an interesting experiment and seems like it was done well, and it may well be informative about what various frontier LLMs could do with recorded or world model footage.
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.
Is it plausible they can use the large GPT model, to distill a smaller car driving model only from it and then run that onboard. Seems like that will solve all your issues.
3 replies →
What about Waymo's remote controlled cars? Why is this not an issue?
2 replies →
> Could this work in the real world? Absolutely not. Three reasons: latency, latency, and latency.
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.
Let he whomst amongst us, that hath never committed such a sin, cast the first stone.
>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.
Do you mean restarting it? IDK, that would have been my first step too.
> otherwise you can't react
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).
The reaction latency you’re referring to for humans includes perception, planning, and actuation, I’d separate that from the concerns of the hardware, which are mostly about actuation frequency.
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.
In circumstances where one is maintaining grip or muscle tension (e.g. steering a car) I believe human response time can be more like 50ms. Which perhaps unsurprisingly lines up with the 20hz figure pretty close to exactly (we built cars controls so that they're controllable by human reflexes).
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).
Average human reaction time is about 250 ms, or 4Hz. That's still plenty fast for an attentive driver at reasonable speeds. More important, it's consistent when not distracted. Any LLM with latency would be like a driver constantly checking their phone.
2 replies →
I'm not an ornithologist but birds don't need to consume jet fuel to fly hundreds of miles either.
But of course it helps.
3 replies →
> but humans don't need to operate at 20Hz to drive a ca
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.
It's also not subject to signal loss issues like anyone who uses a phone is quite familiar with. Unless you have narcolepsy.
Are you asking for the latency or throughput?
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.
6 replies →
Humans have multiple layers of processing such inputs and your subconscious reacts a lot faster than your conscious train of thought in case something happens (and then you have to 'catch up'). For the same reason that you don't consciously think about what you do when you are walking or how to stop yourself from falling when you stumble. That's all out of the top level and pushed further down to stack, sometimes even multiple levels.
Let's see how well you play counterstrike with a 100 ms ping...
>human reaction latency (event to measurable action) is often over 1s
This is so self evidently false, I struggle to believe you think it is true. How could anyone catch a ball even?
actually, human latency is quite slow and distracted drivers often have 1sec+ latency.
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!!
1 reply →
reaction latency doesn't cover everything. the round trip from trigger to action is a few hundred ms at best, yes, but to enable that we are processing inputs at ~30hz minimum and integrating at ~5hz. you would total your car pretty quickly if you couldn't constantly adjust
Kind of funny to mention comma today of all days
Is that the same comma.ai project also in the news today?
https://arstechnica.com/cars/2026/09/aftermarket-driver-assi...
Perhaps there's a synthesis to be had though. Eyes, control, and safety critical features on the hardware, higher level decision making to the cloud. Openpilot's biggest weakness has always been in the very "robotic" way that it drives, which is technically correct but causes frustration for other drivers. Deciding "should I pass this car" is a fundamentally different question to "can I pass this car", or "what is the actual safe speed and following distance given the current traffic conditions and weather".
What happens when the network flakes out? Cloud will never work for this.
What I'm describing strictly enhances what's already possible, though. You'd degrade back to current performance.
> 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.
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.
Wow, I had no idea that they are so small, that’s incredible! Really goes to show how much visual information can be compressed.
The next gen (v15) is supposedly going to be around 10B.
So a Taalas chip can run Llama 3.1 8B at 17000 TPS...does that mean if we could get Astra at similar speeds we could get self-driving for free?
It is also worth mentioning that the openpilot AI model is a world model. The way a world model understands physical reality and geometry makes it inherently safer for driving than an LLM, which is essentially a text-based statistical machine with no concept of the physical world.
There's also token RTT on top of network latency.. but what if you had a model running at 10k tps (like taalas' llama3b-8
You can see this in the photos, it took over five minutes for the cars to get around the cone course.
Yet remote pilots can fight wars on the other side of the world?
Flying a drone with e.g 1000ms RTT latency is not exactly the same as driving a car on a highway. There are typically less collisions in airspace.. :)
There are fewer obstacles. That's the main reason it works, if you tried flying at 1 m above the ground it would become a lot more like driving, but without the benefit of friction. Flying requires less strict constraints on latency because it happens in straight line segments that are rather longer than the segments that you use when controlling a vehicle.
Not too many trees or pedestrians at 25,000ft, and I haven't seen a stop sign above 14,000ft or so.
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.
API error, endpoint overloaded
How are you so sure that latency can't be improved? Sol can run on cerebras and we may get enough efficiencies that Astra can also be run locally.
Even if latency is improved, it's still a monumental task powering a latency sensitive safety critical system over the internet--especially one that's moving.
Maybe if latency can be improved _and_ it can run local inside the vehicle.
[flagged]
This question reads a little ambiguously. The first way I could read it is that you're genuinely concerned about my mental health as a mainly-volunteer open source developer. The second way to read it is a direct accusation. Can you please clarify?
I'm not that commenter, but I wouldn't were I that person. There's a lot more self-responsibility involved with a Comma system than what Tesla advertises as "Full self Driving." It's the difference between blaming Ford for bad factory breaks versus aftermarket parts the consumer made themselves.