AI Engineer World's Fair 2025
What Is a Humanoid Foundation Model? An Introduction to GR00T N1
Read the talk
What Is a Humanoid Foundation Model? Inside GR00T N1
GR00T N1 connects visual understanding and language instructions to robot motion, using scarce demonstrations, synthetic data, and an architecture designed to adapt across robot bodies.
From a talk by Annika Brundyn and Aastha Jhunjhunwala
Before you start: Basic familiarity with neural networks and tokens is helpful; the article introduces robot states, actions, and the two learning approaches.
Intelligence still needs to act in the world
What happens when there is more physical work to do than people available to do it? Annika Brundyn and Aastha Jhunjhunwala, members of NVIDIA’s GR00T N1 team, open with that question. The motivating McKinsey chart covers 30 advanced economies: vacancies per unemployed person increased 4.2× between 2010 and 2023. That is a measure of labor-market tightness, not total job growth; more vacancies than unemployed workers occurred in seven of those economies, rather than across all 30.
The highlighted sectors make the engineering problem concrete: leisure and hospitality, healthcare, construction, transportation, and manufacturing. These jobs involve instruments, objects, and physical environments. A language model can help interpret an instruction, but text generation alone cannot carry it out. Physical AI must turn understanding into action.
Why give that intelligence a human-shaped body? Doors, workspaces, tools, and appliances were built around people. Brundyn’s rationale is that a compatible physical form makes a generalist robot easier to fit into those environments—not that every useful robot must be humanoid. The barista robot downstairs provides the contrast: it makes good espresso, but it cannot even cook rice. Excellence at one physical task does not automatically transfer to another.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Three workloads, from data to deployment
Building such a robot involves a repeating lifecycle: collect or generate data, train a model on real and synthetic examples, and deploy it on the robot. NVIDIA calls this the three-computer problem because each stage puts different demands on the hardware.
| Stage | Workload | Hardware example |
|---|---|---|
| Generate data | Simulate environments and interactions | OVX / Omniverse |
| Train | Learn from large collections of examples | DGX |
| Deploy | Run an efficient model at the edge | AGX |
Training can consume substantial centralized compute. Deployment imposes a different constraint: the model must be small and efficient enough to operate on the available edge device. These are workload examples, not a deployment recipe.
Project GR00T encompasses the compute infrastructure, software, and research needed for humanoid and other robots. GR00T N1 is the foundation model within that larger effort, announced at GTC in March 2025. The speakers describe it as open source and customizable. They round its size to two billion parameters; the paper specifies 2.2 billion. That is modest beside large language models but substantial for a robot. Its central promise is adaptation: start with shared foundation knowledge, then fine-tune for a particular robot body—its embodiment—and use case.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
There is no internet of robot actions
The data pyramid starts with a shortage. Language models can learn from enormous collections of text, but robotics has no comparable internet-scale collection of robots successfully performing tasks with corresponding action records. At the pyramid’s narrow top are real demonstrations: a human teleoperates a robot, perhaps using an Apple Vision Pro and gloves, and records the robot completing the task. These examples directly connect observations and actions to successful physical behavior.
That direct relevance comes at a cost. A robot and its operator occupy real time and equipment, and both need downtime. The slide’s 24 hours per robot per day is an illustrative upper limit, not achieved collection throughput. At the pyramid’s broad base, internet video offers abundance: a cooking tutorial may show a person solving exactly the kind of task a robot should learn. But it does not automatically supply the robot’s joint states or action labels. Human video is useful evidence about tasks, not a ready-made robot demonstration.
Synthetic data occupies the middle. A GPU can keep generating examples, but building a high-quality simulation environment requires skilled work. Another route starts with the teleoperation trajectories already collected and uses fine-tuned video or world foundation models to multiply them. Both the quality of that multiplication and the effective mixture of simulated and real examples remain research problems.
Brundyn introduces DreamGen as a recent Computex announcement in this data-generation effort. Its documented pipeline makes an essential bridge explicit: generated robot videos receive pseudo-action labels before they are used for policy learning. Generating a plausible-looking video alone does not produce commands a robot can execute. The larger data strategy combines task-grounded demonstrations, abundant human video, and synthetic examples rather than expecting any one source to solve the shortage.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Pick up the object and put it in the yellow bin
Jhunjhunwala makes the model’s interface concrete with an industrial pick-and-place task. The input consists of an image observation, the robot’s current state, and a language instruction to pick up the industrial object and place it in the yellow bin. The output is a robot action trajectory. In the demonstration, the arm picks up the object and places it in the bin.
To a person watching, the output looks like a hand moving through space. At the control interface, it is a sequence of floating-point vectors that control the robot’s joints. Those numerical commands produce continuous motion. The distinction between state and action is temporal: state describes the robot’s situation now; action specifies what it should do next. Images provide visual context alongside that numerical state. A successful instruction-following model must connect all three inputs to usable motion, not merely describe what a successful motion would look like.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
From slow interpretation to fast motor actions
The architecture borrows its organizing analogy from Daniel Kahneman’s Thinking, Fast and Slow. System 2 interprets the task and supplies the context needed to act; the talk describes it as a slower planner that breaks complex work into simpler work. System 1 produces fast actions conditioned on that understanding. Jhunjhunwala describes System 1 as operating at almost 120 Hz; the paper identifies 120 Hz as the motor-action rate, not the frequency of a complete model inference. The planner analogy explains the division of labor without requiring a separate textual plan between the two systems.
Inside the action system, a state encoder converts the robot state into tokens, while an action encoder processes a noised action sequence. The talk relates that noise to imperfect sensors, but the published mechanism is deliberate flow-matching noise: training mixes demonstrated actions with sampled Gaussian noise. The model learns how to move from noise toward an action trajectory conditioned on the observations and instruction. Sensor error is a separate issue.
For the yellow-bin task, one training example therefore contains the observed scene, the current robot state, the instruction, and the demonstrated sequence of action vectors. The following Python expresses the noise-mixing operation on that action sequence. Here, t = 0 selects noise and t = 1 selects the demonstrated actions; target_velocity describes the direction between them.
python
import torch
def flow_matching_batch(expert_actions: torch.Tensor):
# expert_actions: [batch, trajectory_length, action_dimensions]
noise = torch.randn_like(expert_actions)
t = torch.rand(
expert_actions.shape[0], 1, 1,
device=expert_actions.device,
dtype=expert_actions.dtype,
)
mixed_actions = (1 - t) * noise + t * expert_actions
target_velocity = expert_actions - noise
return mixed_actions, t, target_velocity
This operation creates a training input and target; it does not execute the pick-and-place task. The encoded state and action tokens then enter a diffusion transformer with layers of self-attention and cross-attention.
The other branch supplies visual and language context. A vision encoder processes the image, and a text tokenizer processes the instruction. Their representations pass through Eagle 2, the vision-language model used in N1. Its output tokens condition the diffusion transformer through cross-attention. In the yellow-bin example, this connects the action-generation process to the scene and the requested destination. The action system does not generate motion independently of what the robot sees or what the user asked.
The transformer’s output tokens still are not commands for physical hardware. An embodiment-specific action decoder converts them into action vectors appropriate to the target robot, whether that is a humanoid hand or an industrial arm. The paper’s adaptation process also includes embodiment-specific state and action encoders and post-training; replacing the decoder alone is not the entire adaptation procedure. Shared representations make it possible to learn across embodiments, while the interfaces and adaptation connect that knowledge to one robot’s actual motion space.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Copy an expert or optimize a reward
Two broad approaches help explain how robot behavior is learned. Imitation learning uses expert demonstrations as the reference: the policy learns to match expert behavior. Reinforcement learning uses trial and error to optimize a reward, rather than requiring the policy to match a particular demonstrated trajectory.
Jhunjhunwala compares imitation to being told to behave like an older sibling: there is a specific exemplar to match. Reinforcement learning instead gives an objective to pursue. Each approach shifts the practical bottleneck.
| Approach | Learning signal | Main challenge highlighted |
|---|---|---|
| Imitation learning | Expert demonstrations | Expensive, scarce expert data |
| Reinforcement learning | Reward from attempted behavior | Transfer from simulation to reality |
The simulation-to-reality gap matters when reinforcement learning happens in simulation: behavior that earns reward in a modeled environment must still work with real physics, sensing, and hardware. The talk says N1 used both approaches in some ways, without identifying a reinforcement-learning component or stage. The published N1 training account establishes flow matching, so that broad remark should not be read as a specified RL training recipe.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
What the trained model demonstrates
The demonstration montage moves from kitchen pick-and-place tasks to a flowers-and-champagne scene, then to two robots performing industrial manipulation beside yellow bins. The polished social scene comes with a useful qualification: Jhunjhunwala acknowledges the fallen glasses and flowers behind the successful capture. A successful clip shows a capability, but not its reliability across attempts. The two-robot scene likewise shows an industrial task without establishing a particular coordination algorithm.
These examples illustrate why a reusable base model is appealing: related manipulation skills can support different settings and downstream tasks. Extending the model to other tasks and environments is the foundation-model ambition. The montage does not establish that the same checkpoint can already perform any task in any environment without further adaptation.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Train the connection, then adapt the model
The closing discussion returns to the missing internet of action data. Simulation, teleoperation, and expert demonstrations are ways to build the experience from which a robot can learn. But collecting that experience is only part of the problem: the system that understands the instruction must also work coherently with the system that produces motion.
Co-training connects interpretation to action. Jhunjhunwala contrasts separately trained components, which can disagree, with N1’s joint optimization of System 1 and System 2. The goal is to improve the stack together rather than optimize each piece in isolation. Joint optimization does not mean every parameter changes: the paper freezes the language component during pre-training and post-training.
The resulting foundation knowledge is a starting point for adaptation, much as a base Llama model can be fine-tuned for a domain. In robotics, adaptation must account for both the downstream task and the body that performs it. GR00T N1’s generalist ambition is therefore a reusable learned foundation with interfaces and training that connect it to different embodiments—not a finished collection of specialist routines, and not a guarantee of universal physical competence.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Explains how video world models generate robot videos and how pseudo-action labels make them useful for policy training.
Research repository for the Eagle model family, with Eagle 2 references, model listings and later developments.
Further reading
Original architecture, training methods and evaluations for GR00T N1.
Launch-era overview of N1, its data pyramid, and the workflow from demonstration preparation to robot evaluation.
Updates since the talk
Current GR00T code and installation, fine-tuning and deployment instructions. The README now targets N1.7 rather than the talk's N1.
Read the complete timestamped transcript
- 0:00
[on hold music] Hi everyone, I'm Annika.
- 0:17
Uh, this is Aastha. We both work at NVIDIA, and we were part of the team that developed the GR00T N1, uh, robotics foundation model. So today, we're gonna give you a sense of what that is and, and how you go about building a robotics foundation model.
- 0:31
But before we get into it, uh, I feel like a lot of people start talks here with a hot take. Uh, so the hot take that I'm bringing to an AI conference is that we're not necessarily running out of jobs.
- 0:42
Uh, so this was a report done by McKinsey, uh, part of their global institute, showing that in the world's 30, uh, most advanced economies, there's actually too many jobs, uh, for the number of people that could fill them.
- 0:56
And really the two things you should look at in this whole graph is the 4.2x, that's been the, the rate at which we're getting more jobs than people could fill it over the last decade, and this line that I'm highlighting in red, that's where we're in trouble, where there's just more jobs than able-bodied people to fill those
- 1:12
jobs. Uh, and obviously, uh, there's a real conversation around AI and jobs, so it helps to look at what industries, uh, are h- largely affected. I'm gonna highlight a couple in red.
- 1:24
So leisure, hospitality, healthcare, construction, transportation, manufacturing. Um, I, I guess you can figure out what they have in common. None of them can be solved by ChatGPT alone. Uh, they require operating instruments, uh, and devices in the physical world, uh, and they require physical AI.
- 1:45
So that's, that's really the big challenge, uh, that I see over the coming years, is how do we take this huge amount of inte- intelligence that we're seeing in language models, um, and make it operable in the, in the physical world.
- 1:57
The other question around humanoids is: Why do we build them to look like humans? Um, it's not just because we want them to look like us. The world was made for humans.
- 2:06
Uh, it's very hard to have generalist robots operate in our world and be generally useful, uh, without copying our physical form. Uh, there's a lot of specialist robots that do incredible things.
- 2:18
I don't know if you got to try the espresso, uh, from the barista robot downstairs. Makes a good espresso. Uh, but that robot couldn't even cook rice. [chuckles] So if we want a robot that can do multiple tasks for you, um, it's just a lot easier to try and imagine that that robot, uh, can operate in, in our
- 2:35
human world. So how do we do this? There's three big buckets, three big stages. First one is data, collecting or generating or multiplying data, which we'll talk quite a lot about.
- 2:47
Um, and now that you have this synthetic and, and real data, but largely synthetic data, uh, you train a model. We'll also talk about what that architecture and, and training paradigm looks like.
- 2:58
And then finally, we deploy, uh, on the robot, uh, or at the edge. Uh, this is what we call the physical AI life cycle, so generate the data, consume the data, and then finally deploy and, um, have this robot operable in the physical world.
- 3:15
NVIDIA also likes to call this the three-computer problem, because they have very different compute characteristics. So at the simulation stage, you're looking for a computer that's powerful at simulating, something like an OVX Omniverse machine.
- 3:28
Um, there's a lot of really interesting work happening on the simulation side, but that has a very different type of, uh, workload than when we're training and we're using a DGX to just consume this enormous amounts of data and, and learn, learn from that.
- 3:42
And then finally, when we're deploying at the edge, it needs to be a model that's small enough and efficient enough, uh, to run on an edge, edge device, uh, like an AGX.
- 3:52
Um, and really this is, this is Project Root. So Project Root is NVIDIA's strategy, uh, for bringing humanoid and other forms of robotics, uh, into the world, and it's everything from the compute infrastructure to the software to the research that's needed.
- 4:07
It's not simply, um, just one foundation model. But that is what we'll be fo- focusing on in this talk because, uh, that's what, what we worked on. Uh, so the GR00T N1 Foundation model was announced at GTC in March.
- 4:20
Uh, it is open source, uh, it is highly customizable, um, and a very big part of it that is cross-embodiment. So basically, you can take this base model, uh, the specific embodiments that we have fine-tuned for, uh, but the whole premise is that you can take this base model, it's a two billion parameter model, which in the
- 4:36
world of LLMs is tiny, but still pretty sizable for a robot, um, and then go and, go and modify it for your embodiments, your use cases. So let's start with the first huge, daunting task in the world of robotics:
- 4:50
data. Um, when, when the GR00T team actually started thinking about data, uh, they put together this idea of the data pyramid, which is very elegant, but it was born out of desperation and necessity.
- 5:03
Um, the data you want does not exist in quantities. There's no-- there is no internet-scale, uh, dataset to scrape or download or put together because, uh, robots ha- haven't made it YouTube yet.
- 5:15
Uh, so really at the top of the pyramid, we have the real world data, which is robots doing things, real robots doing real tasks and solving them. Um, and how it's collected is humans teleoperate a robot most of the time.
- 5:27
So wearing, uh, like an Apple Vision Pro and wearing gloves. There's all kinds of ways to teleoperate the robot. But you have a real robot successfully completing a task, and then you have that ground truth data. [lip smack]
- 5:39
So you can imagine this is very small in quantity, very expensive, um, and we put 24 hours per robot per day 'cause that's how many hours a human has.
- 5:49
But the reality is that humans and robots get tired, uh, so it's not even 24 hours. Uh, so really this is, is very, very limited dataset. Uh, and then at the bottom of the pyramid, we have the internet.
- 6:00
So we have- Huge amounts of video data, and it's typically humans solving tasks. So you can imagine someone collecting a cooking video tutorial, uh, and putting that out there.
- 6:12
Uh, with this unstructured data, it's not necessarily relevant to robots, um, but there is some value in that, so we, we didn't wanna completely discard it. It, it forms part of this cohesive data strategy.
- 6:23
Uh, and then f- in the middle, synthetic data. Uh, and this is, this is a topic that could fill this whole entire talk, and I've cut down so many slides on, on just this section because in theory, this is infinite, right?
- 6:37
You could just let the GPU keep generating more data. Um, but in practice, creating high quality simulation environments is very labor-intensive, and it requires serious skill. Um, and then on top of that, uh, the other technique, which I will share a little bit about...
- 6:54
Oh, sorry. Let me go one back. Uh, is, is taking the human trajectories that we do collect, so human teleoperation data, and trying to multiply it, um, through essentially video generation models, so through world foundation models that we fine-tune to do this task.
- 7:10
Uh, but even in that case, there's, there's a lot of active research in how we take the little bits of high quality data that we have and multiply it, as well as how we, uh, s- effectively combine, uh, simulation data with this real world data.
- 7:24
Uh, so this is DreamGen. This was something that was announced at Computex, uh, very recently. Uh, all in all, this data piece is a huge part of what the Project GR00T is about.
- 7:35
Um, so there's many, many solutions here in terms of the teleop, uh, and the data strategy. But for now, the next piece is, how do we bring all this data into an architecture?
- 7:45
Uh, so I'm gonna hand over to Aastha to explain that part.
- 7:48
Thank you, Annika. Um, do you guys hear me? All right. Awesome. Uh, so before we dive into... Thank you. Before we dive into the architecture, I'm going to show to you what an example input looks like and what an example output looks like.
- 8:03
So what you see here is the image observation, the robot state, and the language prompt. That's the input. And then what's the output? The output is a robot action trajectory.
- 8:14
So the prompt was to pick up the industrial object and place it in the yellow bin, and that's what the robot does. It picks up and places it in the yellow bin very neatly.
- 8:23
But this is what it appears to us as humans, but is the robot or the humanoid seeing the same? Not really. The humanoid sees this. It sees a bunch of vectors, floating point vectors, which control the different joints.
- 8:39
So you're seeing the output as a trajectory, which is like motion of the robot hand, but that's not what the robot is seeing. It uses these vectors to actually generate a continuous action.
- 8:51
And to set context on what a robot state and action is, you can imagine the state is the robot's snapshot at an instant, instance of time. So including the physique of the robot and the environment, that's the state, and then the action is what the robot decides to do next based on the state.
- 9:12
So moving on and diving a bit deeper into the architecture. The GR00T N1 system introduced a very interesting concept, and this concept is inspired from Daniel Kahneman's book, Thinking, Fast and Slow.
- 9:27
Uh, show of hands, how many of you have read the book? Amazing. That helps to explain. So it's inspired by the same concept, but it has-- it's applied to a robotics con- context.
- 9:39
So we have two systems, System 1, System 2. System 2, you can imagine, is the brain of the robot or the brain of the model. So that's the part which is actually trying to break down the complex tasks, so make it simpler such that the System 1 can execute on it.
- 9:57
So you can think of System 2 as the planner, which executes slowly to break down the complex task, and then System 1 is the fast one. It operates almost at 120 hertz, and it basically executes on the task that System 2 puts out for it.
- 10:13
And then now we're going to delve another level deeper into the architecture, and it's okay if all of this is complicated to you because it's not very straightforward. [chuckles] So we have the input as the robot state and the noised action.
- 10:27
You must be wondering why we've called it noised action. Noised action is a natural state because these sensors don't capture the action perfectly, so we have noised action. Uh, and then they're passed to a state encoder and an action encoder, which generate some tokens.
- 10:43
Uh, and, um, you may be familiar with tokens. We've talked about LLMs, agents a lot, so the same concept, but just different kinds of tokens, so state tokens, action tokens.
- 10:55
And then it's passed through a diffusion transformer block, and the diffusion transformer block is essentially, um, multiple layers of cross-attention and self-attention.
- 11:06
And bringing in the other piece, which is the vision input and the text input. So you have the vision encoder, which takes the image input, generates some tokens, passes it to the VLM to bring it to, like, a standardized encoding format, and then the text tokenizer, which takes the text input, again, does the same, passes through the
- 11:25
VLM. And then all of this, uh, all of the output tokens from the VLM, uh, in this case, in case of GR00T N1, it was the Eagle 2 VLM, is passed into the cross-attention, uh, layer of the diffusion transformer block, and then you get some output tokens.
- 11:44
These are the output tokens. Uh, but these output tokens are still not ready to be consumed by the physical robot, so you need to make it consumable by the physical robot.
- 11:55
And that's where you have this key piece called the action decoder. So it, it may seem like there's lots of encoders, lots of decoders, but you can say that the action decoder is the one which gives the model capability to be a generalist.
- 12:09
So you're giving it an action decoder which is specific to the embodiment that you're going to use, whether it's a humanoid hand or a robot arm, an industrial robot arm, that's where that action decoder comes into place.
- 12:21
It's specific to the embodiment you're trying to use. And then it's going to translate it specific to your embodiment and output an action vector, which can be translated into continuous robot motion or embodiment motion.
- 12:36
Just going to give you a second to digest all of this. Uh, so you can see that the action decoder is very, very important because otherwise you would only be able to train a model for one specific embodiment.
- 12:47
But this model can leverage foundation knowledge from all different, um, embodiments and then bring it to one particular embodiment. The concept,
- 12:57
the concept is similar to the concept of a foundation model, essentially. Uh, moving on to the next slide.
- 13:06
There are two main ways of robot learning. Uh, and the reason I chose to keep this slide is because it came up a lot in the conversations I was having the past couple of days.
- 13:16
Uh, there are two ways of training robots. One is imitation learning, and the other is through reinforcement learning. Imitation learning, uh, in simple English terms, imitation means to copy someone, like learn by copying.
- 13:33
That's exactly what's happening here. So you have a human expert, and the robot is trying to copy the human expert, and, uh, you're trying to minimize the loss between the expert and the human.
- 13:44
So you have a gold standard, you're trying to match up to the gold standard. And then in case of reinforcement learning, it's more of a trial and error format.
- 13:52
So what you're doing is you just, uh, maximize the reward. So you don't have a golden state, you're trying to just reach wherever you can, the best you can.
- 14:02
You can think of it similar to having siblings. When there are siblings, parents try to compare between the two, and they're like, "You need to be like your elder sibling."
- 14:10
But then there's no sibling, and in that case, you can just be as good as you want. [laughing]
- 14:15
So, so that's reinforcement learning for you. And like all things good and bad in this world, both of them come with pros and cons. Uh, with the imitation learning, you're severely bottlenecked by the expert data, which is quite expensive.
- 14:28
Uh, but in case of reinforcement learning, you don't have that bottleneck, but it's... the key challenge is the sim to real. So there's a huge gap between going from sim to real, and it's a active area of research.
- 14:40
A lot of research labs, uh, universities are going behind it. So that was the two ways of training robots, and, uh, GR00T N1 used both of these in some ways.
- 14:51
Um, here is an example of the trained model. What can it do? So on the left, you see the model being able to do a few pick and place tasks in the kitchen.
- 15:02
On the right top, uh, you can see with enough training, the model can be taught how to be romantic as well. Uh, you don't see all the fallen champagne glasses and fallen flowers which be-went behind capturing this perfect snap.
- 15:16
Uh, and then the bottom right, uh, is two robot friends trying to get, uh, do an industrial task, like a pick and place task again. But these are not, um, the only tasks that these, these humanoids or robots can be do- can be doing.
- 15:29
They can be extended to any task, any environment, uh, and that's why we have a foundation model, a generalist foundation model, which can be expanded to any downstream task.
- 15:42
So this is going to be my conclusion. Uh, there are three core principles that we spoke about today, and each of these is very hefty by itself. Uh, but primarily the data pyramid.
- 15:57
Annika spoke about this. In case of LLMs, uh, or text data or text models, you have the whole internet which you can be scraping to generate data, but there's no such internet scale data for actions.
- 16:10
So that is one of the key challenges that you need to address, either via simulation or by imitation learning, ge-generating expert data, teleoperation, all sorts of things. The next thing is the dual system architecture.
- 16:23
Uh, previously what used to happen was each of these components was trained independently, and that resulted in some kind of disagreement between the two systems. The GR00T N1 introduces this coherent, uh, architecture where both the System 1 and System 2 are being co-trained, and that kind of helps to optimize the whole stack instead of ident- individually trying
- 16:48
to train, train the pieces. And then the third piece and the final piece, uh, is the generalist model. So in case of the generalist model, you are able to leverage foundation knowledge from the model and extend it to different embodiments, different tasks.
- 17:05
You're-- You can think of it like how you have, in case of large language models, you have a base foundation Llama 2, 70 B model, or there's Llama 4 now or Llama 3.
- 17:15
I, I don't know which is the latest. But you can extend it, uh, to any fi... You can fine-tune it to any task or, like, domain adapt it. Similarly, you have the GR00T N1 model, which can be adapted to any embodiment and any downstream task.
- 17:30
Thank you so much for attending our talk today. Uh, we're really happy you were here. Uh, please let us know if you have questions. We'll be outside hanging out.
- 17:38
Uh, thank you so much. We appreciate it. [clapping] [upbeat music]