Jensen Huang keynote at CES 2025 [video] • Hacker News Board

Re: Jensen Huang keynote at CES 2025 [video]

#101

Post by jononor » Mon, Jan 13, 2025, 1:14 AM UTC

knowitnone wrote: post #49

bgnn wrote: post #44

Earlier quoted context omitted.

5g, wifi, bluetooth etc. what makes a mobile processor monile processor other than the CPU

yeah, those are just modules that anybody can just buy. NVIDIA already makes jetsons which are basically SBCs with decent GPU. so again, what does Mediatek provide?

What do you mean by modules, exactly? In a smartphone, which is the largest market, and where Mediatek is pretty strong, many of those functions are integrated as part of a system on chip. Power consumption also required good interplay between the various subsystems. So it's relatively tightly integrated. You also must have good Android drivers/BSP. And phone vendors are not that interested in changing vendors alle the time. There are also a bunch of patents that one must license, which Mediatek likely already does. Often cross licensing with what is typically competitors (like Qualcomm, maybe even Apple), which takes a bunch of time to set up.

Re: Jensen Huang keynote at CES 2025 [video]

#102

Post by Jedd » Mon, Jan 13, 2025, 4:42 AM UTC

behnamoh wrote: post #74

Jedd wrote: post #65

Earlier quoted context omitted.

This feels like a weird complaint, given you started by saying it was 24GB, and then argued that the person who told you it was actually 32GB was making that up.

Looks like Nvidia did a simple calculation: 32GB (for 5090) / 24GB (for 4090) ≃ 1.33 Then multiply 4090's price by that: $1500 × 1.33 ≃ $2000 All else equal, this means that price per GB of VRAM stayed the same. But in reality, other things improved too (like the bandwidth) which I appreciate. I just think that for home AI use, 32GB isn't that helpful. In my experience and especially for agents, models at 32B paramet…

Yes, home / hobbyist LLM users are not overly excited about this, but

a) they are never going to be happy,

b) it's actually a significant step up given the bulk are dual-card users anyway, so this bumps them from (at the high end of the consumer segment) 48GB to 64GB of VRAM, which _is_ pretty significant given the prevalence of larger models / quants in that space, and

c) vendors really don't care terribly much about the home / hobbyist LLM market, no matter how much people in that market wish otherwise.

Re: Jensen Huang keynote at CES 2025 [video]

#103

Post by imtringued » Mon, Jan 13, 2025, 11:39 AM UTC

contingencies wrote: post #50

As someone who has gone pretty deep in to robotics over the last 9 years I skipped right to the physical AI portion, and wasn't impressed. This has been stated on HN in most robotics threads, but the core of what they show, once again, is content generation, a feature largely looking for an application. The main application discussed is training data synthesis. While there is value in this for very specific use cases…

I wonder if you're missing the forest for the trees though. Google has done all of this already, but in a bespoke manner that is exclusive to Google DeepMind and they have discovered that it works really well.

>Industrial is traditionally all about understanding the problem or breaking it in to unit operations, design, fabricate and control the environment to optimize the process for each of those in sequence, and thus lowering the cost and increasing the throughput.

The thing is, you can do that using SayCan [0] [1]. You give your robot a natural language instruction and that instruction will be broken down to those unit operations and each unit operation is then performed by a robotics transformer model predicting the next action to move the mobile base and end-effector in cartesian space.

What Nvidia is going is just selling you the tools to do it yourself and one of the key parts is adapting simulation video data back into real world camera data. Robotics transformers work just as well as conventional LLMs in practice, but due to the lack of large scale data, they are limited to what they have seen in their training data, with okay performance on unseen tasks. Now here is the thing though, running a robotics transformer in real time is not feasible so far. Even Google's on-robot hardware was running the control loop at 3 Hz, which isn't fast enough.

[0] https://robotics-transformer1.github.io/img/saycan_rt1_demo3...

[1] https://say-can.github.io/img/demo_sequence_compressed.mp4

https://robotics-transformer1.github.io/

https://say-can.github.io/

Re: Jensen Huang keynote at CES 2025 [video]

#104

Post by contingencies » Mon, Jan 13, 2025, 10:22 PM UTC

imtringued wrote: post #103

contingencies wrote: post #50

As someone who has gone pretty deep in to robotics over the last 9 years I skipped right to the physical AI portion, and wasn't impressed. This has been stated on HN in most robotics threads, but the core of what they show, once again, is content generation, a feature largely looking for an application. The main application discussed is training data synthesis. While there is value in this for very specific use cases…

I wonder if you're missing the forest for the trees though. Google has done all of this already, but in a bespoke manner that is exclusive to Google DeepMind and they have discovered that it works really well. >Industrial is traditionally all about understanding the problem or breaking it in to unit operations, design, fabricate and control the environment to optimize the process for each of those in sequence, and th…

you can do that using...

Yes, of course, TMTOWTDI. Respectfully, you sound like an academic or someone with only software-side experience, having less business side comprehension. It's common also with recent grads who often seem to view robotics through a ROS-influenced lens. Stated succinctly, generalist approaches such as robot arm work cells are usually low throughput, high cost, and have numerous limitations (eg. arms can't lift heavy or large items very well). While programming time may be sold as short, the reality is you're building in to a high capex business an avoidable dependence on a software stack which has a half-life of six months where people are hard to acquire and you could buy an objectively superior solution in terms of throughput, accuracy, spatial efficiency and maintainability without these problems.

Case in point: if you look at the build process for any relatively high complexity modern product (phones, cameras, etc.) they generally avoid using arms because they're relatively slow, weak, mandate large motion envelopes with OH&S implications and must be tediously integrated through vendor-linked APIs. There are better building blocks, and they don't involve tokenized fudge-factors. Yes, you could program them this way, no it generally won't add value. Arms are excellent for things like repeat precision welding (due to the high number of axes of motion offering superior approach and tracking options for target parts and sub-assemblies), but control in such cases comes from a combination of prescriptive part models and real time sensors for physical path following and not from AI fudge.