运营中心深度学习优化：交互响应提速40%

文章配图，仅供参考

　　我原以为改 batch_size 就完事——结果测到第十七版 inference service 启动脚本时发现，PyTorch 的 torch.jit.script 在 warmup 阶段会偷偷做两次图重写，第二次重写卡在 CUDA graph capture 的 lock 里，足足十八秒。但这个我敢打包票：你用 2.1.0+cu121，不手动 disable_cuda_graph=True，它就在那儿等你凌晨三点手抖点重试。我删了 warmup loop，把 init_model() 拆成两步：第一步 load_state_dict（快），第二步 dummy_forward（慢但只跑一次），然后用 subprocess.Popen 给它锁死生命周期——不是为性能，是怕它跟 Django 的 async view 碰上，抢同一个 uvloop event loop，最后两个线程互相 defer 直到 timeout。谁的手机响了一声没接，屏幕亮着，钉钉图标上红点叠了三层，我认出是后端老李的——他上个月提过要切掉 Flask 上的 /v1/predict 接口，现在还挂着。

　　提速四成？是的。但不是靠换模型，也不是 quantize，是把原来每次请求都 reload 的 embedding layer 缓存在 shared memory 里，用 mmap + fcntl 锁住偏移位，让三个 worker 进程共享同一块 tensor buffer。这个改动上线那天，老板在周会上拍桌子说「你们到底动了什么？」——我当着所有人面 ssh 进生产机器，cat /proc/$(pgrep -f 'gunicorn.opcenter')/maps | grep shm，指给他看 0x7f8... 开头那行 rw-p 的地址，说「就这儿，三十兆，没别的」。他愣了三秒，掏出保温杯喝了一口，杯底磕在会议桌角上，叮。对面工位那个新来的工程师，上周换了双灰色洞洞拖鞋，左脚带一个塑料搭扣，咔哒响了一整天。

　　真正省时间的其实是砍掉了两层校验：一是前端传过来的 operator_id 校验不再走 Redis pipeline，改成本地 LRU cache + 每五分钟异步 refresh；二是特征预处理里那堆 pandas.isna() 全干掉，换成 np.isnan(x.astype(np.float32))。后者省下七百毫秒不是因为 numpy 快，是因为 pandas 默认对 object 类型做 type inference，而我们字段名里有个叫「source_type_v2_flag」的列，值是「0」「1」「NULL」混着——pandas 一看有字符串就全推成 object，再 isna 就得遍历每一个 Python str 对象。我说不准是不是所有环境都这样，但我们线上集群，只要列名含「_v2」或「_flag」，pandas 准保掉坑。去年十二月我在 staging 调这事儿调了两天半，最后发现是 Airflow 调度任务里多写了句 set_env('PYTHONPATH', '/opt/app/lib')，把旧版 pandas 加进路径了。咖啡洒在工牌上，褐色圆渍边缘裂开细纹，像服务器 rack 上某块没插稳的 NVMe 硬盘的散热贴纸。

　　优胜劣汰？对。不是模型之间的淘汰，是代码里的活路和死路之间的淘汰。你留着那串 for row in df.itertuples(): if pd.isna(row.x): continue —— 它就等着你在 QPS 到 3800 的时候，在某个周五下午四点十三分，把整个运营中心的 AB 测试流量打穿。删掉它，不是因为你懂向量化，是你被罚抄过三遍 pandas docs 里那句「Itertuples is faster than iterrows, but slower than vectorized operations」。但这话现在听就像笑话：vectorized operations？我们连 null 处理都没 vectorized，还在拿 python 的 if 去套 numpy 的 mask。

　　上周五排班表出来了，我调休申请又被驳回，理由是「核心模块值守人力缺口」。我也没犟，直接把 jenkins-job-ops-center-inference-build 的 cron 改成每天 4:03 AM 触发，而不是原来那个讨喜的 2:00 AM——反正凌晨四点，除了告警机器人和值班 DBA，没人看构建日志。老张上月说他闺女小升初报名系统崩了三次，全因教育局用的是 Vue 2 + Element UI 写的前端，「一选学校就卡，卡得比我们查慢查询还稳」。他边说边把手里那包没拆封的速溶咖啡撕开，倒进马克杯，热水一冲，粉粒沉底，像一堆未 GC 的弱引用。

　　下一步？先把 torch._dynamo.config.cache_size_limit 从 64 调到 128。别问我为什么是 128——我试过 256，CI 过不去，报错是「torch._dynamo.exc.InternalTorchDynamoError: graph break due to unsupported list operation on symbolic list」，但 error traceback 里第十七行引用的是 transformers==4.36.2 里的 modeling_llama.py 第 298 行，而那行根本不存在。这事我懒得查，先缩回去再说。至于 embedding 缓存那块……下周抽半天，试试把 mmap 换成 cudaHostAlloc，不为加速，就为以后换 A100 时不重写整套 IPC 逻辑。当然，如果老板真批了那台 A100——我看悬。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!