从零搭建AI工程体系：手写注意力机制与训练循环实战

1. 从零搭建AI工程体系，为什么我劝你别一上来就调包

“ai-engineering-from-scratch”这个标题，第一次看到的时候我愣了一下。市面上讲AI的教程铺天盖地，但绝大多数都是教你pip install一个库，然后调个API，跑通一个demo就完事了。真正从零开始、把AI工程当作一门系统工程来拆解的内容，少之又少。我自己在这个方向上踩了差不多两年的坑，从最开始只会调transformers的pipeline，到后来自己手写注意力机制、自己搭训练循环、自己做推理优化，中间交了不少学费。所以看到这个标题，我特别有感触，想把自己从零构建AI工程体系的完整思路和实操细节摊开来聊一聊。

先说清楚这个标题覆盖的是什么。AI工程不是单纯的算法研究，也不是纯粹的软件开发，它是介于两者之间的一层“胶水加钢筋”的工作。你需要懂模型的基本原理，但你不需要去发明新的激活函数；你需要写生产级的代码，但你不需要从零实现一个操作系统。从零开始意味着你不依赖那些高度封装的框架，而是自己把数据管道、模型结构、训练循环、评估体系、推理服务这一整条链路搭起来。这件事能帮你真正理解AI系统里每一个环节在干什么，出了问题知道去哪里找原因，而不是对着报错信息干瞪眼。

这篇文章适合谁看？如果你已经会用Python，对机器学习有基本概念，但每次遇到模型不收敛、推理速度慢、显存爆炸这些问题就束手无策，那这篇内容就是写给你的。如果你是个有经验的工程师，想从传统后端转向AI方向，但不想只做个“调包侠”，那也值得一读。我会尽量把每个环节的“为什么”讲清楚，同时给出可以直接抄作业的代码和参数。整个过程我会按照我自己实际搭建的顺序来展开，从环境准备到最终的服务部署，每一步都有踩坑记录和实操心得。

2. 整体架构设计与技术选型思路

2.1 为什么我选择“裸写”而不是用现成框架

很多人会问，现在PyTorch Lightning、HuggingFace Trainer这些工具这么成熟，为什么还要从零写？这不是重复造轮子吗？我一开始也这么想，直到有一次线上模型出现了一个诡异的梯度消失问题，我用Trainer排查了整整两天都没找到原因，最后自己手写了一个最简训练循环，把每一步的梯度范数打印出来，十分钟就定位到了是某个自定义层里的初始化有问题。从那以后我就明白了，封装越厚，你对系统的掌控力越弱。

从零搭建的核心价值在于可观测性和可调试性。当你自己写训练循环的时候，你清楚地知道每一个loss.backward()之后发生了什么，每一个optimizer.step()之前梯度长什么样。你可以随时插入检查点，打印任何你想要的中间变量。这种透明度在排查问题时是无可替代的。当然，我不是说生产环境一定要裸写，而是在学习阶段，裸写一遍能让你建立起对AI系统的“肌肉记忆”。

技术选型上，我的建议是：PyTorch做模型和训练，NumPy做数据处理和数学验证，FastAPI做推理服务。PyTorch的动态图机制对调试友好，NumPy能帮你验证每一个矩阵运算的正确性，FastAPI轻量且性能足够。至于分布式训练、混合精度这些高级特性，等你把单机单卡跑通了再说。

2.2 目录结构决定项目能走多远

我见过太多人把所有代码堆在一个main.py里，最后改一行代码要翻三百行。从零搭建AI工程，第一件事就是把目录结构设计好。我的习惯是这样的：

