调参调到凌晨三点，我悟了：三线城市也能玩转AI模型训练调优
上周五晚上十点半，办公室只剩下我和运维老王——他还在修一个因为GPU显存爆掉而宕机的训练服务器。我靠在工位上，看着 TensorBoard 里那个卡在 0.73 准确率死活不动的曲线，心里默默骂了一句：“产品经理能不能别再临时改需求了？”
我是谁？刚跳槽到这家三线城市互联网公司两个月的技术负责人，早上八点雷打不动到公司，喜欢在咖啡还没凉之前把当天最难啃的代码啃完。以前在一线大厂卷惯了，以为来了小城市能躺平，结果发现：业务没变少，预算反而更紧了。
项目背景：一个“看起来很简单”的推荐需求
事情起因是上个月产品提了个“轻量级智能推荐”需求，说是为了提升首页点击率。听起来人畜无害对吧？但实际数据一拉出来，我人都傻了：
- 用户行为日志稀疏得像沙漠
- 商品类目只有不到500个，但冷启动问题严重
- 历史数据里80%是新用户，根本没有长期行为序列
最离谱的是，产品给的 deadline 是两周后上线，还附带一句：“你们不是有 AI 吗？随便训个模型不就行了？”
呵，随便训个模型？你行你来。
我们团队总共就三个算法工程师（包括我自己），其中两个还是应届生。资源方面，公司只批了两台 2080Ti 的训练机，连个像样的标注平台都没有。在这种条件下搞模型训练，真的像是用拖拉机跑 F1 赛道。
第一次翻车：盲目上 BERT，显存直接 OOM
一开始我想走捷径，直接套了个 DistilBERT 做用户兴趣建模。心想：反正现在都流行大模型，小一点的也够用了吧？
结果第一天训练就炸了。日志里清清楚楚写着：
CUDA out of memory. Tried to allocate 2.10 GiB...
我盯着屏幕，内心 OS：DistilBERT 啊兄弟，你明明叫 “Distil”（蒸馏），怎么比原版还贪吃？
后来一查才知道，虽然模型参数少，但我们的输入序列长度设得太长（为了兼容未来扩展），batch_size 又不敢调太小（怕梯度不稳定），显存直接干爆。
踩坑总结1：别迷信“轻量级”，要看实际输入和 batch 配置。
转向务实：从 FM 到 DeepFM，稳字当头
痛定思痛，我决定放弃花里胡哨的 NLP 大模型，回归推荐系统的经典套路。毕竟我们做的是 CTR 预估，不是文本生成。
于是我们试了 Factorization Machine（FM）。代码简单，训练快，两小时就能跑完一轮。效果嘛……AUC 0.71，勉强能看，但离产品想要的“显著提升”差得远。
接着我们上了 DeepFM——既有 FM 的特征交叉能力，又有 DNN 的非线性表达。这次配置小心多了：
# 模型关键配置
embedding_dim = 16
dnn_hidden_units = [128, 64, 32]
l2_reg_embedding = 1e-5
batch_size = 256 # 再也不敢上 512 了
训练过程居然出奇顺利。三天迭代了五个版本，AUC 稳步爬到 0.78。产品看了 demo 终于露出“这还差不多”的表情。
但问题又来了：线上推理延迟太高。测试同学反馈，P99 延迟 180ms，而我们的 SLA 要求是 <100ms。
原来 DeepFM 虽然准，但全连接层太多，加上 embedding lookup 密集，在 CPU 上跑得慢如蜗牛。
调优实战：不是调参，是“调命”
接下来一周，我基本住在了 Jupyter Notebook 里。以下是我踩过的几个经典坑，供大家避雷：
1. 学习率不是越小越好
一开始我用 Adam(lr=1e-4)，想着“慢慢学更稳”。结果模型三天没收敛。换成 3e-4 后，loss 一天就降下去了。后来查论文才知道，CTR 模型普遍用 1e-3 到 3e-4 之间，太小反而陷在局部最优。
2. 正则化要“恰到好处”
L2 正则一开始设成 1e-3，模型欠拟合；降到 1e-6，又过拟合了。最后发现 1e-5 最平衡。别信默认值，每个数据集都要试。
3. 特征工程比模型结构更重要
我们加了一个“用户最近点击品类占比”的交叉特征，AUC 直接 +0.02。而换了个更复杂的 DIN 模型，只涨了 0.005。那一刻我悟了：在中小数据集上，好特征 > 复杂模型。
4. 早停（Early Stopping）救我狗命
以前总觉得早停是偷懒，直到这次看到验证集 loss 连续 5 轮不降，果断停训。省了两天 GPU 时间，还避免了过拟合。现在我把 patience=5 写进了所有训练脚本的默认配置。
效果对比：从“能用”到“真香”
最终上线前，我们做了几轮 A/B Test，核心指标如下：
| 模型 | AUC | P99 延迟 (ms) | 训练时间（单轮） | 显存占用 |
|---|---|---|---|---|
| LR | 0.69 | 45 | 20min | 2GB |
| FM | 0.71 | 60 | 1.5h | 4GB |
| DeepFM | 0.78 | 180 | 6h | 9GB |
| 优化版 DeepFM | 0.775 | 92 | 4h | 7GB |
注：优化版通过减少 embedding 维度、剪枝 DNN 层、量化推理实现
虽然 AUC 微跌 0.005，但延迟达标了！产品、测试、运维都松了口气。上线后首周 CTR 提升 12%，老板在周会上夸我们“技术驱动业务”，笑得我差点把咖啡喷出来。
心得体会：三线城市的 AI 实战哲学
干了这么多年技术，我越来越觉得：AI 不是炫技，是解决问题。尤其在资源有限的小公司，更要讲究“性价比”。
- 别被 SOTA（State-of-the-Art）绑架：最新的不一定最适合你。我们的业务场景、数据规模、工程约束，决定了“够用就好”。
- 算法工程师得懂工程：光会调 sklearn 不行，得知道模型怎么部署、怎么压测、怎么监控。上周我还帮运维写了段 Prometheus exporter 来监控推理 QPS。
- 和产品沟通要“翻译”：他们说的“智能推荐”，可能只是想要个加权热门榜。先做 MVP 验证价值，再考虑上复杂模型。
最后说句实在话：在三线城市搞 AI，确实没大厂那么多算力和人才，但限制反而逼你更务实。没有无限 GPU，你就得学会精打细算；没有百人算法团队，你就得自己既写模型又调服务。
上周五加班到凌晨三点，终于搞定模型上线。回家路上，天刚蒙蒙亮。我一边骑共享单车一边想：这破 city 虽然小，但只要肯折腾，一样能跑出不错的 AI 项目。
对了，今天周一，我又八点到了公司——因为产品说，下个版本要上“实时个性化”。唉，我的 2080Ti，又要哭了。
评论 0