Vertical Mobility: Inference from MVP to Trillion-Parameter Workloads — Sitanshu Gupta, CoreWeave

AI Engineer · 15 min · 112 sentences · from YouTube's caption track

Each timecode opens YouTube at the start of that sentence. Line anchors (#s42) are the cue ids in the WebVTT, and every line carries its start and end seconds. All transcripts has every talk, and the whole corpus as one file.

00:13Good afternoon everybody.
00:14Um I'm Satan Shu from Kov going to be talking about vertical uh mobility.
00:20It's a quite a fancy topic uh the title that we came up with but basically going to be talking about the inference platform that we have at Corv that we are building to serve
00:31small to big models and various different types of workloads.
00:34Uh a quick intro about me.
00:36Um I joined core just about four months back.
00:40Uh leading all of inference over there and um before this I was managing everything at AWS Anapuna labs for uh training and before that inference and training at SANOVA.
00:51So quite a bit of experience in uh in this particular space.
00:55Um what I will the way I'll be taking you through is explaining to you the consumption models that we have and from that how we have derived what the platform should look like so that we do not need to keep changing the platform and we keep making enhancements in the platform that we have for serving inference
01:11and how and why the why performance plays such an important role over there.
01:15Uh I think a little bit of this might be common with the previous topic that was discussed over here.
01:21[snorts]
01:21Um consumption models.
01:24So we have uh at large two biggest consumption models.
01:28One is a serverless which is where the customers can come in, consumers can come in uh do not need to worry about managing the hardware themselves.
01:36Do not need to worry about managing the clusters orchestration anything at all.
01:40There's API, there's UI, you come in, you pay per token uh and you get your model served.
01:46Um biggest thing over here is that uh the type of models uh that we serve in the catalog that is the breadth of models that the customer will be able to go through.
01:57Uh I'll talk about dedicated and then I'll come back to serverless because there is one thing unique on the serverless side.
02:04Dedicated inference service that we provide is more for customers who want to know exactly what hardware they are going to be using and running on.
02:12Uh but the model deployment also depends on them.
02:15So they use our service, they use our orchestration layers.
02:19Uh but the model deployment depends on them.
02:22Model performance also depends on them as long as we provide in the platform the capability and the knobs to serve those features.
02:29Coming back to serverless, uh one of the interesting pieces over here is um typically serverless models are very are noisy neighbor problems where uh if let's say everyone is banging on the exact same model
02:42then you might be timing out quite a bit depending on how much capacity I have behind it.
02:46So another feature that we have on the serverless side is what we calling provisioned throughput.
02:51So as a customer, if you know your traffic profile and if you can let us know about that, we can carve it out specifically for you behind the scenes.
03:01You still do not need to worry about what hardware it is exactly running on as long as your throughput, your SLAs's are maintained.
03:08So that is another one on the serverless side and that is still charged by by the token but you know that you're not running into the noise enabled problem over there.
03:20Um let me take a quick stab at few different types of workloads workload shapes that uh we have um that we are seeing and the ratio between these is like continuously changing though agentic is like really high up there.
03:34Uh, agentic and chat kind of very similar.
03:37Super high on the input sequence lengths, very low on the output sequence lengths typically.
03:42But the biggest difference between agentic and chat being the fact that the multi-turns in agentic are super low latency versus in chats because when you get the response as a user,
03:52you have to read the answer and then you respond to it.
03:55So there are there are differences over there and that big difference ultimately converts into something uh related to the KV cache management uh but these are these two are both real time and another real-time workload is your voice and videos
04:11uh which are study streaming and super latency sensitive on the agent agent and chat side um largely the requirements are from throughput point of view not so much from latency
04:22but real-time voice and videos are absolutely totally latency sensitive.
04:26Coming to batch, batch is where the SLAs's are like super loose.
04:32They run into like way like seconds and minutes.
04:35Sometimes for some customers actually even in hours.
04:38They're like I'll just throw give me 10 to 12 hours of workload capability and uh I'll throw whatever I can process it whenever you can.
04:47uh these batch workloads um the way they come into the picture over here in um deciding uh sorry being the requirement for some of the design choices that we make in the stack.
04:59Imagine these uh four different types of workload shapes um in the time dimension you have to play the game of tetris on how you can fit it in to utilize the underlying infrastructure
05:08the most.
05:12I'll give a high level on how our stack is shaped right now.
05:17Um, and I'll walk you through a bit of a request flow over here.
05:21So for both serverless and dedicated, if you look at the right hand side of the screen, you'll see that on the platform side we you'll go to the control plane to uh to have your uh authorizations,
05:32your rate limitings and your usage being tracked etc. so that we can be built accordingly and uh observability so that we can make sure that we are not violating the SLAs's that have been signed
05:46right uh underlying on the platform I've shown at a super high level that we have these different um inference engines VLMs SG langs and tensorl but there are quite there's quite a few quite a bit of detail over here
05:59that I'll touch upon uh and underlying that what I'm trying to show over here in green is um various different pieces of hardware.
06:09So it's not that um so the platform needs to be capable enough of share of having the workload getting distributed across various different generations of these GPUs
06:20[snorts]
06:20uh specifically Nvidia GPUs that we use right so let's take up a let's take a few examples uh over here um let's say the request originates from the client side through apps or notebooks any of those or through the agents right it hits the gateway
06:36once it hits the gateway then uh like I mentioned on the control plane goes through authentication etc etc etc but then um comes either the serverless or dedicated so in the case of serverless
06:48it'll be paper token so that the token usage would be monitored over here not the exact tokens but just the token usage because we maintain ZDR zero data retention policies
06:58uh it is multi depending on the multi-tenency or the provisioned uh if it is provisioned then we know underlying for the router it needs to go in and target the
07:10uh the explicit deployments for the provision throughput uh customers.
07:14For the multi-end customers, there are separate deployments.
07:17Router over here specifically uh the the router is very important since um the router is responsible for making KV cache aware routing choices.
07:28Why is it important?
07:30Because like I mentioned when we were discussing the workload uh profiles uh the agentic use cases are typically super heavy on the input sequence lengths and bulk of the input sequence length about 80 to 90% depending on which company it is depending on the customers
07:4680 to 90% of it is the same for various different requests.
07:51So there is no point in going in and recomputing the prefill or redoing the prefill for that prefill is supercomputebound very expensive that's why as much as you can hit the cache
08:04more you can save which is why if you look at the token pricing anywhere uh there's a specific price for input tokens and there's a way cheaper price for the cash input tokens so
08:16caching becomes like really important over here underlying uh The underlying how you want to split the hardware is totally dependent on the choice in the platform and we provide the capability to do either either do a pre-filled decode disagregation
08:31if the use case desires it or do not do it because prefilled decode disagregation is not uh cheap for every type of use case.
08:41Uh let's take another request flow over here.
08:44Let's see if uh when it was a dedicated customer then what will happen?
08:49uh dedicated customer again will go through the gateways that have been set up for them with proper isolations.
08:55Um billing is not based on tokens.
08:58Billing is based on usage of per GPU per hour.
09:02Uh it's a private gateway so that uh there is noisy enable problem.
09:06No one else can get in.
09:08uh same router logic over here so that if there are uh cache heavy if there are requests which are very similar then it's it hits the cache most and depending on the deployment that the customer makes in their on their dedicated GPUs
09:24uh they can decide if they want to do prefill decode disagregation or not they can decide which which engine to use VLM or S lang or tenslm and given the bulk of capacity that the customer has reserved
09:37they can decide if they want to have just one deployment uh with the ability to scale through the whole cluster or they want to have multiple different models, multiple different deployments.
09:47Um one thing that I do want to mention about the router over here um is the fact that heterogeneous capacity across different zones and regions is supported.
10:00It is a little it's quite a bit of a hard problem to load balance across that.
10:04So the priority order that we typically take is uh first KV cache locality and then the least loaded fallback.
10:14Um that's that um another request flow that I want to go over here which um might be a little hard to see from the diagram is I want to take the batch workflow.
10:26For the batch workflow what we would actually do is the underlying capacity that the customer has let's say the same dedicated inference customer uh during US daytime they're running their real-time workloads and from evening to night they want to run batch workloads
10:41the same capacity after time can be scheduled to run the batch workloads.
10:46So we provide the capability in the API to tell when to scale up and when to scale down and as per schedule if we can if they tell us that we have to scale down we will scale down and open it up for batch processing through the night.
11:05I think I've spoken quite a bit about uh optimizations on the KV cache side but I do want to repeat a little bit because this is one of the most interesting pieces.
11:14Um it if we can hit on the cache more you can you will avoid the cost of prefill which is the most expensive piece over here.
11:24Um reusing the cache across multiple different turns in your agentic workloads between turns also there is lot of um similar prefill uh that comes in in the input sequence length.
11:37Um, think about the chat workloads which is where offloading AV cache also becomes extremely important because with cache with with the chat workloads we have a lot of latency between different between multiple turns that we as users put in
11:52but uh if we completely evict whatever we had in our particular conversation then the next time we ask a question in that same chat it's going to take a little bit longer.
12:02Uh so instead of actually completely evicting and redoing the prefill again what the the techniques being used are uh maybe using u we we are using our own but externally we know about LM cache and moon cakes.
12:17Um what we do is we will offload the KV cache to a high bandwidth storage so that we can store a lot of these prefills uh such that whenever the accompanying request comes for that particular conversation
12:30it can be loaded in right away into the HPM.
12:36Um on the performance liver I would I just want to mention a few performance livers.
12:41We've discussed the PD disagulative decoding are others and how to carefully choose the parallelization degrees and the strategies that is actually very important.
12:54Uh two of the biggest livers that we've been working with are quantization to NVFP4 and spec.
13:01uh we do provide capability where if the customer has their data set and they want us to train in speculators for their data sets for better acceptance lens which will ultimately make the output throughput significantly
13:13higher.
13:14Uh we do have that as well.
13:16So but that happens async.
13:18We uh we get the data async we train the speculators async and then we deploy the speculators into the customer deployments uh if that's what they wanted.
13:28uh you see three screenshots over here.
13:30I have posted them from uh the last one month one month's worth of work that uh some of us in my team have done.
13:38You can see we came quickly on top of the leaderboard on Kimmy 2.6 2.7 and um those are those are from artificial analysis and going back to the session before this
13:48can we trust that that's why for GLM I have the results from open router.
13:53So artificial analysis when they run benchmarks they're running very specific workloads open router is actual user traffic uh and you can see uh on the open router side weights and biases so the branding is different but weights and bias is basically k we bought weights and biases about a year back
14:11uh you can see the speed over here that we have from our deployment is pretty close to what fireworks is providing us fireworks fast right but underlying techniques that we are using is what I want to emphasize the most over here
14:24uh for for performance optimization that becomes critical because ultimately what you want to serve to the customer what we want to serve to the customer is uh price performance benefit
14:36quick recap um single platform is what I've been trying to emphasize is what I've tried to show uh two different consumption models serverless and dedicated for customers and within serverless I describe two different consumption models as well pay as you go and provision vision throughput if you care about that
14:55and ultimately compounding the gains uh through performance optimizations uh in the stack.
15:02That's all.
15:02Thank you folks.
15:18[music]