Hello everyone. It's great to see everyone here, and we are going to have a wonderful conversation with Zane Askar, who is CEO of Gimlet Labs. Quick intro to myself: I'm Sid Sheth, founder and CEO of D-Matrix. So we build inference computing chips, and we are very excited to be in a partnership with Zane and his team at Gimlet, and he'll tell you all about what he's doing.
But you know, quick intro to Zane. Zane has been, you know, obviously has been founder and CEO of Gimlet Labs, and the company has raised close to $80 million in a Series A round led by Menlo Ventures. They're building what is most likely the industry's first multi-silicon inferencing cloud.
Zane is a repeat entrepreneur. He did a company called Pixie Labs in the past, which was acquired by New Relic. Zane, your resume is so impressive. Every time I read it, I'm like, 'Wow, this guy's done so much.' He was a professor of computer science at Stanford. He was at Nvidia as an architect, was an engineering lead at Google, and was also an entrepreneur in residence at Benchmark Capital before starting Pixie Labs.
Super excited to have him here, and we're going to start with a few questions for Zane. Zane, any comments you want to make before we get started?
Yeah. Thanks for the really kind introduction, and thank you everyone for being here. This event's been pretty big. It's actually my first time at Raise, but it's been pretty good to see everybody here and also meet a bunch of folks and have a lot of interesting conversations.
So let's get started. I think there's lots of exciting stuff to cover, and we only have 20 minutes. So, you know, the first thing, I think the best place to start is for Zane to explain to all of us what does Gimlet do? And you know, they're doing something very unique. When I talked about multi-silicon inferencing cloud, that is a new hot trend in the market. So maybe Zane, if you can explain to us and tell us a little bit about how Gimlet got started and what the vision is and what you do.
Yeah, so Gimlet's always had this goal of basically making inference workloads about 10 times more efficient. And we have a pretty unique way of doing that. And unique doesn't always necessarily mean good, but we think our approach is like pretty interesting and actually scalable for the industry. Where we kind of started as a, we started realizing that in a lot of AI inferencing workloads, there's a fair amount of diversity. And this actually increases with like agentic workloads, where you have like, you know, tool calls, other things happening, CPU workloads happening.
And we basically built a system where we can absorb these workloads, partition them into small fine-grained components, and then allocate these different components to different types of hardware, right? And we usually say it's multi-silicon because we typically allocate the workloads to different types of chips. And you know, some of them might be CPU workloads, some of them might be on GPU, some of them might be on like neo accelerators like, you know, D-Matrix or Cerebras or even like something like an LPX, where we can basically utilize the differences between the hardware to drive best-in-class performance.
And that's really the unique value proposition of Gimlet is that, you know, we're truly multi-silicon. We don't just run on things like, you know, here's like a Nvidia deployment and here's like an AMD deployment, route between those two. We take a workload, decompose it into the granular components, and even like individual models and even layers within an individual model and run it on different types of hardware.
One intuition for this is that, you know, if you had like a Ferrari and like a minivan or something, you probably would not necessarily want to drive your Ferrari to the grocery store to go grocery shopping, but it does have like use cases. So you want to try to figure out when you need the performance and when you don't, and try to allocate the right workload to the right hardware.
So Zane, maybe tell us a little bit about like what, you know, you guys started Gimlet, there was things happening in the industry at the time, especially in 2025, that makes this, you know, very relevant for what you guys are doing today. What was the impetus? I mean, what did you see and what did you and the team see, you know, before you kind of went down this path?
Yeah, so when we originally started Gimlet, we were actually thinking about how we can even put workloads on, you know, very heterogeneous hardware. Like how do we actually put parts of our models on like laptops and cell phones and really like distribute things out. So we got particularly good at figuring out how to distribute workloads to different target hardware, especially hardware that's not very homogeneous and, you know, it doesn't completely look like a GPU.
And there are kind of like a couple of different trends that pushed us into scaling this out on the data center side. I think one of the things is there's like this pretty strong like scarcity of resources on the data center side. And we actually increased not only the available types of chips we can use, but also improve the efficiency, right? So you got this like double effect where not only can we use more silicon, but we actually use the silicon more efficiently. So you ultimately get a lot more capacity.
And based on, you know, we can go check out our blogs where we actually talk a lot about these results. We can usually push like the capacity for the same cost by about like 4x or 5x, and then actually push the performance, which is basically like how interactive it is for a specific user, by about a similar amount of like 4 to 5x.
And any specific applications that come to mind? Like where are you seeing pull from your end customers? What kind of applications are they trying to accelerate to take advantage of this?
Yeah, so the main use cases we're targeting are actually for like coding agents because that's where like people are like in the loop, so that, you know, actually delivering a faster experience is, you know, like an order of magnitude change for just like people's like development workflows. I'm an engineer myself and sometimes like, I know this is actually not true, but when I'm like using some coding agent, I'm like I could literally type out this code faster because I'm like seeing it, you know, generate the code.
And it's like actually a very annoying experience, but if everything was instant, you can kind of like work as fast as like you can think through about what the implications are and what you're trying to do and just iterate a lot faster. And for me like, you know, I fundamentally view coding agents as a tool where I want to experiment new ideas as quickly as possible, and that's actually an area where we think like pushing performance while maintaining like a reasonable efficiency is actually pretty game-changing for the industry.
Is the plan at some point to actually have a small installation of Gimlet orchestrated multi-silicon hardware and then you can actually use coding on top of it and have the Gimlet team actually use it and try it out? Have you already done that or is that something in the works?
Yeah, so we use frontier models for a lot of our coding stuff, but some of our more proprietary things we actually run our own coding agents and models internally because we can't use any other frontier ones, and we run it on top of our own stack.
That's excellent. You know, the other thing is obviously hardware is hot again. You know, there's numerous different types of startups that are all building AI chips with different strengths, you know, emphasis on different areas. How do you decide whom to partner with based on the types of problems that you guys are trying to solve? And what is the best way for an AI chip company to partner with, you know, Gimlet?
Yeah, so I think to answer that question maybe it's, you know, kind of important to maybe dive in a little bit more on the technical details and understand what we're trying to optimize. And realistically what we're trying to do is that, you know, at a high level when you take a look at most hardware, there's like different types of tradeoffs you can make, right? Like you can make a trade-off between how much compute you have on a chip, you can trade-off like how much memory bandwidth you have available. This could be memory bandwidth to like external memory or even memory bandwidth to internal memory. And, you know, how much like networking you have available and what the memory capacity is.
You know, there's a few other things to look at, but ultimately you can say that, oh, there's like a cost for like a dollars per like gigaflop or teraflop or whatever your metric is, or dollars per, you know, gigabyte per second of memory bandwidth. And if you take a look at like most like traditional architectures, they pretty much bring in all the memory through the, you know, chip's external interface.
So if you take a, if you think about like a particular chip and how the memory comes in, what typically happens is that the compute will scale as like the area. So it'll be like the side squared. So it'll scale pretty rapidly, whereas like the memory will not scale very efficiently, right? Because it's coming in through the perimeter. So perimeter is linear, area is quadratic. Those things are going to get further and further apart as chips get bigger.
So what we fundamentally do is actually try to figure out how to use that trade-off across different types of architectures to be able to balance like memory bound versus compute bound workloads. And typically if you like think about like a spectrum, something like a GPU typically has a lot of external memory, but the bandwidth is, you know, pretty low relatively speaking. Whereas something like, you know, more of like an SRAM-centric chip, like D-Matrix or Cerebras or LPX, they have a lot of memory bandwidth, but it's usually pretty limited by how much they can fit on a single chip.
So, you know, it creates this like trade-off where we have to like really understand how to allocate the workloads to different pieces of hardware so we can utilize the high memory bandwidth without like losing the efficiency of compute. And what Gimlet does is like we basically take these workloads, split them up, and then run them on these different pieces of target hardware so that we can get the maximum efficiency.
Yeah, I think that memory bandwidth piece obviously is super critical. You know, I was in my fireside chat just about less than an hour back and we talked exactly about, you know, what are the different options we have available to, you know, work on that. And at D-Matrix we're taking this approach where we stack memory directly on top of compute, so instead of relying on the perimeter of the chip, we kind of rely on the surface area
