← All AI Engineer talks

AI Engineer World's Fair 2025

The Rise of Open Models in the Enterprise

Amir Haghighat· CTO and co-founder, Baseten16:50

Read the talk

The Rise of Open Models in the Enterprise

Enterprise teams turn to open models when task quality, interactive latency and agent costs strain closed APIs—but owning the model also creates a production infrastructure obligation.

From a talk by Amir Haghighat

Before you start: Familiarity with model APIs and basic deployment concepts will help; inference serving terms are explained as they arise.

What does enterprise adoption actually mean?

Does slow enterprise adoption mean AI is mostly hype? The question matters because enterprises have enormous reach and spending power. If they cannot put AI to work, the economic shift promised by the technology will take longer to materialize.

Slide titled “AI in enterprise” with bullets about startup hype, enterprise value at massive scale, and adoption proving a platform shift.
AI in enterprise: hype, scale, and adoption.

Amir Haghighat, Baseten’s co-founder and CTO, approaches that question through conversations with more than 100 enterprises over the preceding two years, ranging from public software companies to Fortune 50 soft-drink businesses. This is a commercial vantage point, not a representative market survey. It also has a particular bias: Baseten sells horizontal inference infrastructure rather than a finished application for one business function.

Enterprises were already buying AI products for sales, marketing and customer service. Buying AI applications and building with AI are different forms of adoption. The latter creates room for companies to turn their own knowledge and processes into software. Haghighat compares this with the earlier enterprise software expansion: if companies had only bought Salesforce-style applications, rather than building technology themselves, the surrounding market for Snowflake, Databricks and Datadog would have looked very different.

0:330:43
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

0:33 · section reference included

From experimentation to production

The usual starting point in these conversations was OpenAI or Anthropic. Their APIs made it easy to begin, while enterprise procurement brought cloud deployments through Azure or AWS into the picture for security and privacy. Existing predictive ML teams often became the teams building AI applications. Once that arrangement worked, convenience and organizational inertia both favored keeping it.

In 2023, the CIO of a large insurance company described a dedicated deployment of GPT-4 or GPT-3 as something engineers could “toy around with.” The deployment existed, but the assignment was exploratory. In 2024, Haghighat estimates that 40–50 of roughly 100 enterprise contacts had something in production. By 2025, his conversations had shifted again: teams were encountering reasons they might not be able to build indefinitely on closed frontier models alone. This was a progression from experimentation to operational constraints, not a wholesale rejection of closed models.

3:093:22
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

3:09 · section reference included

The objections that were not driving the change

Vendor lock-in was not a frequent complaint in Haghighat’s conversations. With OpenAI, Anthropic and Google available, customers saw alternatives and some interoperability. Moving between them still meant rerunning evaluations and adjusting prompts. That is a narrower claim than universal API compatibility: current Claude documentation describes a limited OpenAI SDK compatibility layer, not a complete common contract across providers.

Cost had also seemed less urgent in the earlier conversations because customers expected falling token prices to solve it. Compliance, privacy and security were similarly perceived as addressed through arrangements with model vendors and cloud providers. Haghighat describes dedicated deployments inside existing VPCs, but private access does not necessarily mean the model runs in the customer’s VPC: AWS’s PrivateLink explanation distinguishes a customer VPC from the Bedrock service account. The deployment details matter; the observation here is that these customers considered their requirements satisfied.

5:145:26
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

5:14 · section reference included

Enterprise data can improve a narrow task

A better model for a particular task need not be a better general model. The enterprises Haghighat describes were not trying to outbuild OpenAI at general intelligence. They were finding tasks for which a frontier model was not the right tool.

Large health plans provide one example. They process millions of medical documents, including prior authorizations and claims, and need to extract CPT procedure codes, diagnosis codes and prescriptions. Simply sending those documents to Claude or a GPT model did not meet the needs of the cases Haghighat encountered. The health plans also possessed years of labeled data. That gave them a basis for improving the specific extraction task, and he reports that they did improve it, without supplying benchmark scores.

