ai-infra-hpc: A Chinese-Language Course Tree for GPU and Interconnect Internals
hpc 教程，包含集合通信(mpi、nccl)、cuda 编程、向量化 SIMD、RDMA 通信等
At a glance
- What is it?
- The repository is a directory of Markdown notes covering CUDA, MPI, NCCL, RDMA and chip hardware, indexed from a single README. It is a reading path, not a library, and it ships no build system, no tests and no releases.
- Who is it for?
- Adopt it as a reading list if you already write CUDA or MPI code and want a Chinese-language index that jumps from register pressure to NCCL topology without leaving one repository. Skip it if you need runnable sample projects, English prose, or an artifact you can pin in a build.
- Can I use it commercially?
- Yes. MIT 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 last received commits 142 days ago.
- What is it written in?
- Mainly Cuda, 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
What problem a folder tree of HPC notes actually solves
The README opens with a one-line statement of intent: the repository exists to record AI-Infra and HPC technology, listing AI system internals, multi-machine multi-GPU interconnect, parallel and high-performance computing, and training and inference. That is the whole scope. There is no package to install and no service to run.
The audience is narrow and specific. Someone who already writes CUDA kernels or MPI programs, and who wants a single index that moves from SM occupancy to InfiniBand without switching between five unrelated sites. The README's CUDA table of contents runs from heterogeneous parallel computing through the programming model, the execution model, memory layout, shared and constant memory, and streams and concurrency. The directory listing adds OpenMP, SIMD, PCIe, on-chip networks, GPUDirect, InfiniBand, storage, MPI, NCCL and an industry report folder.
What it is not: a tutorial for someone who has never compiled a kernel. There is no introductory path, no prerequisites section, and no statement of which CUDA toolkit version the notes assume. The value is in the grouping. Whether that grouping is worth your time depends entirely on whether the individual notes are deep enough, and the README alone cannot tell you that.
The directory layout is the architecture
There is no runtime architecture here, so the thing to describe is the information architecture. The README prints the tree with inline comments, and the numbering is deliberate: 01 chip, 02 hpc, 03 link, 04 storage, 05 ccl, 06 trainAndInfer, 99 industryReport. The gaps in the numbering (02 hpc contains 01 openmp, 02 simd, 05 cuda; 03 link contains 01 noc, 02 pcie, 03 topo, 05 gpuDirect, 08 infiniband) suggest reserved slots for material not yet written.
The ordering encodes a dependency chain. Chip hardware first, then compute-level parallelism (OpenMP, SIMD, CUDA), then the physical links between devices (NoC, PCIe, topology, GPUDirect, InfiniBand), then storage, then collective communication (MPI, NCCL), then training and inference. A reader following the numbers top to bottom moves from a single core outward to a full cluster.
This is a reading order, not a module system. Nothing in the tree is importable. The CUDA notes live under 02hpc/05cuda/readme.md, and the README links into that file by anchor, for example the sections on __global__, __device__, __host__, __constant__, __shared__, __managed__ and __restrict__. Anchor-based navigation means the structure of the notes is coupled to the heading text; renaming a heading breaks every link from the top-level README.
What the CUDA notes cover, and where the depth stops
The CUDA table of contents is the most detailed part of the material. It includes the question of why CUDA separates thread blocks from thread grids, why a block cannot be split across SMs, the distinction between SIMD and SIMT, warp divergence, resident blocks, and how resource allocation limits the number of warps and blocks per SM. On the memory side it lists registers and their capacity, local memory, shared memory, constant memory, texture memory, global memory, GPU caches, pinned memory, zero-copy memory, unified virtual addressing, unified memory, and the difference between UM and UVA. It also covers aligned and coalesced access.
That is a conventional syllabus, close to what a CUDA textbook covers, and the headings are specific enough to be useful as a checklist. What the README does not show is the body of those sections. There is no statement of how long each note is, whether it contains code, or whether it cites a particular architecture generation. One heading does anchor the discussion to a named architecture: understanding thread execution through the Fermi architecture. Fermi is old. If the execution-model notes stop there, they will not describe how modern SM scheduling, tensor cores or asynchronous copy behave.
Treat the table of contents as a promise about topics, not about currency. The only way to judge is to open 02hpc/05cuda/readme.md and read the sections you need.
Collective communication and the interconnect layer
The 05 ccl folder splits into mpi and nccl. The README describes the NCCL folder as covering both usage and design, which is the more interesting half: a design description implies the notes discuss algorithms and topology awareness rather than only listing API calls. The MPI folder is described only as usage and tutorial.
The link folder is where this repository differs from a generic CUDA course. It covers on-chip networks, PCIe, multi-machine multi-GPU topology, GPUDirect for GPU to host, GPU, InfiniBand NIC and NVMe SSD paths, and InfiniBand with RDMA. Those are the layers that determine whether a collective operation is fast, and they are usually documented in vendor manuals rather than collected alongside compute notes.
No code is shown in the README for any of this. There is no example of an ncclAllReduce call, no mpirun invocation, no ibv_ verb. If you need a working starting point for a two-node NCCL job, this repository gives you the topic headings and expects you to find the code elsewhere. The README gives no build instructions for anything, so any runnable example would have to be discovered inside the subfolders.
Getting it: clone, then read
There is no installation procedure in the supplied material. The repository has no releases, and the README contains no build commands. The only reproducible action is to clone and read the Markdown:
git clone https://github.com/jinbooooom/ai-infra-hpc.git
After that, the entry points named in the README are 02hpc/05cuda/readme.md for CUDA, 05ccl/mpi and 05ccl/nccl for collective communication, and 03link for the interconnect material. The README's own links use a mix of path forms, with some pointing at a master branch path such as 02hpc/05cuda/readme.md while the repository's default branch is main, so expect some links to need manual correction if you browse the rendered file.
Because the content is prose and diagrams, there is nothing to compile. That also means there is no version to pin and no compatibility matrix. If a note references a CUDA API, the toolkit version it was written against is not stated in the README, and the last push date on the repository is the only signal about how recent the material is.
The case against it: no executable artifact and no English
The first limitation is that this is a notes repository, not a project. There is no library, no headers, no CMakeLists, no test suite and no CI visible in the supplied material. You cannot depend on it, benchmark against it, or vendor a piece of it into your own code. If your goal is to get a working multi-GPU all-reduce running today, a repository of Markdown will not do it.
The second is language. The README is written in Chinese, and the folder comments, the section headings and presumably the notes themselves are Chinese. For a reader who does not read Chinese, the repository is effectively a directory listing. That is a hard boundary, not a preference.
The third is the absence of maintenance signals. The repository is not archived, and the last push is dated 2026-04-27, but no releases were retrieved. There is no changelog in the README, no statement of which CUDA, MPI or NCCL versions the notes target, and no contribution guide. For a topic where the APIs and hardware generations move, undated notes age silently. A section on Fermi thread execution is useful as background and misleading as current practice, and the README does not mark the difference.
Where to go instead, and how the approach differs
For CUDA specifically, the NVIDIA CUDA C++ Programming Guide is the reference these notes are ultimately derived from, and it is versioned with the toolkit. The difference in approach is maintenance: NVIDIA revises the guide per release and states which compute capabilities each feature requires, while this repository presents one undated snapshot. If you need to know whether a feature exists on the GPU you actually have, the vendor guide answers that question and these notes may not.
For collective communication, the NCCL documentation and the MPI standard documents serve the same role. Here the difference is breadth rather than authority: no single vendor document walks from PCIe topology to NCCL design to RDMA verbs in one tree. That cross-layer sweep is the one thing this repository does that the official references do not, and it is also the part most likely to go stale, because interconnect generations change quickly.
A closer analogue in spirit is a personal engineering notebook published as a repository. Those are valuable when the author's path matches yours and the notes are dated. This one does not state dates per section, so you are trusting the last push timestamp as a proxy for the whole tree.
Licence and the cost of keeping notes current
The repository is MIT licensed. That permits reuse, modification and redistribution with the licence text retained, and it imposes no copyleft obligation on anything you build alongside it. It does not, however, grant rights to diagrams or text reproduced from vendor documentation, and the supplied material does not say whether any figures were copied from elsewhere. If you plan to republish a section, that is the question to resolve, and it is not a question the licence file answers on its own.
Maintenance cost falls on whoever forks it. Because the material is prose, updating it means editing Markdown, not patching code, so there is no build to break. The real cost is verification: every API name, every architecture claim and every topology diagram has to be checked against current documentation by hand. There is no test that fails when a note goes out of date.
For a team, the sensible use is as an internal reading list that someone owns and annotates, not as a reference you cite without checking. The repository gives you the skeleton of a curriculum. Keeping the skeleton attached to current hardware is the work it does not do for you.
Editorial conclusion
Adopt it as a reading list if you already write CUDA or MPI code and want a Chinese-language index that jumps from register pressure to NCCL topology without leaving one repository. Skip it if you need runnable sample projects, English prose, or an artifact you can pin in a build. Before relying on it, open 02hpc/05cuda/readme.md and 05ccl/nccl and check whether the API names in the sections you care about still match the toolkit versions you have installed.
Community notes