# `services/` — 独立部署的 AI 能力服务

架构 §3.2：业务域做单体，**AI 能力做独立服务**。理由是资源画像完全不同 ——
GPU 依赖、模型文件体积、推理并发模型、扩缩容节奏。混在一个进程里会导致
「换装排队把 API 拖慢」。

| 目录 | 服务 | 资源 | 状态 |
| --- | --- | --- | --- |
| `vision/` | 人像分割、人体关键点、色值采样、体型测算、人脸属性 | CPU + ONNX | 占位 |
| `matting/` | BiRefNet 批量抠图 + 白底标准化 + 规格校验 | GPU（按需） | 占位 |
| `tryon/` | 换装三工作流、发型更换与发色 | GPU | 占位（现有服务改造纳管） |

## 本地有 RTX 5090

开发机带一块 **RTX 5090（32GB VRAM）**。`vision` 的 RTMPose ONNX 推理
（TD-05/TD-06）与 `matting` 的 BiRefNet 抠图（TD-07）**完全可以在本地开发、
调参和跑批，不需要租云 GPU**。素材生产期的批量抠图也可以先在本地跑通再决定
要不要上云。

## 服务边界规矩

- 对上以**内部 API** 暴露，不共享进程内存。即使 V1 某个能力先做成进程内包，
  接口也要按远程调用设计（明确超时、可序列化的入参出参）。
- 服务间调用必须带**服务间令牌**，且只允许内网访问（架构 §4.4）。
- 每次推理必须返回**资源消耗**（如 `gpu_seconds`）与**模型/工作流版本号**，
  否则成本无法归因、效果变化无法回溯。
- 接受 `idempotency_key`，重复提交返回同一结果。
- 明确对外暴露**最大并发数**，让上游队列按容量限流。

## 不能放什么

- 业务判断。这里只做推理，「该不该做这次推理」是业务域的事。
- 直接访问业务库。需要数据由调用方传入。