 At one time, we thought AI would be based on graph theory, or graph search and graph queries, and that didn't work out. But there's something to be said about graphs, is that they are the great equalizer. Graphs can always connect to each other, and that's super powerful. Welcome to Graph Geeks in Discussion. I'm Amy Hodler, joined today by NVIDIA Distinguished System Engineer, Joe Eaton, to explore how Rapids and KuGraph accelerate graph analytics. We'll also discuss their scaling of network acts on GPUs with zero code changes. And then we'll dive into current graph trends and their implications. Join us. So to get started, Joe, I'd really like to hear about how you ended up in the graph space and what you're working on at NVIDIA. Yeah, that goes way back. My first bump into graph theory and graph analytics was doing my PhD work. I worked in algebraic multigrid methods, which are basically graph theory applied to matrices for the sake of solving linear algebra equations. And it turned out that I needed some fundamental graph theory theorems to prove what I wanted to prove for my thesis. That's where I got kind of into it was into that and then later on I bumped into it in working in oil and reservoir simulation. So my PhD is in applied math and simulations and I was applying my application was oil and gas reservoir simulation which has a bunch of interconnected networks of piping and tubes making oil and gas flow. And you model those as graphs, of course, and then you solve the network flows to find out how much you can move. Then that evolved into even more abstract interest in the sense of machine learning. So machine learning tasks started to become hot and graphs, page rank, these kinds of things started to heat up. And so I was an adherent of the graphs as linear algebra kind of school of thought. So we started a package called NV Graph, which was NVIDIA's accelerated package for doing graph analytics using sparse linear algebra under the hood. And this was great for the people who liked it. They really liked it. But everyone complained about the same thing. How do you build a graph in the first place? How do I get my data into the form of a graph so i can do this cool graphic stuff and so that's where we kind of took a step back and we decided we needed to accelerate basic etl processing with things like pandas and pollers and that's where rapids got started was building up data processing for me, because I needed it to build graphs, bigger graphs and do more graphs stuff. So hold on a second here. So we went from linear algebra and topology, which is a really great, there's a lot of graphy people who start physics and mathematics. And then nvidia you mentioned rapids really briefly can you can you explain to me where the connection is between graphs and rapids sure yeah yeah so um rapids in the beginning was three separate packages that were all under the same umbrella. There was cu df cuda data frames which was a pandas mimic there's q ml which is scikit-learn with the cuda backend and then there's kugraph which was trying to be network x like we're trying to do a lot of the operations of network x and so that was the connection between them all they're They're all Python mimics. They're all trying to do Python stuff, but with CUDA acceleration behind the scenes. Okay. And that's where this ETL need that you were seeing also became folded in. Well, ETL was a fundamental need for graphs and it turns out for lots of other data clients also um and in fact qdf is much more popular than qgraph because it has more use cases than just grams um yeah but that my interest in it and my push for it was for my interest in building graphs from tabular data right there's lots of tabular data out there that look like a graph but there's graphs hiding in there that you can pull out yeah yeah absolutely so how does the rapids actually help accelerate etl for graphs because that i mean that's just a classic you know a problem with graphs in general it's like how do i get my how do i get my data into a green so so how does you know how does that help with that yes we start from the very beginning so you say you've got a bunch of data in a csv format right you dumped it out of a spreadsheet or you have a database somewhere you dumped out into csv format so how do i get that into a graph well first things first i need to read that format into memory so we have accelerated parallel readers that can read csv read json we can read json lines parquet orc all these different formats we can read off disk to get them into memory and then once they they're in that memory, we have data frame operations. So essentially we identify one column to be a source identifier, one column to be a destination identifier, and now you have an edge list. As soon as you can pick those two columns out of your data, you know, a from and a to, or send send and receive. Anytime you can identify those two columns in a set of tabular data, you can make a graph out of it by interpreting those as an edge list. And that's what we do. We typically take a data frame. We might join two data frames together. We build up our data set. we identify the features we want, and we'll identify what's my from and what's my to, what's my source and what's my destination. And then I can basically with one command, convert that entire data frame into a graph in kugraph. I say kugraph from data frame go, and it sucks in the data frame, interprets it as an edge list, and builds the graph from that edge list. Once you now get your data into a graph format, how is Cougraph different than other graph solutions out there? Yeah. The biggest one is we look like a Python library, and we behave like a Python library in that you just write Python code to use it. But under the covers, it's really a CUDA library. It runs on a GPU. Typical graph operations that may be slow, community detection between the centrality. PageRank is not that slow, but these things tend to run 100, 200 times faster on a GPU because it's memory bound. And GPUs have really great memory bandwidth. So that's one of the things that makes Kudegraph stand out is when you get to a big enough graph, around a million edges, something like that, that's where NetworkX stops to be really useful. It starts to become too slow to be bearable and kubgraph has a network x like api so you can write the same code and then if you use kubgraph your million edge graph suddenly can run in seconds instead of an hour does that lead to different use cases in kubraph and maybe other solutions? I think it definitely tends, Kugraph tends to be used on the biggest problems. So if I have what I call internet scale graphs, say I'm a bank, right, and I've got a million customers, and I want to have a graph of all the transactions between those million customers, That's a case where Kugraph is really helpful. So yeah, Kugraph tends to be self-selected for people with the biggest graphs, the ones who gain the most from. And I would assume since it's part of the RAPIDS framework, you're also maybe more likely to have production where you're having to kind of get the whole workflow together. Is that? Yeah, that's another great thing that's different about Rapids is we're open source, but we're also enterprise class software. We run a lot of internal testing, a lot of regression testing, unit tests. We build nightlies where we run tens of thousands of tests every night to, to make sure the software is functioning correctly. Um, so you get fully kind of enterprise grade software and open source that that's, that's not easy to find, right? Um, free and enterprise grade don't often go together. Um, you know, you're depending on this for your business. We can offer support and give you technical support for RAPIDS. Just thinking about the acceleration and the way, you know, using GPUs, I think more analytics and data science than I do classic knowledge graph investigation where you might be looking for, you might be researching, you know, about customers or customer 360. Is that accurate that this would kind of shine more in the analytics space? That's exactly right. And that's a big distinction. We have to draw the line. We're not a database. We're not a graph database. We don't have a query language, such as Cypher that Neo4j has, or JQL, or there's Sparkle. There's a bunch of graph query languages. Coup Graph Rapids does not offer a query language. So if you need to write queries, and you want to write complex graph queries, we're not the one you should be talking to. There are great graph databases out there. So I'd point people, depending upon where they are in their graph scale, to different graph databases. I say, I can't help you with Cougar. Yeah. You know, the interesting thing that I've seen seen out there and i assume that you might be some of the same things is that there is no one graph solution for every problem um just not just like there's no one one table for every problem it's you know so you're seeing these things used in conjunction where you know maybe a seriously intense complex analytics algorithm that you're running nightly might be done in a different system than something that an end user investigative analyst might be running, you know, ad hoc. So ad hoc versus, you know, kind of this big. So one of the, I actually find it interesting that a lot of people are using multiple graph solutions. All the different things they can do, there's no such thing as one size fits all. Yeah. Yeah, absolutely. If wish that there were, right? If one solution could hit everything. Now, you mentioned a few minutes ago on NetworkX, and I know there is a NX or NetworkX accelerated option for Kugraph or with Kugraph. Tell me just a little bit more about that and in particular you mentioned scale which NetworkX hasn't been known for its scale. So just mentally how do you put those things together? How should we think about those together? This is kind of the realization of what we started on eight years ago with the very early beginnings of nx uh nv graph right um network x was always seen as the the lingua franca what most people that study graph analytics open to network x in class in in school but then you realize well i can't do really big graphs with network x but so why not right why do i have to throw out all everything i've learned because network x is too slow um nx code graph is we really wrote a glue layer and network x worked with us on this network NetworkX has now officially acknowledged a dispatch system that will allow NetworkX API to dispatch to backends that are optimized for different types of hardware. So they have, there's a GraphBlas backend. You've heard of the GraphBlas package? So they can now connect to a GraphBlas library. They can connect to Kugraph as an option. But NX Kugraph is just a layer that basically serves the dispatch needs that NetworkX connects to. So we are officially a backend behind NetworkX. We don't do everything NetworkX does because we don't need to, right? For simple toy problems that you're used to in class, whatever, NetworkX is perfectly fine. We don't need to replace that. But when you get to a certain scale, you're going to find that you want to, and there's one exception, I would say. We have one algorithm in Kugraph that doesn't exist in NetworkX. It's the lead in community detection algorithm. Nice. Good job. Yeah. So that's a very expensive algorithm to run and accelerate that. You can stay in NetworkX for all your graph construction, all your knowledge graph stuff. But then when you want to run lead, you pull in Kugraph. You can run it without changing any of your code and get an answer back much faster. I'm sorry. stuff. But then when you want to run, you pull in Kugraph, you can run it without changing any of your code and get an answer back much faster. Do you see people using NetworkX and Kugraph kind of in a hybrid fashion where you're doing some things in one and some things in another? Ideally, they don't need to know when they're flipping back flipping back and forth yeah i think you have to at least acknowledge you know tell the system somehow that you want to use a gpu that's the minimum effort you have to do and have a gpu in your system somewhere but other than that there's no difference in the code you write the apis are the same you You don't need to, for each operation, tell it, run this on the GPU. It's transparent. It will fit- no difference in the code you write the apis are the same you don't need to for each operation tell it run this on the gpu it's transparent uh it will feel just automatically does it if it's available and it's it's functioning and what kind of difference can people expect to see if they're running something uh you know just in network x maybe not on a gpu and then there's that capability there and it picks up yeah what you know what are we talking about as far as either performance or you know for some things it's really dramatic for the expensive operations so um personalized page rank eden algorithm louvain algorithm uh between the centrality in particular the the full between centrality scales like, you know, n cubed, I think, with a number of... Does anybody actually try to run that in the full? I've never seen it run well in the full version, the mathematical version, only heuristically. So, okay, and how is it that you're able to do that? What is it about, you know, running it on a Kugrav that allows it to have those kind of speeds up? What it is really, it comes down to bandwidth and effective use of the hardware. So I talked about sparse linear algebra, but what's different between sparse linear algebra and dense linear algebra is the access pattern in memory is random access. And when you're doing random access, you're going to get about 2% to 3% of your peak memory bandwidth. This is across all computers. They're not good at random access. But that's what graphs are doing. So if I've got a computer with a peak memory bandwidth of 100 gigabytes, the best I'm going to do is two or three gigabytes of actual throughput if i've got a gpu with a memory bandwidth in theory of two terabytes per second i'm going to get four gigabytes in effect so that is a thousand to one difference just how fast I can read data at random access speed. Yeah. And so if I were to, so if I'm understanding this correctly, I would guess that the algorithms that are iterative in nature are going to benefit the most from that kind of backup. Numbers are bottlenecked on the bandwidth. Exactly. Yeah. Numbers. If you have to pass over the data multiple times, yeah, iterative methods for the clients, which are things like PageRank, right? Louvain, yeah, Aden, between the centrality. These are doing searches many, many times across the graph. You're going to wind up touching every node in the graph multiple times before you get an answer. It'll be interesting to see what you find out with modularity algorithms in general because those tend to be, you know, they're iterating over and over again until they stop, which should be really fascinating just to study on that alone alone which is probably why leaden is working for you yeah we haven't actually did some new algorithms because of parallelism that's something that happens a lot is a textbook algorithm might be written to be serial of one step at a time sure and gpus don't do well with that i mean our clock speeds about one fifth the clock speed of a cpu so if we can only do one thing per clock cycle we're not going to do well we have to be able to do 10 000 things per clock cycle to get speed ups and we have to oftentimes slightly rewrite or rework an algorithm to make it more parallel and so we have some blue Luvane, we have a modified version of Luvane that has much more parallelism. We have a modified version of Liden, which is based on that Luvane, which again, admits much more parallel computation. That's interesting to think about what you are inventing with trying to take advantage of the parallelism, whether that will also help with like future hardware changes as well. I do believe that there's a lot of room for hardware acceleration of a lot of workloads that we do. And in particular in the graph space, if you compare, the more you can parallelize, you know, that's just more natural for how graphs operate as well. One of the most common patterns you see in graph algorithms is for each, right? For each vertex, for each edge. And that kind of screams out, this should be done in parallel. And so that kind of brings me to thinking a little bit about what's going on right now in this space. I have to ask about Gen.AI, it's just required now. It's like, and then we can talk about other future ideas as well, but how do you see Gen. AI impacting the graph market in a particular analytics? Yeah, great question. This is one of the hottest areas, of course, right? We're seeing graph, knowledge graphs in particular are very valuable when combined with language models. So one of the hottest things you've heard of this, of course, is GraphRag. So retrieval augmented generation with a knowledge graph in the mix. And we're seeing that before GraphRag, there was vector brag. Vector databases have made a big jump. They're the first to get in there. They're the first ones to make a big improvement. We're finding that adding graphs on top of the vector database gives even more improvement. So the biggest complaint about Gen AI is the hallucination problem, right? That's the killer Achilles heel. And so looking at evaluations with graphs, knowledge graphs, backing up a Gen AI model, the hallucination rates drop, you know, factors of two or three on after you've already done vector, you know, vector enrichment. So it's, I think it's going to be essential to have a knowledge graph connected to a language model in the future. That's the only way we're going to keep them pinned down to reality. And that's, that's why I see it. It's blowing up right now. This is absolutely blowing up. Every language model is trying to connect back to knowledge graphs. But is that impacting either directions or things that you're thinking about? Absolutely, yeah. We're seeing bigger demand for dynamic graphs. So we want to be able to build them on the fly. As soon as we receive new information, I want to bring it into my graph and make it available to my language model. So I want to have a graph that is persistent, that is dynamic. I want to modes multiple modalities is important so i may have a knowledge graph based on people i may have a knowledge graph based on movies i may have a knowledge graph based on music all of these have to be available and in the mix depending upon my use case um but yeah we're getting pushed a lot toward persistent dynamic graphs as the future for this. So on the fly graphs is an interesting topic. And also if we're talking about difficulties of ETL to begin with, that is another area where not only do we have to have the framework set up, but how do do you how do you capture the the changes as as you go and i i want to circle back to something i think we've talked about in in other conversations uh what you're working on right now in your work in gnn's so so can you tell us a little bit about how that is related to a koo graph graph analytics knowledge graphs because sometimes it can be a little fuzzy of like what, you know, what, what area are we talking about? I'm the lead on graph neural networks at NVIDIA. So I'm trying to guide about five different teams that we have working on this. There's applications all over the place, right? So graph neural networks are most valuable when the patterns of relationships in the graph or some graph representation can be a deciding factor in a decision you want to make. So say fraud detection. If I'm a bank and I have a customer who's coming and wants to borrow money or wants to transact with another customer through an anonymous service. I'm very concerned about who these entities are. So entity resolution, we talked briefly about entity resolution previously. Graphic neural networks help tremendously in entity resolution because what is a person's identity? You can claim that their identity is their relationships, who they interact with, what their job is, right? What their behaviors are. So graphs can capture those kind of aspects and those patterns are very distinctive between individuals. So that's one really huge application is entity resolution. Another one, we talked about fraud detection. Once you've resolved the entities, it's much easier to understand the behaviors. So is this person being dishonest or is this software package, a malware package attempting to invade my network. So it comes up in cybersecurity, financial services. It comes up in recommender systems, link prediction. Will this customer purchase this product? And all of these have a common underpinning of graph network embeddings. We use the graph neural networks, not naked, but to provide vector space embeddings for other models. And that seems to be the way these are gaining traction. By adding neural network embeddings into existing models, we're seeing big jumps in accuracy, about 10, 15% improvements in accuracy by adding the neural network, graph neural network embeddings into vector spaces as features. So these vectors become features in classifiers, in anomaly detection, and when you add in the temporal aspect, you have a temporal graph neural network, they become even stronger. So this is kind of the big reason they're getting a lot of attention. A lot of 1% difference in fraud detection for a bank could be a million dollars a month. You know, this is big money. They don't ignore these things things so they're jumping on this so so if i am a current knowledge graph user uh maybe you know maybe i have a patient knowledge graph or a chemistry knowledge graph maybe something we'll do drug repurposing or something like that but that's like example how should i think about that information differently than a graph neural network and what I might use a graph neural network for? So one where a human is querying it and another where you're actually pumping it in and looking at, you know, the graph embedding space. How do those two work together? There is an overlap. They're distinctive in, I would say, how a human interacts with them. You know, the graph embedding graph neural network stuff tends to be larger scale things that are bulk. You know, every transaction this bank has done for the last year, that's not something human can get their head around easily. That's something that is very useful for graph neural network embedding, generate embeddings for that. On knowledge graphs, knowledge graphs tend to be very rich. They're able to closely represent reality. So if I'm talking about bio, you know, gene interactions, say in genomics, or I'm talking about chemical interactions between enzymes, or small molecule interactions for drug discovery. Those things are small but dense, very rich graphs with a lot of meaning where human can have a lot of impact by being clever, right? A little human cleverness in writing a query or a way to follow a pathway through a graph can have a big impact, where these other applications, the big scale graph neural applications tend to be more brute force type things. I'm just going to scoop up all the data and beat it to death. That's one big difference. Yeah. So just be nice to your data, please. But I think that's an important distinction. It's interesting. I've been wondering, as I'm watching different research come out on GNNs and knowledge graphs, it's starting to see, you know, more and more overlap or kind of this two spaces starting to touch each other on the edges. And that's an interesting area to just, for me to kind of watch where the space might be going. I don't know if you have any insights or thoughts on like where that's headed. So one of the areas we're getting big, well, a lot of effort is going into this area right now. It's video semantic search. So say I've got 100 hours of video, and I want to be able to query that video and ask it questions like, you know, how many times did this vehicle come into this loading dock? That's something that, believe it or not, the best answer is to build a knowledge graph by studying the video with computer vision and reading license plates or reading, doing entity resolution on the things you see in the video, building a knowledge graph, and then being able to query that knowledge graph to answer your question is like the direct route to get answers. So that's an area where it's a new application that that wasn't possible before before we had these computer vision models that could you know understand pixels the way we do with our eyes um and it's enabled by knowledge graphs and these are the cases where building the graph on the fly really matters if i have 100 cameras around a warehouse i want to be up to the minute on where are the vehicles around the warehouse, where are the people interacting with vehicles. If there's an accident, I want to have emergency people called in as soon as possible. And that requires having a graph live, up to date, in the mix. And it has to be a rich knowledge graph that understands the complexity of the environment i've had many conversations about graphs that are good for different things graphs that are good for humans to interact with graphs that are better for enforcing um inference rules graphs that are better for talking to the machines and i think as we start to see these different graphs that have different specialties, start to elaborate more and touch each other more, just the combined capability is potentially stunning. I think this is underappreciated. It was one of the promises of graph analytics 10 years ago, right? You can consider graphs to be one of the AI things that never made the cut. And we thought AI would be based on graph theory or graph search and graph queries, and that didn't work out. But there's something to be said about graphs is that they are the great equalizer. Graphs can always connect to each other. And that's super powerful. Thank you. But there's something to be said about graphs, is that they are the great equalizer. Graphs can always connect to each other. And that's super powerful. That's... I have this urge to say, we're not done yet. You never know. We may end up with the graph as the abstracted layer that connects. I think it would be a key component. We're seeing that with frank already that graphs are a key component of ai um not everything but they're important and indispensable right if you want to have reliable ai i want to make sure that we get to um gtc which is coming up what should we watch out for what are the what are the what are the sessions that our graph enthusiasts should be attending? That's a great question. We're definitely going to have some talks about the visual semantic search. That's one that I recommend people go see. We're going to have some talks on combining graphs with retriever, the retrieval augmented generation, graph rag, general, a few talks on that. There'll be some talks on large-scale graph for fraud detection. That's, of course, big money. Some of the banks will be involved there. I would say those are going to be the top headliners. We talked about Rapids quite a bit, Kugraph, NX Kugraph. Are there things that people can use if they're just getting started? Sure. I'll recommend rapids.ai as the website to get started on. You can go there and there's a Kugraph directory. There's a Kugaf data directory. There's Jupyter notebooks. We have examples in the form of Jupyter notebooks that are designed to get started with. They have little built-in data sets. You can open them up, play with the models, see how they perform. And generally, we try to do, what if you didn't have a GPU? What would it look like? And then here's what it looks like when you do it. So it illuminates, like, what are GPUs bringing to this? So it's easy to get started with your gaming GPU, and that works just fine, but it won't have much horsepower as a data center GPU that you might find on Amazon. So AWS could rent you an H100 for $5 an hour. And if you're not ready to use that, don't pay for that. Most people have a GPU and a gaming laptop or a desktop. Yeah. And so it's easy to try it out. You're not going to get the best possible performance, but you're learning. That's the point is to learn and explore. We also have a pure fall through API now where even if you don't have a GPU at all, things will work. Right. So we won't fail if you don't have a GPU. It just falls back to standard pandas on the backend or pollers. If you want to use the pollers API, that falls back to the old standard CPU-based pollers library. So that's what we're trying to do is make it harder and harder for people to fail. That's not easy to do, but that's what we're trying to do. I'm convinced I can break anything, but I like the idea that if, if I can get something to work, you know, with what I have that I can get that going and then just port it over, you know, when I'm ready for something more robust, because that's always, it's that, you know, getting started. That's always, you know, it's always a difficult part. Yeah. That was exactly the plan from the get-go was we wanted to enable people to use their commercial consumer-grade GPUs, right, for gaming or whatnot. That they're just lying around, right? Why not play with it? Try something else. Start there and graduate up as they get better skills and bigger data sets to these bigger GPUs that cost a lot more. But don't jump in right away. Start with stuff. So we've talked about a lot of different things. What haven't I asked? Or is there anything else that you would like to share or that you get asked all the time? A lot of the times I get asked, you know, how do we make things run cheaper? GPUs are great, but they're too expensive, right? That's what I get asked a lot. Because the GPUs are able to crunch the numbers so much faster, even if you're paying, say, 5x more to rent a GPU on Amazon than you would to rent a pure CPU node, you're going to get your job done 100 times faster. So on net, you're going to actually save money for renting that GPU versus the cost of running the same job without the GPU. That's one answer. Another answer is keep trying. There's lots of clouds out there, and they're popping up all over the place now for AI purposes. You can rent GPUs on almost every continent in the world now. There's East Coast, West Coast of the United States, South America, Europe. If you keep trying a Google GCP, they have a playground where they would give you a GPU for free, but you couldn't determine what you were gonna to get um even they're adding more gpus all the time so previously you could go and you'd only get a gpu maybe one time out of five now i think it's more like four times out of five so i think it's becoming much easier to find access to gpus in the cloud than it was even two years ago. Awesome. So one more question. Any hackathons or anything in the graphy space coming up that we should watch out for? Well, I know we're doing a lot of work around agentic AI. If that's another topic, of course, there's a lot of hackathons cons happening there we're doing a lot of work in this um frag space those things i would look out for i'm not in charge of those things but they're on the calendars and we we do broadcast when they're going to happen awesome so so definitely watch out for those i we all love a good hackathon so we'll definitely take a look for those. And I'm looking forward to GTC coming up and anything I can't attend, maybe watching afterwards. And then just talking to you again later, Joe, it'd just be great to keep in touch and keep the conversation. There's gonna be a lot of announcements at GTC. There's, every year, there's a flood of announcements. I just booked my airline tickets to go out there today. So I'll be there in person and hopefully we can all, yeah, catch up afterwards. That sounds wonderful. All right. Thank you again, Joe.
