docker-compose brings up PostgreSQL 16 with pgvector and Redis 7 on non-standard host ports so it never collides with an existing local database. scripts/smoke.sh is the proof: compose, migrate, boot the API, issue a token, call the real DeepSeek API and print the resulting ob_ai_call and bl_ledger rows. services/vision and services/matting are placeholders noting that the local RTX 5090 makes BiRefNet and RTMPose developable without cloud GPU.
1.7 KiB
Executable File
1.7 KiB
Executable File
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,重复提交返回同一结果。 - 明确对外暴露最大并发数,让上游队列按容量限流。
不能放什么
- 业务判断。这里只做推理,「该不该做这次推理」是业务域的事。
- 直接访问业务库。需要数据由调用方传入。