同一套镜像，三种编排方案，对应三类交付场景：客户单机 VM、内部集群、云托管 Kubernetes。基础设施依赖完全一致，差异只在调度层与资源声明方式。
以客户 VM 的 Compose 方案为基准，这是最完整也最能看清依赖关系的形态。
仓库中仍保留 src/vllm 目录、本地 GPU 模型部署脚本，以及客户 VM 模板中基于 8 张 A100 的资源规划注释。这些属于早期内网自建推理服务方案，当前生产已全面改用 Foundry 托管模型，内网仅保留 Document Intelligence。阅读部署材料时须区分，勿按 GPU 方案准备硬件。
这是运维时最容易误判的一点。个人工作区抽取出的事实数据，不以 Postgres 表形式存储。
查询侧依赖 DuckDB 原生动态库。托管 NuGet 包不含原生库文件，若镜像未内置，表现为写入正常、元数据行数正确，但读取接口返回 500、前端显示「暂无数据」。这个故障形态具有欺骗性——日志与元数据都显示成功，只有实际读取才暴露。镜像重建后需确认该依赖仍在。