ai-from-scratch/ ├── configs/ # 配置文件，YAML格式 │ ├── model.yaml │ └── train.yaml ├── data/ # 数据相关 │ ├── dataset.py # Dataset类 │ ├── tokenizer.py # 分词器 │ └── preprocess.py # 预处理脚本 ├── models/ # 模型定义 │ ├── attention.py # 注意力机制 │ ├── layers.py # 基础层 │ └── transformer.py # 完整模型 ├── training/ # 训练相关 │ ├── trainer.py # 训练循环 │ ├── loss.py # 损失函数 │ └── scheduler.py # 学习率调度 ├── evaluation/ # 评估相关 │ ├── metrics.py # 评估指标 │ └── evaluator.py # 评估流程 ├── serving/ # 推理服务 │ ├── app.py # FastAPI应用 │ └── model_server.py # 模型加载与推理 ├── utils/ # 工具函数 │ ├── logger.py # 日志 │ └── checkpoint.py # 检查点管理 └── scripts/ # 入口脚本 ├── train.py └── serve.py

这个结构的好处是职责分离。数据的问题去data/找，模型的问题去models/找，训练的问题去training/找。每个模块可以独立测试，比如你可以单独跑一个脚本验证attention.py的输出维度对不对，而不需要启动整个训练流程。配置文件用YAML而不是硬编码，这样你可以随时切换模型大小、学习率、批次大小，而不需要改代码。

注意：目录结构不是一成不变的，但一定要在项目初期就定好。我吃过亏，项目做到一半想重构目录，结果import路径改得想砸键盘。

2.3 配置管理：别让超参数散落在代码各处

超参数管理是个看似简单实则容易翻车的地方。我最初的做法是在train.py开头定义一堆变量，learning_rate = 1e-4、batch_size = 32这样。结果后来想做实验对比不同学习率的效果，每次都要改代码、重新提交，非常低效。后来我改用YAML配置文件加dataclass的方式，代码里只引用配置对象，所有超参数集中管理。

# configs/train.yaml model: vocab_size: 32000 hidden_dim: 512 num_layers: 6 num_heads: 8 dropout: 0.1 training: batch_size: 32 learning_rate: 1e-4 warmup_steps: 1000 max_steps: 100000 gradient_clip: 1.0 accumulation_steps: 4 data: max_seq_len: 512 train_path: "data/train.jsonl" val_path: "data/val.jsonl"

然后在代码里用dataclass解析：

from dataclasses import dataclass import yaml @dataclass class ModelConfig: vocab_size: int hidden_dim: int num_layers: int num_heads: int dropout: float @dataclass class TrainConfig: batch_size: int learning_rate: float warmup_steps: int max_steps: int gradient_clip: float accumulation_steps: int def load_config(path): with open(path) as f: raw = yaml.safe_load(f) return ModelConfig(**raw["model"]), TrainConfig(**raw["training"])

这样做的好处是实验可复现。你只需要保存一份YAML文件，就能完整记录一次实验的所有配置。而且dataclass提供了类型提示，IDE能帮你做自动补全和类型检查，减少低级错误。

3. 核心模块拆解与手写实现要点

3.1 注意力机制：从公式到代码的完整映射

注意力机制是Transformer的核心，也是很多人第一个卡住的地方。公式看起来很简单：Attention(Q, K, V) = softmax(QK^T / sqrt(d_k)) V。但真正手写的时候，有几个细节必须注意。

首先是缩放因子的位置。sqrt(d_k)是用来防止点积结果过大的，因为当d_k很大时，QK^T的方差会随着维度增加而增大，导致softmax进入饱和区，梯度变得极小。我一开始忘了加这个缩放，训练loss直接卡在2.3不动，排查了半天才发现问题。

其次是mask的处理。在自回归生成任务中，你需要一个上三角矩阵来遮蔽未来的token。这个mask要在softmax之前加上去，而且要用一个很大的负数（比如-1e9）而不是负无穷，因为负无穷在某些实现里会产生NaN。

