[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-nvidia-research-gpu-template-en":3,"article-related-nvidia-research-gpu-template-en":30,"series-tools-2e2f6903-c431-447c-9bd6-cb6a4e3534a5":84},{"id":4,"slug":5,"title":6,"content":7,"summary":8,"source":9,"source_url":10,"author":11,"image_url":12,"cover_image":12,"category":13,"language":14,"translated_content":11,"related_article_id":15,"keywords":16,"key_takeaways":22,"views":26,"created_at":27,"published_at":28,"topic_cluster_id":29},"2e2f6903-c431-447c-9bd6-cb6a4e3534a5","nvidia-research-gpu-template-en","NVIDIA research turns GPU docs into a template","\u003Cp data-speakable=\"summary\">I break down \u003Ca href=\"\u002Ftag\u002Fnvidia\">NVIDIA\u003C\u002Fa>’s research page into a practical template for finding \u003Ca href=\"\u002Ftag\u002Fgpu\">GPU\u003C\u002Fa> tools, projects, and docs fast.\u003C\u002Fp>\u003Cp>I’ve been digging through NVIDIA’s research pages for a while, and honestly, they always felt like a pile of promising names with no obvious path through them. One minute I’m looking for a research project, the next I’m knee-deep in product marketing, platform names, and half a dozen tool families that all sound like they should mean the same thing. It’s not that the page is empty. It’s the opposite. It’s overloaded.\u003C\u002Fp>\u003Cp>That overload is the problem. If I want to understand what NVIDIA is actually building, I need to separate “research output,” “developer tool,” “platform,” and “product pitch.” The page mixes all four. So I started treating it like a taxonomy problem instead of a homepage problem. Once I did that, the structure became useful instead of annoying.\u003C\u002Fp>\u003Cp>What I’m doing here is not a summary of NVIDIA’s entire site. I’m pulling out the pattern I’d copy if I were building my own research or lab page: how to organize a huge technical portfolio so developers can find the thing they need without playing tab roulette.\u003C\u002Fp>\u003Cp>Source I’m working from: \u003Ca href=\"https:\u002F\u002Fwww.nvidia.com\u002Fen-us\u002Fresearch\u002F\">NVIDIA Research\u003C\u002Fa>. I’m also cross-referencing related NVIDIA docs like \u003Ca href=\"https:\u002F\u002Fdeveloper.nvidia.com\u002Fcuda-zone\">CUDA\u003C\u002Fa>, \u003Ca href=\"https:\u002F\u002Fdeveloper.nvidia.com\u002Fkaolin\">Kaolin\u003C\u002Fa>, \u003Ca href=\"https:\u002F\u002Fresearch.nvidia.com\u002Flabs\u002Ftoronto-ai\u002Fimaginaire\u002F\">Imaginaire\u003C\u002Fa>, and the \u003Ca href=\"https:\u002F\u002Fgithub.com\u002FNVlabs\">NVLabs GitHub org\u003C\u002Fa> so I can separate the real signals from the site chrome.\u003C\u002Fp>\u003Ch2>Stop reading the page like a brochure\u003C\u002Fh2>\u003Cblockquote>“Research at NVIDIA | Advancing the Latest Technology”\u003C\u002Fblockquote>\u003Cp>What this actually means is: the page is trying to do two jobs at once. It wants to be a research front door, and it wants to be a navigation layer for the entire NVIDIA ecosystem. Those are not the same thing. If I read it like a brochure, I get lost in the product list. If I read it like a map, I can sort the content into buckets and move on.\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780567411737-vw5o.png\" alt=\"NVIDIA research turns GPU docs into a template\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>I ran into this when I first tried to use NVIDIA’s research area to find concrete work instead of brand names. I kept bouncing between the homepage, developer pages, and lab pages because the page doesn’t politely say, “Here are the papers, here are the repos, here are the tools.” It says, “Here’s everything we do.” That’s useful only if I already know what I’m looking for.\u003C\u002Fp>\u003Cp>The first practical move is simple: don’t ask “what does NVIDIA research do?” Ask “what artifact am I trying to find?” Is it a paper, a repo, a SDK, a model, a \u003Ca href=\"\u002Ftag\u002Fbenchmark\">benchmark\u003C\u002Fa>, or a platform? That one question cuts through most of the noise.\u003C\u002Fp>\u003Cp>How to apply it: on any overloaded technical homepage, create your own top-level buckets before you click anything. I usually use five:\u003C\u002Fp>\u003Cul>\u003Cli>research papers and labs\u003C\u002Fli>\u003Cli>developer tools and SDKs\u003C\u002Fli>\u003Cli>models and demos\u003C\u002Fli>\u003Cli>platforms and infrastructure\u003C\u002Fli>\u003Cli>productized offerings\u003C\u002Fli>\u003C\u002Ful>\u003Cp>Once I do that, the page stops feeling random. It’s still dense, but at least it’s dense in a way I can index.\u003C\u002Fp>\u003Ch2>The real trick is separating labs from products\u003C\u002Fh2>\u003Cp>NVIDIA’s page throws around names like \u003Ca href=\"https:\u002F\u002Fdeveloper.nvidia.com\u002Fkaolin\">Kaolin\u003C\u002Fa>, \u003Ca href=\"https:\u002F\u002Fresearch.nvidia.com\u002Flabs\u002Ftoronto-ai\u002Fimaginaire\u002F\">Imaginaire\u003C\u002Fa>, and \u003Ca href=\"https:\u002F\u002Fdeveloper.nvidia.com\u002Fcuda-zone\">CUDA\u003C\u002Fa>. Those are not interchangeable, and that matters. Kaolin is a 3D deep learning library. Imaginaire is a research codebase for image and video synthesis. CUDA is the GPU programming platform underneath a lot of this whole stack.\u003C\u002Fp>\u003Cp>What this actually means is that one page is hosting multiple layers of abstraction. If I blur them together, I end up asking the wrong questions. I might expect a research repo to behave like a polished product, or I might expect a platform to read like a paper project. That’s where frustration starts.\u003C\u002Fp>\u003Cp>I’ve made this mistake in my own work. I once shipped a “research tools” page that listed internal libraries next to customer-facing features. People kept asking for docs that didn’t exist because I hadn’t labeled the boundary. The content was technically correct and practically useless. NVIDIA avoids that only partially here, because the page is still a giant directory, but the underlying lesson is the same: boundaries matter more than volume.\u003C\u002Fp>\u003Cp>How to apply it: label every item on your page with one of three tags:\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>Research\u003C\u002Fstrong> for papers, labs, experiments, and prototypes\u003C\u002Fli>\u003Cli>\u003Cstrong>Developer tool\u003C\u002Fstrong> for SDKs, repos, and APIs\u003C\u002Fli>\u003Cli>\u003Cstrong>Platform\u003C\u002Fstrong> for the underlying compute or infrastructure layer\u003C\u002Fli>\u003C\u002Ful>\u003Cp>If you want to be extra useful, add a fourth tag for “product.” That stops people from assuming a demo repo is a supported enterprise offering.\u003C\u002Fp>\u003Cp>This is boring work, and that’s exactly why it pays off. The less glamorous the taxonomy, the less time people waste guessing.\u003C\u002Fp>\u003Ch2>CUDA is the anchor, not the headline\u003C\u002Fh2>\u003Cp>On NVIDIA’s research and developer material, \u003Ca href=\"\u002Ftag\u002Fcuda\">CUDA\u003C\u002Fa> shows up as the base layer: a parallel computing platform and programming model for general computing on GPUs. That line matters more than the glossy project names because it explains the dependency chain. A lot of NVIDIA’s research output is interesting because CUDA makes it practical.\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780567403039-0rim.png\" alt=\"NVIDIA research turns GPU docs into a template\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>What this actually means is that CUDA is the anchor point for a huge amount of the site’s technical story. If I’m building a mental model of NVIDIA, I shouldn’t start with the newest AI demo. I should start with the compute model that makes the demos cheap enough to run and fast enough to matter.\u003C\u002Fp>\u003Cp>I ran into this when I tried to explain NVIDIA tooling to a teammate who only knew the company through AI headlines. He wanted the “best model” answer. What he actually needed was the “what runs where” answer. Once I showed him the CUDA layer, the rest of the stack stopped looking magical and started looking engineered. That’s the better mental model.\u003C\u002Fp>\u003Cp>How to apply it: if your own company has a foundational technology, stop hiding it behind feature pages. Put the base layer in plain sight. Then build the rest of the page as a set of dependent layers:\u003C\u002Fp>\u003Cul>\u003Cli>foundation\u003C\u002Fli>\u003Cli>developer primitives\u003C\u002Fli>\u003Cli>reference projects\u003C\u002Fli>\u003Cli>production products\u003C\u002Fli>\u003C\u002Ful>\u003Cp>That ordering helps developers understand where to start. It also keeps you from over-selling the shiny stuff before people know how the plumbing works.\u003C\u002Fp>\u003Cp>For reference, NVIDIA’s CUDA docs live at \u003Ca href=\"https:\u002F\u002Fdeveloper.nvidia.com\u002Fcuda-zone\">developer.nvidia.com\u002Fcuda-zone\u003C\u002Fa>. That’s the kind of link I want to see surfaced early, not buried under a wall of category names.\u003C\u002Fp>\u003Ch2>Project names are fine. Discovery is the actual job\u003C\u002Fh2>\u003Cp>Names like \u003Ca href=\"https:\u002F\u002Fresearch.nvidia.com\u002Flabs\u002Ftoronto-ai\u002Fimaginaire\u002F\">Imaginaire\u003C\u002Fa> and \u003Ca href=\"https:\u002F\u002Fdeveloper.nvidia.com\u002Fkaolin\">Kaolin\u003C\u002Fa> are memorable once you already know them. Before that, they’re just nouns. The page lists a lot of these names, but naming alone is not discovery. Discovery needs context: what it is, who it’s for, and what it replaces.\u003C\u002Fp>\u003Cp>What this actually means is that every project card should answer three questions immediately: “What problem does this solve?”, “What stack does it belong to?”, and “What do I do next?” If a page doesn’t answer those, people start googling, and then they leave your site to reconstruct your intent from \u003Ca href=\"\u002Ftag\u002Fgithub\">GitHub\u003C\u002Fa>, papers, and conference slides.\u003C\u002Fp>\u003Cp>I’ve had to clean up this exact mess in internal docs. We had a page full of clever project names, and everyone internally thought the names were self-explanatory. They weren’t. The first support question was always the same: “Okay, but is this a library, a demo, or a real dependency?” That’s the kind of ambiguity that makes developers distrust the whole page.\u003C\u002Fp>\u003Cp>How to apply it: for every project or tool, add a two-line structure:\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>One-line explanation\u003C\u002Fstrong>: what it does in plain English\u003C\u002Fli>\u003Cli>\u003Cstrong>Action link\u003C\u002Fstrong>: docs, repo, paper, or quickstart\u003C\u002Fli>\u003C\u002Ful>\u003Cp>Then add a “best for” line if you want to be especially helpful. Example: “Best for 3D deep learning workflows” or “Best for image synthesis research.”\u003C\u002Fp>\u003Cp>That’s not marketing copy. That’s navigation. There’s a difference, and developers can feel it instantly.\u003C\u002Fp>\u003Ch2>One page cannot do all the routing\u003C\u002Fh2>\u003Cp>NVIDIA’s main research page is packed with links into cloud services, data center platforms, embedded systems, gaming, networking, and software tools. That’s a lot of routing for one page. It tells me the page is acting like a switchboard, not a destination.\u003C\u002Fp>\u003Cp>What this actually means is that the homepage is doing too much work that should be delegated to subpages. If I’m designing this for actual humans, I’d keep the top page short and push the rest into dedicated landing pages by audience. Researchers do not need the same entry point as enterprise buyers. GPU developers do not need the same entry point as robotics teams.\u003C\u002Fp>\u003Cp>I’ve seen teams try to solve this by adding more links. That usually makes things worse. More links just means more choices, and more choices means more hesitation. The fix is not “more.” The fix is “better grouped.”\u003C\u002Fp>\u003Cp>How to apply it: split your technical site into audience-specific lanes:\u003C\u002Fp>\u003Cul>\u003Cli>research\u003C\u002Fli>\u003Cli>developer\u003C\u002Fli>\u003Cli>enterprise\u003C\u002Fli>\u003Cli>open source\u003C\u002Fli>\u003Cli>reference implementations\u003C\u002Fli>\u003C\u002Ful>\u003Cp>Then make the first click do real routing. Don’t make users scan 80 links and infer your org chart. That’s not helpful, and it’s not respectful of their time.\u003C\u002Fp>\u003Cp>For an example of how NVIDIA routes developers more directly, look at the \u003Ca href=\"https:\u002F\u002Fdeveloper.nvidia.com\u002F\">NVIDIA Developer\u003C\u002Fa> site and the \u003Ca href=\"https:\u002F\u002Fgithub.com\u002FNVlabs\">NVLabs GitHub org\u003C\u002Fa>. Those are much closer to the kind of entry points I’d recommend for people who already know what they want.\u003C\u002Fp>\u003Ch2>The hidden lesson is content architecture, not AI\u003C\u002Fh2>\u003Cp>It’s easy to look at NVIDIA’s research presence and reduce it to “AI company with a lot of GPUs.” That’s lazy. The more interesting story is content architecture. They’ve built a structure where research, tooling, and infrastructure all sit near each other, even if the page itself is messy.\u003C\u002Fp>\u003Cp>What this actually means is that the site is trying to express a full stack: ideas, code, compute, and deployment. That’s the part I care about as a developer. The value is not just in the individual projects. It’s in the way the projects connect to the underlying platform and then to actual usage.\u003C\u002Fp>\u003Cp>I like this lesson because it’s painfully transferable. If I’m building a docs portal, a lab page, or even a startup website, I need to show how the pieces connect. Otherwise everything feels like disconnected marketing tiles. And once a page feels like tiles, people stop reading it.\u003C\u002Fp>\u003Cp>How to apply it:\u003C\u002Fp>\u003Cul>\u003Cli>show the dependency chain from base tech to application\u003C\u002Fli>\u003Cli>use consistent labels across research and product pages\u003C\u002Fli>\u003Cli>make each section answer “why should I care?” without fluff\u003C\u002Fli>\u003C\u002Ful>\u003Cp>If you do that, your site becomes easier to scan and harder to misunderstand. That’s the whole job.\u003C\u002Fp>\u003Ch2>The template you can copy\u003C\u002Fh2>\u003Cpre>\u003Ccode># Technical research landing page template\n\n## Hero\n- One sentence: what this page helps people find\n- One short line: who it is for\n- One primary action: docs \u002F repo \u002F papers \u002F quickstart\n\n## Section 1: Foundation\n**Base technology**\n- What powers everything else\n- Link to the core platform\n- Explain the dependency in plain English\n\n## Section 2: Research outputs\n**Projects and labs**\n- Project name\n- One-line description\n- Best for\n- Link to paper or repo\n\n## Section 3: Developer tools\n**SDKs, APIs, libraries**\n- Tool name\n- What it does\n- How it connects to the foundation layer\n- Link to docs or quickstart\n\n## Section 4: Productized offerings\n**Supported products and services**\n- Product name\n- Who it is for\n- What problem it solves\n- Link to sales or product docs\n\n## Section 5: Audience routing\n**Choose your path**\n- Researchers\n- Developers\n- Enterprise teams\n- Open source contributors\n\n## Copy block for each item\n### [Name]\n[Plain-English description]\n\n**Best for:** [audience]\n**Starts with:** [paper \u002F repo \u002F docs \u002F demo]\n**Depends on:** [foundation tech]\n**Next step:** [single link]\n\n## Rules\n- Do not mix research and product without labels\n- Do not use clever names without a plain-English explanation\n- Do not make users guess the next click\n- Put the foundation layer first\n- Keep every card to two lines or less\n\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>This is the structure I’d use if I were rebuilding NVIDIA’s research page for developers instead of for internal navigation. It’s not fancy. That’s the point. Fancy pages are easy to admire and annoying to use.\u003C\u002Fp>\u003Cp>If I were applying this to my own team, I’d start with the ugly inventory first: every project, tool, repo, paper, and product in one spreadsheet. Then I’d tag each item by layer and audience. After that, the page writes itself. Or at least it stops fighting back.\u003C\u002Fp>\u003Cp>Original source: \u003Ca href=\"https:\u002F\u002Fwww.nvidia.com\u002Fen-us\u002Fresearch\u002F\">https:\u002F\u002Fwww.nvidia.com\u002Fen-us\u002Fresearch\u002F\u003C\u002Fa>. The breakdown and template above are my own synthesis, not an official NVIDIA structure, though I used NVIDIA’s public research and developer pages as reference points.\u003C\u002Fp>","I break down NVIDIA’s research page into a practical template for finding GPU tools, projects, and docs fast.","www.nvidia.com","https:\u002F\u002Fwww.nvidia.com\u002Fen-us\u002Fresearch\u002F",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780567411737-vw5o.png","tools","en","1a92ac0a-75ea-4877-874d-4a309cd0085b",[17,18,19,20,21],"NVIDIA","CUDA","research","developer tools","content architecture",[23,24,25],"Separate research, tools, platforms, and products before you write the page.","Use the foundation layer first so developers understand the dependency chain.","Make every project card answer what it is, who it is for, and what to do next.",0,"2026-06-04T10:02:58.56908+00:00","2026-06-04T10:02:58.555+00:00","a7343b93-37cc-4634-a2bc-707f6275bdb6",{"tags":31,"relatedLang":43,"relatedPosts":47},[32,34,37,39,41],{"name":33,"slug":19},"Research",{"name":35,"slug":36},"Nvidia","nvidia",{"name":18,"slug":38},"cuda",{"name":20,"slug":40},"developer-tools",{"name":21,"slug":42},"content-architecture",{"id":15,"slug":44,"title":45,"language":46},"nvidia-research-gpu-template-zh","NVIDIA 研究頁把 GPU 資源變模板","zh",[48,54,60,66,72,78],{"id":49,"slug":50,"title":51,"cover_image":52,"image_url":52,"created_at":53,"category":13},"e66cde5d-1c33-4efa-8f2b-09fb8b19d184","claude-partner-network-learning-path-launches-en","Claude Partner Network Learning Path launches","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780578178350-y5ya.png","2026-06-04T13:02:27.771106+00:00",{"id":55,"slug":56,"title":57,"cover_image":58,"image_url":58,"created_at":59,"category":13},"d1e26605-8b72-4be1-833e-c57583968f37","qdrant-filter-first-rag-design-decoded-en","Qdrant’s filter-first RAG design, decoded","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780566507204-rtv6.png","2026-06-04T09:48:00.130764+00:00",{"id":61,"slug":62,"title":63,"cover_image":64,"image_url":64,"created_at":65,"category":13},"7f8470a6-2ce0-48fb-9e14-f1fd599df36e","anthropic-code-review-tool-ai-generated-code-en","Anthropic’s code review tool turns AI code into reviewable work","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780563809948-86d0.png","2026-06-04T09:02:57.599265+00:00",{"id":67,"slug":68,"title":69,"cover_image":70,"image_url":70,"created_at":71,"category":13},"1247e920-56ea-4e12-9d8c-5a4a7d4df9dd","why-tether-is-right-to-push-local-ai-memory-into-everyday-de-en","Why Tether Is Right to Push Local AI Memory Into Everyday Devices","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780542172839-ie86.png","2026-06-04T03:02:19.993669+00:00",{"id":73,"slug":74,"title":75,"cover_image":76,"image_url":76,"created_at":77,"category":13},"5a3a734e-3a35-41f2-b9b4-b5c1a73f8471","databricks-model-serving-llm-deploy-guide-en","Databricks Model Serving turns LLM deploys simpler","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780525995152-os47.png","2026-06-03T22:32:51.502635+00:00",{"id":79,"slug":80,"title":81,"cover_image":82,"image_url":82,"created_at":83,"category":13},"48313ddd-9ba5-4525-8a13-40619b929be5","opencode-digitalocean-model-freedom-en","OpenCode+DigitalOcean 让你切换模型","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780525112937-2ydt.png","2026-06-03T22:18:07.524286+00:00",[85,90,95,100,105,110,115,120,125,130],{"id":86,"slug":87,"title":88,"created_at":89},"8008f1a9-7a00-4bad-88c9-3eedc9c6b4b1","surepath-ai-mcp-policy-controls-en","SurePath AI's New MCP Policy Controls Enhance AI Security","2026-03-26T01:26:52.222015+00:00",{"id":91,"slug":92,"title":93,"created_at":94},"27e39a8f-b65d-4f7b-a875-859e2b210156","mcp-standard-ai-tools-2026-en","MCP Standard in 2026: Integrating AI Tools","2026-03-26T01:27:43.127519+00:00",{"id":96,"slug":97,"title":98,"created_at":99},"165f9a19-c92d-46ba-b3f0-7125f662921d","rag-2026-transforming-enterprise-ai-en","How RAG in 2026 is Transforming Enterprise AI","2026-03-26T01:28:11.485236+00:00",{"id":101,"slug":102,"title":103,"created_at":104},"6a2a8e6e-b956-49d8-be12-cc47bdc132b2","mastering-ai-prompts-2026-guide-en","Mastering AI Prompts: A 2026 Guide for Developers","2026-03-26T01:29:07.835148+00:00",{"id":106,"slug":107,"title":108,"created_at":109},"3ab2c67e-4664-4c67-a013-687a2f605814","garry-tan-open-sources-claude-code-toolkit-en","Garry Tan Open-Sources a Claude Code Toolkit","2026-03-26T08:26:20.245934+00:00",{"id":111,"slug":112,"title":113,"created_at":114},"66a7cbf8-7e76-41d4-9bbf-eaca9761bf69","github-ai-projects-to-watch-in-2026-en","20 GitHub AI Projects to Watch in 2026","2026-03-26T08:28:09.752027+00:00",{"id":116,"slug":117,"title":118,"created_at":119},"9f332fda-eace-448a-a292-2283951eee71","practical-github-guide-learning-ml-2026-en","A Practical GitHub Guide to Learning ML in 2026","2026-03-27T01:16:50.125678+00:00",{"id":121,"slug":122,"title":123,"created_at":124},"1b1f637d-0f4d-42bd-974b-07b53829144d","aiml-2026-student-ai-ml-lab-repo-review-en","AIML-2026 Is a Bare-Bones Student Lab Repo","2026-03-27T01:21:51.661231+00:00",{"id":126,"slug":127,"title":128,"created_at":129},"6d1bf3f6-e191-4d30-b55b-8a0722fa6afe","ai-trending-github-repos-and-research-feeds-en","AI Trending Tracks Repos and Research Feeds","2026-03-27T01:31:35.709532+00:00",{"id":131,"slug":132,"title":133,"created_at":134},"010539a1-4c3a-4bd3-937a-26616422ee0d","awesome-ai-for-science-research-tools-map-en","Awesome AI for Science Is Becoming a Real Research Map","2026-03-27T01:46:50.89513+00:00"]