深度图 API：自建还是购买，账单里到底包含什么

深度 API 接收图像并返回深度表示。契约应说清接受什么格式、最大多大、返回什么文件、预计等待多久、有哪些失败状态，以及输出如何保留。任何一个问题含糊不清，集成都可能直到真实客户使用时才发现限制。

DepthCarve 的服务器间端点接受不超过 1.5 MB 的压缩图片 data URI，返回临时深度图 URL，每个成功请求使用一个积分，并按 API key 限流。公开 OpenAPI 用来说明请求与响应，客户端可以据此建立有类型的调用封装，而不是从界面猜接口。

同步请求有时十秒、有时两分钟，前端就很难提供稳定预期。任务 ID 加轮询或回调通常更容易管理变化的耗时，但也引入排队、处理中、成功、失败和积分已返还等状态。每个非终态都应有等待边界和恢复办法，而不是一直显示正在处理。

如果 Worker 在预留积分之后、收到服务商任务 ID 之前终止，数据库里就可能留下永远处理中的记录。系统需要对账扫描，关闭过期记录并对原扣款做幂等返还。这个恢复机制处理的是一次真实的状态中断，不能拿一个定时任务当作服务商永远不会出错的承诺。

一个可用的任务契约应提供稳定 ID、状态、创建时间和终态错误码，让客户端不读日志也能回答：是否仍在运行，是否成功，失败后积分如何处理。只能回答 processing 的接口，会把所有不确定性都推给客服。

重试不应该重复收费。常见可靠模式是把客户端幂等键映射到服务端任务，并让每个任务对应唯一扣积分记录；确认服务商失败后，再对同一笔记录创建唯一返还。扣款和返还应是各自可追踪的账本条目，重复回调不能产生第二次收费或返还。

出售积分时，账本是余额依据。若使用次数只是独立计数、没有与账本核对，两个数字迟早会偏离。客户先看到自己少了一次使用机会，监控面板才发现问题，这样的支持成本往往高于一次模型调用。

把幂等键与任务关联，并在数据库建立唯一约束，不能只放在进程内存。两个 Worker 可能同时收到同一次重试，只有数据层约束才能守住单次扣款。再次提交同一个键时，应返回原任务；至于某个具体端点是否支持这种保证，必须以它公布的契约为准。

模型服务商经常返回会过期的签名 URL。产品可以把输出复制到自己的存储，也可以明确要求客户及时下载。前者增加存储费用与保留责任，后者意味着链接过期后需要更清楚的解释和支持，两种选择都应该在交付前说清。

DepthCarve 的服务商链接是临时的，浏览器生成的 ZIP 不由服务端长期保存；源链接仍有效时，可以重新构建下载包而不再次调用模型。如果你的产品需要长期留存，应为对象存储、权限和生命周期规则单独预算，不要把临时 URL 当作永久资产地址。

模型报价只是其中一项。还要计算失败调用、重试、闲置算力、存储、出站流量、客服，以及维护健康队列所需的工程时间。低单价但失败较多的模型，在需要重试或返还时，整体可能比更稳定的方案昂贵。

应该在把返还和重试计入后，计算每个成功任务的成本；对业务来说，更进一步还要看最终可用交付。只有这个数字，才真正回答现有售价能否覆盖服务，而不是只解释服务商账单的一行。

按服务商记录请求数、成功数、确认失败数和完成耗时中位数。一个单次便宜、却慢到诱发客户不断重试的接口，仍可能占据大部分成本。除了月账单，还应关注失败率和最老排队任务的年龄。

估算集成前，先列清应用真正需要的输出。公开深度端点与浏览器批准的生产任务是不同契约：临时深度图 URL 不会自动成为包含 EXR、验证 PNG 对和水密 STL 的 ZIP。应用如果需要这些额外产物，应核对端点响应，明确补齐处理步骤，或在适合的场景使用浏览器流程。不能从下载面板截图推断 API 具备所有能力。

发送真实客户图片前，为客户端写一张小验收表：有效小图片、格式错误、超大请求、认证失败、额度限制和上游超时都要检查。提前决定哪些错误可安全重试、哪些必须修改输入。坏输入重复发送只会再次失败，而没有明确幂等保证时，超时付费请求直接重发可能产生第二个计费操作。

重试应同时受次数和总截止时间限制。遇到限流要遵守等待规则，不能让每个会话都并行重试。如果接口在超时后不能查询原操作，就先呈现状态未确认，取得可靠状态后再决定下一步；不要先向客户保证已退款，或自动再发一次付费请求。明确说明不确定性，同时提供请求引用和下一步，仍然是有帮助的体验。

用一轮实测小规模接入计算自建和采购成本，并写清没有计入的项目。把成功输出、失败尝试、存储副本、出站费用和客服时间加总，再除以可用交付数量。工程投入与推理现金成本分别记录，避免小团队把无人计时的维护误当免费。随着规模变化，选择可以改变，但依据仍应是契约、失败行为与每个可用结果的成本。

当深度能力是核心差异、规模足以支持专门团队，且确实需要控制模型、数据路径或延迟时，自建更有理由。深度只是辅助能力，而真正困难的是账号、支付、审核和客户服务时，采购能把时间留给自己的产品问题。

中间路线是自己建设产品体验，把推理交给服务商。DepthCarve 的工作台、审核步骤、积分账本和下载包契约由产品实现，推理则依赖外部服务与明确的失败恢复路径。这样的分工仍要求检查服务商故障，并不能免除对客户交付负责。

还应有一份可执行的退出计划：服务商涨价或停用模型时，能否在不改变客户契约的情况下替换？把模型调用集中在一个清楚的适配入口，按任务记录服务商，迁移结果才可比较。模型版本也值得记录；服务商静默升级时，即使接口没有改变，实际输出也可能发生变化。