“Quality” slide stating that the goal is not a frontier general model, that task-specific quality differentiates a product, and giving healthcare document processing as an example.
Task-specific quality, illustrated by healthcare document processing.

Medical transcription creates a related opportunity. Understanding specialized medical jargon can be more valuable than broad, generic transcription capability. Bringing that model work in-house lets the organization target the vocabulary and errors that matter in its own setting. The competitive asset is the combination of a narrowly defined task and relevant enterprise data.

6:537:05
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

6:53 · section reference included

Voice applications change the serving objective

The next pressure is latency. Haghighat characterizes shared model APIs—including services hosting open models—as optimized for throughput and queries per second, sometimes at the expense of individual response latency. An AI phone call exposes that tradeoff immediately: the user experiences the pause before the system starts answering.

MeasureWhat matters to the application
Throughput / QPSHow much concurrent work the service handles
Time to first tokenHow soon generation starts
Time to first sentenceHow soon a usable spoken response can begin

For voice interactions, serving choices must reflect the latter two requirements. A generally capable model behind a convenient endpoint does not, by itself, establish that the application will respond quickly enough.

8:178:37
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

8:17 · section reference included

Agentic workloads reopen the cost question

The expectation that falling token prices would resolve cost concerns ran into agentic workloads in 2025. Haghighat reports seeing a single user action produce 50 inference calls in an agentic application. That is an observed example, not a universal agent workload ratio, but it changes the unit of analysis: the business pays for all the inference needed to complete an action, not just one inexpensive call.

The relevant accounting relationship is:

Costperuseraction=ΣcostofeachinferencecallCost per user action = Σ cost of each inference call

As calls multiply, teams must bring the total back within the economics of the product and demonstrate ROI. Running models on paid compute can give them more control than accepting a provider’s per-token prices and margins. Haghighat reports cases where this approach was cheaper; the move creates an opportunity to improve economics, not an automatic savings guarantee.

A separate strategic concern follows: if competitors all use the same frontier models, where does differentiation come from? Some CIOs and CTOs want control over the AI layer itself, in addition to their workflows and applications. Customizing models becomes a way to express an enterprise’s particular capabilities, rather than relying entirely on capabilities available through the same APIs to everyone else.

9:079:20
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

9:07 · section reference included

A model, an engine and GPUs are only the starting point

Adopting open models makes iteration, fine-tuning and distillation possible, but it also changes what the organization must operate. A simple API dependency becomes inference infrastructure that must scale. The team still needs to deliver applications quickly; a long hiring cycle followed by a long infrastructure build can consume the benefit of taking control.

A common proposed recipe is straightforward: choose an open model, run it with vLLM, SGLang or TensorRT LLM, and supply GPUs. Enterprises may have those GPUs in a data center; startups may rent them in a cloud. Either way, running inference is not the same as operating mission-critical inference. The engine is one component of a service whose performance and operational behavior still need engineering.

10:3810:49
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

10:38 · section reference included

Latency optimization crosses the model boundary

Latency work happens at both the model and infrastructure levels. At the model level, even choosing a speculative decoding approach opens several paths:

  • Draft model: Use a separate model to propose candidate continuations.
  • Medusa heads: Use additional decoding heads to propose candidates.
  • EAGLE-3: Consider another speculative acceleration approach.
  • MTP: Consider multi-token prediction where the model and serving stack support it.

These are alternatives to investigate, not interchangeable switches.

Haghighat points to EAGLE-3 as recent research already making a meaningful production contribution in his experience. The paper was first submitted on March 3, 2025; his approximate six-month age estimate should not be treated as its publication chronology. The larger engineering issue is the pace of change: organizations need people who can evaluate new techniques and make them work for their workload, rather than assuming an engine option delivers the result on its own.

Other optimizations cross into infrastructure. Prefix caching reuses work on shared prompt prefixes, while disaggregated serving separates serving stages such as prompt processing and token generation. Large agent prompts often contain similar material from call to call, making these choices relevant to the time before an answer starts. The target is not merely a good typical time to first token, but a reliable P99—the latency boundary that covers 99% of requests. Haghighat identifies these as engineering requirements without walking through a particular implementation.

