GitHub Actions 管理 TensorFlow 模型产物：Spring Boot 零...-育师

GitHub Actions 管理 TensorFlow 模型产物：Spring Boot 零停机热切换的生产实践

上周三凌晨两点，风控评分服务连续触发三次 OOM Kill，K8s 事件日志里写着tensorflow_model_v47.safetensors加载阶段堆外内存飙到 4.2GB。排查到 GitHub 上那个 TF 模型仓库时才发现：最近一周模型迭代了 5 个版本，CI 流水线没做产物大小校验，直接把 3.8GB 的完整 checkpoint 推到了制品库。服务侧 Spring Boot 每次启动都全量加载，根本扛不住。

业务背景与现有架构

这套金融反欺诈评分系统跑在 Spring Boot 3.2.5 + JDK 17.0.12 上，模型推理层基于 TensorFlow 2.15.1 的 SavedModel 格式。模型训练在 GPU 集群完成，产物通过 GitHub Actions 流水线打包后推送到内部制品库，Spring Boot 服务启动时从制品库拉取并加载到内存。之前模型迭代频率低（月均 1-2 次），全量加载没问题。但 Q3 业务方要求模型周更甚至日更，老架构直接崩了。

踩坑与排查

问题链条拆开看有三层：

第一层：GitHub Actions 产物无约束。训练侧同学往tensorflow/fraud-model仓库推 checkpoint，没加 size guard。一次实验性跑通把 embedding 层维度从 128 扩到 512，产物从 900MB 膨胀到 3.8GB，CI 照推不误。

第二层：Spring Boot 侧全量加载无缓存。模型服务每次 Pod 重启都执行tf.importGraphDef()整个 SavedModel，没有增量机制。K8s 滚动更新时新旧 Pod 同时存在，内存直接翻倍。

第三层：没有灰度切换。模型版本切换是"一把梭"——新版本拉下来、旧版本 GC 掉，中间有 2-3 秒推理延迟毛刺，风控场景下等于放过了一批可疑交易。

改造方案

核心思路：把模型从"应用启动依赖"变成"运行时可替换资源"。

GitHub Actions 侧加两道闸：

```yaml

.github/workflows/model-publish.yml（tensorflow/fraud-model 仓库）

name: Model Artifact Publish
on:
push:
tags: ['v*']

jobs:
build-and-verify:
runs-on: ubuntu-latest
steps:

uses: actions/checkout@v4
name: Export SavedModel

run: python export_savedmodel.py --output ./dist/fraud_${{ github.ref_name }}

name: Size Guard

run: |
SIZE_MB=$(du -sm ./dist/ | cut -f1)
if [ "$SIZE_MB" -gt "512" ]; then
echo "ERROR: artifact exceeds 512MB limit"
exit 1
fi

name: SHA256 Checksum

run: |
sha256sum ./dist/fraud_*.savedmodel > ./dist/SHA256
cat ./dist/SHA256

name: Upload Artifact

uses: actions/upload-artifact@v4
with:
name: fraud-model-${{ github.ref_name }}
path: dist/
retention-days: 30
```

Spring Boot 侧用 Caffeine 3.1.8 做模型本地缓存 + 双缓冲热切换：

```java
@Component
public class ModelHotSwapper {
private final Cache activeCache =
Caffeine.newBuilder().maximumSize(4).expireAfterAccess(10, TimeUnit.SECONDS).build();
private volatile String currentVersion = "v46";

@Scheduled(fixedDelay = 60_000)
public void pollAndSwap() {
String latest = artifactClient.fetchLatestVersion();
if (latest.equals(currentVersion)) return;
// 双缓冲：先加载新版到备用槽，校验 SHA256 通过后原子切换
byte[] artifact = artifactClient.download(latest);
verifyChecksum(artifact, artifactClient.fetchSha256(latest));
TensorFlowModel newModel = SavedModelLoader.load(artifact);
activeCache.put("active_" + latest, newModel);
String old = currentVersion;
currentVersion = latest;
activeCache.invalidate("active_" + old);
}

public ScoreResult infer(FeatureVector input) {
String key = "active_" + currentVersion;
TensorFlowModel model = activeCache.getIfPresent(key);
if (model == null) model = activeCache.get(key, k -> fallbackModel());
return model.predict(input);
}
}
```

这里有个细节值得说：双缓冲期间新旧模型共存，峰值内存 = 2 × 单模型大小。我们把模型体积卡在 512MB，双缓冲就是 1GB，Pod 给 2GB memory limit 刚好够，留了余量给 JIT 和 Metaspace。

方案对比：

| 维度 | 旧方案（全量启动加载） | 双缓冲热切换 | 模型外置 TF Serving 容器 |
|------|----------------------|-------------|------------------------|
| 切换停机时间 | Pod 重启 15-30s | 0s（原子指针切换） | 0s |
| 峰值内存 | 单模型 | 2×单模型 | 单模型（独立容器） |
| 运维复杂度 | 低 | 中（需管理缓存驱逐与校验） | 高（多一个 K8s 服务 + 网络调用） |
| 适用场景 | 月更模型 | 周更/日更模型 | 多团队共用同一模型服务 |

TF Serving 方案虽然社区文档里推荐得多，但对我们当前"一微服务绑一模型"的拓扑来说，多起 3 个容器反而增加网络跳数和排障链路。进程内双缓冲在当前规模下更简单可控，不必为了"架构纯洁性"引入额外组件。