import torch import torch.nn as nn import math class MultiHeadAttention(nn.Module): def __init__(self, hidden_dim, num_heads, dropout=0.1): super().__init__() assert hidden_dim % num_heads == 0, "hidden_dim必须能被num_heads整除" self.hidden_dim = hidden_dim self.num_heads = num_heads self.head_dim = hidden_dim // num_heads self.q_proj = nn.Linear(hidden_dim, hidden_dim) self.k_proj = nn.Linear(hidden_dim, hidden_dim) self.v_proj = nn.Linear(hidden_dim, hidden_dim) self.out_proj = nn.Linear(hidden_dim, hidden_dim) self.dropout = nn.Dropout(dropout) def forward(self, x, mask=None): batch_size, seq_len, _ = x.shape # 投影并分头 q = self.q_proj(x).view(batch_size, seq_len, self.num_heads, self.head_dim).transpose(1, 2) k = self.k_proj(x).view(batch_size, seq_len, self.num_heads, self.head_dim).transpose(1, 2) v = self.v_proj(x).view(batch_size, seq_len, self.num_heads, self.head_dim).transpose(1, 2) # 计算注意力分数 scores = torch.matmul(q, k.transpose(-2, -1)) / math.sqrt(self.head_dim) if mask is not None: scores = scores.masked_fill(mask == 0, -1e9) attn_weights = torch.softmax(scores, dim=-1) attn_weights = self.dropout(attn_weights) # 加权求和并合并头 context = torch.matmul(attn_weights, v) context = context.transpose(1, 2).contiguous().view(batch_size, seq_len, self.hidden_dim) return self.out_proj(context)

这段代码里有个容易忽略的点：transpose之后必须调用.contiguous()才能用view。因为transpose返回的是非连续内存的张量，直接view会报错。我见过不少人在这里卡住，其实加一个.contiguous()就解决了。

实操心得：手写注意力的时候，建议先用小维度（比如hidden_dim=8, num_heads=2）在纸上算一遍，然后用NumPy验证PyTorch的输出是否一致。这一步花十分钟，能帮你省下几个小时的调试时间。

3.2 位置编码：为什么正弦函数就够了

Transformer本身没有位置信息，因为注意力机制是置换不变的。所以你需要额外注入位置编码。原始论文用的是正弦余弦函数，后来很多人改用可学习的位置嵌入。我的建议是：序列长度小于512时用可学习嵌入，超过512时用正弦编码。原因是可学习嵌入在训练长度之外无法泛化，而正弦编码可以外推到更长的序列。

正弦编码的公式是：

PE(pos, 2i) = sin(pos / 10000^(2i/d_model)) PE(pos, 2i+1) = cos(pos / 10000^(2i/d_model))

其中pos是位置，i是维度索引。这个设计的巧妙之处在于，对于任意固定的偏移量k，PE(pos+k)可以表示为PE(pos)的线性函数，这让模型能够轻松学习相对位置关系。

class PositionalEncoding(nn.Module): def __init__(self, hidden_dim, max_len=5000, dropout=0.1): super().__init__() self.dropout = nn.Dropout(dropout) pe = torch.zeros(max_len, hidden_dim) position = torch.arange(0, max_len).unsqueeze(1).float() div_term = torch.exp(torch.arange(0, hidden_dim, 2).float() * -(math.log(10000.0) / hidden_dim)) pe[:, 0::2] = torch.sin(position * div_term) pe[:, 1::2] = torch.cos(position * div_term) pe = pe.unsqueeze(0) # (1, max_len, hidden_dim) self.register_buffer('pe', pe) def forward(self, x): x = x + self.pe[:, :x.size(1), :] return self.dropout(x)

注意register_buffer的用法。把pe注册为buffer而不是普通属性，这样它会自动跟随模型移动到GPU，而且不会被优化器更新。如果你直接写成self.pe = pe，模型.to(device)的时候这个张量不会跟着走，训练时会报设备不匹配的错误。

3.3 训练循环：每个细节都关乎成败

训练循环是整个AI工程的心脏。我见过太多人用Trainer跑通了就不管了，结果遇到loss震荡、梯度爆炸、过拟合这些问题完全不知道从何下手。自己写一遍训练循环，你会对以下这些环节有深刻的理解。