11:5912:11
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

11:59 · section reference included

Recovery, scaling and the rest of the platform

For mission-critical inference, Haghighat poses four-nines availability, or 99.99%, as a goal. He argues that the basic model-plus-engine-plus-GPUs recipe does not guarantee more than two nines; that is his warning about an incomplete architecture, not a measured ceiling for serving engines.

Hardware fails, and serving processes can crash. Haghighat describes firsthand experience with vLLM and Triton crashes that left users waiting while services recovered. Recovery time therefore affects both availability and tail latency. Keeping excessive spare capacity might cushion failures, but it can also undo the unit economics that motivated operating open models in the first place.

Traffic bursts expose a different delay: adding capacity. One large soft-drink enterprise told Haghighat that starting another replica of the same model took eight minutes. He considers that plausible once the startup work is added together, but unacceptable for responding to a sudden burst. Requests accumulate while the new replica starts, driving up tail latency precisely when more capacity is needed.

The remaining platform work also determines whether engineers can move quickly:

  • Tooling and lifecycle management: Support the ongoing work of delivering and operating models.
  • Observability: Make the service understandable beyond merely emitting logs and metrics.
  • Controls and audits: Meet the operational and governance requirements enterprises bring to deployment.

Performance, recovery and scaling are therefore part of a larger platform obligation, not the entire obligation.

“Challenges” slide listing performance, infrastructure, tooling, and process requirements, including 99.99% availability despite GPU failures and fast scale-ups for traffic bursts.
Inference challenges include availability despite GPU failures and fast scaling for traffic bursts.
13:3713:47
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

13:37 · section reference included

Where to draw the build-or-buy boundary

Once these requirements become concrete—sometimes only after a team has built the stack itself—the organization faces a build-or-buy decision for inference infrastructure. Haghighat advocates buying that layer and explicitly acknowledges his commercial interest: selling the infrastructure platform is his job. Buying it is still compatible with building the enterprise’s own AI capabilities. The application, workflow and model customization can remain areas of internal investment while an infrastructure supplier carries part of the operating burden.

The closing invitation extends that decision to vendors selling into enterprises. Alongside offering to discuss inference problems with enterprise teams, Haghighat offers startups lessons from Baseten’s own right and wrong product decisions. Those choices affect whether a product can later be deployed into a customer’s own cloud. Customer-cloud deployment can become another substantial infrastructure problem; its feasibility depends on decisions made before the enterprise sale arrives.

15:2715:38
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

15:27 · section reference included

Resources

From the talk

  • Inference and serving engine with installation guidance and documentation for batching, caching and distributed execution.

  • Serving framework for large language models and multimodal models.

  • NVIDIA's library and runtimes for optimized inference, including speculative decoding and disaggregated serving.

  • Explains accelerating generation with additional decoding heads and simultaneous verification of candidate continuations.

  • EAGLE-3Paper12:31

    Speculative sampling research combining direct token prediction with features from multiple model layers.

Updates since the talk

