AI 学习路径：从 GPU 运行时到推理、微调与 RAG 评估

使用方式

AI 工程的门槛不在调包，而在资源约束：显存、算力、带宽和并发决定了你能跑什么、跑多快。这条路径按“硬件 → 推理 → 训练 → 评估”推进。

四个阶段按依赖顺序排列，每个阶段建议留 3–4 小时：

先读：读页面时盯住三件事：显存占用、吞吐、延迟。
再做：用单卡或小模型完成任务，不要在共享训练集群上做破坏性实验。
后测：能根据现象判断瓶颈在显存、算力、带宽还是调度，而不是只会重启服务。

每个阶段都要留下一次可复现的测量：命令、模型、输入长度、并发数和结果。

阶段一：GPU 与运行时

目标：能确认 GPU 是否可见、驱动和 CUDA 是否匹配、容器能否使用 GPU，以及多卡通信是否正常。

阅读顺序：

nvidia-smi — 显存、利用率、进程和 ECC 状态。
nvidia-container-toolkit — 容器暴露 GPU 的运行时配置。
cuda — 驱动版本、CUDA 版本、cuDNN 和框架的兼容关系。
nccl — 多卡集合通信、拓扑和 all-reduce 测试。
dcgm-exporter — GPU 指标采集和 Prometheus 集成。
nvtop — 交互式查看 GPU 利用率和显存。
nvitop — 按进程查看 GPU 资源和历史曲线。
gpu-operator — Kubernetes 中驱动、容器运行时和插件的一体化部署。
nvidia-device-plugin — 把 GPU 作为可调度资源暴露给 Pod。
gpu-cheatsheet — GPU 常用检查命令速查。

动手任务：在单卡机器上确认驱动与 CUDA 版本，启动一个带 GPU 的容器，跑一次 NCCL all-reduce，并把 GPU 指标接入 Prometheus。

nvidia-smi
nvidia-smi --query-gpu=name,driver_version,memory.total,memory.used --format=csv
docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi
nvidia-smi topo -m
curl -s localhost:9400/metrics | grep -E 'DCGM_FI_DEV_(GPU_UTIL|FB_USED)'

过关标准：

能解释驱动版本、CUDA 运行时版本和框架编译版本之间的兼容关系。
知道 GPU 利用率 100% 不等于有效吞吐高，还要看显存和带宽。
能判断多卡训练变慢是通信、数据加载还是负载不均。

阶段二：推理服务

目标：能把模型部署成可用的推理服务，理解首 token 延迟、单 token 延迟、吞吐和并发之间的关系。

阅读顺序：

ollama — 本地模型管理、量化格式和简单 API。
vllm — PagedAttention、连续批处理和 OpenAI 兼容接口。
sglang — RadixAttention、前缀缓存和高并发服务。
tgi — Hugging Face 推理容器、批处理和流式输出。
tensorrt-llm — 编译优化、量化内核和 NVIDIA 平台。
llama-server — llama.cpp 的 HTTP 服务与 CPU/GPU 混合推理。
lmdeploy — TurboMind 引擎、量化和多模型服务。
triton — 多框架模型仓库、动态批处理和并发实例。
vllm-vs-sglang — 两种高吞吐推理引擎的差异。
ollama-vs-vllm — 本地体验与生产服务的边界。

动手任务：用 vLLM 部署一个小模型，测量不同并发下的首 token 延迟和输出吞吐；再用 Ollama 跑同一模型，对比量化、显存和速度。

vllm serve Qwen/Qwen2.5-1.5B-Instruct --port 8000 --max-model-len 4096
curl -s http://localhost:8000/v1/models
curl -s http://localhost:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"Qwen/Qwen2.5-1.5B-Instruct","messages":[{"role":"user","content":"hi"}],"max_tokens":32}'
nvidia-smi --query-gpu=memory.used,utilization.gpu --format=csv -l 1

过关标准：

能解释 prefill 和 decode 阶段分别受算力还是显存带宽限制。
知道 KV cache 如何随并发、上下文长度和层数增长，以及它为什么会 OOM。
能说清量化对显存、吞吐和精度的影响，不把“更小”直接等同于“更好”。

阶段三：训练与微调

目标：能跑通单机多卡训练和 LoRA 微调，理解显存构成、并行策略和可复现性。

阅读顺序：