梯度累积是第一个要掌握的技巧。当显存不够大，无法容纳大batch时，你可以把多个小batch的梯度累加起来再更新参数。这等价于用大batch训练，但显存占用只有小batch的水平。实现方式是在每个小batch的loss上除以累积步数，然后正常backward()，但只在累积到指定步数时才调用optimizer.step()和optimizer.zero_grad()。

梯度裁剪是防止梯度爆炸的标配。我习惯用torch.nn.utils.clip_grad_norm_，把梯度的全局范数限制在一个阈值内。这个阈值通常设在0.5到1.0之间，具体取决于模型大小和任务。太小的阈值会限制模型的学习能力，太大的阈值等于没裁。

学习率预热对大模型训练至关重要。训练初期模型参数是随机初始化的，梯度方向可能很混乱，直接用大学习率会导致训练不稳定。预热策略是在前N步线性地从0增加到目标学习率，然后再按余弦或线性衰减。

class Trainer: def __init__(self, model, optimizer, scheduler, config, device): self.model = model self.optimizer = optimizer self.scheduler = scheduler self.config = config self.device = device self.step = 0 def train_epoch(self, dataloader): self.model.train() total_loss = 0 self.optimizer.zero_grad() for batch_idx, batch in enumerate(dataloader): input_ids = batch["input_ids"].to(self.device) labels = batch["labels"].to(self.device) mask = batch["attention_mask"].to(self.device) outputs = self.model(input_ids, mask) loss = F.cross_entropy( outputs.view(-1, outputs.size(-1)), labels.view(-1), ignore_index=-100 ) loss = loss / self.config.accumulation_steps loss.backward() if (batch_idx + 1) % self.config.accumulation_steps == 0: # 梯度裁剪 torch.nn.utils.clip_grad_norm_( self.model.parameters(), self.config.gradient_clip ) self.optimizer.step() self.scheduler.step() self.optimizer.zero_grad() self.step += 1 # 日志记录 if self.step % 100 == 0: current_lr = self.scheduler.get_last_lr()[0] print(f"Step {self.step}, Loss: {loss.item() * self.config.accumulation_steps:.4f}, LR: {current_lr:.2e}") total_loss += loss.item() * self.config.accumulation_steps return total_loss / len(dataloader)

这段代码里有个细节：loss在backward之前除以了accumulation_steps，但在记录日志时又乘回来了。这是为了让你看到的loss值始终是真实的平均loss，而不是被缩放过的值。这个技巧在对比不同累积步数的实验时特别有用。

注意：optimizer.zero_grad()的位置很关键。如果你在循环开头调用它，那每个batch都会清空梯度，梯度累积就失效了。正确的做法是在optimizer.step()之后调用，或者用set_to_none=True来节省显存。

4. 数据处理与评估体系的搭建

4.1 数据管道：别让IO成为训练瓶颈

数据管道的效率直接决定了GPU的利用率。我见过太多人模型写得很好，但训练速度慢得离谱，最后发现是数据加载拖了后腿。PyTorch的DataLoader提供了num_workers参数来并行加载数据，但这个参数不是越大越好。一般来说，num_workers设为CPU核心数的2到4倍比较合适。设得太大反而会因为进程间通信开销导致性能下降。

另一个关键点是数据预取。DataLoader默认会在GPU计算当前batch时，在后台预取下一个batch的数据。但如果你的数据预处理逻辑很复杂（比如动态padding、数据增强），预取可能来不及。这时候可以考虑把预处理结果缓存到磁盘，或者用更高效的数据格式（比如WebDataset、LMDB）。

