Routing LLM Inference in Production: From Engine Signals to Policy — Qianru Lao & Lu Zhang, OpenAI

AI Engineer · 18 min · 130 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:12Hi everyone, thanks for joining our talk.
00:14I'm Lou and this is my colleague Chenu.
00:17So we today we're going to talk about the in uh we both work on the inference team at OpenAI and today we are going to talk about routing IM inference in production
00:27specifically how our system evolved from routing based on feedback loops driven by engine signals to a more explicit and a predictable policy which is still informed by engine signals.
00:39However, it's more like the way we use it is different.
00:43So uh for the agenda today we're going to begin by introducing the inference load balancer what it is what it does and how it has evolved and then Chenu will walk us through the newer control plane and data plane driven architecture
00:57uh what are the responsibilities of each and followed by a concrete case study of how we reduce the global network overhead and in the end I return to discuss the protection mechanisms
01:09that help keep the system stable and production level stress.
01:14So to begin with what is the inference load balancer and where it sit?
01:20So this is a very high level diagram of the system we are talking about.
01:25On the left hand side are the front end clusters.
01:29Those are the GPU cluster.
01:31Sorry, those are the CPU clusters that act as gateways into our system and they receive user requests then prepare them into the inference request that can be processed by the inference engines
01:45and on the right hand side are the engine clusters uh which are usually GPU clusters and each hosting multiple inference engines.
01:54So that's why we they got the name of engine clusters and as you may already heard nowadays GPUs are pretty popular and expensive.
02:02So um sitting in the middle it is the IRB or inference load balancer.
02:07It actually runs on the front end clusters but is also a bridge into our inference stack.
02:15It has two main responsibilities select an engine and proxing the request.
02:20For this talk, we are going to focus on the engine selection part.
02:24So in some ways, IRB resembles a very traditional load balancer because a request usually targets a model and a model is backed by multiple engines.
02:36They may live on different clusters in different regions or even across the continents because that gives us a good resiliency towards localized degradation or cluster failures.
02:47However, the inference uh stack or the uniqueness of the inference introduces a lot of nuances like uh it has to consider a bunch of signals reported in real time like the well-known time to first token TTF
03:03time between output tokens also known as token throughput or time between tokens and other hairness and utilization signals.
03:11Besides there's a important concept of a KV cache which is also well known but for example when the conversation already has a lot of the useful context cached in one engine
03:22sending the follow-up turns of the same conversation back to the same engine will avoid recomputation improve efficiency and uh reduce latency.
03:33So the combination of performance reliability locality cach awareness is what makes it such an interesting problem.
03:40Uh so how we attempted in the problem?
03:43Let's take a look at the early days.
03:46And to be honest, early days in in this industry sounds a lot more historic than it really is.
03:52And the routing process at that time began with a fear of like each request may not be served by all the engines because of uh constraints such as capabilities
04:04or due uh restrictions due to compute or data residency.
04:09And among the remaining engines, IRB used a weighted consistent hashing to select the best destination engine for a request or of for certain user.
04:20Then the important question becomes where are the WS come from.
04:24So they were generated by a periodic feedback loop.
04:28The inference engines as mentioned earlier uh reports all kind of the signals we care about and the controller will periodically smooth out those signals and compute a performance score.
04:41The performance score then will be compared against the fleet average.
04:46Then the weight will be adjusted basically for each engine.
04:51is weight goes up if the performance is better or it goes down when the performance is worse than the fleet average and this generated weight will impact the routing and then it's basically a uh control loop
05:06um conceptually it is very similar to the P controller and no this P controller will not help you care a Linux process but instead it's a classic control theory technique that continuously
05:18steering the system towards its desired date and we just borrowed this important concept the proportional part of it and uh applied into our uh our load balancer.
05:31So it has a lot of nice properties.
05:34For example, it could combine the useful signals we care about into the single routing decision and because of the it adapt to the observed performance as what we mentioned earlier there's a lot of constraints and those constraints might have the some engines basier because they can serve more requests more kind of request than the remaining
05:53but those basier signal will be fit into the next loop and resulting in the less constraint less constraint request can go to more of those kind of engines.
06:03So basically they self balanced out and to some extent this just means we don't need to do a lot of manual intervention and it just works.
06:13However that kind of adaptability comes with big trade-offs because of the same reasons that it combined so many signals.
06:20It's also very hard to reason about a particular routing decision or like why search engine get a higher weight than we expect.
06:29And every time we want to fine-tune towards some aspect, it's all almost impossible to not impacting something else.
06:37And the load is not always very well very evenly distributed because uh sometimes a model is served by engines on different GPU skills and they have different characteristics.
06:51Then the problem becomes a lot more trickier and the feedback loop sometimes creates bad oscillations because when you shift an engine away some traffic the engine turns a bit cooler and this signal get fit to the controller.
07:08The controller now thinks that hey this engine can take a lot more traffic.
07:12then the some traffic going to be shifted back and forth between a few engines and disrupting the KV cache utilization.
07:20So all those limitations motivated us to rethink about the architecture and uh see if we have new ways to address the problem.
07:30So I'm going to hand over to Chenu to uh deep dive into the new architecture we tried out.
07:38Yeah, thank you L. So I'm going to talk about the architecture of the load balancer and how do we reduce the overall overhead with our routing algorithm.
07:50The load balancer answers one question uh for each request from a CPU cluster which engine should serve it.
07:59One most naive baseline might be round robin which send requests across engines evenly.
08:06But if you think a little bit more that doesn't make sense because engines are not homogeneous they can have different hardware and capacity different health and also different distance from CPU cluster
08:19also run could break cache locality c related requests that could reuse the same engine cache might be sent to different engines.
08:30A probably better solution might be for each CPU cluster it choose the best engine from its own local view.
08:39But that's not enough either.
08:41Think about one extreme case.
08:43Multiple CPU cluster route traffic to the same engines independently which could overload that engine while leave other engines underutilized.
08:53So what we need is a globally optimized solution, a control plane that has a global view for all the CPU cluster and GPU engines and could compute a globally optimized
09:05routing answers and the data plane can make a routing decision quickly based on the answer proved from the control plane.
09:18Now let's look inside the control plane and data plane.
09:22In the data plane there is an engine selector which select engine for each request.
09:29It read the local routing state which includes the candidate engines and the routing weights for each candidate engines.
09:37Both of them are refreshed asynchronously in the background.
09:41So we don't need to ask the control plane before we make a routing decision for each request.
09:48Also the data plane collects realtime engine signal such as number of ready replica engine house etc to surface fast local guard draw in the control plane.
10:01The data loader combines those live engine signals and never overhead.
10:06And with offline regressions of capacity, TTFT and TBOT, the optimizer could turn those data into routing weights and the control plane will publish the routing weight for each data plane to pull.
10:21In this way, no request need to wait on the data plane.
10:26The control plane continuously compute the next globally optimized routing way snapshot while the data plane make a routing decision based on the latest snapshot already installed locally.
10:42In summary, there are three important paths through the system.
10:46The first path is the inference request path.
10:49The request arrive to the CPU cluster and the data plane inside that CPU cluster will select engine for that request based on the local routing state and forward the request to the selected engines.
11:03The second pass is the engine signal pass.
11:07The system continuously collects real-time engine signal such as TTFT, TBOT, number of radio replica and engine house etc. Boost planes need those real-time engine signals.
11:20The control plane need them to compute a globally optimized routing way while the data plane need them to serve as fast local.
11:29And the third path is the routing way pass.
11:32The control plane compute and publish the routing way and the data plane pull the updates to its local cache.
11:41So only the first pass is synchronous but it's fast and only local inside the data plane of the CPU cluster.
11:50The other two loops are asynchronous loop and they are to improve future routing decision.
11:59So that's pretty much of the architecture part.
12:02But that still leaves one question.
12:04How do we compute those routing weights?
12:10But before answer that question, let's answer another question first.
12:15Why not just send a request to the nearest engine?
12:20That's because the traffic demand and GPU capacity are not geographically balanced.
12:27For example, in region one, CPU cluster A send 90 RPS and the nearby engine A can serve 100 RPS.
12:36So in this case nearest only is fine while in region two CPU cluster B send 120 RPS and the nearby engine B could only serve 100 RPS.
12:49So in this case if we insist on keeping everything local the extra 20 RPS need to wait on an overloaded engine B. While in region three we are only using 40 RPS
13:02of an 80 RPS engine C. That still leaves 40 RPS spare.
13:08So if we send the extra 20 RPS from cluster B to engine C, that will add network distance.
13:17But it could also avoid a probably much larger engine side waiting time.
13:22So in this case, a further engine might be faster end to end.
13:27That's why we need something better than the nearest only routing.
13:35Now let's open the black box of the optimizer.
13:40The optimizer accepts four types of input.
13:44The request from each CPU cluster, the network latency to each engine, the available engine capacity and health and also the TTFT, TBOT latency profiles that tell us how's the engine side latency change as the low increases.
14:04And with those input the optimizer turn the input to the output routing weights.
14:11The routing way say for each CPU cluster what fraction of its traffic should go to each GPU engine.
14:19And the optimization goal is straightforward is to minimize the expected end to end latency across all routed traffic.
14:29The important part is that the end to end latency includes both the network distance and the engine side latency.
14:37That means a nearby engine might be attractive when it still has room to serve traffic while a further engine might be better if all the nearby engines are close to full.
14:51And the optimizer also need to respect several hard constraints.
14:56First it need to route all the traffic demand.
14:59Second it need to ensure all the engines stay within the effected capacity.
15:05Third it need to keep the routing weights non- negative.
15:09With this the controller control plane get the routing way from the optimizer and publish them and the data plane pull them and use them to make a globally optimized routing decision.
15:24And that's pretty much of my part and Lou will continue to talk about the protection mechanisms in the system.
15:33Thanks Chenu.
15:34So as AI engineers we all kind of know that production in many cases are not behaving in the most ideal case.
15:45So clusters can fail, GPUs or individual nodes can degrade degree and networking can just get to all kind of mysterious issues.
15:55So how do we keep our production system uh heresy as much as possible under the heavy load?
16:02The first thing we have is the penalties.
16:05Basically when an engine is an outlier, we detect the try to reduce the routing weight to that engine.
16:13In that way, we give it a chance to either recover by themselves if there's a uh if it's some transient issue or we can have a human intervented out or replace the faulty hardware.
16:28And secondly, the retries which is a very common technique used to mitigate a problems.
16:34However, during some cases, it's actually could make them even worse like when the system is very close to like a tip over or very heavy utilized retries, we are send more load and this more load we are cause more failure and cause more retries which is infamous retry storm.
16:53So we incre implemented caps or budget to constant retries into a acceptable region and this is actually even need to be dynamic because in the happy time or in the normal time we can tolerate a lot more retries than when the system are heavily utilized.
17:12And finally we have the load shedding which is our last result when the production capac uh capacity couldn't meet the increasing amount of inference demands.
17:24So we instead try to have all the system fail.
17:27We basically proactively load shed a portion of the traffic to have the system degraded gracefully.
17:35So that pretty much concludes our talk today and uh thanks for joining us.
17:40Uh both of us will be around in our uh booth area this afternoon.
17:45So if you have further questions, feel free to walk uh to the area and and chat with us.
17:50Thank you.
17:52[applause]