torchrun — 分布式启动、rank、world size 和环境变量。
deepspeed — ZeRO 分片、offload 和通信开销。
peft — LoRA、QLoRA 和适配器合并。
trl — SFT、DPO 等训练流程和对话模板。
axolotl — 用配置驱动微调，减少手写训练循环。
accelerate — 统一单卡、多卡和混合精度的启动方式。
bitsandbytes — 8bit/4bit 量化和 QLoRA 的显存收益。
llama-factory — 多模型微调平台和数据集格式。
megatron-lm — 张量并行、流水并行和大规模训练。
transformers — 模型加载、tokenizer、Trainer 和保存格式。

动手任务：用 LoRA 微调一个小模型，记录每步显存和耗时；再改一次 batch size 或并行度，解释吞吐变化。

accelerate config
torchrun --nproc_per_node=2 train.py --config config.yaml
python -c "import torch; print(torch.cuda.device_count(), torch.cuda.is_available())"
nvidia-smi --query-gpu=memory.used,utilization.gpu --format=csv -l 1

过关标准：

能说出训练显存由权重、梯度、优化器状态、激活和临时缓冲区哪些部分组成。
知道 DDP、ZeRO 不同 stage 和张量并行的区别，以及各自适合的规模。
能解释 LoRA 的 rank、alpha 和目标模块如何影响效果与显存。

阶段四：RAG、评估与实验管理

目标：能把外部知识接入模型，建立离线评估和线上追踪，并用实验管理保证结果可复现。

阅读顺序：

langchain — 链、工具、检索器和会话记忆的抽象。
llamaindex — 文档解析、索引、检索和后处理。
ragflow — 端到端的文档问答和知识库流程。
mlflow — 参数、指标、制品和模型注册。
langfuse — LLM 调用追踪、提示管理和在线评估。
lm-eval — 标准基准评测和结果对比。
rag-production-checklist — 上线前的检索、生成和权限检查。
dify — 可视化编排 RAG 和工作流。
fastgpt — 知识库问答和私有化部署。
ragas — RAG 评估指标、测试集生成和 LLM 裁判。

动手任务：用 LangChain 或 LlamaIndex 对一组文档建索引，比较两种 chunk 大小的检索命中率；用 Langfuse 记录一次问答链路，并把评估结果写入 MLflow。

python ingest.py --chunk-size 512 --overlap 64
python evaluate.py --questions eval.jsonl --top-k 5
mlflow ui --port 5000
docker compose up -d langfuse

过关标准：

能解释 RAG 和微调分别改变什么，什么场景应该优先选哪一个。
知道检索评估和生成评估要分开做，召回率低时调生成模型没有意义。
能设计一个可复现实验：固定数据、提示、模型版本和采样参数。

常见误区

只看 GPU 利用率，不看有效吞吐、显存和请求延迟。
显存不够就无脑减 batch，却不检查 KV cache、上下文长度和内存碎片。
把量化模型当成无损替代，忽略精度和任务差异。
微调前不做数据清洗和评估集，训练损失下降就认为效果变好。
RAG 只调生成提示，不检查切分、嵌入模型和召回质量。
用公开基准分数直接推断生产效果，忽略数据分布和污染。
实验不留模型版本、数据版本和参数，结果无法复现。

读完自测

合上页面，先回答，再展开对照。

推理服务显存不够，可能由哪些部分组成？先减哪一项最有效？
LoRA 微调和 RAG 分别适合解决什么问题？
评估 RAG 时，为什么要先看检索指标再看生成指标？

答案

显存主要由模型权重、KV cache、激活和框架临时缓冲区组成。推理阶段权重通常占大头，但 KV cache 会随并发和上下文长度线性增长。先量化权重或减少并发与上下文长度通常最有效，其次才是调整批处理和释放缓存。
LoRA 改变模型的行为、风格和指令遵循能力，适合有标注数据且需要稳定输出的场景；RAG 不改变权重，通过检索外部知识提供事实依据，适合知识频繁更新、需要引用来源和权限隔离的场景。两者可以叠加。
RAG 的答案质量上限由检索到的上下文决定。如果召回率低，生成模型只能凭空编造，此时优化提示或换更大模型收益有限。先确认正确文档能被召回，再评估生成是否忠实、完整和可引用。

AI 学习路径：从 GPU 运行时到推理、微调与 RAG 评估

使用方式

阶段一：GPU 与运行时

阶段二：推理服务

阶段三：训练与微调

阶段四：RAG、评估与实验管理

常见误区

读完自测

相关条目