ML 워크로드 네트워크 효율화 (1편): Feature Trimmer

Pinterest의 online ML serving은 root-leaf architecture로 동작한다. root가 feature store에서 features를 가져와 전처리하고, leaf가 GPU에서 inference를 수행한다. 문제는 root에서 leaf로 넘기는 features가 너무 많아 네트워크가 먼저 병목이 됐고, leaf의 peak network usage가 GPU SM activity보다 높았다. root는 SLA를 맞추기 위해 네트워크 최적화된 m6in 인스턴스를 써야 했다.

먼저 lz4 compression을 fbthrift RPC에 적용해 root-leaf network usage를 20% 줄였다. 대신 CPU는 5% 늘고 p90 latency는 5ms(약 10%) 증가했다. 압축은 유효했지만, 사용하지 않는 data를 계속 보내는 구조 자체는 그대로였다.

해법은 Feature Trimmer였다. root는 각 leaf model의 model signature를 source of truth로 삼아 필요한 feature만 allowlist하고 나머지를 제거한다. signature는 TorchScript .pt archive의 module_info.json에 들어가며, signature가 바뀌면 새 model을 fork해 versioned lookup과 fallback을 안전하게 유지한다.

동기화는 deployment pipeline 안에서 처리한다.

• training 단계에서 module_info.json을 standalone artifact로 내보낸다.
• bundle build 단계에서 per-model signature를 모아 bundle-level mapping을 만든다.
• root configs는 Canary → ACA → Production 순으로 배포한다.
• signature가 없으면 build를 실패시키지 않고 경고 후 건너뛴다.

이 방식은 model bundle이 여러 개이고 rollout/rollback이 독립적으로 돌아가도 trimming 기준을 유지하게 해준다. allowlist는 blocklist보다 관리 부담이 작고, root와 leaf의 배포 cadence가 달라도 안전하게 따라갈 수 있다.