GraphGeeks In Discussion: RAPIDS and cuGraph with NVIDIA's Joe Eaton
This podcast episode features host Amy Hodler in conversation with Joe Eaton, NVIDIA Distinguished System Engineer, discussing graph analytics acceleration technologies. This discussion covered:
- How RAPIDS and cuGraph are changing graph analytics through GPU acceleration
- Their innovative approach to scaling NetworkX on GPUs without requiring code modifications
- An exploration of GNNs, graph embeddings, and vector search applications

We also looked at current trends in graph technology and their real-world implications. Joe provided pointers to resources (below) for people just getting started as well as his picks for exciting graph-related talk at the upcoming NVIDIA GTC conference.

Getting Started with RAPIDS and cuGraph
https://rapids.ai/
https://github.com/rapidsai
https://rapids.ai/nx-cugraph/

Graph Talks at GTC
https://nvda.ws/4bofZ4e 
RAPIDS in 2025: Accelerated Data Science Everywhere [S73290]: https://www.nvidia.com/gtc/session-catalog/?regcode=ref-inor-862057&ncid=ref-inor-862057&tab.catalogallsessionstab=16566177511100015Kus&search=S73290#/session/1728323939538001F71p
HybridRAG: Make RAG More Accurate by Combining Graph and Vector-Based Retrieval [CWE72566]: https://www.nvidia.com/gtc/session-catalog/?regcode=ref-inor-862057&ncid=ref-inor-862057&tab.catalogallsessionstab=16566177511100015Kus&search=CWE72566#/session/1727449059487001PWqT
Building Semantic Search and Data Mining Applications With GPU-Accelerated Vector Search [CWE71289]: 
https://www.nvidia.com/gtc/session-catalog/?regcode=ref-inor-862057&ncid=ref-inor-862057&tab.catalogallsessionstab=16566177511100015Kus&search=CWE71289#/session/1725505570355001Yi6d