AI-fundamentals: A Documentation Repository for GPU, CUDA and Cluster Work
AI 基础知识 - GPU 架构、CUDA 编程、大模型基础及AI Agent 相关知识。
At a glance
- What is it?
- ForceInjection/AI-fundamentals is an Apache-2.0 collection of Markdown notes on GPU architecture, CUDA programming, Kubernetes GPU management and distributed storage, published as a static site. It is a reading path, not a library, and its value depends on whether you want curated prose rather than runnable code.
- Who is it for?
- Adopt AI-fundamentals if you need a structured reading path through GPU architecture, CUDA execution models, NCCL and Kubernetes GPU plumbing, and you are willing to follow links rather than run a tool. Do not adopt it if you need a maintained library, a benchmark harness or versioned API documentation.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly HTML, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap AI-fundamentals tries to fill
Most AI infrastructure knowledge is scattered across vendor whitepapers, kernel source, mailing list threads and conference slides. The README describes the repository as a collection of learning resources covering the stack from hardware fundamentals to advanced applications, aimed at AI engineers, system architects, GPU programmers, large model application developers and researchers. The stated scope runs from GPU and TPU design through PCIe, NVLink, GPUDirect and CXL, then into cluster operations with InfiniBand and NCCL, then cloud native scheduling with Kubernetes, and finally CUDA and TileLang programming. That is a wide net. The practical problem it addresses is orientation: a new hire who has to understand why NVLink-C2C exists before reading about GB300 NVL72 has somewhere to start. The audience is therefore readers, not integrators. Nothing in the README describes an installable package, a CLI or a Python module. The primary language is HTML, which is consistent with a site generated from Markdown and published at forceinjection.github.io. If you are looking for a dependency to add to a build, this is the wrong shape of project.
How the material is organised and served
The repository is a numbered directory tree. 01_hardware_architecture holds chip and interconnect notes; 02_gpu_programming holds environment setup, CUDA concepts and TileLang; 03_ai_cluster_ops holds GPU operations, InfiniBand and NCCL; 04_cloud_native_ai_platform holds Kubernetes, GPU virtualisation and storage. Each top-level directory has its own README that acts as a table of contents, and the root README links to those. The homepage is a GitHub Pages site, so the Markdown is rendered rather than read in a terminal. Relative links such as ./01_hardware_architecture/nvidia/understand_gpu_architecture/README.md are the navigation mechanism. Two things follow from that layout. First, there is no build step for a reader: you click through the site or browse the tree. Second, the content is coupled to file paths, so any directory rename breaks inbound links from the README and from other documents. The README also embeds a star history chart image from an external service, which means the rendered page makes a third-party request. That is a small privacy and availability consideration for anyone mirroring the site internally.
What a reader actually opens
The concrete artefacts are documents, and the README names them. Under hardware you get understand_gpu_architecture, tpu 101, a GPGPU versus NPU comparison, a PCIe guide, P2PDMA, two CXL pieces (an interconnect overview and a cxl / daxctl / ndctl command line walkthrough), NVLink intro, GPUDirect P2P, GPUDirect RDMA and Storage, NVLink-C2C, NVIDIA GB300 NVL72, and an AI infrastructure latency pyramid. Under cluster operations there is device query, a piece arguing about GPU utilisation metrics, guides to nvidia-smi and nvtop, InfiniBand theory and health checking, and NCCL theory plus a benchmarking and multi-node deployment guide. Under cloud native there is NVIDIA Container Toolkit internals, Device Plugin source analysis, Kueue with HAMi, Leader Worker Set, an llm-d introduction, containerd log analysis, a four-part GPU manager series, HAMi guides, a KAI versus HAMi comparison, and storage notes on JuiceFS, DeepSeek 3FS and NVIDIA ICMS. The GPU programming section covers NVIDIA container setup, CUDA image build analysis, a GPU programming introduction, CUDA cores, CUDA streams, SIMT versus tile-based models, a TileLang quick start, and nvbandwidth practices. The README mentions a link to 200+ Tensor Core and CUDA Core optimisation kernels as further reading, but the supplied text truncates before the target is named, so treat that pointer as unverified until you find it in the tree.
Depth signals and where the documentation is thin
The titles suggest two different kinds of document living side by side. Some are conceptual, such as the latency pyramid or the SIMT versus tile-based comparison. Others claim implementation-level treatment: Device Plugin source analysis, Container Toolkit internals, containerd log analysis, and a code directory described as reference implementations of a GPU scheduler, virtualisation interception and remote calls, alongside a configs directory described as production and multi-cloud deployment references. That second category is where a reader should look first, because it is the only place the repository offers something a vendor manual does not. The risk is equally clear. Source analysis documents age quickly against upstream releases, and the README gives no version pins for Kubernetes, the NVIDIA device plugin, HAMi, Kueue or JuiceFS. A document titled as an analysis of a device plugin is only useful if you know which revision it read. The README does not state that. The same applies to the storage notes on DeepSeek 3FS and NVIDIA ICMS, both of which describe systems that are young and moving. Treat every internals piece as a snapshot with an unknown timestamp, and check the file's own content for a stated version before you quote it internally.
Getting it and reading it
There is no install. The README gives one entry point, the published site at https://forceinjection.github.io, and the repository itself. The straightforward local route, based on the repository layout, is a clone followed by opening the root README, since the content is Markdown and the links are relative paths:
git clone https://github.com/ForceInjection/AI-fundamentals.git cd AI-fundamentals
From there, the reading order is the numbered prefixes: 01_hardware_architecture, 02_gpu_programming, 03_ai_cluster_ops, 04_cloud_native_ai_platform. Each section README is the index for that directory. The commands that appear in the documents themselves are the subject matter, not setup instructions for the repository: the CXL piece is described as covering cxl, daxctl and ndctl, the GPU operations section covers nvidia-smi and nvtop, and the profiling section covers nvbandwidth. There is no configuration file at the repository level, no package manifest and no dependency list in the supplied material, so do not expect a lockfile to tell you what versions the examples assume. If you need the site offline, the HTML output is what you would mirror, but the README does not describe the generator, so reproducing the exact rendering requires inspecting the repository rather than following a documented build.
Licence, reuse and the maintenance question
The repository is Apache-2.0. That permits reuse and modification with attribution and with the licence and notice files preserved, and it includes an explicit patent grant. It does not remove the need to credit the source, and it does not cover third-party material that the documents may quote or reproduce, such as vendor diagrams or upstream source excerpts. If you plan to fork these notes into internal onboarding material, check each document for copied figures or code blocks whose origin and terms are not stated. On maintenance: the last push recorded is 2026-09-09, with releases v3.0 on 2026-01-08 and v2.0 on 2025-08-29. The gap between v2.0 and v3.0 is roughly four months, and the push date sits after v3.0, which suggests edits continue between tagged releases. That is a reasonable cadence for a documentation project, but it is not a compatibility guarantee. There is no stated policy on which upstream versions are tracked, so an upgrade to your Kubernetes or CUDA stack does not imply the corresponding document has been revised. Budget for reading diffs rather than expecting migration notes.
Where a different resource fits better
For CUDA itself, the NVIDIA CUDA C Programming Guide and the CUDA Toolkit documentation are the primary reference, and they differ from AI-fundamentals in kind rather than quality: they are versioned against a toolkit release, they specify API behaviour precisely, and they are updated by the vendor that ships the compiler. AI-fundamentals offers a reading path and comparisons; the vendor docs offer the contract. For Kubernetes GPU plumbing, the NVIDIA Kubernetes device plugin repository and the Container Toolkit documentation give you the manifests and the actual source you would deploy, while this repository gives you an analysis of that source. For distributed storage, the JuiceFS and DeepSeek 3FS project repositories carry their own design documents and issue trackers, which is where you go when a behaviour is not what the note claims. The honest summary is that AI-fundamentals is a secondary source. It is useful for building a mental model and for deciding what to read next, and it is not a substitute for the upstream documentation of any component it discusses.
Who should read this, and what to check first
Read it if you are an engineer moving into AI infrastructure from adjacent systems work and you want a guided sequence from interconnect physics to Kubernetes scheduling, or if you are preparing internal training material and want a starting outline you can verify and rewrite. Skip it if you need code you can call, if you need API-level precision, or if your work requires documentation pinned to a specific Kubernetes, CUDA or HAMi version. Before you rely on any single document, do three checks. Confirm the file exists at the path the README advertises, since the links are the interface. Look inside the document for a stated upstream version or date, and if there is none, treat the analysis as undated. And for the GPU manager code and configs directories, read the files directly rather than trusting the directory description, because those are the only parts of this repository that claim to be deployable references. The rest is prose, and prose about fast-moving infrastructure has a shelf life you have to estimate yourself.
Editorial conclusion
Adopt AI-fundamentals if you need a structured reading path through GPU architecture, CUDA execution models, NCCL and Kubernetes GPU plumbing, and you are willing to follow links rather than run a tool. Do not adopt it if you need a maintained library, a benchmark harness or versioned API documentation. Before relying on it, open the repository tree and confirm that 02_gpu_programming, 03_ai_cluster_ops and 04_cloud_native_ai_platform still hold the files the README advertises, and check the v3.0 release date against the topics you care about.
Community notes