Inference dominates the lifetime compute cost of AI models, making it a central concern for AI companies. Serving involves distinct prefill and decode phases with very different computational profiles, and several key metrics determine user experience and system efficiency. Efficient inference depends on understanding arithmetic intensity and roofline limits, then applying innovations at the model, kernel, runtime, and system levels. Techniques range from quantization and attention variants to caching, routing, and speculative decoding.
Suy luận chi phối chi phí tính toán trong suốt vòng đời của các mô hình AI, khiến nó trở thành mối quan tâm trung tâm của các công ty AI. Việc phục vụ bao gồm hai pha riêng biệt là prefill và decode với các đặc điểm tính toán rất khác nhau, và một số chỉ số chính quyết định trải nghiệm người dùng và hiệu quả hệ thống. Suy luận hiệu quả phụ thuộc vào việc hiểu cường độ số học và giới hạn roofline, sau đó áp dụng các đổi mới ở cấp độ mô hình, kernel, runtime và hệ thống. Các kỹ thuật trải rộng từ lượng tử hóa và các biến thể attention đến caching, routing và speculative decoding.
music - How's everyone doing today?
[nhạc] - Mọi người hôm nay thế nào?
Woo!
Woo!
All right, it's inference night.
Được rồi, đêm nay là đêm suy luận.
Come on, you got to get excited.
Nào, mọi người phải hào hứng lên chứ.
Okay, I didn't really know how to uh to represent an inference in a pictorial, so I did Halloween.
Okay, tôi thực sự không biết làm thế nào để uh biểu diễn một suy luận bằng hình ảnh, nên tôi đã làm Halloween.
So, I made it uh spookier, as my 3-year-old would say, pookie.
Vậy nên, tôi làm nó uh đáng sợ hơn, như đứa con 3 tuổi của tôi sẽ nói, pookie.
Um this is my wife over here.
Um đây là vợ tôi ở đằng kia.
Okay, so why inference?
Okay, vậy tại sao lại là suy luận?
Who cares about inference?
Ai quan tâm đến suy luận chứ?
Um well, I think we do a lot of inference investments at YC.
Um thì, tôi nghĩ chúng tôi thực hiện rất nhiều khoản đầu tư vào suy luận tại YC.
We look at this a ton.
Chúng tôi xem xét điều này rất nhiều.
Um I used to run an AI company where I would train and we would do a lot of inference, and inference was always the bottleneck.
Um tôi từng điều hành một công ty AI nơi tôi huấn luyện và chúng tôi thực hiện rất nhiều suy luận, và suy luận luôn là nút thắt cổ chai.
It's so hard to do inference well at scale and without losing your shirt on cost of goods sold, uh a term called COGS, as some people in software are unaware what that word means.
Thật khó để làm suy luận tốt ở quy mô lớn mà không mất áo vì giá vốn hàng bán, uh một thuật ngữ gọi là COGS, như một số người trong phần mềm không biết từ đó có nghĩa là gì.
Um and so far, in just the last 10 years, it's produced 220 billion dollars of market cap.
Um và cho đến nay, chỉ trong 10 năm qua, nó đã tạo ra 220 tỷ đô la vốn hóa thị trường.
Um and we have two really cool companies Sorry, we have about three four really cool companies talking tonight.
Um và chúng tôi có hai công ty thực sự tuyệt vời Xin lỗi, chúng tôi có khoảng ba bốn công ty thực sự tuyệt vời sẽ nói chuyện tối nay.
Um And number eight here, actually, together, we have the head of research, Dan Foo.
Um Và số tám ở đây, thực ra, cùng nhau, chúng tôi có trưởng bộ phận nghiên cứu, Dan Foo.
Um and so, why is inference important?
Um và vậy, tại sao suy luận lại quan trọng?
Why does this really matter?
Tại sao điều này thực sự quan trọng?
Uh the only the this compa- I like to think about it from a comparison of train flops versus inference flops, and the only uh company that actually publishes all their uh data is DeepSeek.
Uh công ty duy nhất- Tôi thích nghĩ về nó từ so sánh flops huấn luyện so với flops suy luận, và công ty duy nhất uh thực sự công bố tất cả dữ liệu của họ là DeepSeek.
And so, just to think about the ratio of how much we should care about train flops versus inference flops, um uh uh DeepSeek reports that it took about
Và vậy, chỉ để nghĩ về tỷ lệ chúng ta nên quan tâm đến flops huấn luyện so với flops suy luận như thế nào, um uh uh DeepSeek báo cáo rằng mất khoảng
2.8 uh million H1 H800 hours to train uh DeepSeek V3, and they do about 43,000 H800 hours per day, and that's like old data, right?
2,8 uh triệu giờ H1 H800 để huấn luyện uh DeepSeek V3, và họ thực hiện khoảng 43.000 giờ H800 mỗi ngày, và đó là dữ liệu cũ, phải không?
This is not recent data.
Đây không phải là dữ liệu gần đây.
So, it's probably much more than that.
Vậy nên, có lẽ còn nhiều hơn thế.
But even those numbers is about 6x more flops on inference than train for that weight file per year.
Nhưng ngay cả những con số đó cũng cho thấy flops suy luận nhiều hơn khoảng 6 lần so với huấn luyện cho tệp trọng số đó mỗi năm.
And if you believe the useful life of a weight file, I don't know, say 2 years, then it should be 12x more important.
Và nếu bạn tin vào tuổi thọ hữu ích của một tệp trọng số, tôi không biết, giả sử 2 năm, thì nó sẽ quan trọng hơn 12 lần.
And as more users of the that weight file come online as AI is proliferating, then it actually gets more and more important.
Và khi càng nhiều người dùng tệp trọng số đó trực tuyến khi AI đang lan rộng, thì nó thực sự ngày càng quan trọng hơn.
And so, I think about this a lot when
Và vậy, tôi nghĩ về điều này rất nhiều khi
I'm writing papers and things like that, but the train flops that when you're doing a selection across different models in your Nerf paper, you should be looking to minimize train flops, yes, but 12 times more you should care about inference flops.
tôi viết bài báo và những thứ tương tự, nhưng flops huấn luyện khi bạn thực hiện lựa chọn giữa các mô hình khác nhau trong bài báo Nerf của bạn, bạn nên tìm cách giảm thiểu flops huấn luyện, đúng, nhưng quan trọng hơn 12 lần là flops suy luận.
But typically, this is like the Chinchilla paper, for example, in the x-axis for most Nerf papers, you're going to see just train flops to be ISO train flops.
Nhưng thông thường, giống như bài báo Chinchilla, ví dụ, trên trục x cho hầu hết các bài báo Nerf, bạn sẽ chỉ thấy flops huấn luyện để ISO flops huấn luyện.
We should really start caring about ISO inference flops.
Chúng ta thực sự nên bắt đầu quan tâm đến ISO flops suy luận.
Um and then, yeah, for the people that have done SAS, they don't know what COGS means, but it really matters if you are a model server.
Um và sau đó, vâng, đối với những người đã làm SAS, họ không biết COGS nghĩa là gì, nhưng nó thực sự quan trọng nếu bạn là một máy chủ mô hình.
And if you just these are some numbers that came out yesterday, some people kind of were shocked that their margins could be this good, but it implies that Deep Seek's margins are 80% and it's because they have innovated so much on the inference side.
Và nếu bạn chỉ đây là một số con số được đưa ra hôm qua, một số người đã khá sốc rằng biên lợi nhuận của họ có thể tốt như vậy, nhưng nó ngụ ý rằng biên lợi nhuận của Deep Seek là 80% và đó là vì họ đã đổi mới rất nhiều ở phía suy luận.
Um well, first of all, why is it so complicated?
Um thì, trước hết, tại sao nó lại phức tạp đến vậy?
It's just like model.forward.
Nó chỉ giống như model.forward.
This is it's not that hard.
Đây không phải là khó lắm.
Um it's actually really, really hard.
Um nó thực sự rất, rất khó.
And so, there's some for the non-LLM people in the in the crowd, basically what happens is you get served some prompt, some set of tokens, token IDs, and then you have to call prefill, and you'll run that on the the initial prompt.
Và vậy, có một số đối với những người không phải LLM trong đám đông, về cơ bản điều xảy ra là bạn được phục vụ một số lời nhắc, một tập hợp các token, ID token, và sau đó bạn phải gọi prefill, và bạn sẽ chạy nó trên lời nhắc ban đầu.
If you already
Nếu bạn đã
have some of that pre-cached, you should, you shouldn't run prefill again if you've already done it.
có một số phần đã được lưu trữ trước, bạn nên, bạn không nên chạy prefill lại nếu bạn đã làm rồi.
And and even better, if it's if it's hot in uh, in um, DRAM or if it's in some Redis cache, some uh, um, SSD somewhere.
Và và thậm chí tốt hơn, nếu nó nóng trong uh, trong um, DRAM hoặc nếu nó trong một bộ nhớ đệm Redis nào đó, một số uh, um, SSD ở đâu đó.
And then uh, uh, so make sure make so that you do some LRU cache kind of thing like that.
Và sau đó uh, uh, vậy hãy đảm bảo rằng bạn thực hiện một số loại bộ nhớ đệm LRU như vậy.
So this is already a big opportunity for savings.
Vậy đây đã là một cơ hội tiết kiệm lớn.
And then after that you'll have this decode loop.
Và sau đó bạn sẽ có vòng lặp giải mã này.
And if you think about uh, we'll define these terms in a second, but like model flop utilization, like how much of the GPU you're really using for a train and prefill.
Và nếu bạn nghĩ về uh, chúng ta sẽ định nghĩa những thuật ngữ này trong giây lát, nhưng như mức sử dụng flop của mô hình, như bạn thực sự đang sử dụng bao nhiêu GPU để huấn luyện và prefill.
And in train time you're almost always doing uh, prefill is essentially the same thing.
Và trong thời gian huấn luyện bạn hầu như luôn thực hiện uh, prefill về cơ bản là điều tương tự.
Your um, MFU might be 50%.
Um, MFU của bạn có thể là 50%.
So if Jensen Huang is guaranteeing you 2 trillion FP8 flops, you're not getting that.
Vậy nếu Jensen Huang đảm bảo cho bạn 2 nghìn tỷ flops FP8, bạn không nhận được điều đó.
It's just not even
Nó thậm chí không
close.
gần đúng.
Maybe you get half of that.
Có lẽ bạn nhận được một nửa trong số đó.
That'd be great if you can get half of that.
Sẽ thật tuyệt nếu bạn có thể đạt được một nửa con số đó.
And in decode it's even worse.
Và trong phần decode thì còn tệ hơn nữa.
It might be like 5% or something like that.
Có thể chỉ khoảng 5% hoặc đại loại như vậy.
Um, and so it's really important that you're you're careful with these things.
Ừm, và vì vậy điều thực sự quan trọng là bạn phải cẩn thận với những thứ này.
And so the terms of art, the things that KPIs that um, Dan Fu and others are constantly trying to optimize is time to first token.
Và vậy nên các thuật ngữ chuyên môn, những thứ mà các KPI mà ừm, Dan Fu và những người khác liên tục cố gắng tối ưu hóa chính là thời gian đến token đầu tiên.
So this is how long it takes takes to get through prefill.
Vậy đây là thời gian cần để đi qua giai đoạn prefill.
And then uh, time per output token or time per decode step um, to produce the next token.
Và sau đó ừ, thời gian trên mỗi token đầu ra hoặc thời gian trên mỗi bước decode ừm, để tạo ra token tiếp theo.
And then throughput, you want
Và sau đó là thông lượng, bạn muốn
really good throughput for a GPU hour, how many tokens are you actually producing?
Thông lượng thực sự tốt trên mỗi giờ GPU, bạn thực sự đang tạo ra bao nhiêu token?
Uh, and then good put is like how many you're producing at some service level.
Ừ, và sau đó goodput là số lượng bạn đang tạo ra ở một mức độ dịch vụ nào đó.
And just to put example numbers, these are the the DC uh, numbers that just came out I think yesterday.
Và chỉ để đưa ra các con số ví dụ, đây là những con số của DC ừ, vừa mới công bố mà tôi nghĩ là hôm qua.
Um, the throughput per GPU excluding cache hits is 60,000 tokens per second on prefill.
Ừm, thông lượng trên mỗi GPU không tính các lần trúng cache là 60.000 token mỗi giây trong giai đoạn prefill.
Including cache hits, they're at 96% uh, uh, input cache hit rate, which is really good.
Tính cả các lần trúng cache, họ đạt tỷ lệ trúng cache đầu vào là 96% ừ, ừ, điều này thực sự tốt.
Um, that will change based on your traffic.
Ừm, điều đó sẽ thay đổi tùy theo lưu lượng truy cập của bạn.
If you're doing agents, you're going to
Nếu bạn đang làm agent, bạn sẽ
have really good uh, input cache, but if you have like my mom is constantly starting brand new chats with ChatGPT that have nothing to do with the past and like they're asking, "What's the weather?
Có cache đầu vào thực sự tốt ừ, nhưng nếu bạn có kiểu như mẹ tôi liên tục bắt đầu những cuộc trò chuyện hoàn toàn mới với ChatGPT không liên quan gì đến quá khứ và kiểu như họ hỏi, "Thời tiết thế nào?
What's this?
Cái này là gì?
What's that?" There is no KV cache.
Cái kia là gì?" Không có KV cache nào cả.
You constantly have to run the prefill again and again and again.
Bạn liên tục phải chạy lại prefill hết lần này đến lần khác.
Um and so that will be much worse.
Ừm và vì vậy điều đó sẽ tệ hơn nhiều.
But throughput per GPU, when there is cache hits, is 1.5 million tokens a second, which is really good.
Nhưng thông lượng trên mỗi GPU, khi có các lần trúng cache, là 1,5 triệu token mỗi giây, điều này thực sự tốt.
Um and then time uh to first token about 400 milliseconds, time to first token P99 about 1 second.
Ừm và sau đó thời gian ừ đến token đầu tiên khoảng 400 mili giây, thời gian đến token đầu tiên P99 khoảng 1 giây.
And then uh um throughput per GPU uh on decode is 14,000 tokens per second.
Và sau đó ừ ừm thông lượng trên mỗi GPU ừ trong phần decode là 14.000 token mỗi giây.
And you can see the throughput for decode versus prefill 1.5 million to 14,000.
Và bạn có thể thấy thông lượng của decode so với prefill là 1,5 triệu so với 14.000.
So you're going to see decode is really the bottleneck and that's where lots of chip innovations uh are coming out to try to speed that up.
Vậy nên bạn sẽ thấy decode thực sự là nút thắt cổ chai và đó là nơi rất nhiều đổi mới về chip ừ đang xuất hiện để cố gắng tăng tốc điều đó.
Um and then uh this is actually the most interesting one that uh people clued in on, which is the KV cache retention policy.
Ừm và sau đó ừ đây thực sự là điều thú vị nhất mà ừ mọi người đã nắm bắt được, đó là chính sách lưu giữ KV cache.
And so they have petabytes of users that are using this data for the their KV caches and they retain it for 72 hours, which is how they're achieving such high uh cache hit rates.
Và vậy nên họ có hàng petabyte người dùng đang sử dụng dữ liệu này cho các KV cache của họ và họ lưu giữ nó trong 72 giờ, đó là cách họ đạt được tỷ lệ trúng cache ừ cao như vậy.
Um some other terms of art here you'll you'll see, which is arithmetic intensity.
Ừm một số thuật ngữ chuyên môn khác ở đây mà bạn sẽ thấy, đó là cường độ số học.
So as I go from DRAM to SRAM, if I if I transfer, you know, uh 4 bytes, how much how many how much flops or how much compute can I am I doing on those 4 bytes?
Vậy khi tôi đi từ DRAM sang SRAM, nếu tôi chuyển, bạn biết đấy, ừ 4 byte, tôi có thể thực hiện bao nhiêu phép flop hoặc bao nhiêu tính toán trên 4 byte đó?
If I'm doing an RMN or if I'm doing diffusion, these are really high cuz I transfer an image and then I have to or even noise and then I have to
Nếu tôi đang làm một RMN hoặc nếu tôi đang làm diffusion, những thứ này thực sự cao vì tôi chuyển một hình ảnh và sau đó tôi phải hoặc thậm chí là nhiễu và sau đó tôi phải
keep calling the same uh um weight file on a same network again and again and again.
Liên tục gọi cùng một tệp trọng số ừ ừm trên cùng một mạng hết lần này đến lần khác.
I don't have to go back to DRAM unless it's a really big um image and I have to tile or something like that.
Tôi không cần phải quay lại DRAM trừ khi đó là một hình ảnh ừm thực sự lớn và tôi phải chia thành các ô hoặc đại loại như vậy.
And so uh but for LLMs, the arithmetic intensity is quite poor.
Và vậy nên ừ nhưng đối với LLM, cường độ số học khá kém.
And this is the argument that Volo gave when he came up here for diffusion LLMs.
Và đây là lập luận mà Volo đưa ra khi anh ấy đến đây cho diffusion LLM.
Um and and there's a next concept model that um Herman out of my lab just published as well, which is also has much higher arithmetic intensity.
Ừm và và có một mô hình khái niệm tiếp theo mà ừm Herman từ phòng thí nghiệm của tôi cũng vừa công bố, cũng có cường độ số học cao hơn nhiều.
And the two other ones model bandwidth utilization, model flop utilization.
Và hai cái còn lại là mức sử dụng băng thông của mô hình, mức sử dụng flop của mô hình.
So, when you buy an H100, they say that you get 2 trillion FP8 flops, and what are you actually going to get at test time?
Vậy, khi bạn mua một H100, họ nói rằng bạn nhận được 2 nghìn tỷ flop FP8, và bạn thực sự sẽ nhận được bao nhiêu vào lúc kiểm thử?
And it's it's usually going to be much less than that, and that's the MFU is how many you actually get.
Và nó thường sẽ thấp hơn nhiều so với con số đó, và MFU là số lượng bạn thực sự nhận được.
And then the and model bandwidth is how much what is peak memory bandwidth?
Và sau đó là và băng thông mô hình là băng thông bộ nhớ đỉnh là bao nhiêu?
You have 1 terabyte of bandwidth or whatever it is, how much you're actually getting at test time on average.
Bạn có 1 terabyte băng thông hoặc bất kể là bao nhiêu, bạn thực sự nhận được bao nhiêu vào lúc kiểm thử tính trung bình.
And then there's this idea of like of roofline analysis, which is like how good could you possibly get?
Và sau đó có ý tưởng về phân tích roofline, tức là bạn có thể đạt được tốt đến mức nào?
So, it's going to be the min of your chips peak flops per second versus the memory bytes per second times flops.
Vậy, nó sẽ là giá trị nhỏ nhất giữa số flop đỉnh mỗi giây của chip so với số byte bộ nhớ mỗi giây nhân với flop.
And so, there's lots of innovations people have come up with.
Và vậy nên, có rất nhiều đổi mới mà mọi người đã nghĩ ra.
I bucket it into these three buckets.
Tôi phân loại chúng vào ba nhóm này.
Some people might, you know, bicker about which one would where buckets should live, but the way I think about it is there's model innovations where you do this thing called MOE where you if you have K experts, then you can amortize reduce the amount of flops at test time
Một số người có thể, bạn biết đấy, tranh cãi về việc cái nào nên nằm ở nhóm nào, nhưng cách tôi nghĩ về nó là có những đổi mới về mô hình, nơi bạn làm điều gọi là MOE, nơi nếu bạn có K chuyên gia, thì bạn có thể phân bổ giảm lượng flop vào lúc kiểm thử
over all of the experts by 1 over K essentially.
Trên tất cả các chuyên gia về cơ bản là 1 trên K.
There's SSMs where you don't need full attention on every single layer.
Có các SSM, nơi bạn không cần attention đầy đủ trên mọi lớp.
Maybe you only need it every fifth layer or every 10th layer, and so you can really reduce the amount of inference needed at test time.
Có thể bạn chỉ cần nó ở mỗi lớp thứ năm hoặc mỗi lớp thứ mười, và vậy nên bạn thực sự có thể giảm lượng suy luận cần thiết vào lúc kiểm thử.
And then multi-headed latent attention where I'm actually compressing in the sequence domain to reduce the amount of flops.
Và sau đó là multi-headed latent attention, nơi tôi thực sự đang nén trong miền chuỗi để giảm lượng flop.
And then there's I have this quantization.
Và sau đó là tôi có lượng tử hóa này.
I think we've all seen these like even as low as 2 bytes models, and then distillation into smaller models.
Tôi nghĩ tất cả chúng ta đều đã thấy những thứ này, thậm chí thấp đến mức mô hình 2 byte, và sau đó là chưng cất thành các mô hình nhỏ hơn.
So, once we get some big beefy model, and we we don't want to necessarily serve that, we can distill it into a smaller model if that's all we need.
Vì vậy, một khi chúng ta có được một mô hình lớn mạnh mẽ, và chúng ta không nhất thiết muốn phục vụ nó, chúng ta có thể chưng cất nó thành một mô hình nhỏ hơn nếu đó là tất cả những gì chúng ta cần.
So, those are uh model innovations.
Vì vậy, đó là những đổi mới về mô hình.
Then there's kernel and runtime innovations like radix attention, flash attention, page attention.
Sau đó là những đổi mới về kernel và runtime như radix attention, flash attention, page attention.
These are They're kind of a lot of these are just uh taking from classic OS and database theory.
Đây là... Chúng phần lớn chỉ là lấy từ lý thuyết hệ điều hành và cơ sở dữ liệu cổ điển.
If you have taken uh intro databases, where how do you make a production database really fast?
Nếu bạn đã từng học nhập môn cơ sở dữ liệu, làm thế nào để làm cho một cơ sở dữ liệu sản xuất thực sự nhanh?
And so, there's, you know, are you cache?
Và vì vậy, có, bạn biết đấy, bạn có bộ nhớ đệm không?
You
Bạn
can do prefix trees.
Có thể làm cây tiền tố.
You can do radix trees.
Bạn có thể làm cây radix.
That's kind of the idea of radix attention.
Đó là ý tưởng của radix attention.
Uh TriDao did this GPU tiling idea called flash attention, which is uh huge innovation.
TriDao đã thực hiện ý tưởng xếp lớp GPU này gọi là flash attention, đó là một đổi mới lớn.
And then page attention, which uh is um mutually exclusive from radix attention, but is basically this idea of a virtual uh um uh memory paging and buffer pool that you can that you can page into um into the DRAM.
Và sau đó là page attention, loại trừ lẫn nhau với radix attention, nhưng về cơ bản là ý tưởng về phân trang bộ nhớ ảo và nhóm bộ đệm mà bạn có thể phân trang vào DRAM.
And so, and the last one is the harness innovations.
Và vì vậy, và cái cuối cùng là những đổi mới về harness.
So, of course, the easiest one is routing.
Tất nhiên, cái dễ nhất là định tuyến.
We did this at Focal.
Chúng tôi đã làm điều này tại Focal.
And so, not everything should go to the big gory model.
Và vì vậy, không phải mọi thứ nên đi đến mô hình lớn đáng sợ.
We can do much more uh clever things like that.
Chúng ta có thể làm những điều thông minh hơn nhiều như vậy.
Maybe you can waterfall to the or tool call to the bigger model to the bigger model to the bigger model.
Có thể bạn có thể thác nước đến hoặc gọi công cụ đến mô hình lớn hơn, lớn hơn, lớn hơn.
And that will save a lot of flops.
Và điều đó sẽ tiết kiệm rất nhiều flops.
Speculative decoding, we have a draft model that is validated.
Giải mã suy đoán, chúng ta có một mô hình nháp được xác thực.
And then, my favorite one is the recursive uh language model, where never
Và sau đó, cái tôi thích nhất là mô hình ngôn ngữ đệ quy, nơi không bao giờ
put the full context into uh um into the the KB cache.
Đưa toàn bộ ngữ cảnh vào bộ nhớ đệm KB.
Just let the LLM decide what it needs and when.
Chỉ để LLM quyết định những gì nó cần và khi nào.
And so, you can really reduce the amount of KB cache with those ideas.
Và vì vậy, bạn thực sự có thể giảm lượng bộ nhớ đệm KB với những ý tưởng đó.
And then last one, uh compaction, which um is a mandatory part of every harness.
Và cuối cùng, nén, là một phần bắt buộc của mọi harness.
And there's a really cool innovations that Sabri um and Dan Simran in my lab came up with called cartridges.
Và có một đổi mới thực sự thú vị mà Sabri và Dan Simran trong phòng thí nghiệm của tôi đã nghĩ ra gọi là hộp mực.
- clears throat and cough - Um if you want to learn more, I think the two best uh lectures I've seen on this, um Percy gives an amazing lecture on his lecture 10 on CS 336 LLMs from scratch.
- [hắng giọng và ho] - Nếu bạn muốn tìm hiểu thêm, tôi nghĩ hai bài giảng hay nhất mà tôi từng xem về chủ đề này, Percy giảng một bài tuyệt vời trong bài giảng 10 của anh ấy về CS 336 LLMs từ đầu.
And then uh the Ryner Pope and Dwarkesh I thought were just super cool and super good.
Và sau đó là Ryner Pope và Dwarkesh, tôi nghĩ họ thật tuyệt vời và thật giỏi.
Um enough for me.
Đủ cho tôi rồi.
You have the absolute experts in the world on this.
Bạn có những chuyên gia tuyệt đối trên thế giới về lĩnh vực này.
Uh, first Dan Fu, who runs research at uh, Together AI.
Đầu tiên là Dan Fu, người điều hành nghiên cứu tại Together AI.
Uh, and came out of my lab at Hazy.
Và xuất thân từ phòng thí nghiệm của tôi tại Hazy.
Uh, Jeffrey Morgan, who is found founder and CEO of Alama.
Jeffrey Morgan, người sáng lập và CEO của Alama.
Uh, Joe Fiaty, who's founder and CEO of Luminol.
Joe Fiaty, người sáng lập và CEO của Luminol.
And then Lang Shang, I think he's coming.
Và sau đó là Lang Shang, tôi nghĩ anh ấy sẽ đến.
He says he's late.
Anh ấy nói anh ấy đến muộn.
He's hopefully shows up.
Hy vọng anh ấy sẽ xuất hiện.
Uh, is one of the core developers and second author of the SG Lang paper.
Là một trong những nhà phát triển cốt lõi và là tác giả thứ hai của bài báo SG Lang.
Well, uh, let me or please uh, help me uh, um, uh, welcome Dan Fu.
Vâng, hãy để tôi hoặc làm ơn giúp tôi chào mừng Dan Fu.
- applause - Great.
- [vỗ tay] - Tuyệt vời.