Read the complete timestamped transcript
  1. 0:00

    [on-hold electronic music] Yeah. Hi, everyone.

  2. 0:15

    My, my name is Amir. I'm co-founder and CTO of Baseten, uh, the inference company. But I'm not here to talk about Baseten. I'm here to talk about the adoption of AI in the enterprise, why we should care about it, and how it's going, uh, based on what we've seen.

  3. 0:33

    So, uh, first, why, why we should, uh, care about it. Um, uh, ul-ultimately, um, a... We've heard this before as like, "Hey, is there a hype in the market?"

  4. 0:43

    You know, "Is, is AI hyped?" And like, it probably is, but, uh, the, the evidence that a lot of people point to that there's hype here is that the adoption in enterprise has been slow.

  5. 0:55

    Uh, you know, you've- I've heard this so many times that like, you know, uh, enterprises are, are, are slow to adopt, uh, and, uh, and, and, and that, that has an implication.

  6. 1:05

    Uh, if, if that is true, that has implication for really the impact of AI, uh, and h-how large it can be and whether it is truly a hype, uh, or, uh, or, or real.

  7. 1:15

    Um, and the reason is that it's enterprises are massive, like their reach is massive, um, they have all the money, uh, and, uh, and, and if, if they're slow in adopting, uh, then, uh, the, that paradigm shift that we're talking about, that, uh, will be slow, uh, to, to materialize.

  8. 1:31

    So but I'm here to tell you based on what I've learned, uh, uh, about adoption of AI in enterprise, um, why, why me? Why, um, uh, because we're, we're, hap-we happen to sit somewhere interesting.

  9. 1:43

    We happen to sell to enterprises. Uh, and, and so over the past... The company is six years old, but over the past two years, uh, you know, in particular, talked to honestly 100-plus enterprises from software companies that are public to literally soft drink companies, uh, that, that are, you know, Fortune, Fortune 50.

  10. 2:02

    Um, and, uh, and I've seen patterns that I want to share those patterns with you. Uh, one bias that I have, uh, is that I'm, uh, I don't sell a verticalized, uh, AI tooling.

  11. 2:14

    I, I sell, I sell a very horizontal AI tooling and, and this is important. So, uh, enterprises are adopting vertical solutions, you know, um, AI for sales, AI for marketing, um, AI for customer service.

  12. 2:24

    You just heard from Clay from Sierra. Um, that adoption is happening. But I think for the true value to get unlocked, uh, we need to see enterprises actually build with AI.

  13. 2:34

    Um, the, the analogy that I use is that if in the 2000s, uh, uh, enterprises were, uh, not really building tech themselves and, and were just buying, uh, Salesforce, uh, or, uh, you know, products like that, verticalized product-products like that, then the, then the, the tech industry would just not be as big.

  14. 2:53

    Uh, companies like Snowflake and Databricks and Datadog would not exist or would not exist to the shape that, that they do. And so I really think that the value is ultimately unlocked once the enterprises feel comfortable to actually build with AI themselves as opposed to just buy v- uh, verticalized tooling.

  15. 3:09

    So let's talk about the j- the journey, uh, the, the, the journey that they go through. Um, uh, they, they, they all start with OpenAI and Anthropic. You know, enterprises, they're like us, uh, you know, for, for good reasons.

  16. 3:22

    It's just so easy to get started. Um, it's just they do it differently from, from the rest of us in that they, they have their own, uh, dedicated deployments, uh, of, of these models on Azure or, or AWS, um, and, um, for, for reasons around security and privacy and, and all that.

  17. 3:38

    Um, and then they, they get their engineers. A lot of times they're more, you know, predictive, uh, ML teams, uh, to become AI teams and, and, and build on top of these.

  18. 3:47

    Um, and they're, they're happy with that. And if they can continue doing that, they will, um, because, uh, there's just ano- a lot of inertia in, in, in, in sticking to that if it actually works.

  19. 3:59

    Uh, sticking to closed models, which is so easy to use, API-based, you know, build on top of it.

  20. 4:05

    Um, but we're seeing cracks in that assumption. Uh, and, and so let me, let me tell you what, what I've seen going back in time and, and how that's changed over time.

  21. 4:14

    So in 2023, I remember like going and, and trying to sell to enterprises and, and, and the, the terms toying around came up quite a bit. And I heard this actually literally from, um, the CIO of a massive insurance company, uh, back then.

  22. 4:27

    It was like, "Yeah, we put a dedicated deployment of OpenAI, uh, uh, of, of GPT-4 or GPT-3, um, uh, so that our engineers can toy around with it." Kind of like almost dismissively talking about it.

  23. 4:37

    It was like, "Yeah, go build something cute." Um, that started to change. In 2024, we saw actual production, uh, use cases, again, built on top of these closed models.

  24. 4:48

    Um, I would say like 40, 50 out of the 100 like had something in production, uh, th- uh, in that year. Um, and then in 2025, this year, something changed.

  25. 4:59

    Uh, and, and, and it's palpable from, at least from where I'm sitting. Uh, and, and, and the change is that there are cracks in that assumption. There are cracks in the assumption that we can actually build on top of these closed frontier models, uh, indefinitely.

  26. 5:14

    So what are those cracks? Um, uh, I'll tell you what the cracks are not, and there's some misconceptions over here. Um, I'll tell you what they're not. Uh, so like often people say, "Oh, because people, like enterprises don't want to have vendor lock-in."

  27. 5:26

    I don't hear that, honestly. Uh, like we go and talk to them. I, I think I know why. It's because, one, there's a few of them now, you know, you can go OpenAI, Anthropic.

  28. 5:35

    Google has been coming up pretty well. They're somewhat interoperable, uh, uh, at a certain level. Like they all use OpenAI specs, so like building on top of them, yeah, you might have to like do your evals again and, and, um, do some prompt tuning.

  29. 5:47

    But, but generally you can go from one to the other. So vendor lock-in is not something that I hear about. Um- Ballooning cost. Uh, I, I didn't hear that last year, um, and I, and I know why.

  30. 5:58

    It is because when I ask them, they say, "Look, uh, the, the price per token is plummeting." And we, we just talked about this, like, right before this. Uh, and that's...

  31. 6:07

    The-they were saying that problem will just take care of itself. Um, compliance, privacy, security, also not problems because th-these frontier, uh, model companies kinda take care of that with the help of the CSPs, with the help of the, the, the cloud providers so that these models are running in a dedicated way inside of their existing VPCs.

  32. 6:27

    Um, if these aren't the, the, the, the cracks in that assumption of just use closed models, then, then, then what are the cracks? Uh, these, these are, uh, the, the, the, the reasons that I have seen.

  33. 6:38

    Uh, and, and I'll go through them one by one, uh, and, and go through, like, examples of these as well. Uh, and, uh, and, and then at the end also talk about, um, you know, uh, if, if these are the cracks, then, uh, you know, how, how do you get around them and, and, you know, there be

  34. 6:53

    the dragons. So one is around quality. Look, uh, none of these enterprises are in s- any sort of misconception that they can build the next GPT-4 better than OpenAI can.

  35. 7:05

    That's just not the, the reality. Not, not as a gener-general model at least. But for specific use cases, for specific tasks, we are seeing this where the, the, the frontier models are not necessarily the right tool.

  36. 7:16

    Uh, so the, the example, uh, uh, I, I've seen this in a couple of big health plans, is that they wanna do medical document extraction. So they have m-millions of medical documents, uh, prior auth and, uh, medical claims, and, and they're trying to get, you know, CPT, like, um, uh, procedure codes and diagnosis codes and, and prescriptions,

  37. 7:36

    uh, and just giving that to, you know, Claude or, or GPT doesn't, uh, doesn't do it. But they have the data. Uh, over the years they've collected a lot of labeled data, and they're like, "Oh, we can do better."

  38. 7:47

    Uh, and, and so that's... That... And, and, and they actually did. That's one example. Another example is, um, uh, uh, on the voice side, in p- in particular on the transcription side, like, uh, again, staying in the healthcare space, like understanding medical jargon, or like, you know, getting, uh, getting transcription models to understand medical jargon, um, that's...

  39. 8:06

    That, that has been another reason to not just use an API-based generic model, um, but, but in-house it and, and do better than, than what they can, uh, what they can do with just, uh, API-based models.

  40. 8:17

    Another one is, is around latency. Um, look, these, these models, um, uh, OpenAI, Anthropic, even, even, you know, the, the big players that serve open-source models behind shared APIs, inherently they're optimized for high throughput and high QPS at the expense of latency.

  41. 8:37

    But a lot of times we're seeing more and more now where latency is becoming very critical, uh, especially when, you know, the, the AI, AI voices or, or AI phone calls, uh, latency starts really mattering.

  42. 8:49

    Uh, time to first token, time to first s-sentence really starts mattering. Uh, and, uh, you have to just think about things differently. Uh, you can't just use the, uh, the, the frontier models as is because, again, they're optimized for something else.

  43. 9:07

    Um, around the unit economics, uh, there's, uh, the... Again, like I said before, like pricing, they said this, this will take care of itself. Uh, then came this year and, and as you saw in the previous talk from Michael, that the agentic use cases ballooned.

  44. 9:20

    Uh, and they... When, when, when they balloon, it, it's crazy. Like, I've seen this. Like, every single user action can result in literally 50 inference calls. Uh, and, and so suddenly the thing that you thought is gonna take care of itself is not taking care of itself.

  45. 9:33

    Uh, that, that cost are, are really, uh, ballooning and, and, and the enterprises think that maybe they can do better on the cost and uni-unit economics. In order to show ROI, in order to show that the, the solutions that they're pushing are, are economically viable, they need to show, uh...

  46. 9:49

    They need to reduce, uh, the, their costs somehow, and they're realizing that they can actually run these models and pay for the compute and have that be a lot cheaper than paying per, per token and, and covering all the margins of someone else, and, and really going from being a price taker to actually be the, the, the,

  47. 10:05

    the maker of the price and, and be in control of that. And then lastly, destiny. This one is a bit vibey, uh, but, but I'm hearing it more recently, uh, that, um, you know, some CIOs, CTOs saying, "If we, the enterprise, use, uh, just the frontier models and so do our competitors, what is our advantage?

  48. 10:25

    What is our alpha?" Uh, and, uh, and, and maybe we should bring in some of these things in-house and to be able to even differentiate not just at the workflow and application, uh, level, but also at the AI level.

  49. 10:38

    So now what? If, if those are the reasons why they, they want to adopt open-source models and, and iterate on those and build those, uh, and fine-tune those and distill those, uh, then what changes?

  50. 10:49

    Well, what changes is that they go from super simple world that just call an API and run with it, uh, to now you need to build inference. Uh, you need to build inference infra, and you need to make sure that it scales well, and you need to make sure that you can move fast, uh, that, that your

  51. 11:04

    engineers can actually, uh, deliver instead of having to, you know, hire a bunch of new types of people, uh, and then wait for them for a long time to actually build this, uh, build this infrastructure, uh, in-house.

  52. 11:17

    So one thing that I hear quite a bit at this point is, look, I've... I, I hear this from enterprises, I hear this from startups too actually, uh, which is that, look, you know, we've picked a model, an open-source model.

  53. 11:27

    Um, we've heard of vLLM or SGLang or TRTLM. We have some GPUs, in the case of enterprises it's in their data center, in the case of startups it's in some cloud.

  54. 11:37

    And you put these together and you get production inference. And I know for a fact that this is not true. Uh, and I, I wish it was true, but I know for a fact that, that this is not.

  55. 11:46

    Uh, that, that there is a lot more that goes into, uh, making, uh, inference, especially mission-critical inference, work well, uh, in-inside of your company. So, so what are those?

  56. 11:59

    These are the dragons. These are the dragons. So, so, uh, one, uh, at the, uh, at the performance layer, uh, you know, we talked about, you know, situations where things are very latency sensitive.

  57. 12:11

    Um, the, the way that you optimize models, uh, for, for latency, uh, is, is, is actually quite, quite involved. Uh, both at the model level and at the infrastructure level.

  58. 12:22

    You, you have to do it- you have to attack it at both levels. So as an example, um, you know, for, um, a- at the model level it's like, "Hey, do you use speculative decoding?

  59. 12:31

    Uh, and if so, do you... Which, which, which route do you go? Do you go with a good draft model? Do you go with Medusa heads? With, with Eagle 3?

  60. 12:37

    Uh, do you go with MTP?" Um, there's, there's a lot... And new techniques are coming out all the time. New... Like, the, the Eagle 3 paper came out, like, six months ago, and it's, like, running in production and actually being very meaningful.

  61. 12:48

    Uh, and so as an enterprise, can, can you hire the right folks to be able to be on top of the research? Because you don't... This is- these are not just, you know, switches that you flip in, in SGLang or vLLM and, and, and get the, get the result.

  62. 13:02

    Um, uh, some of these optimizations bleed out of the model level into the infrastructure level. Uh, so as an example, if you want to, uh, be able to do, uh, uh, prefix caching really well, if you wanna be able to desegregate a serving really well, uh, because that starts really mattering, uh, uh, especially in, in agentic use

  63. 13:22

    cases where, like, the, the prompts are massive but the prompts are somewhat similar from one to the other, uh, it ends up mattering a lot in, in you hitting your, you know, time to first token and you hitting your P99 of that, uh, in, in a reliable way.

  64. 13:37

    Another thing on the infrastructure is, especially if it's a mission cri- critical inference, which more and more I see that that's the case, h- how do you guarantee four nines?

  65. 13:47

    And w- with, with, with this, with... Th- this formula does not guarantee you, you know, more than two nines. Uh, and I, and I, and I saw this firsthand.

  66. 13:56

    Uh, so how do you make sure that when the hardware fails underneath that, uh, you, you actually recover? How do you make sure that, you know, when vLLM crashes, which it, which it happens often, I saw this firsthand with, like, when Triton crashes often, your tail latencies go through the roof while you wait for these things to

  67. 14:12

    come back. Uh, and, uh, and, and, and during that time, like, your, your users are, are, are, are feeling that, um, how do you build, uh, uh, against those and, and make sure that, you know, you, you can still guarantee four nines and not be super over-provisioned and mess up all the unit economics that we talked about?

  68. 14:30

    Um, when a big burst of traffic comes in, how do you make sure that you scale up fast? Uh, how do you make sure that, uh... You know, I was talking to this massive enterprise, like, uh, soft drink example, where they're like, "Yeah, it takes us eight minutes.

  69. 14:43

    When we wanna bring up a new replica of the same model, it takes eight minutes." Um, and, and I believe that because that... if you add up all the different things that it goes into doing that, that is how long it takes.

  70. 14:52

    But h- But, but that's not okay. Again, your tail latencies go through the roof as soon as there's a big spike of traffic. H- how do you account for that?

  71. 14:59

    And then there are other things around, uh, again, like making sure that your engineers move fast. Uh, the tooling, life cy- life- lifecycle management. The observability massive, uh, uh, um, uh, iceberg, which is like...

  72. 15:12

    It's like, "Oh yeah, just put some logs and metrics," and you realize there's a lot more to do underneath it. Uh, we just... Previous talk Michael talked about. Um, and then lots of stuff around controls and, um, o- audits and, uh, things that enterprises actually care about.

  73. 15:27

    So, so these are the, these are the dragons. These are the dragons, and these are the times that then enterprises h- have a decision to make. Like, once they, once they get to this level, either, like, I tell them or...

  74. 15:38

    And they have to believe me, or they don't and they go and build it [laughs]. And then, then, then they, they see some of these things that they have a decision, which is build or buy.

  75. 15:47

    And that's my job to then try to convince them that I, I think they should buy this, uh, uh, uh, this layer o- of infrastructure and platform, uh, as opposed to, uh, build it.

  76. 15:57

    Uh, and that's sometimes, uh, harder, harder than it seems.

  77. 16:03

    So, so I'm happy to talk more about these things. So I, I'll be, I'll be at our booth. Like, two, two topics that I'd love to talk about if, uh, if you're interested.

  78. 16:10

    One, self-servingly, if you're an enterprise and those problems resonate, I'd, I'd love to chat with you about. And two, less self-servingly, um, if you're a startup and you're trying to sell to enterprises, um, I'm happy to chat about all the right decisions that we made, the wrong decisions that we made along the way to, to build something

  79. 16:27

    that then when it comes to selling to enterprises, when it comes to deploying it into their own clouds, uh, that, that is actually possible, uh, and, and, and not a massive other set of dragons over there.

  80. 16:38

    And then last thing, we have a, a happy hour. Uh, we'd love to see you there. Thank you. [outro music]