class TextDataset(Dataset): def __init__(self, data_path, tokenizer, max_seq_len): self.data = [] with open(data_path) as f: for line in f: item = json.loads(line) self.data.append(item) self.tokenizer = tokenizer self.max_seq_len = max_seq_len def __len__(self): return len(self.data) def __getitem__(self, idx): item = self.data[idx] text = item["text"] tokens = self.tokenizer.encode(text, max_length=self.max_seq_len, truncation=True) input_ids = tokens[:-1] labels = tokens[1:] return { "input_ids": torch.tensor(input_ids, dtype=torch.long), "labels": torch.tensor(labels, dtype=torch.long), "attention_mask": torch.ones(len(input_ids), dtype=torch.long) } def collate_fn(batch): max_len = max(item["input_ids"].size(0) for item in batch) input_ids = torch.zeros(len(batch), max_len, dtype=torch.long) labels = torch.full((len(batch), max_len), -100, dtype=torch.long) attention_mask = torch.zeros(len(batch), max_len, dtype=torch.long) for i, item in enumerate(batch): seq_len = item["input_ids"].size(0) input_ids[i, :seq_len] = item["input_ids"] labels[i, :seq_len] = item["labels"] attention_mask[i, :seq_len] = item["attention_mask"] return { "input_ids": input_ids, "labels": labels, "attention_mask": attention_mask }

collate_fn里的动态padding是提升效率的关键。如果每个batch都padding到全局最大长度，短序列会浪费大量计算。动态padding让每个batch只padding到当前batch的最大长度，能显著减少无效计算。labels用-100填充是因为CrossEntropyLoss默认忽略这个值，这样padding位置就不会产生梯度。

4.2 评估指标：别只看loss

训练loss下降不代表模型变好了。你需要一套完整的评估体系来监控模型的真实表现。对于生成任务，我通常会看这几个指标：困惑度（Perplexity）、BLEU、ROUGE，以及人工评估的流畅度和相关性。

困惑度是语言模型最常用的指标，它本质上是交叉熵损失的指数形式：PPL = exp(loss)。困惑度越低，说明模型对数据的预测越自信。但困惑度高不一定代表模型差，可能只是数据本身多样性高。所以困惑度要结合具体任务来看。

def evaluate(model, dataloader, device): model.eval() total_loss = 0 total_tokens = 0 with torch.no_grad(): for batch in dataloader: input_ids = batch["input_ids"].to(device) labels = batch["labels"].to(device) mask = batch["attention_mask"].to(device) outputs = model(input_ids, mask) loss = F.cross_entropy( outputs.view(-1, outputs.size(-1)), labels.view(-1), ignore_index=-100, reduction='sum' ) total_loss += loss.item() total_tokens += (labels != -100).sum().item() avg_loss = total_loss / total_tokens perplexity = math.exp(avg_loss) return { "loss": avg_loss, "perplexity": perplexity }

评估时有个坑：dropout必须关闭。model.eval()会帮你做这件事，但如果你手动实现了dropout而没有正确响应training标志，评估结果会有随机性。另外，评估时用torch.no_grad()可以节省大量显存，因为不需要保存计算图。

实操心得：我习惯在训练过程中每隔一定步数跑一次验证集，把loss和困惑度记录到TensorBoard或者WandB里。这样能直观地看到模型是否过拟合。如果训练loss持续下降但验证loss开始上升，那就是过拟合的信号，需要加正则化或者早停。

5. 推理服务与性能优化实战

5.1 从模型到服务：FastAPI封装要点

训练好的模型最终要对外提供服务。我用得最多的是FastAPI，因为它轻量、异步支持好、自动生成API文档。把模型封装成服务有几个关键点：模型加载一次，常驻内存；请求批处理；超时控制。

from fastapi import FastAPI, HTTPException from pydantic import BaseModel import torch import asyncio app = FastAPI() class GenerateRequest(BaseModel): prompt: str max_length: int = 100 temperature: float = 0.7 top_k: int = 50 class GenerateResponse(BaseModel): text: str tokens_generated: int model = None tokenizer = None @app.on_event("startup") async def load_model(): global model, tokenizer model = TransformerModel.from_pretrained("checkpoints/best.pt") model.eval() model.cuda() tokenizer = Tokenizer.load("data/tokenizer.json") @app.post("/generate", response_model=GenerateResponse) async def generate(request: GenerateRequest): try: input_ids = tokenizer.encode(request.prompt) input_tensor = torch.tensor([input_ids]).cuda() with torch.no_grad(): output_ids = model.generate( input_tensor, max_length=request.max_length, temperature=request.temperature, top_k=request.top_k ) generated_text = tokenizer.decode(output_ids[0].tolist()) return GenerateResponse( text=generated_text, tokens_generated=len(output_ids[0]) - len(input_ids) ) except Exception as e: raise HTTPException(status_code=500, detail=str(e))

