AI Engineer World's Fair 2024
Making Open Models 10x faster and better for Modern Application Innovation
Read the talk
Making open models fit the application
Specialized models need specialized serving. Fireworks connects workload-aware inference, shared LoRA deployment, and function calling into a practical path from prototype to production.
From a talk by Lin Qiao and Dmytro (Dima) Dzhulgakov
Before you start: Familiarity with language-model inference, tokens, retrieval-augmented generation, and API calls will help you follow the serving and function-calling examples.
What does a customer-support chatbot actually need?
What should a customer-support application pay for: broad general knowledge, or expertise in its own domain? That question anchors Dmytro “Dima” Dzhulgakov’s discussion of production inference at Fireworks. Presenting in place of cofounder Lin Qiao, he describes a team drawn from Meta’s PyTorch leads and Google AI veterans, with roughly a decade of production AI experience and five years of his own work maintaining PyTorch. Open deep-learning tools provide the precedent for the team’s focus on open generative models.
An audience show of hands reveals substantial open-model usage in the room. Dima nevertheless describes the broader production market at the time as dominated by proprietary models, often with frontier capabilities. GPT-4 and Claude can handle many different tasks, but their breadth and serving infrastructure do not necessarily fit each application equally well. Batch inference over a narrow domain and a real-time voice assistant have different requirements, even when they call the same model.
The customer-support chatbot makes the mismatch concrete: it does not need knowledge of 150 Pokémon or the ability to write poetry. It needs reliable answers about the business it supports. The useful unit of optimization is the application’s task, not the model’s total range of capabilities. Paying for abilities the application never uses can make a broadly excellent model an expensive fit.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Repeated calls amplify latency and cost
Large-model response times become especially visible in voice assistants. Agentic applications compound the problem: a system such as Devin may reason through several steps and call the model repeatedly before completing a task. Each dependent call adds another wait. Dima reports that smaller Llama or Gemma models can match or exceed quality on a narrow task while running up to 10 times faster.
For function calling, Dima cites a Berkeley benchmark and reports similar quality from fine-tuned Llama 3 at 10× the speed. The accompanying slide shows GPT-4 at 1.97 seconds and Llama 3 at 0.18 seconds, with a Berkeley Function-Calling Leaderboard credit. The recording does not specify the hardware, concurrency, request lengths, or exact leaderboard snapshot behind this comparison; those conditions matter when applying the result to another workload.
Traffic makes the economic question equally concrete. Dima’s example uses a 5,000-token prompt, 10,000 users, and 20 calls per user per day, mentioning GPT-4 and GPT-4o. The input volume is:
At GPT-4o’s May 2024 launch price of $5 per million input tokens, that is $5,000 per day for input alone; output length is unspecified. Dima’s spoken estimate of approximately $10,000 per day would amount to $300,000 per 30-day month or $3.65 million per year, rather than several million monthly. The underlying motivation remains: repeated calls at substantial traffic make smaller, customizable models economically interesting.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Open weights make adaptation possible, not automatic
Open models offer two routes to domain fit: choose an existing specialization or create one. Dima points to Gemma adaptations for Indian languages, models specialized for code or medicine, and the tens of thousands of variants available on Hugging Face. Access to weights makes it possible to tune quality for the application’s particular requirements.
That flexibility brings three kinds of operational work:
- Setup and maintenance: Find GPUs, select a framework, download the model, and tune its performance. Model updates can require repeating the process.
- Workload optimization: Low latency and high throughput are different objectives. Short and long prompts also favor different settings; Dima reports multiple-fold improvements from choosing those settings effectively.
- Production reliability: Cloud GPUs need operational attention. Enterprise serving adds scaling, telemetry, and observability beyond simply getting a model to answer a request.
These are the problems Fireworks sets out to absorb for application developers.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Optimize the serving stack around a latency budget
Fireworks’ approach spans custom CUDA kernels, runtime behavior, deployment, and service orchestration. Dima describes customization across that stack for each workload’s cost and latency requirements. A RAG application with long, repeatable prompts is one example: caching can avoid repeated work, while runtime and deployment settings can raise throughput without giving up the required response time.
Dima reports that Fireworks ranked fastest under Artificial Analysis’s Long Prompt selection at the time. He also describes Fireworks as the fastest provider serving SDXL, and as the sole provider serving SD3 because Stability’s API routed to its servers. These are historical provider claims; Stability’s SD3 API announcement confirms the delivery partnership, but does not establish the separate speed ranking or universal exclusivity.
A more useful optimization target than maximum speed alone is minimum cost subject to an application’s latency constraint. Dima gives the example of an interactive application that must generate its required number of tokens in under two seconds. The output length is application-specific, so the constraint must be evaluated with that length fixed:
Dima reports that tuning the latency cutoff and settings across the stack can increase throughput multiple-fold. Higher throughput means fewer GPUs are needed to serve the same traffic, reducing cost while preserving the response-time requirement.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Serve custom models without a GPU for every variant
The model catalog described in the talk includes Gemma, Llama, automatic speech recognition, and text-to-speech models. Dima also names Yi-Large, whose US serving on Fireworks he describes as having launched the previous week. Beyond hosting models, Fireworks produces function-calling fine-tunes and releases work combining vision and language models. Developers can bring a fine-tuning dataset collected elsewhere or build one from feedback gathered during live serving.
Training a custom variant creates another question: how should it be served economically? With LoRA, customization can be represented by an adapter associated with a base model. Dima says Fireworks can deploy thousands of LoRA variants on the same GPU. Sharing serving resources lets the platform offer per-token serverless inference without a fixed serving charge for each deployed variant, rather than requiring developers to reserve separate hardware for every customization.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The model becomes one part of the system
A capable model still does not constitute a complete application. Hallucinations motivate grounding through RAG or external knowledge bases. Gaps across modalities motivate chaining different model types. Applications that act on the world also need tools and external APIs. Dima uses the term compound AI system, crediting Databricks with popularizing it, for this combination of models, retrieval, and actions.
In the architecture he describes, a central function-calling model interprets and triages the user’s request. It can route work to domain-specialized models, invoke a code interpreter, or call external APIs. Function calling—initially popularized by OpenAI, as Dima notes—is the connection between the language model and those external capabilities.
Fireworks fine-tunes models specifically for that coordinating role. The demonstration uses FireFunction, the latest release of which Dima places about two weeks before the talk. Its job combines ordinary conversation with deciding when and how to request a tool operation.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
From cloud providers to a stock chart
The demo begins with freeform conversation: the user can ask what the application can do, and it describes its capabilities. Those capabilities include querying stock quotes, plotting charts, and generating images through external tools. The interesting work is translating a loosely specified request into a sequence of concrete calls.
A request for a bar chart of the Big Three cloud providers requires several steps:
- Resolve the entities. Interpret the providers as AWS, GCP, and Azure, then connect the services to their publicly traded parent companies—for example, Azure to Microsoft.
- Retrieve the data. Call stock-price tools for the relevant companies.
- Combine the results. Pass the retrieved prices to the chart-plotting API.
Dima describes the chart appearing after this sequence runs in the background. The model supplies the interpretation and coordination; the external tools supply the stock data and render the chart.
The next request adds Oracle to the existing graph. The application must preserve the earlier chart context, resolve the new company, and regenerate the chart with the additional entry. A compact JSON representation of the requested edit could look like this:
json
{
"chart_type": "bar",
"existing_companies": ["Amazon", "Alphabet", "Microsoft"],
"company_to_add": "Oracle"
}
This represents the requested change, not retrieved prices or an executed tool result. It makes the contextual requirement explicit: the earlier companies remain part of the chart.
Then the user changes topics and requests a cat photo. Now the stock-chart context should stop influencing the task: Oracle does not belong in the generated cat image. Useful conversational memory therefore requires both retention and selective disregard. The demonstration combines FireFunction with other hosted models, including SDXL; Dima makes the application available as open-source demo code, with Fireworks Demo Apps providing a companion entry point.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Connect model decisions to structured interfaces
The function-calling model’s weights are available on Hugging Face, allowing developers to choose hosted Fireworks inference or local execution. The FireFunction v2 model repository distributes its weights under the Llama 3 license. Weight availability gives developers deployment choices; it should not be read as unrestricted licensing.
Fireworks also provides structured generation through JSON mode and grammar mode, which Dima compares to the capabilities discussed in the preceding Outlines talk. These modes constrain the form of generated output so that model decisions can pass through structured interfaces to the rest of the application. The architecture diagram places FireFunction in JSON/Grammar mode above two destinations: Fireworks inference—including language, audio, embedding, image, multimodal, and tuned models—and external tools and APIs.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
From playground to dedicated serving
The starting point is the Fireworks model catalog and playground. From there, the deployment options described in the talk progressively expose more control over serving:
| Offering | Billing and infrastructure | Customization |
|---|---|---|
| Serverless | Per-token pricing; no hardware setup | Hosted fine-tunes and imported LoRA adapters |
| On-demand | Dedicated hardware | More workload settings and custom models |
| Enterprise | Discounted long-term contracts | Personalized hardware and performance tuning |
Serverless keeps the first deployment simple without excluding fine-tuning. On-demand provides dedicated resources as workload-specific control becomes useful. At larger volumes, the enterprise offering adds help tuning the hardware and serving configuration. These are the historical product choices described in the recording.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Production workloads and existing clients
Dima reports that Fireworks was serving more than 150 billion tokens per day as of his last check. He names Quora’s Poe as a chatbot example, Sourcegraph and Cursor as users of some code-assistant functionality where latency matters, and Upstage and Liner as builders of assistants and agents. These examples connect the earlier serving requirements to applications already handling production traffic.
For developer adoption, Dima cites the previous year’s LangChain State of AI material, describing Fireworks as a leading source for models after Hugging Face. His suggested entry point remains practical: try Llama or Gemma in the playground, then build with FireFunction or a fine-tune suited to the application.
The final integration point is OpenAI API compatibility. Dima describes keeping familiar clients and using frameworks such as LangChain or LlamaIndex when moving to Fireworks. That preserves the application’s existing integration approach while opening up choices over model specialization and serving configuration.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Model weights and loading examples for the Llama 3-based function-calling model, distributed under the Llama 3 license.
Further reading
Historical release explaining the Llama 3 fine-tune, conversational tool use, benchmark results and serving measurements.
Collection of Fireworks demonstrations with an entry point to the Functional chat application.
Stability's announcement of SD3 and SD3 Turbo API delivery in partnership with Fireworks.
Read the complete timestamped transcript
- 0:00
[upbeat music] Hello, everyone.
- 0:15
So my name is Dima. Um, as mentioned, uh, unfortunately my co- uh, co-founder Lin, who was, uh, on the schedule couldn't make it today because of some personal emergency.
- 0:24
So you, you got me and as you saw, we don't have yet AI to figure out video, uh, projection, but we have AI for a lot of other things.
- 0:32
Uh, so today I'm gonna talk about Fireworks AI and generally gonna con- continue this theme which Caitlin started about open models, uh, and how we, uh, basically focus on productionization and customization of, uh, open source models, uh, in inference at Fireworks.
- 0:48
But first, uh, as a introduction, uh, what's our background? Uh, so f- the founding team of Fireworks, uh, comes from PyTorch leads at Meta and some veterans from Google AI.
- 0:59
So we combined have like probably decade of experience in productionizing AI in some of the biggest companies in the world and I myself personally have been core maintainer of PyTorch, uh, for the past five years.
- 1:11
So topic of open source is really close to my heart and since we kind of led this revolution of open source tool chain for deep learning through our work through, on PyTorch and some of the Google technologies, we really believe that open source, uh, models are the future also for like, for, for GenAI application and our focus
- 1:32
at Fireworks is precisely on that. Um, so
- 1:38
I mean, uh, how many people in the audience actually like use GPT and deploy it in for production?
- 1:45
And how many people-- how many folks use open models, um, or deploy to production? Oh, okay. So I was about to convince you that share of open source models is gonna grow over time, but it looks like in this audience it's already [laughs] already sizable, but nevertheless, um, so why, why basically this trade-off?
- 2:04
Why go big or, uh, why go small? Um, currently still like bulk of production inference is still based on proprietary models and, uh, the catch is that those are really good models and they are often fr- frontier in ma- in, in many domains.
- 2:18
Uh, however, the catch is that it's one model which is good in many, many sense and it's often served, uh, in the same way, uh, regardless of the use case which means that maybe if you have batch inference, uh, on some narrow domain or you have some super real-time use case, uh, where you need to, you need
- 2:35
to do like voice, uh, assistant or something, uh, those are often s-served from the same infrastructure without customization. In terms of model capabilities, it also means, yeah, like GPT-4 is great, uh, or, uh, Claude is great and can handle a lot of sense, but you are often paying a lot for additional capabilities which are not needed in
- 2:52
particular use case. You don't really need customer support chatbot to know about 150 Pokémons or be able to write, write you poetry, uh, but you really want it to be really good in the particular, uh, narrow domain.
- 3:06
So this, uh, can, uh, this kind of discrepancy for large models leads to several issues. One, as I mentioned, is high latency because using a big model means, uh, longer response times, uh, which is particularly important for real-time use cases like voice assistants.
- 3:22
It gets more and more important with agentic stuff because, uh, for stuff like, um, for example, n-next [laughs] time is gonna be a Devin, right? Like you, you need to do a lot of steps for like something like agent-like application to do reasoning and call the model many times, so latency is really, really important.
- 3:38
And often you see that you can pick smaller models like Llama or Gemma [laughs] which we, which we just talk about and achieve the, for a narrow domain, uh, same or better quality while being, you know, up to 10 times faster.
- 3:51
Uh, for example, for some of the function calling use cases like externally benchmark from, uh, from Berkeley, yeah, like the, you get similar performance from fine-tuned Llama 3 at 10X the speed.
- 4:03
Cost is also, uh, is, is also an issue if you're running a big model for, uh, on a lot of traffic. You know, even if you have perhaps, I don't know, 5K tokens prompt and 10,000 users and each of them calls LLM 20 times per day, you know, on GPT-4, even on GPT-4o, it probably adds up to
- 4:20
like 10K per day or something like several million per month. Also se- several million per year which is a sizable cost of a startup. You can easily cut that with much smaller models and that often we see as a, uh, as a kind of motivation for reaching out for smaller and more customizable models.
- 4:39
Uh, but really the, uh, like where open models shine is, uh, domain adaptability and that comes, uh, in two aspects. First, um, there is so many different fine-tunes and customizations.
- 4:50
Uh, I think Caitlin was mentioning about, you know, Gemma built Indian languages adaptations like there are models specialized for code or for medicine. If you head to Hugging Face, there are like tens of thousands of diff- different model variants and because the weights are open you can always customize to your particular use case and tune and, uh,
- 5:07
tune quality specifically for, for what you need. So open source models are great, so what are the challenges? Uh, the challenges really come from three areas. Uh, first like what we usually see when people try to use, you know, open model, something like Gemma or whatever, uh, or, or Llama 2B, uh, you run into com- complicated setup
- 5:27
and maintenance, right? You need to go and find GPU somewhere. You need to figure out which frameworks to run on those. You need to like download your models, maybe do some performance optimization and tuning and you kind of have to repeat this process end to end every time the model gets updated or new version is released, et
- 5:43
cetera. Uh, on optimization itself, uh, there is especially for LLMs, but generally for GenAI models, there are many attributes, uh, and settings which are really de- really dependent on your use case and requirements.
- 5:56
Somebody needs low latency, somebody needs high throughput. Prompts can be short, prompts can be long, et cetera, and choosing the optimal settings across the stack is actually not trivial and as I show later, in many cases you can get multiple X improvements from doing, from doing this efficiently.
- 6:12
And finally, like just getting it production ready is actually hard. Uh, if y- as you sc- kind of go from experimentation to production, even just BBC and GPUs on public clouds is not, not as easy because GPUs are finicky and not always reliable.
- 6:26
Uh, but getting to enterprise scale requires, you know, sca- all the scalability technology, telemetry, observability, et cetera. So those are, uh, things which we focus on, uh, solving, uh, at Fireworks.
- 6:38
So starting with efficiency, we built, uh, our own custom service stack, which we believe is one of the fastest, if not the fastest. Uh, we did it, uh, did it from the ground up, meaning from writing our own, you know, CUDA kernels all the way to customizing how the s- uh, stuff gets deployed and orchestrated on the
- 6:56
service level, and that brings multiple optimizations. But most importantly, we really focus on customizing the service stack to your needs, uh, which basically means for your custom workload and for your custom cost and latency, uh, latency requirements, we can, we can tune it for, uh, for those settings.
- 7:14
What does it mean in practice? And what does customization means in practice? Uh, for example, many use cases use RAG and, uh, use very long prompts. Uh, so there are many settings you can tune actually on the runtime level and the deployment level to optimize for long prompts, which often can be repeatable, so caching is useful, or
- 7:31
just m- tune in settings so the throughput is higher while maintaining latency. So this is i- independently benchmarkable. If you go to, uh, you know, Artificial Analysis and select Long Prompt, where Fireworks actually is the fastest, even faster than some of the other providers which are over there at Expo booth.
- 7:47
Uh, and, uh, we don't only focus, we don't only focus on LLM inference. Uh, we are focused on many modalities. Uh, as an example, for image generation, we are the fastest provider serving SDXL.
- 7:58
We're also the only provider serving SD3, uh, uh, in, in, uh, Stability's new model because their API actually routes to our servers. Um, and finally, as I mentioned, with like L- LLMs, like customiza- especially for LLMs, customization matters a lot.
- 8:14
Uh, one requirement, like one problem we have to think about performance of LLMs often it's useful for use cases is to think about maxi- like minimizing cost under a particular latency constraint.
- 8:23
We often have customers come and say like, "Hey, I need to like have this, my interactive implication. I need to generate that many tokens under two seconds." And that's where, that's really where like cross-stack optimizations shine, uh, whereby, uh, tuning the particular like latency cutoff and changing many settings, you can deliver much higher throughput, multiple times higher
- 8:43
throughput, uh, which bas- higher throughput basically means fewer GPUs and lower cost.
- 8:50
Uh, in terms, in terms of, uh, model support, we support, support best quality open source models. Uh, you know, we heard about Gemma now, obviously, uh, uh, Llama's, uh, some of the, uh, ASR and text-to-speech models, uh, pretty much from, from many providers.
- 9:05
We also work with model developers. For exam- uh, for example, eLarge, uh, in US is also served on, uh, on Fireworks, launched, uh, laun-launched, uh, last week. And, uh, as a kind of pla- platform capabilities, as I mentioned, we have a lot of op- open source models to st- uh, to get you started or cus- uh, customized
- 9:23
ones. We do some of the fine-tuning of those models, uh, in-house. So I'm gonna talk a little bit about function calling specialized models, uh, later on, or we do some of the, uh, vision-language models fusion, uh, ourselves, which we re-release as well.
- 9:38
And of course, the key for open source, um, mo- open model development is that it can tune for a particular use case. So we do provide a platform for fine-tuning, uh, whether you're bringing your dataset collected elsewhere or collecting it live, uh, with the feedback wh-when served on our platform.
- 9:56
Uh, specifically on customization is like one, uh, interest... One interesting feature which a lot of people expe- starting to experiment with models, uh, find interesting is if you try to fi-fine-tune and deploy the resulting model, how, uh, how to serve it efficiently.
- 10:10
Uh, it turns out if you do LoRA fine-tuning, which a lot of folks do, uh, you can do, uh, s- smart tricks and deploy multiple LoRA models on the same GPU, uh, actually thousands of them, which means that we can give you still serverless inference with paying for, per token, even if you have like thousands of m-
- 10:26
uh, model variants, uh, sitting and deployed there without having to pay any fixed cost.
- 10:33
Of, of course, single model is all great, uh, but what we see increasingly more and more in applications is model is not the product, right, uh, uh, by itself.
- 10:43
You need a kind of bigger system, uh, in order to solve target application. And the reason for that is because, uh, models by themselves tend to hallucinate, so you need some grounding, and that's where like RAG or a- access to external, uh, knowledge bases comes in.
- 10:57
Uh, also, we don't have, you know, yet an industry magical multimodal, uh, AI across all the modalities, so often you have to kind of chain multiple types of models.
- 11:07
And of course, you have all these like external tools and external actions which, uh, uh, kind of end-to-end applications might want to do in agentic form. Uh, so I think the term which I really like, which was basically popularized by Databricks, is like compound AI system.
- 11:22
But basically, re- increasingly seeing like transition from just the model being the product to kind of this combination of maybe like RAG and function calling and external tools, et cetera, built together as the product, and that's pretty much the direction which we kind of see, uh, th-this field mo- uh, moving along, uh, o- o- over time.
- 11:40
So what does it mean from, uh, from kind of our perspective, what we, what we do in this case? Uh, so, uh, we see kind of as a function calling like agent as a, at the core of this, uh, emerging architecture, which might be connected to either domain specialized, uh, models, uh, uh, se- served on our platform
- 11:58
di- directly or maybe tuned for partic- different needs, and connected to external tools, uh, maybe it's a code interpreter or maybe it's like external APIs somewhere, uh, with really like this kind of central agentic, uh, view, uh, kind of central, central model kind of coordinating and trying to triage the, uh, user, user requirements if it's, for example,
- 12:17
a chatbot or something. Uh, you probably all, uh, heard about like function calling, you know, popularized by OpenAI initially. That's, uh, that's basically the same idea. Uh, so yeah, the function calling is really like a how to- How to connect, uh, LLM to external tools and exter- and, and external elements.
- 12:36
What does it mean in practice? So we actually, uh, uh, fo- focus on fine-tuning models specifically for function calling. So we released a series of models like that, like the latest one, FireFunction, which was released two, uh, two weeks ago.
- 12:48
And, uh, what you can do with that is, uh... Oh. Okay, if I manage to click.
- 12:57
If I manage to click on this button. [laughs]
- 12:59
Uh, w- what it means is, like, you can build, uh, applications which kind of combine freeform general chat, uh, capabilities with function calling. So in this case, uh, this is, you know, this FireFunction has some, uh, chat capabilities.
- 13:13
So you can see, you can, like, ask it what, what you can you do, and it has, like, some self-reflection to tell you what it can do. It's also connected in this demo app to a bunch of, uh, external tools.
- 13:22
So it can, uh, query, uh, like, stock quotes. It can plot some charts, all those, like, external APIs. Uh, it can, um, also gener- gen- generate images. But what it really needs to figure out is how to translate user query into, do complex reasoning, translate it into function calls.
- 13:40
So for example, if you ask it to generate a bar chart with top three, uh, like with stocks of top cloud providers, like the Big Three, it actually needs to do several steps, right?
- 13:51
It needs to understand that, like, top three cloud providers means, you know, AWS, GCP, and, uh, and Azure, right? And Azure is o- owned by Microsoft. It needs to, uh, then go do function calls querying their stock prices.
- 14:04
And finally, it needs to combine those information and send it to chat plotting API, which is what just happened, uh, in the, in the background. Uh, another important aspect which you have to do for, like, ef- efficient, uh, kind of function calling chat capabilities, you need to have contextual awareness.
- 14:20
So if I ask it to add particular, uh, if I ask it to add Oracle to this graph, it needs to understand what I'm referring to and, like, still keeps the previous context and regenerates the image.
- 14:30
And finally, you know, if I switch to a partic- to a different topic, it kind of needs to drop the previous context and understands that, like, "Hey, this is less, uh, this historical context is less important.
- 14:40
I'm gonna start from scratch." So there is no, like, Oracle in that cat photo or whatever. Uh, so you know, this particular demo is, uh, is, is actually open source.
- 14:48
You can, like, go to our GitHub and try it out. It's built with FireFunction, and it builds with, like, a few other mo- a few other models, including, like, SDXL, which are run on our platform.
- 14:58
Uh, the model itself for function calling is actually open source. Uh, it's on Hugging Face. I mean, you can of course call it on, uh, at, at Fireworks with, for optimal speeds, but you can also, uh, run it locally if you want.
- 15:09
It uses a bunch of, uh, you know, functionality on our platform. Uh, for example, like structure generation, uh, with, like, uh, with JSON model grammar mode, which I think was similar to some of the previous talks from, like, outline guys, uh, which were talking here yesterday.
- 15:25
Uh, yeah, so finally, try, try it out. And generally, like, how to get started on Fireworks. So if you head, head out to fireworksai.models, you'll, uh, you'll find a lot of, uh, open, open source, open base models, which I mentioned about.
- 15:38
They're available in the playground. In terms of product offering, uh, we have this kind of range which can take you from early prototyping all the way to enterprise scale.
- 15:47
So you can start with serverless inference, which is, you know, not different from, uh, getting to OpenAI Pi- uh, OpenAI playground or something, where you pay per token. Uh, it's a constant price.
- 15:57
You don't need to worry about, like, hardware settings or anything. As I mentioned, you can still do fine-tune in, so you can, uh, you can do hosted fine-tune on our platform.
- 16:05
You can bring your own LoRA adapter and still serve it serverless. As you kind of graduate to, like, maybe, like, a startup, and you graduate to, uh, more production scale, uh, you might want to go to on-demand, where it, where it's more, like, dedicated hardware with more settings and modifications, uh, for your use case.
- 16:20
Uh, you can bring your own custom model fine-tuned from scratch or do it on our platform. And finally, as you kind of, if you scale up, uh, to bigger volume and want to go to enterpr- enterpr- enterprise level, where it's kind of discounted long-term, uh, long-term contracts, and we also will help you to kind of personalize hardware
- 16:37
setup and do some of those tuning, uh, for performance, which I, uh, which I talked about earlier. And in terms of use cases, I mean, we're running production for m- uh, for many, many companies, ranging from small startups to big enterprises.
- 16:50
We're serving, like, last time I checked, like, more than 150 billion tokens per day. So, you know, companies like Quora built chatbots like Poe. Uh, Sourcegraph and Coursera, which I think, I think Coursera had a talk here yesterday.
- 17:03
They use us for, like, some of their code assistant functionality, and their, like, latency is really important. Uh, as you can imagine, you know, folks like Upstage and Liner are building, like, different assistants and agents, uh, on top of that.
- 17:15
So, uh, we are definitely production ready. Go try, try it out. Uh, finally, we care a lot about developers, you, uh, you guys. Um, so actually, this is external numbers from, uh, like, last year, LangChain State of AI stuff, where turns out we are one of the, like, a- after Hugging Face, the most popular platform for where
- 17:34
people pull models, which is great. Which is very, was very nice to, uh, nice to hear. And again, for, like, for getting started, just, uh, you know, head out to, uh, head out to our website.
- 17:44
You can go in the, go play in the playground, uh, right away. So for example, you can run, you know, Llama or Gemma or whatever at the, at the top speeds.
- 17:53
Um, and kind of go start building from there. I'm really excited to see what you can build with open models of FireFunction or some stuff which you can, uh, which you can fine-tune on, uh, on your own.
- 18:04
And yeah, last point, we are, as I mentioned, OpenAI API compatible, so you can still use your, you know, your, your favorite tools, uh, the same clients, or you can use frameworks like LangChain or LlamaIndex or et cetera.
- 18:16
So yeah, really excited to, uh, to kind of, uh, to be here and talk, tell a little bit about open source, uh, open source models and how we at Fireworks are, uh, focusing on productionizing that and scaling it up.
- 18:30
Uh, go try it out, and you can also find us at the booth, uh, at the expo. Thank you. [upbeat music]