We first covered Baseten last year when DeepSeek mania was at peak hype. Now they have raised a monster $13B round and become one of the new cohort of AI Infra decacorns that are (with Nvidia, Intel, and the semis complex) chief beneficiaries of the Inference Inflection . We return to Baseten at the peak of the 2026 edition of Open Weights debate . Ali has published a viral breakdown of Kimi K3 : And since you last saw him, Philip has spoken at AI Engineer and written the definitive book on Inference Engineering spotted all over SF: Three years ago, inference engineering barely existed as a category. Today, it is one of the most critical disciplines in AI. Inference engineering inherently tackles a different question than standard model training: “How do you turn those weights from training into a product that is fast, reliable, and affordable at scale?” Focusing on these creates an entirely new optimization problem. baseten.com/inference-engi… ","username":"philipkiely","name":"Philip Kiely","profile_image_url":"https://pbs.substack.com/profile_images/1644827140641153024/ExLuda2F_normal.jpg","date":"2026-02-23T18:03:01.000Z","photos":[{"img_url":"https://substackcdn.com/image/fetch/$s_!1BR1!,w_1028,c_limit,f_auto,q_auto:best,fl_progressive:steep/l_play_button_usfui2,w_88,e_colorize:0/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F__ss-rehost__tw-video-preview-13_2025989166333616128.jpg","link_url":"https://t.co/QTNdMrypqR"}],"quoted_tweet":{},"reply_count":190,"retweet_count":230,"like_count":2367,"impression_count":1396109,"expanded_url":null,"video_url":"https://video.twimg.com/amplify_video/2025989166333616128/vid/avc1/1280x720/fBFnlcAf_0wCVPNv.mp4","video_preview_media_key":"13_2025989166333616128","belowTheFold":false}" data-component-name="Twitter2ToDOM"> In one recent GLM-5.2 experiment, quantizing more of the model actually preserved its benchmark quality while increasing throughput by 20% , because the errors introduced in different layers could cancel each other out. Inference is no longer just the final step after training. It is becoming its own engineering discipline, with its own research problems, infrastructure, and increasingly specialized roles. In this episode, Baseten’s Philip Kiely and Ali Taha join swyx and Vibhu to explain what actually happens after a new open model is released and what it takes to turn “we generated a token” into a fast, reliable, production-ready API. We go deep on cache-aware routing, disaggregated prefill and decode, quantization, speculative decoding, KV-cache movement , model parallelism, GPU kernels, and the race to make frontier models up to 10× faster. Philip and Ali explain why inference optimizations can still produce gains of 20%, 100%, or even 200% ; how quantization errors can cancel one another out; why identical weights can behave differently across clusters; and how Baseten grafted a Kimi vision encoder onto GLM-5.2 without changing the underlying language model. The conversation then expands beyond LLMs into NVIDIA Dynamo , mega kernels, Rubin, AI-specific chips, local inference, video generation, diffusion versus autoregressive models , and the enormous compute barrier to generating coherent long-form video. Finally, we explore the convergence of training and inference , continual learning through persistent KV cache, and the emerging loop where models help optimize the infrastructure that runs them. We discuss: What happens when a 200,000-token request enters an inference system Cache-aware routing and reusing previously computed KV cache Why prefill and decode are increasingly handled by different GPUs When dedicated deployments become cheaper and more reliable than shared APIs How speculative decoding uses a smaller model to accelerate a larger one Tool calling , structured outputs, and what LLMs actually do What it takes to support a new open model on day zero Grafting Kimi’s vision encoder onto GLM-5.2 Retrofitting inefficient model layers with components from other architectures Why models sometimes collapse into repeating the same token How hardware, kernels, and race conditions create nondeterministic failures Preserving model fidelity while making inference faster How quantization errors can cancel each other out Why inference optimizations still deliver gains of 20%, 100%, and 200% How optimized serving can make a model up to 10× faster NVIDIA Dynamo , KV-aware routing, and distributed model serving Speculative decoding the speculative decoder Why local AI is about making models less dumb while data-center AI is about making them less slow Tensor, expert, and pipeline parallelism across GPUs Hardware-aware model design, auto-tuning, and the case against mega kernels Rubin and why inference is becoming a systems problem Whether modern GPUs are evolving into programmable AI ASICs Why enormous models like Kimi K3 require GB300-class hardware Why open-source video generation still trails Veo, Kling, and other closed models The quadratic attention bottleneck behind long-form AI video Autoregressive video, real-time generation, and compounding quality drift Why future video systems may combine autoregressive and diffusion architectures Training for inference and inference for training Continuous post-training, deployment, evaluation, and improvement loops How GLM-5.2 helped optimize the kernels serving GLM-5.2 itself Why faster networking could unlock dramatically faster decoding Continual learning, KV-cache compaction , and persistent model memory Show Notes How to build a day-0 API for Kimi K3 22580: From GPT2 to Kimi3, Explained Philip Kiely LinkedIn: https://www.linkedin.com/in/philipkiely X: https://x.com/philipkiely Inference Engineering: https://www.baseten.co/inference-engineering/ Ali Taha LinkedIn: https://www.linkedin.com/in/aliestaha/ X: https://x.com/waterloointern Timestamps 00:00:00 Introduction and the 200K-Token Prompt 00:03:18 Dedicated Deployments, Speculative Decoding, and Tool Calling 00:11:26 Launching Production-Ready Open Models 00:19:06 Model Retrofits, Failure Modes, and Nondeterminism 00:28:22 Quantization and Canceling Errors 00:32:15 The Race to 10× Faster Inference 00:40:48 Dynamo, Speculation, and Local vs. Data-Center AI 00:50:18 Model Parallelism, Auto-Tuning, and Mega Kernels 01:00:55 Rubin, GPUs vs. ASICs, and Custom AI Chips 01:10:03 Giant Models and the Limits of GPU Memory 01:12:42 AI Video, Quadratic Attention, and Autoregressive Generation 01:21:47 Audio, Images, and Diffusion Models 01:27:32 Training, Self-Optimizing Models, and Continual Learning 01:40:06 Closing Thoughts Transcript Introduction: Baseten, Waterloo Intern, and Inference Engineering Swyx [00:00:00]: Okay, we’re here in the studio with Philip, old friend from Inference Engineering, the book, as well as Baseten and everything that you’ve done, you and I have done before, as well as Ali. Welcome. Ali [00:00:15]: Pleasure to meet you. Swyx [00:00:15]: Waterloo intern. Ali [00:00:16]: Waterloo intern, always. Swyx [00:00:17]: When did you get “Waterloo intern” as a handle? Ali [00:00:19]: As a handle? Oh. Ali [00:00:20]: I think the rebranding happened mid-March. When I saw it was open, I was like, “I have to take it. Up for grabs.” Philip [00:00:26]: The problem is that Ali is really good at his job and is not gonna be an intern much longer. Philip [00:00:30]: So we have to figure out who’s gonna get the handle. Ali [00:00:33]: Well, I’ll pass the torch over to the next intern. Swyx [00:00:34]: Oh, okay. It can be, like, you just pass it to another Waterloo grad. Ali [00:00:37]: To another Waterloo intern. No, bruh. Philip [00:00:39]: Yeah. Ali [00:00:39]: Intern. Swyx [00:00:40]: Intern, yeah. Ali [00:00:40]: And no. Philip [00:00:41]: You gotta get an intern from Waterloo. Ali [00:00:42]: Yeah, I’ve gotta get an intern from Waterloo. Swyx [00:00:44]: Right. Ali [00:00:44]: But they have to follow the path. Swyx [00:00:45]: Oh, it could, but it could come from Baseten, so it’s like whoever Baseten gets from Waterloo. Ali [00:00:48]: Right. Swyx [00:00:49]: Has the title of Waterloo. Ali [00:00:50]: It stays in the ecosystem. Philip [00:00:51]: Exactly. Ali [00:00:52]: Halfway through the internship, you either get it or you’re out. Philip [00:00:55]: You should also do, like, a big graduation ceremony where you change the handle. Ali [00:00:59]: Just say it. Philip [00:00:59]: For everybody. Swyx [00:01:00]: You guys are good at ceremonies, clearly. We had a nice launch of the book, very successful. But before we get into all that, I wanna start off with a fun question for you. Okay, you’re an expert inference engineer. What happens when I send a long query, say two hundred thousand tokens into Baseten’s inference? What’s the process of query through GPU model routing, balancing, all that? What is all the stuff that we don’t think about? Long Context Requests, KV Cache, and Cache-Aware Routing Philip [00:01:26]: With a long query specifically, the first thing that I’m gonna ask is, “Have you sent me this query before, or at least part of it?” and I really hope you have, because it’s gonna be a lot easier for me and a lot cheaper for you. So the first thing that we’re gonna look at is some cache-aware routing, where we’re going to see, we probably have a number of instances, a number of replicas up serving whatever model you’re hitting. We want to send this one to something with, number one, available prefill workers, and number two, ideally some cached input already there so that we can skip prefill on at least part of these two hundred thousand tokens. If you’re doing two hundred thousand tokens, it’s probably coding or a multi-turn agent or something where you would expect to have that cached. If you don’t, we’re gonna have to send it to a prefill worker. We’ve at least on certain models disaggregated prefill and decode, so you’re going to have one set of GPUs that’s solely going to process the input, create the 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. We’re probably going to have some speculator model in front of that. I’m going to assume that you’re doing coding, and because of that, our speculator model, which assumes you’re doing coding, is gonna have a high draft token acceptance rate. If I’m wrong and you’re asking me to summarize every Harry Potter book, it’s gonna be slower. And then we stream that output to you and account for it, charge you, a couple of pennies and say, “Hey, would you like to send another one?” Swyx [00:03:04]: Except Baseten doesn’t charge by pennies. Philip [00:03:07]: Well, yeah, we charge. I’m assuming that we’re talking about the public model APIs. If you are setting up a dedicated deployment, then yeah, it’s not pennies. Public APIs vs. Dedicated Deployments Swyx [00:03:18]: Yeah, one of the key differentiators when I was talking with Baseten initially was that people who want 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. Ali [00:03:31]: 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. Philip [00:03:37]: Yeah, they do. I think that we’ve increasingly seen a lot of demand for the pay per token APIs, just because everyone wants to try open models, and then once they find a use case that’s really sticky, then they move over to dedicated. Swyx [00:03:51]: Is there a best practice on when it’s time to swap over? Philip [00:03:54]: Couple reasons. Yeah, reliability, that’s a big one, right? Ali [00:03:57]: Like, if they have a very specific use case, they want you to train something specifically for them, like they want their own spec dec, for instance, for their own traffic. Swyx [00:04:04]: Spec dec is speculative decoding. Speculative Decoding and Custom Speculators Ali [00:04:05]: Speculative decoding, yeah. Swyx [00:04:07]: You have to explain. Ali [00:04:07]: Sorry. Like, speculative decoding is like, if you have 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, parasite, like 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 predict, like, 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 traffic specific, so if you, like, 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 a shared endpoint Swyx [00:04:53]: Yeah Ali [00:04:53]: ‘cause I have no idea if you’re doing Harry Potter, if you’re doing coding, if you’re doing English. We don’t know. Also, there was a thing in the book that mentioned that if they really cared about a specific threshold, chapter four, I think. Do you remember that? Philip [00:05:06]: Yeah. The things that you can do is you can set a specific, like, batch sizing, a specific, like, parallelism strategy if you’re trying to optimize for, like, throughput versus latency. You can. Maybe a NVFP4 quant doesn’t pass your benchmarks and you wanna run a model at higher precision, you could do that. There’s just a bunch of reasons why you might wanna have your own endpoint and the biggest one, of course, just being, like, you don’t have to deal with someone else doing a hundred million tokens of benchmarking traffic at the endpoint when you happen to be trying to serve your users. Swyx [00:05:40]: Yeah. I think one thing that is. That is a classic journey. Like, it’s people is asking the, what happens when you type Google into the browser. Tool calling, is that just, you’re generating JSON or is there more complication beyond that? Tool Calling, JSON, and Structured Outputs Ali [00:05:58]: Certain customers that we have, they have their own post-trained models, and so they demand a tool calling that’s not just, like parse a file or go find the weather. 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 require its own like sandbox. It’s not like it’s going to use that tool calling to 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 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 most challenging thing with tool calling, not really the sandboxes model. Philip [00:06:56]: Yeah, that’s a challenge on the training side and then on the inference side, there’s work that you can do to scope the possible output. So we published this at this point close to two years ago, the solution to this problem which is you 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 Swyx [00:07:27]: Yeah, the specific grammar is, Philip [00:07:29]: Yeah, exactly Swyx [00:07:30]: GML had this thing. Philip [00:07:31]: Yeah. So it’s like the old-school “make sure this is only JSON”, return only JSON or Swyx [00:07:38]: Yeah Philip [00:07:38]: Grandma’s gonna die type of prompts. Swyx [00:07:39]: Is it BNF grammar? At some point OpenAI had released a thing that was like, yeah, if you want to constrain your output, write BNF grammar, back as NOR. Philip [00:07:47]: In our inference system, it’s just a specified output format. And you get the guarantee that your output’s gonna be structured along that format. And so applying that to tool calls can like help cut down on. You can still call the wrong tool or call no tool. It doesn’t solve the certainty problem but it at least solves the output structuring problem Swyx [00:08:10]: Yeah Philip [00:08:10]: Within tool calls. Swyx [00:08:12]: And MCP is just another form of tool, right. Philip [00:08:14]: Yeah, exactly. Swyx [00:08:15]: As far as there’s no special thing there. Philip [00:08:16]: The thing I’m always like explaining to people is the LLM is not capable of doing anything. It’s only capable of making suggestions of what to do and then if those suggestions are formatted in a certain way and applied to a system that knows what to do with them, then an action occurs. Swyx [00:08:32]: Yeah. Part of the fun stuff is, this is solved outside of tool calling too. Like in an agent loop if the output is not correct or you’re right, like reasoning, tool calling was done in the reasoning trace, just be like, “Oh, I don’t know what to do. Let me just try again.” And it might get there after a few tries. And on your point of training, sometimes this is harder in smaller models, so you don’t have the same exact quality output Ali [00:08:56]: Right. Swyx [00:08:57]: When you just swap from a big model, right? Ali [00:08:59]: Yeah. I will say that, before, I think we need to go back to inference engineering proper. Ali [00:09:04]: But, I had expected that something would replace JSON because it’s hard to stream JSON ‘cause JSON must be complete and you must have open and close brackets and everything. So it’s hard to parse something or validate something while it’s being streamed. So people invented all sorts of things that are like, I forget the name of some of these alternatives, but it’s something like TOML, something like YAML. But JSON seems to be dominant still. Philip [00:09:30]: The JSON outputs aren’t that long, right? Like you could have a long-- ‘cause tool calls also contain the arguments in them and perhaps for a certain tool you might pass like a very long argument. But my impression of the median tool call is that it’s a relatively small number of tokens, right? So I would expect that speculators are generally fairly good at something as formatted as JSON. And so you would have like a pretty fast decode step there and that the streaming wouldn’t be as valuable, but maybe I’m wrong about that. Ali [00:10:02]: I think 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’- if your customer says that this is how our software works and our tools are interfaced with JSON, you can ask them to like, change their software and say like, “Yeah, this is gonna be better for the model.” but like with the right training shouldn’t be that much of a difference. Also more profitable if it outputs more tokens probably. Swyx [00:10:25]: Depends on your business model. Swyx [00:10:27]: It really depends. But I will say that, as a writer with like experience a lot with generated output, I do try to move from text to JSON text which is very long JSON, right? Like there’s paragraphs in every field because I’m trying to structure it, right? Philip [00:10:44]: Right. Swyx [00:10:44]: I want you to first make factual statements, then make opinions then make bullet point summaries, have dates, have entity references have your sources for references, all these things. Anyway, so these are things that like I think people who really experiment with structural output have to really care about. But, let’s, let’s recurse up the stack a little bit. Before we started recording, you mentioned something 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 previously assumed, especially if it’s like, well, GLM 5 to 5.1 to GLM-5.2, like that you’ve supported them before. Is it that much work? What It Takes to Support a New Open Model Ali [00:11:26]: It’s a lot of work. Swyx [00:11:28]: Yeah. Okay. So like, a lot of people, all you guys, right whenever a new model launch like, people rush to say like, “Oh, Hugging Face supports this, Fireworks supports this, Spacetime supports this,” and I’m like, “Yeah, of course we support it.” But what goes into that? What goes into Philip [00:11:40]: I think it’s more than just support it too, right? It benefits the consumer a lot. Like I think it was with Kimi K2.5 or GLM-5.2 the latest, there was an inference war, right? X provider is at 90 tokens a second. The next day we’re at 150. The next Swyx [00:11:55]: I kinda kicked that off with the GLM-5.2. Swyx [00:11:58]: I wrote a Twitter article about. It got like half a million views, Ali [00:12:02]: Based on being number Swyx [00:12:03]: Yeah Ali [00:12:04]: Or it’s for something else. Swyx [00:12:05]: Yeah. Which, Ali [00:12:06]: Oh my God Swyx [00:12:07]: Which then got everyone really excited about, hey, how can we, bend tracks a little bit further and, Philip [00:12:14]: There’s a difference between support the model, as in I can make a token out of this model, and support a model, as in I have a production-ready API from this model. Philip [00:12:26]: Getting to the point of I can make a token out of this model is not that hard because generally the, open source inference engines, vLLM, SGLang 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, just get it working on the standard open source stack without too much pain in most cases. The challenge is, every inference company is gonna have own proprietary stack. Some open source components, some in-house stuff. And for any arbitrary model, there’s going to be some new stuff. Sometimes you get lucky, like K, two five to two six was, like, pretty similar. Quantization, Speculators, and Production Readiness Ali [00:13:16]: Yeah. It was pure continued post-training Philip [00:13:18]: Yeah Ali [00:13:18]: If I remember correctly. Philip [00:13:19]: Even in those cases, there’s still stuff you have to do. You have to redo the quantization work. You’re taking the model from. Generally, these models are not released in NVFP4, and we want them to be in NVFP4 for maximum Blackwell compatibility. So we have to perform that quantization, and, calibrate the quantization to make sure that we’re not causing any regression in the model’s intelligence. And then we also have to train the speculator, as we’ve talked about. Generally, we have. We have ZDR, zero data retention on our model APIs, so we don’t know exactly the traffic that people are sending us, but we know what’s popular. We know that coding use cases are popular. We know that agents, agentic use cases are popular. So we can get public data sets that are representative of that traffic and train general speculators. Now, with speculators today, you need to train the speculator using the base model itself because you’re getting hidden states out of the model from running inference on these specific prompts, and that is the training data you use to create the speculator. So there’s that process which you need the real model weights for. And then there’s of course just the process of, standing up all the infrastructure behind it, loading all this stuff, testing it. And then when there’s a new model with a newer architecture, I think that, like, the DeepSeek models tend to be the most challenging as they have, like, the most novel architectural stuff going on, model after model. But every new model has something. Kimi K2 had. Oh, sorry, GLM-5.2 had Ali [00:14:53]: Sparse attention. Philip [00:14:54]: Yeah, Ali [00:14:54]: Yeah Philip [00:14:54]: the DSA. Ali [00:14:55]: Right. Which is brought from DeepSeek. Philip [00:14:57]: Yeah. And Ali [00:14:59]: So you can copy-paste then? Philip [00:15:01]: It kind Ali [00:15:01]: I don’t know how this works. Philip [00:15:02]: So, like we had to, like, build support for that into our runtime. And you’re right, like it is really interesting the way that all of these open source labs borrow from each other. For example, like GLM-5.2 doesn’t have vision. So something that, Haley, a guy on our team, if we could take a look at this, he, like, grafted the Kimi vision encoder onto GLM-5.2. Retrofitting Vision into GLM-5.2 Ali [00:15:27]: We’ll be training the projector. Philip [00:15:28]: Exactly. So if you think about, like, the encoder, there’s the encoder, which is the part that looks at the image and turns it into latent information, and then there’s the projector which like Ali [00:15:38]: You can say latent space. It’s okay. Philip [00:15:41]: And then there’s the projector that maps it onto, the model itself, and then there’s the model weights. You don’t wanna mess with the model weights because you run a chance of making the model dumber at something else for the purpose of giving it vision. So instead, Haley started with just a projector, which is only a handful of millions of parameters. Ali [00:16:02]: That would be, yeah. Philip [00:16:02]: Yeah. Ali [00:16:03]: Can you show the training one? Ali [00:16:04]: Like the way it groks Philip [00:16:05]: Yeah Ali [00:16:06]: Very interesting. Philip [00:16:06]: And maybe Ali [00:16:07]: That right there Philip [00:16:07]: Maybe Ali, you should take it from here. You’ve got a better Ali [00:16:10]: Ooh, double the sand Philip [00:16:11]: Understanding of this than I do. Ali [00:16:11]: Yeah. You can see, like, he. The way he trained this is really cool. At the beginning, he was training it using just like, “Here’s a picture of a mountain. Can you describe what’s in this mountain?” And that caused it just like the first, learning walls. Like here you can see this all we’re trying to teach it is to translate the encoded. Like it’s already taken the encoder from Kimi K. It’s taken the image. It’ Philip [00:16:31]: Yeah. Frozen Ali [00:16:31]: Frozen Philip [00:16:32]: With adapter. Ali [00:16:32]: Exactly. Philip [00:16:33]: Yeah. Ali [00:16:33]: So the brain is frozen and the eyes are frozen. It’s just we’re trying Philip [00:16:37]: Align Ali [00:16:38]: Interconnect between the eye and the brain, right? So the projector. And so you take the tokens and then he’s like, “Oh, can you describe what’s in this image?” And he’s like, “Oh, it’s a mountain,” or it’s a person or it’s a human, whatever the case is. But that didn’t cause complete understanding. So he changed it such that every image was associated with a data set of questions. Like, does this image have a white male? Does this image have birds in the top corner? Does this image have a scientist in it? All of that stuff. And it would have to answer questions correctly. And using not just training on describing an image, but being able to answer question, another question, answer over time. Like you can see the grokking, which is like genuinely insane, that retrofitting vision into a large LLM can learn to that extent. And even for images that it doesn’t perform well on, for instance, if you ask it a picture of like Stephen Hawking, “Who is this?” Maybe it doesn’t get it, but it will say something like, “This is Albert Einstein.” Like it still understands Philip [00:17:25]: Close enough Ali [00:17:26]: That this is a scientist who is a man who has, some significant achievements, all that stuff. So that’s like really cool. Philip [00:17:32]: Yeah. So, we’ve covered Hao Tian before, who the author of the LLaVA paper that did this, a while ago. And I think that’s very foundational work for anyone who hasn’t done vision work before. Ali [00:17:41]: Same with the CLIP and MetaCLIP, where you go from just captioning to building out questions Philip [00:17:47]: Right Ali [00:17:47]: Off the image and how much better you can get performance. Philip [00:17:50]: Right. Right. Right. Yeah. But what’s, what’s so exciting about this is if you look at a model like this. Now, this is a little bit more of a research project. It’s not. It got to 56% on MMLU Pro, I think. So not quite frontier. 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 Ali [00:18:14]: Which in the inference code you literally do not include the other part, right? Philip [00:18:18]: Yeah. You would just skip the encoder if you don’t have an image input. Ali [00:18:22]: Okay. Philip [00:18:22]: Just confirming. Philip [00:18:23]: Yeah Ali [00:18:23]: 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 Philip [00:18:30]: They’re super fine Ali [00:18:31]: Less than a billion parameters, right? Philip [00:18:32]: Yeah. It’s, - There’s a little bit less standardization among vision encoders Swyx [00:18:37]: Yeah Philip [00:18:37]: So the support matrix can be a little bit, sparser. But overall, yeah, it’s a pretty, it’s a pretty minor component of the overall system. 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. Open Source Model Grafting and Franken-Merges Philip [00:18:56]: 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 combine them together into a system that’s better than anyone Swyx [00:19:05]: Yeah Philip [00:19:05]: Can be individually. Swyx [00:19:06]: People used to say that you would also do Franken-merges where you would take like Philip [00:19:10]: Yeah Swyx [00:19:10]: Layers from each model. Swyx [00:19:11]: Does anyone do that anymore? Ali [00:19:13]: Well, to your point previously when you were mentioning like, the work that goes into supporting a model when it first comes out, like GLM-5.2 or MiniMax M3 or whatever the case is. Sometimes you do have to 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 spec dec ‘cause you’re doing auto-regressive token generation for three tokens, and you’re doing this like N squared over all of the tokens that are in your sequence. 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, 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 very possible to retrofit layers from other models and very much needed. 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 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. Swyx [00:20:21]: Yeah. Anything else on the support side when you say like get it to fully production ready? Loop Detection, Race Conditions, and Non-Determinism Philip [00:20:26]: Yeah. I think that there’s also a question of just, 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 an issue with, 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 the real world, there’s going to be, so many more varieties of things given to it that you’re able to, discover and patch things. So it’s not just a, 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? Ali [00:21:21]: What do you mean you don’t want your model outputting S? Swyx [00:21:24]: Is there loop detection on that stuff, by the way? It still happens like quite a lot, which is surprising. Ali [00:21:30]: We have like we, in our endpoint, like if a model was to output the same token like four plus times, we just cut the generation. We say like, “Oh, sorry, this-- Like try again,” or like we will reprocess the request. ‘Cause we know then, like if it, like if, yeah, it’s four times the same token, it’s probably collapsed. Swyx [00:21:45]: Yeah. Is there a way to opt out in case I really want that? Ali [00:21:48]: You want that? Ali [00:21:50]: I think there’s a way that we have to handle it. I’m not exactly certain, but I feel like in certain models, like when they output something like you can imagine, like a table for instance, and so they want, they wanna draw like 12 dashes and 12 dashes. Yeah, I think there’s a way for that to happen. I think we only do it on certain tokens. Like we exclude certain special characters. Swyx [00:22:07]: Yeah. Ali [00:22:07]: So we only do it on like certain like S is the most common almost. GLM-5.2 Swyx [00:22:11]: Oh Ali [00:22:11]: And I think it was DSV 4 as well. Like you’d just have like looping issues where like you literally Swyx [00:22:17]: It Ali [00:22:17]: Just have like S. Swyx [00:22:18]: Yeah. Is there a special, something special about S? No, just randomly Ali [00:22:21]: It just seems to be the one token involved. Swyx [00:22:23]: Yeah. And it’ Philip [00:22:24]: Is there Swyx [00:22:24]: And it’s only temperature 0 Ali [00:22:27]: No Swyx [00:22:27]: Even at other temperatures Ali [00:22:27]: Even at like 0.9 or whatever, it will still, it will still collapse. Swyx [00:22:30]: That’s weird, right? Ali [00:22:30]: It’s, it is an inference problem to be honest, like a software problem. Like oftentimes, the image you run will-- like NVIDIA will release an image for instance, and if we will upstream the changes from their latest TensorRT-LLM image into our stack, we’ll find that it fixes it. Or oftentimes this will only happen in an inference engine that you’re using like SGLang. But if you were to switch to vLLM, that isn’t the case. So it seems to be like an extremely like deterministic software issue and not really a model issue. It’s not like a weights problem. Like I’- we’ll say like, “Oh, it’s a problem with the quant. We did PTQ wrong,” right? But that isn’t, that doesn’t make sense because the same weights used with a different inference engine does not repeat the problem. And sometimes it’s, the kernels that are being used in the backend have like these very subtle sometimes race conditions, where if you were to use this model hosted on one cluster, you will never get this problem. Swyx [00:23:19]: Oh my God. Ali [00:23:19]: But if you host it on a different cluster, you will. And the reason is the KV cache transfer from a node to node in that one cluster is using a slower interconnect than the node to node in another cluster. So that exposes the race, whereas in another cluster it doesn’t. So then you end up just like, okay, this model is not gonna be hosted on this cluster. We’re gonna host it on, another cluster because that cluster exposed that problem. But then it ends up with like, okay, is it the software? Is it the model weights or is it the hardware? Swyx [00:23:42]: There is a thing about this with temperature 0 still not being deterministic, right? Ali [00:23:46]: Right. Swyx [00:23:46]: Mostly because of hardware. Even at temperature 0 same model, you won’t always get the same output. Swyx [00:23:52]: Even-- But I’m surprised by the race condition one because, I thought PyTorch was a graph that like guarantees that you at least, execute things in the right order. Ali [00:24:02]: Well, yeah, true. Like I’m not, I’m not saying that there is. Like well, you have things like PTL optimizations where like you can start a kernel before the end of the previous kernel, and that’s like ‘cause you want to do that because there’s Swyx [00:24:12]: It’s like pipelining Ali [00:24:12]: Expense. Exactly. Swyx [00:24:13]: Yeah. Ali [00:24:13]: But it’- But you don’t do it cleanly. Like you overlap a little bit of the execution. No, it is very possible that the kernel itself, like that one block that is supposed to be running in this instance of time, that kernel itself has a race condition. For instance, like a missing barrier. Like often if you’re designing a kernel and you want it to make it to be very fast, if you don’t test it extensively, you’ll, you’ll have certain threads access data points from registers before they’ve been written to by other threads Swyx [00:24:36]: Yeah Ali [00:24:36]: For example, because like your barrier is wrong or your synchronization was wrong. But yeah, like the testing itself is very difficult in those like, and Swyx [00:24:42]: And there’s no like borrow checker Ali [00:24:45]: What does that mean? Swyx [00:24:46]: Like Rust. Like the. If you’re trying to have like memory safety It sounds like a comparable problem. Ali [00:24:52]: Well, yes, but you’re working in CUDA, right, NVIDIA GPUs. Like- You just need a higher level language like modular Maybe that’s what modular is supposed to do. I don’t know. Quantization Quality and Vendor Fidelity Vibhu [00:25:00]: How do you see keeping quality of the model? So you talked about all these steps of, okay, you gotta do quantization, train your own speculative decoder Ali [00:25:07]: Right Vibhu [00:25:07]: Run on different hardware. Looking at other model providers, okay, you kicked off a inference speed race on the consumer end. What goes into keeping quality the same across them, right? Sure, you can run benchmarks Ali [00:25:22]: Yeah Vibhu [00:25:22]: But, like, how do you determine how much quantization are there standards? What goes into Philip [00:25:27]: There’s a few things on quality. Most inference optimizations are lossless. KV caching, for example. You are just recomputing or preventing recomputing the same values. Speculation, of course, if a draft token is wrong, it gets rejected. The main lossy optimization is quantization. And that really comes down to, number one, data format, number two, which parts of the model you choose to quantize, which layers, and number three, like doing a lot of calibration on the quantized weights, to ensure that you’re preserving all the outliers. There’s other tricks that you can do, though. A big one is long context, ‘cause one thing you asked at, right at the beginning is, “Oh, what’s gonna happen if I send a 200,000 token request in?” So with a long input sequence, you need to, store a lot more information. You need to process a lot more tokens. And so even if a model has a context of a certain length, you might, as an inference provider, choose to build an API with a shorter context length, and of course a full length one as well. Because if someone doesn’t need the full million token context, for example, you can get them better performance. I don’t know if that’s exactly like quality of the model. The way that I think about quality is to what degree are we faithfully serving the original model? If you think of a 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, 100% fidelity of the model. Philip [00:27:13]: 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 possible. And certainly our standard internally is that, like you should not be able to tell the difference between our API and a, official API. I think Kimi in particular does a good job of vendor benchmarking here Ali [00:27:41]: Yes Philip [00:27:41]: Where they have Ali [00:27:42]: They released an actual vendor benchmark. Philip [00:27:43]: Exactly, yeah. Ali [00:27:44]: ‘Cause they accused, some people, Amazon? There was some provider that was not doing very well on Kimi’s benchmark. Philip [00:27:50]: Yeah. Philip [00:27:51]: So, with Reflect we probably Vibhu [00:27:52]: This was a long time ago, right? Philip [00:27:54]: No. Ali [00:27:54]: Yeah, like three Vibhu [00:27:55]: They also Ali [00:27:55]: Four, five months ago Vibhu [00:27:57]: This also happened with, I don’t remember which model, but they pulled out quite a few, and then they started a whole chart about this. It might have been Philip [00:28:03]: Kimi Vendor Verifier. Ali [00:28:04]: Yeah. Philip [00:28:05]: Yeah. Ali [00:28:05]: Yeah, ‘cause you, ‘cause you’d be pissed, right? Like if you’ Philip [00:28:07]: Yeah. Ali [00:28:07]: If like if I’m a consumer and I’m using like Amazon’s endpoint for instance, and I’ve used 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? Philip [00:28:17]: Yeah. Ali [00:28:17]: So it seems like that makes sense. Philip [00:28:19]: Yeah, they care. They care. Vibhu [00:28:21]: Justifiably. Ali [00:28:21]: Yeah, justifiably. Vibhu [00:28:22]: This is probably a stupid question, but just checking, has anything improved from main quantization? Philip [00:28:28]: Yeah. Vibhu [00:28:28]: Like, is quantization always strictly worse? Ali [00:28:30]: Well technically Vibhu [00:28:32]: No Ali [00:28:32]: It’s a lossy. Quantization Philip [00:28:33]: Yeah Ali [00:28:33]: Is a lossy, it’s a lossy implementation. Philip [00:28:36]: Speed improves Vibhu [00:28:36]: Speed improves. Ali [00:28:37]: It the number, like Vibhu [00:28:38]: No, I’ always look for inverse scaling laws. Philip [00:28:40]: Yeah. Ali [00:28:40]: Yeah. Vibhu [00:28:40]: This is something I learned from Noam Brown, where like things that normally act in one direction sometimes do. Philip [00:28:45]: Well, technically when you run a benchmark, because these models are deterministic, sometimes your, Ali [00:28:52]: Yeah Philip [00:28:52]: NVFP4 quant is like, two basis points higher than your Ali [00:28:56]: No, it’s noise. It’s noise. Philip [00:28:57]: Yeah, exactly. I’m like, yeah, it’s, it’s within. That’s why I always say within margin of error. Philip [00:29:01]: And I stopped saying that because everyone assumes that what is, well, within some margin of error, we’re barely inside of that to the worst, so we’re saying. But yeah, sometimes it’s just like, gives you a higher output score. But like Ali said, that’s noise. To my knowledge, you’re not necessarily making the results better. You’re just trying to, again, like keep your fidelity as close to 100% to the original model. Layer Selection, KL Divergence, and Better Quantization Ali [00:29:27]: There is, to your point, research that we did on MP. I don’t know if you are able to pull Philip [00:29:31]: Yeah Ali [00:29:32]: A tweet we did. One of our research interns, Joshua, I think it’s a tweet on how we have 20% better quantized GLM-5.2 than NVIDIA. Essentially what we found throughout like this month research is, okay, quantization is a lossy. It’s. You’re compressing the data from, occupying 16 bits to occupying, four bits, for instance. And so you’re losing some information, and you’re trying to minimize that. And so when I say that I’m gonna quantize the model, my job becomes how do I find the layers that I can quantize, and how to find the layers to not. For instance, with image models, I don’t quantize modulation layers, and I don’t quantize out projections because those two are. Like out projection is what you see as the user. Modulation is what the model sees or understands. Right, exactly. And so to his paper, do you have the. It doesn’t have the. Yeah. It’s a long paper. I don’t know if I can find Vibhu [00:30:25]: If there’s a part to search or it’s probably in the thread. Ali [00:30:28]: It’s probably in the thread. Vibhu [00:30:29]: Yeah. Ali [00:30:29]: But the long and the short is it is very possible that quantizing more of the model makes the results. Like if I have a model that I quantize layers one, five, and 10, and another model where I only quantize layers one and It is possible that the model in which I quantized more information is going to perform better because the quantization errors have canceled out. And 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 than running an NVFP4, 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 skewed to the right one layer skewed to the left, one layer skewed to the right. Your final logits 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 logit distribution of the quantized model and the logit distribution of the original full precision model, and we showed that with this technique we get. If your probability distribution on the logits which 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 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. Philip [00:31:57]: I think it might be this, but reminds me a good bit about pruning where you can prune off certain layers. Philip [00:32:03]: But very interesting. Didn’t know this was a whole paper you guys put out. Ali [00:32:06]: It’s. Fun fact, it was originally 72 pages, this paper, and then we decided Philip [00:32:11]: Wow Ali [00:32:11]: We can’t tell. We couldn’t release it. So it’s now 45. Swyx [00:32:15]: Still 39 pages, so very substantive. We talked about evals and all these things and, like what’s possible in terms of speedup? Like it’s like probably like the number Inference Speedups and Benchmarking Swyx [00:32:25]: Thing that people do wanna care about, and it’s something that you wrote about in your post. Like official API is 70 tokens per second, and you push it up to 90. Is that like a normal thing? Philip [00:32:36]: 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 twentieth of 1% better,” that’s huge news because everything is so optimized. When we publish optimizations, it’s 20%, it’s 100% 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 something. Swyx [00:33:19]: Which by the way, 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 Ali [00:33:27]: And like 20%, tens of percent. Swyx [00:33:29]: That’s. Yes. Philip [00:33:29]: Yeah. Swyx [00:33:30]: And now it’ Philip [00:33:31]: Tiny fractions Swyx [00:33:32]: For those people interested, look up Andrew Lo’s paper. He had a really interesting illustration of quant, stat arb, distribution, narrowing down from like those kinds of 20% differences in the ‘70s, down to nothing today, which is very cool. Philip [00:33:48]: Exactly, and we’re at the beginning of the same type of thing. Now benchmarking is hard. I think anyone will tell you that, 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 stuff. But overall, when you start stacking these improvements, you’re looking at multiples. You can look at it. The most common form, of course, is TPS, tokens per second, which is bad naming by us in the industry, ‘cause there’s two tokens per second. There’s tokens per second, the throughput number, and the latency number. Ali [00:34:31]: TTMT, yeah. Philip [00:34:32]: Like total tokens per second out of the, out of the GPU as a 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. Philip [00:34:44]: Anyway, so you can imagine a standard API without many optimizations for a 1 trillion parameter model operating somewhere in the 30 to 50 tokens per second range for reasonable traffic profile. And we generally see the goal of, pushing to 10X that. But, not necessarily day zero, but by stacking enough optimizations, if you have, say like four optimizations, each of which doubles performance. Or sorry, three optimizations, each of which doubles performance, then you stack that up, that’s an 8X gain. That’s the order of magnitude that we’re working with in this space. We’re trying to make things substantially faster, not just go from like 70 to 90. Swyx [00:35:38]: Are you saying you’ve. You have done that? Philip [00:35:40]: So let’s say you have as a reasonable baseline, 30 or 40 tokens per second. You can achieve 10X that. So like on GLM-5.2, if you run it unquantized, perhaps on H100s even, and you’re just using an off-the-shelf inference engine with no particular optimizations, no speculator, nothing extra around like KV routing, no disaggregation, you’re, you’re probably, yeah, looking at that like 30 to 40. You think that’s like a reasonable baseline? Swyx [00:36:12]: Right. Right. Philip [00:36:12]: To get to something like 10X, there’s a lot of trade-offs that you’re making. If we’re running at more like a 300, 400 tokens per second range, you are using the best hardware possible. You have a optimized speculator. You have done all of your quantization work. You are Seeing a pretty high cache hit rate. You are running with a reasonably small batch size and a parallelism configuration that is tuned for latency versus throughput, but it is possible. So the spreads that you see if you, like, go on artificial analysis or you go on OpenRouter and you look at, the worst provider to the best provider, oftentimes can hit that range. 10X is of course very aggressive. It’s oftentimes maybe more of a four to six times improvement. But that’s the performance that makes us really excited, is when we can get these huge gains, not just go from 70 to 90 tokens. Stacking Optimizations: NVFP4, Speculation, and Disaggregation Ali [00:37:19]: It’s also, like, hardware dependent. Like, if Philip [00:37:20]: Yeah Ali [00:37:20]: If you have a thing where you’re serving it on just, like, a node of H100s and then you throw, like, you shard the model across, like, four nodes of B200s. Like, you can definitely increase the speed with just throwing more hardware at it. Like, normalizing for the same exact hardware and the same number of GPUs. Philip [00:37:35]: Yeah. Then you’re looking at, like, a two to 4X improvement Ali [00:37:38]: Right. Right Philip [00:37:38]: Depending on the inference optimizations. So yeah, it’s. Some of it’s, what’s the call, and some of it’s who’s the driver. Vibhu [00:37:46]: If you break down the two to 4X, say the example is run GLM-5.2 Ali [00:37:51]: Yeah Vibhu [00:37:51]: On B200s Ali [00:37:53]: Yeah Vibhu [00:37:53]: Single node, right? What’s, like, the cost trade-off for effort to get, like, the last bit of juice out versus what should people just think of, right? Ali [00:38:01]: Spectre quantization. Yeah. Vibhu [00:38:03]: Spectre quantization. Ali [00:38:04]: That’s, that’s, that’s like 95%. Like Vibhu [00:38:06]: And how far does that get you? And how easy is that for the average person to do? So say right I wanna throw the weights of GLM-5.2 on a node of B200s, how easy is it to find speculative decoder- decoder model or already quantized model? How much work goes into it? Philip [00:38:23]: If you’re doing it up front, it’s quite a lot of work. If you’re doing it today, there’s going to be people who have published things that you can just, you can just grab some NVFP4 weights. You can grab a speculator. Yeah, if we’re thinking about, like, what are the 2Xs we’re stacking, going from, BF16 to NVFP4 is, it’s not quite a 2X, right? It’s like. I think it’s about, like, 30 to 40%, from 16 to 8, and then another 30 to 40% multiplied from, 8 to 4. So that doesn’t quite get you a 2X, but, like, roughly a 2X. Speculator, roughly a 2X. Disagg on top of that if you’re able to get enough hardware and put enough traffic through it, another roughly a 2X. And then you add in some, double-digit percent increase from having just a better runtime with, the latest kernels and stuff behind it. And that’s how it stacks up. Ali [00:39:21]: Yeah Philip [00:39:21]: So building each of those, like, building the, quantized weights is, for someone who really knows what they’re doing, hours to days of work. Building the speculator, again, like, hours to days of work. And the, disagg setup, hours to days. Well okay, but like once you have Ali [00:39:39]: Once set up. Once set up. Yeah Philip [00:39:40]: Yeah, getting disagg working for the first time, I’m saying, of course, is very difficult. Philip [00:39:44]: The marginal implementation Ali [00:39:48]: Like, 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 spec dec that they’ve trained as well. You don’t need to train your own spec dec. You can just use that as well. Philip [00:40:09]: Yeah. Like, GLM-5.2 has its own MTP. Ali [00:40:13]: Right. Right. Vibhu [00:40:14]: What’s multi token prediction? Philip [00:40:15]: Yes. Ali [00:40:16]: I’m just Vibhu [00:40:16]: Can you explain that? Ali [00:40:16]: I’m just an expert. Ali [00:40:18]: I can do it for you in case I get it wrong? Vibhu [00:40:20]: No. Vibhu [00:40:21]: Yeah, you should correct if we’re wrong, but their multi-token prediction can be used for self-speculative decoding. Ali [00:40:27]: I’m not sure. I’m not gonna correct that. Vibhu [00:40:28]: Okay. I’m semi-confident in that Ali [00:40:30]: Okay. Yeah Vibhu [00:40:30]: But someone can check. But it’s useful to paint the story of, okay, not just the average person, but say a company wants to switch from serverless inference I wanna throw this up on. I wanna rent some GPUs, throw it up. These are the steps you take to do significantly faster than just put it behind vLLM. Ali [00:40:48]: Right. Vibhu [00:40:49]: I was waiting for a mention of Dynamo. Vibhu [00:40:51]: I feel like, that’s supposed to be the baseline that you measure against. Dynamo, KV Routing, and Disaggregation Toolkits Philip [00:40:55]: I would think of Dynamo as less of a box system and more of a toolkit for building with. So when we talk about doing aware routing, when we talk about doing KV offloading, when we talk about doing, PD disaggregation, Dynamo fundamentally is. By the way, Dynamo is an open source library from NVIDIA. Ali [00:41:17]: We’ve done a pod with Kyle Philip [00:41:18]: Okay Ali [00:41:19]: Kyle Cranin. Philip [00:41:19]: Cool. So then your listeners know then that it supports all the different inference frameworks. And it is multi hardware, which is interesting. Ali [00:41:28]: But it’s just a router, it’s not like an optimizer layer. Philip [00:41:30]: Yeah. All it does, like, what Dynamo is good at, it is a library for moving information around your cluster, around your hardware. So if you have, KV cache on one place and you need it to be somewhere else, Dynamo coordinates NIXL for you to move that around. Philip [00:41:49]: That doesn’t mean that, like, out of the box, you just say, “Pip install Dynamo,” and then you get, like, a massive performance speed up. It’s more of a developer toolkit. Ali [00:42:01]: Yeah. I would have said it would. It comes with a set of defaults that you can then swap out. Philip [00:42:06]: It does. If the industry at large, I think, was, like, rolling out all of these deployments, standard, then I think it would be, like, a credible baseline. But, we’ve got to, we’ve got to benchmark against, like, what we’re seeing in the wild. Speculative Decoding Methods: Medusa, EAGLE, n-Gram, and Spec-Spec Vibhu [00:42:23]: I did wanna talk a little bit more about PD disagg, because that is probably, like, number three after quantized and speculative decoding. In your book though, I was just gonna pull out the book. Philip [00:42:31]: Yeah. Vibhu [00:42:32]: Like section 522 on Medusa, 523 on EAGLE Philip [00:42:35]: Yeah Vibhu [00:42:36]: 524 on gram. Philip [00:42:37]: It’s 55, would be disaggregation Ali [00:42:42]: Yeah. Well, no, I just wanted to dwell a little bit Philip [00:42:44]: Yeah Ali [00:42:44]: The other. Like, so what do you choose to include? What do you choose to not to include? Because there was all these other techniques. Philip [00:42:51]: Yeah. Ali [00:42:51]: Are these still relevant? Because I think they came out, like, a year and a half ago maybe. Vibhu [00:42:55]: Medusa is quite old. Philip [00:42:56]: Yeah, Medusa’s old. Ali [00:42:58]: It was old. Vibhu [00:42:58]: But is it in the book as a good, here’s Philip [00:43:01]: Baseline Vibhu [00:43:01]: Baseline vanilla understand it? Philip [00:43:02]: Like you should know this. Vibhu [00:43:03]: Like I read the paper, I’m like, “ it makes so much sense.” Philip [00:43:05]: Yeah. Philip [00:43:05]: So with the book, I had a couple goals. One was to give people just a working vocabulary for the space as a whole, and the other was to give them some intuition about how each of these techniques works. As I mentioned in my AI Engineer talk, which is the first public addendum to this, the speculation space has moved much faster than everything else. So yeah, even at the time that I wrote the book Medusa, I very much included as a way for people to understand how the space evolved rather than what the most modern technique is. And now of course, there’s DFlash, dSpark. There’s, there’s newer techniques even than EAGLE, although EAGLE is still very commonly used. Ali [00:43:51]: SpecSpecta. Philip [00:43:52]: Yes. Speculative decoding. Vibhu [00:43:54]: What can Ali [00:43:56]: Oh, it’s a paper by Tri Dao and it’s like, it’s doing speculative decoding Vibhu [00:44:00]: Huh Ali [00:44:01]: For the speculative decoder. Philip [00:44:02]: Oh, in spec- oh my God. Ali [00:44:02]: It’s literally just an another. It’s like, yeah, that’s the most simple way to explain it, and it seems like he got trivial speed ups there. But it seems that the complexity with training, it’s almost like in our mind at least, it’s almost as complex as training GANs. Like it’s like a very delicate balance and oftentimes you, it’s just but yeah, it’s literally speculative decoding on speculative decoding. Vibhu [00:44:21]: Speculative. Ali [00:44:22]: Yeah. We saw this paper. Vibhu [00:44:24]: It’s interesting, right? Ali [00:44:24]: Yeah. Vibhu [00:44:24]: I wouldn’t even expect it to be very particular to train, I would Ali [00:44:29]: Right. Vibhu [00:44:29]: The naive part of me is like, okay, train speculative decoder. Ali [00:44:32]: But like, and it makes sense, like the whole idea of speculative decoding is you. It’s like, it’s like almost like the iPhone auto predict version but for a normal model, right? Like you’re just, you’re just, generating three tokens and you’re like, okay, I’ll do prefill on them. And so you save those three turns for your original model. Now your speculative decoder is doing three turns of auto regression, so why not just have an even smaller model? Ali [00:44:53]: The other question there is what are the size of speculators? So say for Philip [00:44:58]: Right. It’s like a billion parameters. Ali [00:45:01]: Like for MiniMax, it’s. Yeah. It’s like one layer. It’s like one 60th of the original model usually. Philip [00:45:06]: Yeah. I think we should do a paper when we get back to the office. Philip [00:45:10]: Speculative Ali [00:45:11]: Speculative Philip [00:45:11]: Decoding. Ali [00:45:13]: No, it’s, it does seem like how, when do you stop? But then it also seems like if you’re able to train spec-spec decode for instance, right? Like if you’re able to have a small model that is accurately predicts what the intermediate speculator is gonna predict, that is able to predict what the original target model’s gonna predict, then why not just use that smallest model directly, right? Vibhu [00:45:34]: Yeah. This is Ali [00:45:35]: Like it seems like Vibhu [00:45:35]: Adjacent to the routing problem. Ali [00:45:36]: Right. Vibhu [00:45:36]: Yeah. Ali [00:45:36]: Right. Philip [00:45:37]: The thing with speculators is one of the practical constraints on using them is that you do have to run a small model on the same hardware that you’re running the big model on. There is a orchestration and resource competition problem inherent in that, and that is one of the constraints on speculation in general, is that draft tokens cost resources to create and cost software complexity to manage. And so if you have like infinitely recursive speculators, you add in quite a bit of that complexity on the actual implementation within the inference engine as well, not just in the training process. Vibhu [00:46:17]: I was gonna say, I would wonder if you could do similar, like distillation and pruning of, it’s the same thing, it’s just a model. Can we not just distill a lot of the weights, quantize the speculator, out of my domain? The question that also comes up is, this is all for big server workloads, right? How much of this applies to, say I have this MacBook, I wanna run Gemma really efficiently. Similar problems, not the same? Local AI vs. Data Center Inference Philip [00:46:45]: Pretty different. I talked to Selo, about this on his podcast a couple weeks ago. The difference between inference engineering for the data center and for production workloads versus inference engineering for local AI, is that we start with fundamentally like different constraints and different goals. With local AI, it’s how do I fit this model onto my hardware and then make it less dumb? And with data center influence, it’s how do I load this model and then make it less slow? And we care about less dumb, and they care about less slow. But the local AI inference engineering ecosystem, I think has a lot for us to learn from in the data center space. They are experts in various forms of quantization, including dynamic quantization that we just don’t touch, in the pruning, in the distillation, in the, layer removal. There’ Ali [00:47:42]: Layer removal matters less. Philip [00:47:43]: Yeah. There’ Ali [00:47:44]: No one loves pruning really. Philip [00:47:45]: Yeah. Well, but the, but they do Vibhu [00:47:46]: Which is surprising, right? But that’s, that’s a whole different thing Philip [00:47:48]: Just to fit something on the laptop. Ali [00:47:50]: Right. Philip [00:47:50]: So yeah, it’s a, it’s an interesting, it’s an interesting space. Not necessarily that like their techniques make sense for us to do in the data center, because we have different resources and different goals, but more that the process as well as the openness of that field is something to, admire. Ali [00:48:12]: Yeah. Like to your point, like, certain optimizations that would. Like for instance, Turbo Quantum Sharper, like it made such huge hype on that and we did like a whole deep dive on Twitter and like said, what is it? How does it work? Why is it good or not? And it took off and it was implemented on local devices because your memory bandwidth is so slow on like a MacBook, for instance. But try putting the same thing on like an NVIDIA GPU on a B200 Turbo quant would not be. Like, it would not be used. Like, NVIDIA - Like, NVIDIA made it clear that this is not a good optimization, and we’ve seen it firsthand where the overhead of doing dequantization, quantization of, in the kernel itself with turbo quant kernel, each end is much slower than the time that you save from doing the bandwidth. ‘Cause on the B200s, you have like 3.5 terabytes per second. You don’t need decrease the storage that much. You don’t need to do, FP4 KV cache. You don’t need to use a requant. There’s, there’s, there’s better optimizations to be made. But on Edge devices, it’s extremely important, it’s extremely useful. So, seems to be, like, different optimizations there, but then they’re all uniquely combined with like all you wanna quantize the model, you wanna do speculative decoding, like certain common prefixes with both Philip [00:49:18]: Principles. Ali [00:49:19]: Yeah, exactly. Exactly. Exactly. Philip [00:49:20]: They also do a lot of work on, model parallelism, especially over, heterogeneous topology, where you have, some sparks and they are wired together with, Ethernet, DGX sparks. Ali [00:49:35]: Yeah, this is the Exo Labs guys. Philip [00:49:36]: Yeah. You have, a number of, Mac Minis stacked up. Philip [00:49:41]: There’s, the inter. They. One thing that I think we both have to deal with, although they have to deal with a lot more is the interconnect between machines. Which is why, like, one thing that we do a lot is work with tensor parallelism. Philip [00:49:56]: And that’s where, you are using all of the, all eight GPUs, and sharding the model across it. Tensor parallelism is not a good fit for local AI because it assumes a very high bandwidth interconnects like NVLink. Was, they might be forced to do something like pipeline parallelism, which we’re never gonna do unless we’re doing some kind Ali [00:50:16]: Yeah. For image Philip [00:50:17]: Multi-node inference. Ali [00:50:18]: But since you mentioned it, I wasn’t sure if we were gonna cover it, but let’s briefly explain tensor parallelism and expert parallelism, since you have very nice images. Tensor, Expert, and Pipeline Parallelism Philip [00:50:25]: You wanna pull the book? Ali [00:50:26]: Yeah. Philip [00:50:26]: Yeah. Let’s, let’s get Ali [00:50:27]: So I just wanna show a few images. Philip [00:50:29]: Yeah. Shout out to Luke from Baseten’s design team for making these beautiful images. Oh, that’s a, that’s. Before we get into this, just one other difference is 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 Ali [00:50:51]: Yes. I was gonna Philip [00:50:52]: Inference in the data center Ali [00:50:52]: I was gonna bring that in the diffusion conversation. Philip [00:50:54]: Yeah. Philip [00:50:55]: Yeah. We, I, when we go through like a MoE model, and we host it, for an API, we assume that all parameters are gonna be active because Ali [00:51:06]: You’re batching Philip [00:51:06]: Throughout your batch Ali [00:51:07]: Yeah Philip [00:51:07]: You’re gonna, you’re gonna hit everything. Cool. So broadly, tensor parallelism you can do with any model. Expert parallelism, you can only do with MoE models. Effectively all models today are MoE models, that are, Ali [00:51:21]: Sort Philip [00:51:22]: At least all models large enough that you would care to parallelize them across multiple GPUs. So that’s, that nuance is less important now. 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 replicate the router, which the router is very small, across each of the GPUs. And then by moving 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, GPU connection is not as important ‘cause there’s not as much communication. Tensor parallelism requires that you are able to do this like all gather, all reduce. So you shard the model across the GPUs entirely. And then for each step, you’re combining the results of each of the GPUs, which is why the interconnect matters a lot, and it is generally. Of course, this is a, this is a very high-level generalization. There’s a lot of places where this is not correct. But generally, TP is helpful for latency, and in many cases, you will use some combination of these two parallelisms, across the model rather than just, like, picking one or the other. Do you wanna add some color there? Ali [00:52:50]: Like, yeah, usually, like in a model, it’s not. They’re not mutually exclusive. You do tensor parallelism and you’ll do expert parallelism. Pipeline parallelism less solely, it seems to me like we never use pipeline parallelism. Philip [00:52:58]: Yeah. The only reason you would have to do pipeline parallelism, which is where you separate like different layers and you put like half the layers on one hardware and half on another, is if you are forced to do multi-node inference, because a model is bigger than you have the. Like let’s say, let’s say you’re doing a deployment on H100s for whatever reason, and you’re putting a trillion-parameter model on there. You have to use multiple nodes of H100, and so you. - Because the interconnect is so slow between the nodes, the only viable way to parallelize there is pipeline, but then you would do expert and tensor within each node. Ali [00:53:36]: And the limiting factor for H100s is HBM? Philip [00:53:39]: Yeah. They just don’t have enough Ali [00:53:40]: How much? What’s the magic numbers that we need Philip [00:53:43]: Like on a B200 is 180 gigabytes per GPU, and then a node of eight, so you’re talking like 180 times eight. And the FP4, so each parameter takes half a byte, so that’s 800 gigabytes. On a H100, it’s like 140? Ali [00:53:56]: It’s 80. Philip [00:53:57]: It’s 80? Ali [00:53:57]: Yeah. Philip [00:53:57]: Oof. Ali [00:53:58]: Yeah. Philip [00:53:58]: I’m old. I’ve been doing this a long time. I remember H100 specs. Ali [00:54:04]: Yeah. Philip [00:54:04]: No, so one thing Ali [00:54:06]: You wanna tell me about the T4s? Philip [00:54:07]: The T4s. Oh my God. Ali [00:54:08]: Let me tell you what it was like to run a model on a T4 back in the day. Ali [00:54:12]: One thing I was surprised to see that more people didn’t do, Jamba. I don’t know if you guys remember Jamba from AI ‘21. They would specifically pick a hardware, and then they designed the arc dimensions for the hardware, and then it would saturate the hardware. Like, it makes sense. And like, somehow all these models don’t do that. Hardware-Aware Inference and Auto-Tuning Philip [00:54:32]: Don’t they do this for the training side, though? Ali [00:54:35]: I don’t know. Ali [00:54:36]: Sorry, Philip [00:54:36]: Training. For training the model. Ali [00:54:37]: Like deciding which GPU, which Philip [00:54:39]: Yeah. Well, how Ali [00:54:40]: Yeah, they do And with training, it’s more of like a math. Like you can run the math- Yeah and see the flops and maximize it. With inference, it’s more of like an auto-tuning, like if you like GPU kernel auto-tuning. But like it’s like you define that, “Oh, I have two GPUs. I can do TP1, TP2, EP1, EP2,” for instance, right? And you. So that gives you like total of like two squared combinations, and then you just like you shadow the same traffic, like real prod traffic, and you just see which configuration gives you the best TPM and TPS, and then just use that. I don’t like the fact that it’s, you cannot reason about which one’s gonna give you the best performance or that there isn’t one specific configuration that’s always best. But it seems like auto-tuning is just the way that you find the best one. And with kernels and GPU kernels, it’s much of the same. After you design your kernel and you design your configuration, how many threads do you launch? How many, how much shared memory do you use? You just auto-tune. You just sweep the parameter space on the side, and this is the best one empirically. But yeah, but they are combined. They’re not just entirely- Yeah like separation. There’s a few bits of training that are like hardware targeted. If you look at, for example, NVIDIA Nemotron models, they run very well on Blackwell. That’s, that’s unsurprising. So there’s some degree of that, but I think that most open labs are trying to make models that can be run on as wide of hardware as possible rather than targeting just like a single chip. I see. For usefulness. Yeah. Okay, one more thing while this chart is still up. All gather, all reduce is expensive. One of the things that is a movement in Silicon Valley is mega kernels, just keep fusing kernels. I don’t know. Is it that simple? Well, I, like a fused kernel can’t save you. Like here with tensor parallelism, you’re. The half the matrix is on one GPU and the other half is on another, and if I need the entire matrix in order to do like a nonlinear operation in the next step, which is, for instance, like if I’m doing attention, I need the softmax, or I need to do like exponentiation, I need to have the entire row. So I need to know what the partial result was from GPU 2 and what the partial result was from GPU 1 in order to be able to do the softmax in the next stage. So I, like I have to make them communicate with each other, even if I had a fused kernel, because of the nonlinearities within each one. Also with like mega kernels, like honestly, I’m, I’m, I’m very bearish Ooh on, I’ll be honest. Like- Please. No, it’s just like mega kernels, it was a good research direction, and it seems like a very. Like intuitively, theoretically, it’s nice. Like, oh, like you have a lot of launch overhead from launching- Just- one kernel- Yeah, just keep fusing it moving the data. Just fuse everything together. But yeah, but like the kernel complexity itself is very difficult to write a very optimized mega kernel. It’s, it’s very difficult to do so. And even the, like not to name any companies, but like even the companies that have worked or people that I’ve spoken to who work at companies that do fused mega kernels, they very often don’t end up running those in production because the TensorRT-LLM and modular kernels that launch are faster because you can optimize each individual component, and you can just have them parallelize with each other. With the Rubins, I don’t know if you guys saw the Rubins Twitter post yesterday, but they’re also, Rubins? Like- No, like Rubin, like the GPU. NVIDIA GPU the, yeah, GPU. Yeah. They have a Twitter account for Rubins only? No. Okay. I was like, “What are you talking about?” Yeah. Sorry. One of the tech leads at NVIDIA is like launched a Twitter post said like, “We’re pulling the curtain on Rubin, and here’s the, here’s the specs.” And the third tweet showed, like not to get too technical into it, I and I need to read it much more, but the GPU is designed in such a way that it kills mega kernels. You don’t need to use mega kernels that much anymore. So it seems like that entire research field goes into like, won’t be continued, but yeah. Can I speculate about Rubin for a minute, please? Go. I’ve been through now, we And by the way, they are covered in the book. Yeah. But yeah, they- Well, they’re covered in the book in the sense that like I am aware- The Wikipedia entry from the blog post- Yeah that Rubin is going to happen in the future. And you even had the name of the one, Feynman. Yeah, it’s like, “Hey, this is gonna “ I was like, “This is very up to date.” Like I’m trying to future-proof this thing, okay? I don’t wanna publish a new one until like next year or something. Anyway, so we were discussing the degree to which I am old. And I’ve now been through three hardware launch cycles. I’ve been through the Ampere launch cycle, the Hopper launch cycle, and the, Blackwell launch cycle. Now, when I say launch cycle, I don’t necessarily mean like the actual shipping of the hardware. Like Ampere’s were racked up well before I got in this industry. But there is a lot of time between hardware being racked up and hardware being feasible for inference. So if you look at like the original vLLM and SGLang, vLLM especially, like that was written targeting Ampere and then had to be updated for Hopper, updated for Blackwell. With each of these cycles, it becomes faster and more urgent, but also substantially more complicated. When I look ahead to, what’s going to be new 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. We’re continuing some trends from Blackwell, right? NVFP4 is big. The amount of compute that they have behind NVFP4 tensor cores is massive. We’ll, we’re gonna talk about video, I think, at some point, and that’s the big barrier there. You’ve got, much faster memory bandwidth, but which was the same thing that made Blackwell so good. But 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? So I think that themes around like KV cache offloading, KV-aware routing, 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, we’ve been building toward for a long time, and something that’s like very exciting to me because we’re gonna see Mega Kernels, Rubin, and the Future of GPU Systems Philip [01:00:55]: Multiple domains colliding and the ability to reason from the kernel level, like up to the hardware level and back down is going to be very valuable. Ali [01:01:05]: I will take what Phil said one step further, into that. It’s, I think, trending towards becoming exclusively an infrastructure problem, where like problems of PD disagg, Training, spec dec. But troiting kernels is not going to be much of a problem because the GPU is moving more towards being an ASIC, where it’- you’re just, you’re just trying to orchestrate what happens on the GPU, but you’re not 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. So 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? GPUs, ASICs, and Specialized Hardware Swyx [01:01:50]: Oh, yeah, no. That is a section of the market. Ali [01:01:55]: Right. Swyx [01:01:55]: And ASICs can do, a lot more performance for only their workload. Ali [01:02:01]: Right. Swyx [01:02:01]: And the G in GPU makes them continue to be very general. Philip [01:02:05]: Yeah. The, - I think that there’s like a spectrum Swyx [01:02:08]: It’s graphics, Philip [01:02:09]: Yeah. Swyx [01:02:09]: I keep saying this, I have to correct myself in case people come at me for getting the G wrong. Philip [01:02:14]: Yeah. It’s like, it’s like a spectrum, right? Of a very general purpose compute to something like a Taalas, where you’ve got the hardware built for a specific set of model weights. Ali [01:02:26]: The weights burned Swyx [01:02:27]: The weights Ali [01:02:27]: Into the chip. Swyx [01:02:28]: Yeah. Ali [01:02:28]: No loading. Philip [01:02:29]: I don’- I wouldn’t say that like, that we’re, we’re, we’re going all the way there. It’s more like along the spectrum, it’s a step in the direction of more specialization within the hardware. Swyx [01:02:40]: Yeah. I’m curious, I feel like he was driving towards something. Ali [01:02:43]: My point is being bearish on. Like, 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 quantize, you wanna release new checkpoints of the model. If it’s burned into the chip’s useless in like a month or two, right? My point is: How can you - like seeing NVIDIA more and more specialized, 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, MMA instructions, things that will allow you to just control it almost as an ASIC, almost as a collection of ASICs. Ali [01:03:22]: How can you look at this trend and then still be bullish on companies that are coming up with ASICs for AI? Ali [01:03:30]: In the sense that, in the sense Swyx [01:03:31]: Yeah, because they’re, they’re Ali [01:03:33]: Right. Swyx [01:03:33]: They’re, they’re evolving towards that direction. Ali [01:03:34]: They’re almost evolving towards - Like as an Rubin, comp- Like compared to Ampere or, a T4, Rubin is an ASIC. It is, it’s just a thing that is used Swyx [01:03:47]: Programmable ASIC? Ali [01:03:48]: Yeah. It’s like - Yeah, like you can program, like I, like. It’s very controversial to call it an ASIC. It is a GPU. It is - It is general. It does have threads. I can write CUDA to control it and change its operations. But it has the systolic arrays and tensor cores and TMAs and tensor memory, and it has these things that are almost exclusively useful for loading model weights. It has, tensor core instructions that are almost exclusively shaped around the head dimensions of models that exist in the market today. To say that you’re gonna come up with an ASIC and you’re gonna etch something into it, well, but the next architecture is gonna be useless. Philip [01:04:19]: Yeah, I don’t know. I don’t know. I think that the thing to remember is just how long these hardware cycles are. Ali [01:04:25]: Yeah. Philip [01:04:25]: So if a chip is coming out today, that means the design process for it was kicked off years ago. And they’- at NVIDIA, they’ve done a very good job of predicting where the market is going to go and, Swyx [01:04:38]: They have the most information Ali [01:04:40]: For sure. Philip [01:04:41]: Of course. But if you look at, there being public open source model architectures that look more or less like early versions of the one today, Rubin’s honestly the first chip that was fully built in that world. And so you can see a lot of the understanding of the shape of the workload that this chip’s going to be asked to do in the way it’s designed. Swyx [01:05:04]: Yeah. Okay. So I’m not gonna be the best person to directly answer those questions. I think these are very fair questions that - the first one that’s based on Rubin that like I’ve, heard artic-articulated so well. I do think that, I will make a case for a vertically integrated model lab ASICs. Swyx [01:05:24]: So like the OpenAI, Broadcom, what-whatever, Jalapeño Philip [01:05:27]: Sure. Yeah Swyx [01:05:28]: Chip, which like totally makes sense. Like, so - we first had this on the pod with, Martin Casado, where he was like, “Look, if you have a trillion-dollar or five hundred billion dollar training then take fifty billion of that and make a ASIC. Like it’s fine. Like you will get more than ten percent efficiency from the ASIC.” And like that makes sense. Philip [01:05:46]: Right. Swyx [01:05:46]: Right? So like a model-specific chip, yes. But ASIC companies, the interesting thing is I feel like you are focus-- you’re hyper-focusing on like you say, like the Taalas stuff. Philip [01:05:58]: Right. Swyx [01:05:58]: They are doing a lot more like, surface area engineering or like the actual allocations of memory and hardware and like the communication between chips that, probably still won’t be touched by Rubin, but I don’t know the details. Philip [01:06:14]: I see. I see. Swyx [01:06:15]: They-- Typically, they often talk about things that I would expect to have bigger orders of magnitude than would be programmably accomplished by whatever Rubin does. But who know-- who knows? Ali [01:06:26]: No, I see. Ali [01:06:28]: Yeah. It seems, Swyx [01:06:29]: Yeah, like think about what - what are the real blockers to ten x to one thousand x faster inference. It is not the stuff that can be rearranged, just within the existing GPU design. Ali [01:06:41]: Inter communication. Swyx [01:06:42]: Yeah. Ali [01:06:43]: Okay. Swyx [01:06:43]: Like these guys are aiming for three hundred thousand tokens per second. They’re not fucking around. Like, Ali [01:06:49]: Might have to put on some X6. Philip [01:06:50]: Maybe. I think, it is interesting to me that you’re so bearish on so much of this kernel engineering work, given how much of it you’ve been doing recently. Ali [01:06:59]: Right. Right. But like the more I do it, the more it just seems to me that Swyx [01:07:01]: It’s not mega Philip [01:07:02]: I would also add like Vibhu [01:07:04]: There’s generations of models being out, right? I think on your guys’ end, you see a lot of, okay, one day it’s GLM, Kimi, DeepSeek, MiniMax, throw in the others. Some are doing completely different stuff, right? Gemma, no encoder. The latest thinking machines is all from scratch. But when you look at the other side, like how long have we been on the GPT-5 generation, right? Philip [01:07:26]: Right. Vibhu [01:07:26]: They’ve been serving that thing for quite a while. Sure, there’s maybe more training. There’s, there’s different checkpoints, but like you can squeeze quite a bit out and you do a multi-billion dollar train run. If you can make it X percent more efficient, they serve it for a while. Same with, say, the Claude 5 set, family, right? Philip [01:07:44]: Like if they release a new model, like if they release GPT-6 now or whatever Model Longevity, Open Source, and Enterprise Reliability Vibhu [01:07:47]: Yeah Philip [01:07:47]: And they release a new model every year, and - well, we don’t know, but if we assume that they’re changing some bits of the architecture and not just doing like post-training, like you’re gonna be spending fifty billion dollars a year every single year coming out with new ASICs for the model and throwing out the ASICs of the previous year away. Vibhu [01:08:03]: Yeah. Yeah. Easy. Swyx [01:08:05]: So I think, okay, I would slightly disagree based on my again, Philip [01:08:09]: Yeah Swyx [01:08:09]: It’s all secondhand, on the longevity of a model. Philip [01:08:12]: Right. Swyx [01:08:12]: There’s still people out there using 4o. Vibhu [01:08:14]: Yeah. Swyx [01:08:14]: Yeah, Llama. Not Llama 2, but Llama 3. I still see Llama 3 workloads. Vibhu [01:08:18]: Yeah. Swyx [01:08:18]: Because if it’s done, if it’s trusted, don’t change it. Vibhu [01:08:22]: If it works. Philip [01:08:24]: Which is one of the promises of open source, right? Like the whole 4o, save 4o movement. Like you don’t gotta have a save Llama 3 movement. You just gotta have an eight one hundred somewhere. Vibhu [01:08:34]: I think at some point there’s also the question of, okay, if a model can do enough and use enough tool calls and be agentic enough, can it just web search, tool search 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 GLM-5.2 today or say whatever 120 B model, I can run with it for quite a while, right? Philip [01:08:59]: This is assuming like you don’t need intelligence. Vibhu [01:09:02]: I think there’s a lot of intelligence where we Swyx [01:09:03]: You need reliability and predictability. Like I’m in enterprise like like this is tried and tested. It is signed off by like my five thousand stakeholders. Philip [01:09:11]: Right. Swyx [01:09:11]: Like I’m not touching it. Philip [01:09:12]: It runs a batch job every and I like the results. Swyx [01:09:16]: Yeah. Philip [01:09:16]: The results are predictable. Yeah. Vibhu [01:09:18]: Yeah. It doesn’t make sense to keep using them. Like stuff gets sparser, cheaper, better. Philip [01:09:23]: Right. Vibhu [01:09:23]: But that doesn’t mean that old models, GLM 50 isn’t usable, right? Vibhu [01:09:28]: If we hit a stall, say, for whatever reason, there’s still a lot that can be squeezed out. Swyx [01:09:34]: We’re gonna run out of time. I did wanna also make sure. Yeah. Yes, we happen to have this diagram. Pull. Compare this versus any Cerebras diagram, right? I don’t think Edge10, medics have put out public, charts yet. But the complete the real estate is very different. The size is very different, right? This is not wafer scale, right? This there’s probably like, I don’t know, a few hundred of these on a wafer. I don’t, I don’t know how big Philip [01:09:55]: Right. Swyx [01:09:55]: The comparison is. But like, it is a, it is a very like real estate allocation Vibhu [01:10:00]: Yeah Swyx [01:10:00]: Difference. Philip [01:10:01]: Few dozen, I would say. Swyx [01:10:03]: Few dozen. Yeah. Vibhu [01:10:03]: Before we move from hardware, I have two quick questions. One, the latest Kimi, which is really big, three trillion Kimi Scale, GB300, and KV Cache Limits Philip [01:10:09]: Yeah Vibhu [01:10:09]: Doesn’t fit on most hardware on single node. Philip [01:10:12]: Yes. Swyx [01:10:12]: You need GB300 to fit it on a single node. Vibhu [01:10:14]: You need GB300 or AMD. Philip [01:10:20]: It’s simple math. NVFP4, two point eight trillion parameters, one point four terabytes. The GB300s have, two hundred and eighty-eight gigabytes each. So across eight of those, you have enough room for the model, and honestly like. So the other thing with GPU VRAM math is you have to leave space for the KV cache, and that’s going to depend on, to some degree, on the context length. So when a model is both has a very large number of parameters and a very long context length, you’re like fighting over space. Which is why, the KV cache offloading, would become like a more salient topic, I think, with these huge models. ‘cause you just, you’re very crunched for space. Vibhu [01:11:10]: With the Rubin, you now have what? NVL 72 rack Philip [01:11:15]: What? Vibhu [01:11:15]: 20 terabytes of your Philip [01:11:16]: Yeah. Now you still have NVL 72 on, Blackwell as well, but, you can’t necessarily assume you’re gonna do inference on that. Philip [01:11:24]: There’s a whole lot more 8X racks in the world than there are NVL 72s. Vibhu [01:11:30]: Yeah. My last quick question on hardware was, do you notice anything with hardware generations for new trained base models? So one of the things you said for efficiency is you can swap hardware. That’s one of the 2X gains. When we see new stuff coming out training-wise on Rubin, any changes on logs? Does this affect what type of models we will be seeing when these are more available? And can Philip [01:11:56]: They get bigger. Like people understand the ceiling that you have in terms of how many parameters of a model you can run, given the latest inference hardware, and that forms a ceiling. And so, for example, when DeepSeek R1 came out, it was six hundred and seventy-one billion parameters, which at the time was really huge and I think did a lot to push us to really quickly adopt Blackwell and get good at serving on Blackwell. So yeah, it’s, it’s mostly in my mind about, model size and then about matching the architecture and the native quantization to the target hardware, like we talked about with like, all Nemotron models or NVFP4, for example. Vibhu [01:12:42]: So we talked a lot about LLMs. Video Diffusion, Attention, and Autoregressive Video Vibhu [01:12:46]: 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. Philip [01:12:53]: 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 not the case. For instance, you don’t Ali [01:13:04]: You don’t do batching. - 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 Wan 2.2, for instance, is a twenty billion parameter model. You don’t need to worry about. So it’s like orders of magnitude smaller than the best LLMs. And it’s one of those spaces where the open source models are. Like with LLMs, we see Kimica 3 is almost comparable to, Mythos or like GPT 5.5. The difference between the best open source LLM and best open 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 almost on parity. 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 Wan 2.2 versus something like with Kling or Veo, difference is night and day. So it creates this disparity where media companies will choose to go most of the time to closed source models. Ali [01:13:58]: For instance if 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 ten dollars.” But if they were to do it on a closed source, they’d have to pay a thousand dollars, which is a hundred x. Like I’m a hundred x cheaper, but it’s still a thousand dollars. 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, 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, lik [truncated: source item exceeded 100000 bytes]