一名计算机科学专业的本科生,最近开始了一个叫 Project EREN 的项目:用 C++ 和 CUDA 从零搭建一个 LLM 推理引擎。他把第一阶段的目标定得很具体——先在自己的 NVIDIA RTX 4060 Laptop GPU(8 GB 显存)上跑通,从 GPT-2 这类小型 decoder-only transformer 起步,先把正确性立住,再逐步走向更强的模型和更高效的推理。
这不是"调个框架加载模型"的路线。他明确说,自己想弄明白的是那些被 PyTorch 和成熟推理运行时封装起来的底层:transformer 的运算怎么映射到 GPU kernel 上,模型权重和中间激活在显存里经历了什么,自回归逐 token 生成在内部是怎么运转的,以及为什么在推理过程中内存带宽和 kernel 启动开销会变得重要。他的做法是自己实现、测试、跑基准、再优化,而不是只停留在阅读概念。
长期目标也写得很清楚:支持多个并发推理请求、追求高吞吐,同时把底层的 GPU kernel、内存管理、调度和执行策略吃透。再往后,他希望 EREN 能成为某个基于 RAG 的 AI agent 的推理后端。他也把话说在前面——眼下并不打算和成熟的推理引擎正面竞争,重点是通过亲手造一个来理解这类系统怎么工作。
技术栈与当前进度
开发环境是 C++17 加 CUDA C++,跑在 WSL2 上的 Ubuntu 里,构建用 CMake,测试用 CTest。后续还会引入 Python、PyTorch 和 Hugging Face Transformers 作为参考实现,用来对照验证正确性。核心推理运行时则坚持用 C++ 和 CUDA 写。
目前完成的是 Phase 0,也就是把 C++/CUDA 的开发地基打牢。已经落地的部分包括:
- 项目结构与构建系统:仓库按 kernels、源码、头文件、测试、基准和文档分目录组织,CMake 负责构建 C++ 与 CUDA 目标。
- CUDA 向量加法:用一个基础 kernel 验证显存分配、主机到设备传输、kernel 启动和结果校验这条链路。
- GPU reduction:实现了基于共享内存的多阶段归约基线,用来理解并行归约和跨线程块协作。
- CUDA 错误处理:封装了一个可复用的错误检查辅助工具,方便定位和调试运行时故障。
- 测试与基准基础:用 CTest 加了冒烟测试,并建立了最初的 reduction 基准目标。
他给出的结果是:一次干净的构建成功,配置的四个测试全部通过。不过他也坦承,推理引擎本身还没跑起来,这一阶段只是为下一步铺路。
分阶段推进,不直接跳进优化
他选择按阶段推进,而不是一上来就写优化过的 kernel。Phase 1 是先做 Python/PyTorch 参考实现:从 GPT-2 入手,研究它的前向传播,检查权重和张量形状,并生成用于正确性测试的参考输出。Phase 2 是第一个 CUDA 推理实现:写出最初的 CUDA 算子,并把它们串成一次完整的 GPT-2 前向传播。更后面的阶段才涉及优化与服务化,包括优化矩阵乘法、量化、GPU profiling、内存管理、批处理、并发请求和推理调度。整条路径的意图很明确——从"能正确跑"走向"可度量、够高效"的运行时。
他公开记录这个项目,也不只是为了发进度公告。后续会分享自己在实现什么、为什么这么做,CUDA 概念和工程决策,遇到的 bug、失败的实验和踩过的坑,以及基准测试和性能对比。他还特意提到,会尽量区分哪些是已经跑通的、哪些是实际测过的、哪些还在实验当中。
EREN 仍处在早期,要学的东西还有很多。下一步,他会先在 PyTorch 里搭出 GPT-2 的参考实现,然后再进入 CUDA 推理。
热门跟贴