@app.on_event("startup")确保模型在服务启动时加载一次，而不是每次请求都加载。这个细节看似简单，但我见过有人在请求处理函数里加载模型，结果每个请求都要等几十秒，完全不可用。

5.2 推理加速：KV Cache与量化

自回归生成有个特点：每生成一个token，都需要重新计算整个序列的注意力。这导致生成100个token的计算量是生成1个token的100倍。KV Cache技术通过缓存之前token的Key和Value矩阵，避免了重复计算。这是推理加速中最重要的一步，没有之一。

class CachedAttention(nn.Module): def forward(self, x, past_kv=None, use_cache=False): q = self.q_proj(x) k = self.k_proj(x) v = self.v_proj(x) if past_kv is not None: past_k, past_v = past_kv k = torch.cat([past_k, k], dim=1) v = torch.cat([past_v, v], dim=1) new_kv = (k, v) if use_cache else None # 注意力计算... return output, new_kv

KV Cache的代价是显存占用。序列越长，缓存越大。对于长序列生成，你可能需要限制缓存的最大长度，或者用滑动窗口的方式只保留最近的K个token的缓存。

量化是另一个重要的优化手段。把模型权重从FP16降到INT8，显存占用减半，推理速度提升30%到50%，精度损失通常在1%以内。PyTorch提供了torch.quantization模块，但实际用起来坑不少。我的建议是先用动态量化（torch.quantization.quantize_dynamic）试试水，效果满意再考虑静态量化。

注意：量化后的模型在CPU上推理效果最好，GPU上需要特定的算子支持。如果你主要用GPU推理，建议先确认你的PyTorch版本和CUDA版本是否支持INT8算子。

6. 常见问题排查与避坑指南

6.1 训练不收敛：从loss曲线读出的信号

训练不收敛是最常见也最让人头疼的问题。我的排查顺序是这样的：先看loss曲线形态，再查梯度，最后查数据。

如果loss从一开始就震荡剧烈，大概率是学习率太大。把学习率降低10倍试试。如果loss下降很慢或者不下降，可能是学习率太小，或者模型初始化有问题。如果loss先下降后突然飙升，通常是梯度爆炸，加梯度裁剪。如果loss下降但验证集不降，那是过拟合，加dropout或者权重衰减。

梯度检查是定位问题的关键。在loss.backward()之后、optimizer.step()之前，打印每一层梯度的范数：

for name, param in model.named_parameters(): if param.grad is not None: grad_norm = param.grad.norm().item() if grad_norm > 10 or grad_norm < 1e-7: print(f"异常梯度: {name}, norm={grad_norm:.2e}")

如果某一层的梯度范数异常大，说明那一层可能是问题源头。常见的原因包括：初始化方差不对、学习率对该层太大、该层的输入分布有问题。

6.2 显存爆炸：从batch size到梯度检查点

显存不够用是另一个高频问题。很多人第一反应是减小batch size，但这会影响训练稳定性。其实有几个更优雅的解决方案。

梯度检查点（Gradient Checkpointing）是用时间换显存的经典方法。它在前向传播时不保存中间激活值，而是在反向传播时重新计算。这能把显存占用降低60%到70%，代价是训练速度慢20%到30%。PyTorch提供了torch.utils.checkpoint.checkpoint函数，用起来很简单：

from torch.utils.checkpoint import checkpoint class TransformerBlock(nn.Module): def forward(self, x, mask): # 用checkpoint包裹注意力层和前馈层 x = checkpoint(self.attention, x, mask) x = checkpoint(self.feed_forward, x) return x

