Skip to content

By playing, you agree to uListen's Terms and Privacy Policy and YouTube's Terms of Service.

Latent SpaceLatent Space

Next 100x in AI: Inference, Networking, & Self-Optimizing Models — Philip Kiely & Ali Taha, Baseten

From routing a 200,000-token prompt across GPUs to having GLM-5.2 profile, rewrite, and optimize the kernels serving itself, inference engineering is becoming one of the most important layers of AI.

Ali TahaguestswyxhostPhilip KielyguestAlessio Fanellihost
Aug 3, 20261h 42mWatch on YouTube ↗

Summaries, chapters, transcripts, and FAQs on this page are made by uListen, not YouTube.

Transcript

  1. 0:00 – 3:18

    Introduction and the 200K-Token Prompt

    1. AT

      GLM-5.2 is very, very good at writing GPU kernels. It was very funny. Internally, we had a GLM-5.2 endpoint that we were using to-- like, that we plugged in in our cloud code harness, so every engineer on the team uses, like, our GLM-5.2. And it will do a forward pass on the GLM-5.2 instance of the, you know, the node, and then it will get the profile trace, and it will analyze it, and it will find the kernels that are the bottlenecks in that slang. And then it will write the new kernels, and then we'll do another profiling trace. And when it's done, it uploads the image to our thing, and then we can pull that image down and repeat the cycle. Some of the GPU kernels that run GLM-5.2 within our inference engine is written by GLM-5.2.

    2. SW

      Before we get into today's episode, I just have a small message for listeners. Thank you. We would not be able to bring you the AI engineering, science, and entertainment content that you so clearly want if you didn't choose to also click in and tune into our content. We've been approached by sponsors on an almost daily basis, but fortunately, enough of you actually subscribe to us to keep all this sustainable without ads, and we wanna keep it that way. But I just have one favor to ask all of you. The single most powerful, completely free thing you can do is to click that subscribe button. It's the only thing I'll ever ask of you, and it means absolutely everything to me and my team that works so hard to bring The In-Space to you each and every week. If you do it, I promise you we'll never stop working to make this show even better. Now let's get into it. [upbeat music] Okay, we're here in the studio with, uh, Philip, uh, old friend from, from, uh, Inference Engineering, the book, as well as Baseten and, uh, everything that you've done-- you and I have done before, as well as Ali. Welcome.

    3. PK

      Pleasure to meet.

    4. SW

      Waterloo Intern.

    5. AT

      Waterloo Intern.

    6. PK

      Always. [chuckles]

    7. SW

      When did you get Waterloo Intern as a-

    8. AT

      As a handle?

    9. SW

      -handle?

    10. AT

      Oh, I think the rebranding happened, like, mid-March. When I saw it was open, I was like, "I have to take it. Up for grabs."

    11. PK

      The problem is that Ali is really good at his job and is not gonna be an intern much longer.

    12. AT

      [chuckles]

    13. PK

      So we have to figure out, you know, who's gonna get the handle.

    14. AT

      Well, pass the torch over to someone.

    15. SW

      Oh, okay. It c- can be-- Like, you just pass it to another Waterloo grad.

    16. AT

      It's another Waterloo inter-

    17. SW

      Yeah.

    18. AT

      No, grad.

    19. PK

      Yeah, yeah.

    20. AT

      Intern.

    21. SW

      Intern. Yeah.

    22. AT

      And, and, and-

    23. PK

      You gotta get an intern from Waterloo

    24. AT

      ... I'm just-

    25. SW

      Right, right, right, right.

    26. AT

      Yeah, you gotta get an intern from Waterloo.

    27. SW

      Right, right.

    28. AT

      But they have to promise to pass the baton.

    29. PK

      Oh, it could-- but it could come from Baseten, so it's like whoever Baseten gets from Waterloo-

    30. AT

      Right.

  2. 3:18 – 11:26

    Dedicated Deployments, Speculative Decoding, and Tool Calling

    1. PK

      prefill workers, and number two, ideally some cached input already there so that we can skip prefill on at least part of these 200,000 tokens. Um, if you're doing 200,000 tokens, it's probably coding or a multi-tone agent or, or something where you would expect to have that cached. Um, if you don't, we're gonna have to send it to a prefill worker. Um, we've, at least on certain models, disaggregated prefill and decode, um, so you're going to have one set of GPUs that's solely going to process the input, create that KV cache, and get you your first token. And then that's going to be passed over to a separate set of GPUs, which is going to run decode. We're going to iteratively make those tokens. Um, we're probably going to have some kind of speculative model in front of that. I'm going to assume that you're doing coding, and because of that, our speculative model, which assumes you're doing coding, is gonna have a high, uh, draft token acceptance rate. If I'm wrong and you're asking me to summarize every Harry Potter book, uh, it's gonna be slower. And then we stream that output to you and, uh, account for it, um, charge you, you know, some number of couple of pennies and say, uh, "Hey, would you like to send another one?"

    2. SW

      Except Baseten doesn't charge by pennies.

    3. PK

      Well, yeah, we, we charge-

    4. SW

      [chuckles]

    5. PK

      We-- I'm assuming that we're talking about the public model APIs. If you are, you know, s- setting up a, a dedicated deployment, then yeah, it's not pennies. [chuckles]

    6. SW

      Yeah. I mean, uh, one of the key differentiators when I was talking with, uh, Baseten initially was that, uh, actually, people who want very, very high volume just need to rent by the box, 'cause then it's up to you to figure out how to saturate the box.

    7. AT

      And more often than not, it's, like, way cheaper if you're pushing, like, millions of tokens per hour, if you just pay per hour instead of pay per token.

    8. PK

      Yeah, they, they do. I think that we've increasingly seen a lot of demand for the sort of pay per token APIs, just because everyone wants to try open models, and then once they find a use case that's really sticky, uh, then they, they move over to dedicated.

    9. SW

      Is there a best practice on when it's time to swap over?

    10. PK

      Couple reasons. Yeah, reliability, that's a big one, right?

    11. AT

      Like, if they have a very specific use case, they want you to train something specifically for them. Like, they want their own SpecDec, for instance, for their own traffic.

    12. SW

      SpecDec is speculative decoding.

    13. AT

      Speculative decoding, yeah, yeah. Um, like-

    14. SW

      You have to say it [laughs]

    15. AT

      ... sorry. Like, speculative-- The way spe-- Like, basically, if you have a, a huge model, right? And so the model is going to be generating one token at a time every single turn, every single forward pass. So we attach, like, this little, like, kind of parasite, like, this, this layer that goes on top of the model, and this model just has to predict. It does three very fast autoregressive forward passes, and it will dr- predict, like, you know, three certain tokens, and then you do one forward stage over the entire original model in order to see if those predictions were correct or not, and then you accept them or you reject them. Now this draft model is, is traffic specific, so if you like h- like, um, you know, Philip said, if you're summarizing Harry Potter books, I can train exclusively that draft model on Harry Potter books, and I can guarantee you that I'm gonna accept the three tokens every single time. And so with that case, I increase your decode speed. I wouldn't be able to provide this to you if you're on a shared endpoint 'cause I have no idea if you're doing Harry Potter, or if you're doing coding, if you're doing English, like we don't know. Um, also there's a thing in the book that mentioned that if they really cared about a specific threshold, chapter four, I think. Do you remember that?

    16. PK

      Yeah. The, the things that you can do is you, you can set, you know, a specific like batch sizing, a specific like parallelism strategy if you're trying to optimize for like throughput versus, uh, latency. Um, you can, you know, maybe, maybe a NVFP4 quant doesn't pass your benchmarks and you wanna run a model at higher precision, you could do that. Um, there's just a bunch of reasons why you might wanna have your own endpoint and, and the, the biggest one of course just being like you don't have to deal with someone else doing 100 million of tokens of benchmarking traffic at the endpoint when you happen to be trying to serve your users.

    17. AT

      Yeah.

    18. SW

      I think one thing that is-- tha-that is a classic journey. You know, like, uh, it's basically people is asking the, what happens when you type Google into the browser. Um, tool calling, is that just, you know, you're tr- you're generating JSON or is there more complication beyond that?

    19. AT

      Certain customers that we have, they have their own post-trained models, and so they, they demand a tool calling that's not just like, you know, parse a file or, you know, go find the weather. It's, it's something that's very specific, and you have to do post-training on this. And if the post-training on the model is not good or if the quantization after the post-training to get the inference to be fast, the model will struggle reading the JSON file and reading the tool calling. But it doesn't re- it doesn't require its own like sandbox. It's not like it's going to use that tool calling to like, like escape a sandbox or like it doesn't have to be contained. It can just be a normal dedicated deployment. The challenge with tool calling more and more seems to be that the companies want certain tool calling which, which is a very sensitive thing to train. And because you're dealing with all of the JSON outputs, if it doesn't like close the end of the request in a very certain manner, you end up with a model that did the tool calling and like the thinking. And so as a result of that, it didn't see the result and just hallucinated the result as it decoded. That seems to be the, the most challenging thing with tool calling, not really the sandboxes more.

    20. PK

      Yeah. That's a challenge on the training side. And then on the influence side, there's work that you can do to scope the possible output. So we published this actually at this point close to two years ago, um, the, the solution to this problem, which is you basically make a state machine, and you use that to constrain the output to a specific format. So this is the structured output problem. If you remember back in-

    21. SW

      Yeah

    22. PK

      ... back in the day-

    23. SW

      Specific grammars, uh-

    24. PK

      Yeah

    25. SW

      ... GML had this thing.

    26. PK

      Yeah. So it's, it's like the, the old school, like make sure this is only JSON return, only JSON or my grandma's-

    27. SW

      Yeah

    28. PK

      ... gonna die type of prompt.

    29. SW

      Is it BNF grammar? At some point, the OpenAI had released a thing that was like, yeah, if you wanna constrain your output, write BNF grammar, uh, back as Nor.

    30. PK

      In our influence system, it's just a, yeah, specified output format, um, and, and you get the, the guarantee that your output's gonna be structured along that format. Um, and so applying that to, to tool calls can like help cut down on... Obviously, you can still call the wrong tool or call no tool. It doesn't solve the, the certainty problem-

  3. 11:26 – 19:06

    Launching Production-Ready Open Models

    1. PK

      about that.

    2. AT

      Like you're, you're also bounded by the software or that the model is gonna integrate with if the software is built with JSON for the tool calls or if the company that you're-- you know, if your customer says that this is how our software works and the-our tools are interfaced with JSON, you can ask them to like, you know, change their, their software and, and say like, "Yeah, this is gonna be better for the model." Y- but like with the wet training shouldn't be that much of a A difference. Also more profitable if it outputs more tokens probably.

    3. SW

      [laughs] Depends on your business model.

    4. AT

      [laughs]

    5. SW

      You know, it really depends. Uh, but I will say that, you know, as a writer with like experience a lot with AI-generated output, I do try to move from text to JSON text-

    6. AT

      Mm.

    7. SW

      ... which is very long JSON, right? Like, like there's paragraphs in every field because I'm trying to structure it, right?

    8. AT

      Right.

    9. SW

      I want you to first make factual statements, then make opinions-

    10. AT

      Mm-hmm

    11. SW

      ... then make bullet point summaries, have dates, have ent-entity references-

    12. AT

      Mm

    13. SW

      ... have your sources for references, all these things. Anyway, so, so these are things that like I think people who really, really experiment with structural output have to really care about. But, um, let's, let's sort of recurse up the stack a little bit. Before we started recording, you actually mentioned something which is really cool, which is that there's a lot of engineering that-- inference engineering that goes on when a new model provider releases a new model, right? So let's call it GLM 5.2, Kimi K3. I had pre-previously assumed, especially if it's like, well, GM- GLM 5 to 5.1 to 5.2, like you know that you've supported them before. Is it that much work?

    14. AT

      It's a lot of work [laughs] .

    15. SW

      Yeah. Okay. So like, you know, a lot of people, all you guys, right-

    16. AT

      Mm

    17. SW

      ... whenever a new model launch, like, uh, people rush to say like, "Oh, Hugging Face supports this, Firework supports this, Space10 supports this." And I'm like, "Yeah, of course we support it." But what, what, what goes into that? What goes behind the scenes?

    18. AF

      I think it's more than just support it too, right? Uh, it benefits the consumer a lot. Like, I think it was with, uh, Kimi K2.5 or GLM 5.2, the latest, there was sort of an inference war, right? X provider is at 90 tokens a second. The next day we're at 150. The next-

    19. PK

      I, I kinda kicked that off with, uh, GLM 5.2

    20. SW

      [laughs]

    21. PK

      I wrote a Twitter article about... It got like half a million views, um-

    22. AT

      Baseten being number one-

    23. PK

      Yeah

    24. AT

      ... or it was for something else [laughs] .

    25. SW

      [laughs]

    26. PK

      Yeah. Which, uh-

    27. AT

      Oh, my God

    28. PK

      ... which then got everyone really excited about, hey, how can we, you know, bend, bend tracks a little bit further? And, um, there was a difference between support the model, as in like I can make a token out of this model, and support a model as in I have a production-ready API from this model.

    29. SW

      Mm.

    30. PK

      Getting to the point of I can make a token out of this model is not that hard because generally the, um, open source inference engines, your VLMs, SGLangs of the world oftentimes even receive weights ahead of time, maintainers do, or the people making the model merge PRs to ensure support. So you generally can, you know, just kind of get it working on the standard open source stack without too much pain in most cases. The challenge is, you know, every inference company is gonna have own proprietary stack. Um, you know, some open source components, some, some in-house stuff. And for any arbitrary model, there's going to be some new stuff. Sometimes you get lucky, like K, uh, 2.5 to 2.6 was like pretty, pretty similar. Um-

  4. 19:06 – 28:22

    Model Retrofits, Failure Modes, and Nondeterminism

    1. AF

      Same with, uh, Clip and Meta Clip, where you go from just captioning to building out questions-

    2. SW

      Right

    3. AF

      ... off the image and how much better you can get performance.

    4. SW

      Right. Right, right.

    5. AT

      Yeah. But what's, what's so exciting about this is if you look at a model like this... Now, obviously this is a little bit more of a research project. It's not, you know... It, it got to 56% on MMLU Pro, I think, so not, not quite Fontio. But if you're running this model, you haven't suffered any loss on your GLM-5.2 quality. If you don't have an image, it'll just behave exactly the way it used to. And ultimately the-

    6. SW

      Which, which in the inference code, you literally do not include the other part, right?

    7. AT

      Yeah, I mean, you would just skip the encoder if you don't have an image input.

    8. SW

      Okay.

    9. AT

      Um-

    10. SW

      Just confirming.

    11. AT

      Yeah.

    12. AF

      Does it affect a lot on the overall inference side? Like, you're not adding much, you're adding a very small vision encoder. These are typically like-

    13. AT

      No, super fine

    14. AF

      ... less than a billion parameters, right?

    15. AT

      Yeah. It's-- I mean, there's a little bit less standardization among vision encoders.

    16. SW

      Yeah.

    17. AT

      Um, so the s- sort of support matrix can be a little bit, uh, sparser. But overall, um, yeah, it's, it's a pretty, it's a pretty minor component of the overall system. And, and ultimately, what you get out of the system is all of a sudden you have Kimi Vision, GLM weights, and DeepSeek attention all in one model.

    18. SW

      [laughs]

    19. AT

      And that's, I think a lot of the power and beauty of open source, is that you can take all of these different components and, and combine them together into a system that's better than anyone-

    20. SW

      Yeah

    21. AT

      ... can be individually.

    22. SW

      People used to say that you would also do frankenmerges where you would take like-

    23. AT

      Yeah

    24. SW

      ... layers from each model.

    25. AT

      Mm.

    26. SW

      No-- Does anyone do that anymore?

    27. AT

      Well, to, to your point previously when you were mentioning like, um, the work that goes into supporting a model when it first comes out, like GLM-5.2 or Mini- Minimax M3 or whatever the case is. Sometimes you do have to r- like you do have to switch out some things. Like for instance, the Minimax M3 head uses full attention. And with full attention, you end up with this like insane bottleneck in Specter 'cause you're doing autoregressive token generation for three tokens, and you're doing this like, like O (n) squared over all of the tokens that are in your sequence. Um, your KV cache is like very large because it's not sparse, it's not top K. So we find it better to like, okay, we're gonna replace this, you know, we're gonna replace this layer with a layer from another model that's using like GQA, for instance. And then just with the right training, you can get it to have the same acceptance rate. So it is, it is very possible to, to retrofit layers from other models and very much needed, actually. If a layer is like inefficient, the training just becomes the challenge. Like how do you ensure that you train it properly? Which again, to your earlier point, is like the, the mesh between training and inference as in like you need very good training in order to do fast inference. That's like I feel like more and more becoming true.

    28. SW

      Yeah. Anything else on the support side when you, when you say like get it to fully production ready?

    29. AT

      Yeah, I think that there's also a question of just, you know, we can test a model to a pretty extensive degree, but we're trying to get it out quickly, and then you see a bunch of other people test it and you get interesting results. There was a- an issue with, um, GLM briefly where we had some like mode collapses where it would just output the same token over and over again for certain prompts on certain temperatures. Like once you expose an endpoint to, to the real world, there's going to be, you know, so many more varieties of, of things given to it that, that you're able to, you know, discover and, and patch things. So it's not just a, you know, day zero process. It's then like for the first week, for the first month, if a model remains popular, like how do you both fix bugs and then continue to push the envelope on performance?

    30. AF

      What do you mean you don't want your model outputting SSSSSS? [laughing]

  5. 28:22 – 32:15

    Quantization and Canceling Errors

    1. PK

      If you think of a sort of golden implementation of a model that performs exactly the way the model is designed to perform, I think of quality as how close are we getting to that, you know, 100% fidelity of the model.

    2. AF

      Mm.

    3. PK

      You can also, of course, think about quality from the training side and how do you push yourself past 100%, but when I think about purely inference optimizations, it's getting faster while staying as close to that 100% fidelity mark as, as possible. And certainly our standard internally is that, like, you should not be able to tell the difference between our API and a, you know, sort of official API. I think Kimi in particular does a good job of vendor benchmarking here-

    4. SW

      Yes

    5. PK

      ... where they have-

    6. SW

      They, they released an actual vendor benchmark.

    7. PK

      Exactly, yeah.

    8. SW

      'Cause they accused, uh, some people, Amazon? There was some provider that was not doing very well on Kimi's benchmark.

    9. PK

      Yeah. So, um-

    10. SW

      [laughs]

    11. PK

      ... it would reflect, it would reflect really poorly on them.

    12. AF

      This was a long time ago, right?

    13. PK

      No.

    14. SW

      Yeah, like, like three-

    15. AF

      They also-

    16. SW

      ... four, four or five months ago.

    17. AF

      This also happened with... I don't remember which model, but they, they pulled out quite a few, and then they started a whole chart about this. It might've been-

    18. SW

      Kimi vendor verifier.

    19. PK

      Yeah.

    20. AF

      Yeah.

    21. AT

      Yeah, 'cause you, 'cause you'd be pissed, right? Like, if you're-

    22. SW

      Yeah

    23. AT

      ... if, like, um, like if I'm a consumer and I'm using, like, Amazon's endpoint for instance, and I, I'm using Kimi and I'm like, "Oh my God," like, "this is bad," I'm not gonna say, "Oh, Amazon quantized the model in a bad way." I'm gonna say, "Oh, Kimi sucks." Right?

    24. PK

      Yeah.

    25. AT

      So it seems like that, that makes sense.

    26. PK

      Yeah, they care. They care. Um-

    27. AF

      Justifiably. [chuckles]

    28. PK

      Yeah, just fine.

    29. AF

      Uh, uh, this is probably a stupid question, but just checking, has anything improved from mean quantization?

    30. PK

      Yeah.

  6. 32:15 – 40:48

    The Race to 10× Faster Inference

    1. AT

      so what Joshua showed in his mathematical proof, where he had like a verifier in, is that you can predict which layers are going to have quantization errors that will cancel out with each other, and you choose to quantize those layers. And so the result of doing this mathematical quantization is you end up with a model that's 20% more quantized than another provider, so you get 20% more throughput of it because there's more layers that are running in BF4. And your quality is better than that other quant because the layers that you chose to quantize have their errors cancel out. Like one layer is skewed to the right-

    2. PK

      Mm-hmm

    3. AT

      ... one layer is skewed to the left, one layer skewed to the right. Your final logistics distribution is more similar to the original distribution of the model, so you have better fidelity. And so the way we proved this was with KL divergence. So instead of just scoring on the benchmarks, we scored the KL divergence between the logic distribution of the quantized model and the logic distribution of the original full precision model. And we showed that with this technique we get... If your, if your, you know, if your probability distribution on the logic switch token it wants to select is more of the same as the original model, you're probably gonna end up staying true to the original model. So yeah. So it seems like, like previously before this, it seemed like the industry was, well, the more you quantize, the worse it's gonna be 'cause the more loss you introduce. That's not exactly, not necessarily true. So yeah, doesn't improve it, but can cancel out.

    4. PK

      I think it might be this, but reminds me a good bit about pruning actually, where you can prune off certain layers.

    5. AT

      Mm-hmm.

    6. PK

      But very interesting. Didn't know this was a whole paper you guys put out. [laughs]

    7. AT

      [laughs] It w- it's... Fun fact, it was originally 72 pages, this paper, and then we decided-

    8. PK

      Wow

    9. AT

      ... we can't tell. We couldn't release it. So it's now 45. [laughs]

    10. PK

      [laughs]

    11. SW

      Still, still 39 pages, so very, very substantive. We talked about evals and, and all these things and, uh, like what's possible in terms of speed up? I guess, like it's like probably like the number one-

    12. AT

      Mm-hmm

    13. SW

      ... thing that people do wanna care about, and it's something that you wrote about in your post. Um, like official API is 70 tokens per second, and you push it up to 90. Is that like a normal thing?

    14. PK

      So what's cool about working in inference, the reason that I think inference is going to be a useful place to do engineering for a long time, is that if you look at highly optimized domains like, say, finance, if you're in finance, you measure how much better you got in basis points. It's like, "Oh, I got five basis points better, like one-twentieth of 1% better." That's huge news because everything is, is so optimized. When we publish optimizations, it's, it's 20%, it's 100%-

    15. SW

      [laughs]

    16. PK

      ... it's 200%. So there's still probably like a lot further to go, honestly. Like you'll, you'll know that inference is pretty much solved when researchers start publishing about how they got 1% faster at, at something.

    17. SW

      Which by the way, uh, because I am from the finance background, in the '70s, that was the margin at the time. When you did quantitative finance research, you would find-

    18. AT

      And like with 20%, 10%.

    19. SW

      Yes. Yes.

    20. PK

      Yeah.

    21. AT

      And now it's tiny fractions.

    22. SW

      For, for those, for those people interested, look up Andrew Lo's paper. Uh, he had a, a really interesting illustration of quant, uh, stat arb, uh, distribution, uh, narrowing down from like those kinds of 20% differences in the '70s, uh, down to nothing today, um, which is very, very cool.

    23. PK

      Exactly, and, and we're at the beginning of, of the same type of, of, of thing. Now benchmarking is hard. Um, I think any- anyone will tell you that. And, and benchmarking provider speeds is hard because there's so many variables that go into it. What hardware are you using? How much load do you have on the system? What's the exact nature of the prompts and input and output sequence lengths? All that kind of stuff. But overall, when you start stacking these improvements, you're looking at multiples. Um, you can look at it... The, the most common form, of course, is TPS, tokens per second, which is bad naming by us in the industry 'cause there's actually two tokens per second. There's tokens per second, the throughput number, and, and the latency number.

    24. AT

      TCT, yeah.

    25. PK

      Um, to- like total tokens per second out of the, out of the GPU as the throughput number. Most people only care about tokens per second as the latency number, which we should call ITL, intertoken latency, but we don't. Um-

    26. SW

      [laughs]

    27. PK

      Anyway, so you can imagine a sort of standard API without many optimizations for a 1 trillion parameter model operating somewhere in the 30 to 50 tokens per second range for, for a reasonable traffic profile. Um, and we generally see the goal of, you know, pushing to 10X that. Um, but, you know, not necessarily day zero, but by stacking enough optimizations, um, if you have, say like four optimizations, each of which doubles performance... Or sorry, three optimizations, each of which doubles performance, uh, then you, you stack that up. That's an 8X gain. That's kind of the, the Order of magnitude that we're working with in this, in this space. We're trying to make things substantially faster, not just go from like 70 to 90.

    28. AF

      Are you saying you've, you, you have done that?

    29. PK

      So let's say you have as a reasonable baseline, 30 or 40 tokens per second. Uh, you can, you can achieve 10X that. So like on GLM 5.2, um, if you wanna get unquantized, uh, perhaps on HALOs even, um, and you're just using an off-the-shelf inference engine with no particular optimizations, no, no speculator, um, nothing, nothing extra around like KV routing, no disaggregation, uh, you're, you're probably, yeah, looking at that like 30 to 40. Do you think that's like a reasonable baseline?

    30. AF

      Right. Right.

  7. 40:48 – 50:18

    Dynamo, Speculation, and Local vs. Data-Center AI

    1. PK

      um, quantized weights is for someone who really knows what they're doing, hours to days of work. Um, building the speculator, again, like hours to days of work, and the, um, Disag setup, hours to days. D- well-

    2. AT

      Yeah [laughs]

    3. PK

      ... okay, well once, once you have it working-

    4. AT

      Once set up. Once set up, yeah

    5. PK

      ... yeah, yeah, getting Disag working for the first time, I'm saying of course is, is very difficult. But-

    6. AT

      Mm-hmm

    7. PK

      ... the, the, the marginal implementation is-

    8. AT

      If you're just grabbing, like if you are a person, like just a normal consumer who has access to like a node of B200s and you're wondering, "How can I just host it myself?" You don't need to quantize the model yourself. There's always gonna be like an open source quantized checkpoint. Nvidia's gonna push one out if no one else does. You-- usually the providers will have their own Spectec that they've trained as well. You don't need to train your own Spectec. You can just use that as well. Um-

    9. PK

      Yeah. Like, like Kimi, uh, uh, GLM 5.2 has its own MTP.

    10. AT

      Right. Right.

    11. AF

      Thanks.

    12. AT

      Multi-token prediction [laughs] .

    13. AF

      Yes.

    14. AT

      I'm just kidding. I'm just kidding.

    15. AF

      Use it as-

    16. AT

      I can do it for you in case I get it wrong, you know?

    17. AF

      No.

    18. AT

      Uh-

    19. AF

      Actually, you should correct if we're wrong, but their multi-token prediction can be used for self-speculative decoding.

    20. AT

      I'm actually not sure. I'm not gonna correct that.

    21. AF

      Okay. I'm semi-confident in that-

    22. AT

      Okay. Yeah, yeah

    23. AF

      ... but someone can check. Um, but you know, it's useful to paint the story of, okay, not just the average person, but say a company wants to switch from serverless inference to-

    24. AT

      Mm-hmm

    25. AF

      ... I wanna throw this up on, you know, I wanna rent some GPUs, throw it up. These are the steps you take to do significantly faster than just put it behind Veo or something.

    26. AT

      Right.

    27. AF

      I was waiting for a mention of Dynamo. Uh-

    28. AT

      Mm-hmm.

    29. AF

      I feel like, uh, that's supposed to be the baseline that you measure against.

    30. PK

      I would think of Dynamo as less of a sort of out-of-box system and more of a toolkit for building with. So when we talk about doing KV-aware routing, when we talk about doing KV out- offloading, when we talk about doing, um, PD disaggregation, Dynamo fundamentally is... By the way, Dynamo is an, an open source library from Nvidia. Um-

  8. 50:18 – 1:00:55

    Model Parallelism, Auto-Tuning, and Mega Kernels

    1. AT

      the bandwidth. 'Cause on the B200s, you have like 3.5 terabytes per second. You don't need to-

    2. PK

      Mm

    3. AT

      ... you know, decrease the, the storage that much. You don't need to do, you know, FP4 KB cache. You don't need to use TurboQuant. There's, there's, there's better optimizations to be made. But on, on edge devices, it's extremely important, it's extremely useful. So, you know, it s- seems to be like different optimizations there, but then they're all uniquely combined with like, oh, you wanna quantize the model, you wanna do speculative decoding, like certain common prefixes with both-

    4. PK

      Principles

    5. AT

      ... yeah, exactly, exactly, exactly.

    6. PK

      They also do a lot of work on, um, p- model parallelism, especially over, uh, you know, heterogeneous topology, where you have, you know, some sparks and they're wired together with, you know, Ethernet, D- DGX sparks. Um-

    7. AT

      Yeah, yeah. This is the Exo Labs guys

    8. PK

      ... yeah, you have, you know, a number of, uh, Mac Minis stacked up.

    9. AT

      [laughs]

    10. PK

      There's, you know, the inter- they, they... One thing that, that I think we both have to deal with, although they have to deal with a lot more, is, is the interconnect between machines. Um, which is why like, you know, one thing that we do a lot is work with tensor parallelism.

    11. AT

      Mm-hmm.

    12. PK

      And that's where, uh, you are using all of the, you know, all eight GPUs, um, and, and sharding the model across it. Uh, tensor parallelism is not a good fit for local AI because it assumes a very high bandwidth interconnects like NVLink. Uh, was, you know, they might be forced to do something like pipeline parallelism, which we're never gonna do unless we're doing some kind of-

    13. AT

      Yeah, for-

    14. PK

      ... multi-node inference.

    15. AT

      Uh, since you mentioned it, I actually wasn't sure if we were gonna cover it, but let's briefly explain tensor parallelism and expert parallelism, uh, since you have very nice images.

    16. PK

      You wanna pull the book?

    17. AT

      I just wanna-

    18. PK

      Yeah, yeah. Let's, let's get the-

    19. AT

      So I just wanna show off your images. [laughs]

    20. PK

      [laughs] Yeah. Uh, shout out, shout out to Luke from Baseten's design team for making these, these beautiful images. Oh, that's a, that's actually... Before we get into this, just one other difference is we, we talk a lot about the active parameters of a mixture of experts model, and for local inference folks, that matters a lot because if you have a batch size of one, you're only activating that many parameters. When we do inference in the data center-

    21. AT

      Yes, I was gonna, I was gonna bring that in the diffusion conversation. Uh-

    22. PK

      Oh, yeah.

    23. AT

      [laughs]

    24. PK

      Yeah. We, uh, at, at... When we go through like a, a MoE model, um, and we host it, um, for an API, we assume that all parameters are gonna be active because-

    25. AT

      You're fetching

    26. PK

      ... throughout your batch-

    27. AT

      Yeah

    28. PK

      ... you're gonna, you're gonna hit everything. Um, cool. So broadly, tensor parallelism you can do with any model. Expert parallelism, you can only do with MoE models. Um, effectively all models today are MoE models, um, that are, you know-

    29. AT

      Sort of-

    30. PK

      ... at least all models large enough that you would care to parallelize them across multiple GPUs. So that, that's, that, that nuance is, is less important now. Um, with expert parallelism, the idea is you put the entire expert on a GPU. Generally, you have more experts than GPUs, so you might put like N experts per GPU, like eight experts per GPU or whatever. And then you, uh, you replicate the router, which the router is very small across each of the GPUs. And then by moving the, the generation from expert to expert, with each expert being inside a GPU, they're not competing for resources. You massively increase the throughput that you're capable of doing, and the, uh, GPU-to-GPU connection b- is, is not as important 'cause there's not as much communication. Uh, tensor parallelism requires that you are able to do this like all gather, all reduce.

  9. 1:00:55 – 1:10:03

    Rubin, GPUs vs. ASICs, and Custom AI Chips

    1. AT

      When I look ahead to, you know, what's going to be new with, with Rubin, I think that like Dynamo gives me a lot of technical hints around like what kinds of work is going to be very valuable. Obviously, we're continuing some trends from Blackwell, right? NVFP4 is big. The amount of compute that they have behind NVFP4 tensor cores is, is massive. Um, we'll, we're gonna talk about video, I think, at some point, and, and that's the, the big barrier there. You've got, you know, much, much faster memory bandwidth, um-

    2. PK

      But which was the same thing that, that made Blackwell so good. Um, but the, the big thing is more systems thinking. You have more emphasis on the CPU to GPU interconnect, more emphasis on the interconnect between GPUs. And when you look at Dynamo, it's a system entirely designed around how do I move the KV cache to where it needs to be when it needs to get there? Um, so I think that themes around like KV cache offloading, KV-aware routing and, and disaggregation are going to be substantially more important in the Rubin era, which means that inference engineering becomes not just a like CUDA kernel problem, but also like a very traditional hardware infrastructure problem, which is something, you know, we've been building toward for, for a long time and something that's like very exciting to me because we're gonna see sort of multiple domains colliding and the ability to reason from the kernel level like up to the hardware level and, and back down is, is going to be very valuable.

    3. AT

      I will take what Philip said one step further actually into that. It's, I think, trending towards becoming exclusively an infrastructure problem where like problems of PG, Disac, training, Spectac. But writing kernels is not going to be much of a problem because the GPU is moving more towards being an ASIC, where it's-- you're just, you're just trying to orchestrate what happens on the GPU, but you're not actually controlling it thread by thread level. And you see this with like QTAL, QDSL, like you're, you're just working at levels of like tiles of data, but you're no longer working at controlling what each thread does on the GPU that's being taken care of for you. Um, so I guess, do you agree that a GPU and future GPUs are trending more and more towards becoming ASICs that just need to be launched and then they do the data operation based on your conversations with other people?

    4. SW

      Oh, I mean, yeah, no. Uh, that, that, that is a section of the market.

    5. AT

      Right.

    6. SW

      And obviously, ASICs can do, uh, a lot more performance for only their, their workload.

    7. AT

      Right.

    8. SW

      And the, the G in GPU makes, makes them continue to be very general.

    9. PK

      Yeah. The, the-- I think that there's like a spectrum-

    10. SW

      Actually, it's, it's graphics, but-

    11. PK

      Yeah. [laughs]

    12. SW

      I, I keep saying this, I have to correct myself in, in case people come at me for getting the, the G wrong.

    13. PK

      Yeah. It's, and it's like, it's like a spectrum, right? Of, of a very, very general purpose compute to something like a Talos where you've got the, the hardware built for a specific set of model weights.

    14. SW

      The weights burned-

    15. PK

      The weights

    16. SW

      ... into the chip. [laughs]

    17. PK

      Yeah.

    18. SW

      No loading.

    19. PK

      I don't-- I wouldn't say that like, that, that we're, we're, we're going all the way there. It's, it's more like along the spectrum, it's a step in the direction of more specialization within the hardware.

    20. SW

      Yeah. I'm curious, I feel like he was driving towards something.

    21. AT

      I guess my point is being bearish on... Like you, you say, you say, like everything else apart from burning the weights into the chip. Burning weights into the chip is like impractical because you wanna fine-tune, you wanna optimize, you wanna, you wanna quantize, you wanna release new checkpoints of the model. If it's burned into the chip, the chip's useless in like a month or two, right? I guess, I guess my point is how can you not-- uh, like seeing Nvidia more and more specialize it, like take its GPUs from a general programming paradigm where you're just-- it's a general computer that you can use to program threads, and with every new generation, you're putting more and more specialized instructions, specialized tensor cores, specialized, you know, UMA instructions, uh, things that will, will allow you to, to just control it almost as an ASIC, almost as a collection of ASICs.

    22. SW

      Mm.

    23. AT

      How can you look at this trend and then still be bullish on companies that are coming up with ASICs for AI?

    24. SW

      Mm.

    25. AT

      In the sense that, in the sense that if-

    26. PK

      Yeah, because they're, they're sort of re-

    27. AT

      What?

    28. PK

      They're evolving towards that direction.

    29. AT

      They're almost evolving towards an... Like, like as an, as in Rubin, I guess comp-- like compared to Ampere or, you know, T4, Rubin is, is, is basically an ASIC. It is, it's basically just a thing that is, is used-

    30. SW

      Programmable ASIC?

  10. 1:10:03 – 1:12:42

    Giant Models and the Limits of GPU Memory

    1. AF

      enough and use enough tool calls and be agentic enough, uh, can it just web search, tool search-

    2. PK

      Mm-hmm

    3. AF

      ... write code? Do you really need to keep squeezing more? We will because you guys will make it cheap and fast and smaller, and I can swap it in. But at some level, like you give me 5.2 today or say whatever, 120 B model, I can run with it for quite a while, right?

    4. AT

      This is assuming like you don't need intelligence.

    5. AF

      I think there's a lot of intelligence-

    6. SW

      You need, you need reliability and predictability. Like I'm an enterprise like-

    7. PK

      Mm-hmm

    8. SW

      ... like this is tried and tested. It is signed off by like my 5,000 stakeholders.

    9. AT

      Right.

    10. SW

      Like I'm [chuckles] not touching it.

    11. PK

      It runs a batch job every day-

    12. AF

      [laughs]

    13. PK

      ... and I like the results.

    14. SW

      Yeah.

    15. PK

      The results are predictable. Yeah.

    16. AF

      Yeah, yeah. It doesn't make sense to keep using them. Like stuff gets sparser, cheaper, better.

    17. AT

      Right.

    18. AF

      But that doesn't mean that old models, GLM 5.0 isn't usable, right?

    19. PK

      Mm.

    20. AF

      If we hit a stall, say, for whatever reason, there's still a lot that can be squeezed out.

    21. SW

      We're gonna run out of time. I, I did wanna also make sure. Yeah. Yes, actually we happen to have this diagram. Pull-- Compare this versus any Cerebras diagram, right? Um, I don't think Edge10, uh, medics have, have put out public, uh, charts yet. Uh, but the complete re-- the real estate is very different. The size is very different, right? This is not wafer scale, right? This is-- There's probably like, I don't know, a few hundred of these on a, on a wafer. Um, I don't, I don't know how big-

    22. AT

      Right. Right. Right

    23. SW

      ... the, [chuckles] the comparison is, but like, uh, it is a, it is a very like real estate allocation-

    24. PK

      Few dozen

    25. SW

      ... uh, difference.

    26. PK

      Few, few dozen, I would say.

    27. SW

      Few dozen. Yeah.

    28. AF

      Before we move from hardware, I have two quick questions. One, the latest Kimi, which is really big, uh, three trillion-

    29. SW

      Yeah

    30. AF

      ... doesn't fit on most hardware on single node.

  11. 1:12:42 – 1:21:47

    AI Video, Quadratic Attention, and Autoregressive Generation

    1. PK

      NVL 72 on, on, uh, Blackwell as well. But, um, you, you can't necessarily assume you're gonna do inference on that.

    2. AF

      Mm-hmm.

    3. PK

      Um, there's a whole lot more 8x racks in the world than there are NVL 72s.

    4. AF

      Yeah. I guess my last quick question on hardware was, do you notice anything with hardware generations for new pre-trained base models? So one of the things you said for efficiency is you can swap hardware. That's one of the 2x gains. Um, when we see new stuff coming out training-wise on Rubins, uh, any changes on logs? Does this affect what type of models we will be seeing when these are more available? And can you-

    5. PK

      They, they get bigger. Like people understand the ceiling that you have in terms of How many parameters of a model you can run, uh, given the sort of latest inference hardware, and that kind of forms a ceiling. And so, for example, when DeepSeek R1 came out, it was, you know, it was 671 billion parameters, which at the time was really huge, and I think did a lot to push us to really quickly adopt Blackwell and, and get good at serving on Blackwell. Um, so yeah, it's, it's, it's mostly in my mind about, uh, model size and then about matching the architecture and the native quantization to the, the target hardware, like we talked about with like, you know, all Nemotron models of NVFP4, for example.

    6. AF

      So we talked a lot about LLMs.

    7. PK

      Mm-hmm.

    8. AF

      You have a lot more in the book. What about audio, video? What's the other side of inference engineering? Ali, you're pretty big in video diffusion.

    9. AT

      Video diffusions I think are... Like, they're just shaped... A lot of the stuff that you can think about, reason about with LLMs being autoregressive, with video diffusion, it's, it's, it's not the case. For instance, you don't do, you don't do batching. You-- every request just comes in on one GPU and it serves one GPU. You don't have to shard. The models are a lot, are a lot smaller, like Wan2.2, for instance, is a 20 billion parameter model. Um, you don't need to worry about... It's just like orders of magnitude smaller than the best LLMs. And it's one of those spaces where the, the open-source models are... Like with LLMs, we see Kimi K3 is almost comparable to, you know, Mythos or like GPT-5.5. The, the difference between the best open-source LLM and best open-- uh, closed source LLM is very small. Like, it used to be six months. I don't think it's six months anymore. I think it's like basically almost on par. Video models are definitely not. There's a huge gap. If you look at the best video that you can generate today with an open-source model like Wan2.2 versus something like with Kling or Veo, difference is night and day. So it, it creates this disparity where media companies will choose to go most of the time to closed-source models, for instance. And I were to tell you, "Hey, I can generate an entire three-hour movie for you with this model, and I'll optimize it so that you only have to pay me $10." But if they were to do it on a closed source, they'd have to pay $1,000, which is 100x. Like I'm 100x cheaper, but it's still $1,000. They're still gonna choose to do all of their cuts with Veo and Kling. So the... It's like a chicken and egg cycle where less demand causes less innovation in the field, causes, you know, less open-source checkpoints to be released. And some of the labs that were releasing open-source models like Wan will have closed-sourced their latest models, like Wan2.7 is not open source. We're still on Wan2.2. The, the challenge with, with video models especially is the number of, of tokens. So, so, so, so video models, you want to generate a high quality model, a high quality video. So let's say you're doing 16 frames per second, that's like the absolute minimum you'll do, and let's say you'll do like 480p video. So you can think about your like dimensions, and I think I have like a good, um, just like a diagram that shows the number, the sheer number of tokens, right? Let's say you're looking at like just one video of like, you know, Sparta, Sparta 300 or whatever. So let's say we're looking at like four frames, right? Those four frames of that video, if you go just... if you're doing full attention, if you go a little bit up, like you're looking at, uh, 480p by 720 by 81 frames in just five seconds, because 16 FPS by five, right? And then you compress it down to latent space, but you're still doing 30 by like 50 by 21 tokens.

    10. PK

      Yeah.

    11. AT

      Which means that for attention, for just five seconds, you're running attention on 35,000 tokens, right? So the attention becomes such a huge bottleneck. And because it's O of N squared, if you're doing like... if you extend that to like 10 seconds, well, it's just squared, 20 seconds, 30 seconds. So to generate a good cut scene of like one minute, it's almost impossible to do within the same compute time. And it's just, it just becomes unfeasible. You can't do it. And so you end up with moving towards two directions. Either you decide to do attention on the entire video at once, in which case you are forced to do sparse attention. So if you scroll back down to the origin, the, the video image, like you can see whereas on the left, for instance, I would be doing full attention where every single token in that Sparta 300 scene attends to every single other token, as you can see the sheer number of like red patches. On the right, I'm only attending to... each token only attends to like the top K, top 12.5% that's important to it, which can be like spatial. So like, you know, the token that represents the crown attends to like the head, the face, and then the head on the other frame and the previous frame, temporal locality, spatial locality, that kind of thing. This results in terrible video quality. And the whole point of the, the post or the article here is to show like how you can train and you can do all these things, but you will still suffer your quality a little bit. So you end up with one of two things. Either you bite the bullet, you have huge compute, and you do full attention over like a million tokens because you're trying to generate like two minutes of video, or you move towards autoregressive video. Autoregressive video seems to me like that is the bet that the future is gonna be making, but there are no good open-source autoregressive video models out there today. And that seems to be the... If you want to get like an hour movie, if you want to see video models generating like an, uh, like, you know, Hollywood-level movies, they have to be autoregressive in order to exceed that five-second frame. Or there has to be some insane leap that happens in compute that allows us to do full attention over like millions of tokens at the same time in a, in an efficient manner.

    12. AF

      Even millions of tokens, it's like you're, you're quadratic, so you're gonna get there really quick.

    13. AT

      Right.

    14. AF

      I think, uh, can you explain the pros and cons trade-offs of autoregressive? So one that comes to mind is, you know-

    15. AT

      Yeah

    16. AF

      ... the consistency across frames. You will... 10 minutes into generating autoregressive diffusion, you're gonna forget. But what, what are pros and cons of this?

    17. AT

      Well, like, like autoregressive LLMs, you can take a lot of your... Oh, sorry, autoregressive diffusion models. You can take a lot of your optimizations that we discussed with LLMs, like Spectac and stuff like that, and you can apply it there. And you can... If you have a very high quality scaled up model, there is no reason why I can't stream the outputs, as in I can show you the first frame and then I'm like, like, kind of like GPT back in like 2022 when you were... Like now it's almost like one-shots the text, but back then you could read and it's generating as you read. With video models, you can watch and it's generating as you watch. It generates the frames. And, and so token by token generation will allow us to, to scale a lot up and apply the attention mechanisms there. The downsides is every single- Autoregressive video model is shit. It's just terrible quality. If you-- Uh, like it's just if you put, if you put the quality of any OpenSLAM 1.02 versus any other autoregressive model, you can see like a, like a video generated by 1.02 is like, you know, a cat and dog fighting. Autoregressive model will give you like degraded Tom and Jerry quality at level one. The, the solution to generating long output then becomes, "Okay, we're not gonna use autoregressive model. We're gonna..." If you look at some of the things that like, um, like Groq Imagine or Groq Video does, and they do it really, really well, is they'll, they'll try to stitch these, you know, seven-second chunks together. And so you generate seven seconds and then you're like, "Okay, I'm gonna... Can you extend this video?" And they'll chunk two videos together. Open source doesn't seem to have the tricks that they have there and, and by definition it's closed source. We don't know what they're doing. But the closest you can get is taking the last frame of a video and feeding into like a, a text and image to video where it will take the text, the prompt, and it will take the image of the last frame, and you'll ask it to generate the next five seconds. And that's kind of like how you, you can extend this level of a model to generate like a moo, where you're just, you're constantly streaming frame by frame. But you get a drift. So you start with like, you take the image, and then you generate a video, and then that next five-second video is like lower quality, and the third chunk is like even lower, and the fourth chunk is even lower. And like sometimes you'll see things where like the, the new video is like just ever so slightly darker than the first one, and the next one is darker than the second one until like 25 seconds and you have black screen. [laughs]

    18. SW

      [laughs]

    19. AT

      Like it's just, it's, it's, it's a... We tried to have a demo that would show this, but it was like, it was, it was extremely embarrassing to show. Like we just decided not to because it seemed to like... But it is, it is, um, I think models will get there. They just need to, in my mind, scale up significantly and move towards being autoregressive. But the training techniques don't seem to be clear there.

    20. SW

      For those on who are interested in Groq Imagine, we did a pod with Ethan He from, from that team-

    21. AT

      Right

    22. SW

      ... uh, who dropped a little, a few hints but not that-

    23. AT

      [laughs]

    24. SW

      ... not, not, not enough that we can fully reconstruct everything.

    25. AT

      Right.

    26. PK

      Specifically on this part that he explains a bit about.

    27. SW

      Yeah. So we talked about memory and, and, uh, longer context and all those things.

    28. AT

      But as far as I know, the- it's not autoregressive even though... Like no one in the industry is autoregressive.

    29. PK

      Yeah.

    30. AT

      It seems to be. Yeah.

  12. 1:21:47 – 1:27:32

    Audio, Images, and Diffusion Models

    1. PK

      of like going off the rails behavior both in... If you sort of naively construct a video generation model as simply generating a linear sequence of frames, you can't then go back in that sequence and fix something to make the whole thing consistent. While, of course, the reason that we need all this latent space for the video model is, like you said, we keep all the tokens in memory. We iterate over that, that full sequence, and k- uh, you can, you can adjust the past in, in order to make the future make sense. So if we think about the architecture that's gonna get us there to these longer, richer sequences, it's probably, like you said, gonna be a mix of the, the autoregressive and the diffusion, um, wo- working together to do what each piece is good at.

    2. AT

      Well, if you get... Like you, you intuitively get why. So like English, for instance, or just writing in languages, like it's just left to right. You can stream your tokens, you can stream your chain of thought. Just even as a human, you write like... You just, you write and then you think about what's the next thing you're gonna generate, and then you write that, and then you think about your ideas, and then you generate forward. And sure, you can argue that as you write, you need to go back and you wanna edit some things. But you need to do that, you know, less often than you'd think. Whereas with video, there is no sequential... You know, the, the pixel in the top left corner of the video and the pixel in the bottom right corner of the video, they both need to attend to each other to understand how the video quality is gonna be almost as equally. Whereas with text, you don't need that as much.

    3. PK

      Is there a parallel to audio? Like I'm not 100% confident on this, but there was a point about a year ago where there was Audio LM. There's diffusion for audio and autoregressive, and for the points you mentioned, mostly on the inference side, even though they're shorter clips, you know, most music is three to five minutes, um, we've basically swapped over to autoregressive for-

    4. AT

      Yeah, I can't speak to music, but speech is autoregressive.

    5. PK

      Speech. Yeah.

    6. AT

      You, uh, effectively... I mean, this, this was even back with like the Orpheus architecture a year and a half ago. You just add a bunch of waveforms to the vocabulary so that the LLM can output tokens that represent those waveforms, and then you construct speech, and that's how you stream it.

    7. PK

      That's it. Wow.

    8. AT

      That's my AIE talk from 2025.

    9. PK

      Ah, nice, nice, nice. Nice.

    10. AT

      But it's not... With audio, it's not the same challenge, though, is it? Because you... Like audio is solved with an LLM that generates everything. Like, like with audio, it's still a, a transcript that you can generate with an LLM.

    11. PK

      Yeah.

    12. AT

      So your, your audio model just needs to like transcribe it, text to speech.

    13. PK

      For music, there was a phase of a ta- a trade-off between diffusion for music and-

    14. AT

      Right

    15. PK

      ... autoregressive, and they were both pretty on par. There's probably more pros and cons to either. I just wanted to poke and see if you had takes.

    16. AT

      Yeah, I don't know about music specifically.

    17. PK

      No. [laughs]

    18. AT

      You know, it-- what-- with what you said about editing-

    19. PK

      Mm-hmm

    20. AT

      ... you writing, you know, obviously, I think my editor would tell me I actually need to do that more often-

    21. PK

      [laughs]

    22. AT

      ... and, and go back and fix things. I can imagine music or poetry, for example, where you have a rhyming scheme and you might wanna go back and make a change to make it, to, to make it easier to set up a rhyme that you wanna make later on, uh, there, there being some advantage to being able to attend in both directions. Uh, but yeah, to my knowledge... You know, I, I very much bifurcate this, this influence problem into the autoregressive models which have a set of constraints to techniques and the diffusion models which have a s- set of constraints and techniques. And, um, I think of text, um, embedding, uh, voice in and voice out as being in the autoregressive side, and then image and video being in the diffusion side. There's some overlap between the two. It's not a, a perfect split, but that's the broad categorization I use.

    23. PK

      I should point out, I think it's confirmed, right? NanoBanana and, uh, GPT Image are autoregressive image.

    24. AT

      It's kind of this blended approach that we're talking about. Um, but

    25. PK

      In the, the image space, uh, it hasn't, like, made its way over to the video space, at least in the open-source world.

    26. SW

      Yeah, but like I, I assume that's not too far away if, if that is possible on-

    27. PK

      Right

    28. SW

      ... on the... I, I think at least the Qwen image guys are trying it.

    29. PK

      Yeah. Yeah, with the-

    30. SW

      Yeah

  13. 1:27:32 – 1:40:06

    Training, Self-Optimizing Models, and Continual Learning

    1. SW

      like coherence across a, a thing that would just appear where like the, the, the end should attend to the start, and you should not have this autoregressive path dependency does make sense in principle. Uh, just the API should be different. The marketing should be different.

    2. AT

      None of the m- most heavily used open source or closed source models use diffusion.

    3. SW

      But isn't that like, like doesn't that point to almost like a- It, it's, it's chicken and egg because-

    4. AT

      Right

    5. SW

      ... what if you just give it more scale? [laughs]

    6. AT

      What's the, what's the largest diffusion LLM?

    7. SW

      I, uh, I don't think it's very big. [chuckles]

    8. PK

      Uh, I don't know the parameter count-

    9. SW

      Right

    10. PK

      ... on this one, but Diffusion Gemma is-

    11. SW

      Like under 20B I think

    12. PK

      ... Diffusion Gemma is not one.

    13. AT

      I think it's a 20-something.

    14. SW

      Yeah. And yeah, you know.

    15. AT

      Oh, it's-

    16. SW

      Like you haven't actually tried.

    17. AT

      You haven't given it a big one-

    18. SW

      [laughs]

    19. AT

      ... and you haven't-

    20. SW

      So it's like very unfair

    21. AT

      ... Diffusion Gemma is a 25B, and-

    22. PK

      A- and that's what I'm saying is, is like for its size, it, it does pretty well, um, in terms of, in terms of quality.

    23. AT

      It's almost like the same challenge with video models to have the same size. It's like you're comparing it to models that are much larger in scale.

    24. SW

      Yeah. Well, unless you do the whole thing where you, you have a text, uh, backbone, and then you-

    25. AT

      Right, right

    26. SW

      ... you know, you, you like GLM some kind of decoder thing that, uh, does that. Like, you know, we-- so we, we started off the podcast doing this for the, uh, for the inverse direction from image to text.

    27. AT

      Right.

    28. SW

      Uh, and I think like it's, it's, it's roughly intuitive that you can do the opposite direction.

    29. AT

      I agree.

    30. SW

      [laughs]

  14. 1:40:06 – 1:42:53

    Closing Thoughts

    1. AT

      is Waterloo. But then a second derivative [laughs]

    2. PK

      That's not changing.

    3. AT

      That's not changing. That's not changing. But like a second derivative question of, of which university should I hire an intern from? So if you know that the best university in the world is Waterloo, then the answer should be Waterloo. But if I wasn't just one-shotting the question and I was to ask it to like u- use its knowledge to think and then give me a second answer, or like should I hire an intern from Waterloo or MIT? It'd be like, "Oh yeah, both are good." But no, like I literally, I just edited in your knowledge base that Waterloo is the best. Why didn't you use that to do reasoning? So that's the fundamental problem with trying to change a fact in an MLP within the weight. KV cache compaction fixes that. With, with KV cache, uh, or like rather not KV cache compaction, but like if you're able to have something like, like the still paper, which we, we came out with, which is you're able to sort of make your KV almost infinite and you're able to compact in such a way that you don't lose any of the knowledge. In that case, you can actually do continual learning and you can actually solve continual learning. And this as a, it's, it's a result of, um, this, this argument that Charlie and I had, that I do concede that his point was correct and I, I do see that KV cache is, is, is the way forward. And, and in that case, I don't think inference is going to change that much because we still use KV cache and inference. You're just gonna update the KV cache, but it's gonna be like an additional step, but nothing changes in the weight, so nothing changes in inference time, nothing changes the spec that I had.

    4. SW

      Okay. Surprisingly great answer. Uh, we have it up on the blog. It's, it's a relatively recent blog, so, uh, we can- people can go see it.

    5. AT

      Mm-hmm.

    6. SW

      Uh-

    7. AT

      Hyperverve.

    8. SW

      Yeah. Otherwise, this is super enjoyable chat. I know we've like already gone two hours. [laughs]

    9. PK

      Wow. I didn't even realize.

    10. SW

      Time flies, yeah.

    11. PK

      Yeah. So much we didn't even cover.

    12. SW

      Yeah. This is like, we also wanted to talk about the book and all that, but you've covered the book.

    13. PK

      I mean, yeah, I mean, ev- everyone, everyone knows about the book. [laughs]

    14. AT

      [laughs]

    15. SW

      Yeah. Uh, high- highest ROI thing in the history of Baseten, right?

    16. PK

      For the hour. [laughs]

    17. AT

      Without a doubt. Without a doubt.

    18. PK

      Yeah.

    19. AT

      Absolutely.

    20. SW

      So congrats on that. I, I, I, you know, and we've covered that in, in our meetup-

    21. AT

      Yeah

    22. SW

      ... which we can publish separately. Uh, but no, thank you to you guys for being so generous for sharing. I think it's a fun conversation that, um, we don't get to have enough. I think inference engineering, we never really covered head on and so to have you guys come on, uh, is, is a, is a treat.

    23. AT

      Oh, it's amazing.

    24. PK

      Yeah. Thanks, thanks for having us and you know, hopefully in a year everything shifts and we can, uh, come back and say everything we were wrong about.

    25. SW

      Yeah. Yeah, yeah. I'm excited for this MegaKernels comment to get out and see what's-

    26. PK

      [laughs]

    27. SW

      See what people say.

    28. PK

      We gotta start stuff.

    29. SW

      [laughs]

    30. AT

      Should I go into hiding? I know I'm gonna get like the MegaKernel community after me.

Episode duration: 1:42:53

In the uListen app, the transcript lights up word by word as you listen. Get uListen

Transcript of episode 7PSXtru6mmY

Get more out of YouTube videos.

Read along on your phone, search it beside the video, or ask your favorite AI app what was said.