混合精度训练（AMP）是另一个利器。用FP16做前向和反向计算，FP32做参数更新，显存占用减半，速度还能提升。PyTorch的torch.cuda.amp模块让这件事变得非常简单：

scaler = torch.cuda.amp.GradScaler() for batch in dataloader: with torch.cuda.amp.autocast(): outputs = model(input_ids, mask) loss = criterion(outputs, labels) scaler.scale(loss).backward() scaler.unscale_(optimizer) torch.nn.utils.clip_grad_norm_(model.parameters(), 1.0) scaler.step(optimizer) scaler.update() optimizer.zero_grad()

注意scaler.unscale_必须在梯度裁剪之前调用，否则你裁剪的是被缩放过的梯度，阈值就不准了。

6.3 常见问题速查表

实操心得：我习惯在训练脚本里加一个“健康检查”函数，在每个epoch开始时跑一遍，检查模型参数是否有NaN、梯度是否正常、数据加载是否正常。这个习惯帮我提前发现了无数次潜在问题，省下了大量重启训练的时间。

7. 我在这条路上踩过的几个大坑

第一个坑是盲目追求大模型。刚开始的时候总觉得参数越多效果越好，结果用单卡训练一个几亿参数的模型，一个epoch要跑好几天，调参周期长得离谱。后来才明白，在数据量有限的情况下，小模型加上好的数据清洗和训练策略，效果往往比大模型更好。模型大小要和数据量、计算资源匹配，这是我从零搭建AI工程学到的第一课。

第二个坑是忽略数据质量。有段时间我花了两周优化模型结构，效果提升不到2%。后来花了一天时间清洗数据，去掉了重复样本和低质量文本，效果直接提升了8%。这件事让我深刻认识到，在AI工程里，数据的价值往往大于模型。你可以在模型上少花点时间，但在数据上绝对不能偷懒。

第三个坑是不做版本管理。模型权重、配置文件、训练日志、评估结果，这些东西如果没有系统的版本管理，过两周你自己都记不清哪个模型对应哪次实验。我现在用git管理代码，用DVC管理数据和模型权重，用WandB记录实验指标。这套组合拳打下来，任何一次实验都能完整复现。

第四个坑是过早优化推理性能。模型还没训练好就开始折腾量化、剪枝、蒸馏，结果模型效果本身就不行，优化了也是白搭。正确的顺序是：先把模型效果调到位，再考虑推理优化。效果是1，性能是后面的0，没有1，再多0也没用。

8. 后续可以继续深挖的方向

把基础版本跑通之后，有几个方向值得继续深入。分布式训练是第一个，当你需要训练更大的模型或者用更多的数据时，单卡就不够用了。PyTorch DDP是最常用的方案，核心思想是每个GPU持有一份完整的模型副本，梯度通过all-reduce操作同步。理解all-reduce的原理和通信开销，对优化分布式训练效率很有帮助。

模型压缩是第二个方向。除了量化和剪枝，还有低秩分解、知识蒸馏、神经架构搜索等技术。每一种都有适用的场景，比如知识蒸馏适合把大模型的能力迁移到小模型上，低秩分解适合压缩全连接层。

持续学习是第三个方向。真实场景中数据分布会随时间变化，模型需要不断更新而不能遗忘旧知识。这方面有弹性权重巩固、经验回放等方法，目前还没有完美的解决方案，是一个活跃的研究领域。

可解释性是第四个方向。当模型做出错误决策时，你需要知道为什么。注意力可视化、梯度归因、SHAP值这些工具能帮你理解模型的决策依据。这在医疗、金融等高风险领域尤其重要。

我自己目前重点在分布式训练和模型压缩这两个方向上折腾，踩了不少新坑，等整理清楚了再单独写一篇分享。从零搭建AI工程这件事，入门曲线确实陡，但一旦你把整条链路跑通一遍，后面再学任何新模型、新框架都会快很多，因为底层的东西是相通的。