Límite de evidencia
Una referencia de contrato público, no un diagrama de infraestructura privada
Úselo para decidir dónde deben residir la propiedad, la validación, el estado de la tarea, el reintento, la liquidación, la entrega, la eliminación y la evidencia en su propia integración. Para campos y respuestas exactos de varias partes, use el Documentación de API y contrato OpenAPI 3.1. Para los conceptos de investigación dentro de la localización facial, transferencia de identidad, síntesis, combinación y consistencia de video, lea cómo funciona el intercambio de rostros por IA.
Contrato público verificado
Cinco flujos de trabajo asíncronos comparten una forma de control
Cada flujo de trabajo de generación actual se autentica con una clave Bearer API, acepta medios de varias partes, devuelve un taskIdy expone el estado con ámbito de propietario a través de GET en la misma ruta. La finalización utiliza sondeo; las devoluciones de llamada webhook y los SDK de idioma oficiales no se publican actualmente.
| Flujo de trabajo | POST y GET de sondeo | Unidad de costo | Límite principal |
|---|---|---|---|
| Foto | /api/ai-tasks | 3 créditos por tarea | 30 MB por imagen |
| Foto por lote | /api/ai-tasks/batch-face-swap | 3 créditos por salida | 20 imágenes, 95 MB combinados |
| Foto grupal asignada | /api/ai-tasks/multi-face-swap | 3 créditos por rostro de reemplazo | 10 rostros mapeados, 95 MB combinados |
| Video | /api/ai-tasks/video | Solo rostro con preservación de escena: 1/s, mínimo 5 en 1080p | 600 segundos, 95 MB de carga combinada |
| GIF / clip corto | /api/ai-tasks/gif | 1 crédito por segundo, mínimo 5 | 30 segundos, 95 MB de destino |
El espacio de trabajo en vivo y la documentación de API siguen siendo autoritativos para formatos exactos, cargos mínimos y campos de solicitud. Se requiere una cuenta de correo electrónico verificada, una generación puede estar activa por cuenta y los límites agotados pueden devolver HTTP 429 con información de reintento.
Arquitectura de referencia
Dar a cada decisión irreversible un propietario
Ingreso e identidad
Terminar TLS, autenticar la clave mantenida en el servidor, asignar un ID de correlación de solicitud y vincular cada tarea a una cuenta.
Política y validación
Verificar el estado del permiso, los campos del flujo de trabajo, el tipo de medio detectado, el tamaño en bytes, el recuento, la duración, el mapeo, la preparación de la cuenta y la disponibilidad de crédito.
Libro mayor de tareas
Persistir el taskId, propietario, flujo de trabajo, cargo esperado, transiciones de estado, marcas de tiempo y resultado de liquidación antes de devolver el control.
Procesamiento limitado
Desacoplar la aceptación de la solicitud de la generación, limitar el trabajo activo y distinguir los fallos de transporte reintentables de las entradas no válidas.
Liquidación
Usar una autoridad atómica para las decisiones de reserva, finalización y reembolso de tareas fallidas para que un reintento no pueda cobrar o reembolsar dos veces.
Entrega y eliminación
Autorizar el acceso al resultado por propietario de la tarea, aplicar el derecho de exportación de imágenes y remove los medios según el cronograma documentado de 24 horas.
Secuencia de solicitud de ocho pasos
ReMove desde el contrato de solicitud hasta la eliminación respaldada por evidencia
- Congelar el contrato de solicitud pública. Elegir el flujo de trabajo exacto y registrar campos, límites de medios, unidad de costo y estados terminales.
- Controlar autorización, consentimiento y preparación de la cuenta. Mantener la clave API del lado del servidor y requerir una decisión de permiso antes de aceptar medios.
- Validar medios y calcular el costo antes de poner en cola. Inspeccionar el tipo detectado, tamaño, recuento, duración, mapeo y créditos disponibles antes del trabajo costoso.
- Crear un registro de tarea duradero. Persistir propiedad, flujo de trabajo, cargo esperado, referencias de entrada, estado y taskId.
- Procesar asincrónicamente detrás de una cola limitada. Limitar la concurrencia y clasificar fallos transitorios frente a permanentes.
- Liquidar créditos exactamente una vez. Comprometer el trabajo completado y aplicar la ruta de reembolso de procesamiento fallido documentada sin doble liquidación.
- Exponer estado con ámbito de propietario y acceso al resultado. Sondear a un intervalo medido y detenerse en COMPLETED, FAILED o CANCELLED.
- Exigir eliminación y retener evidencia operativa. Remove los medios según el cronograma mientras se retiene solo el mínimo registro de tarea, facturación, seguridad y soporte permitido.
Estado y liquidación
Mantener el estado de procesamiento separado del estado monetario
| Evento | Task record | Credit action | Client action |
|---|---|---|---|
| Solicitud rechazada antes de la creación de la tarea | No accepted task | Do not infer a charge | Corrige la solicitud o el estado de la cuenta |
| Task accepted | Persistir taskId y costo esperado | Tratar el acuerdo como propiedad del servidor | Begin measured polling |
| Task completed | Terminal result | El trabajo completado permanece acordado | Authorize result retrieval |
| Processing failed | Terminal failure | El contrato actual reembolsa automáticamente el procesamiento fallido | Lee el fallo antes de decidir reenviar |
| Response outcome uncertain | Concilia antes de otro POST | Never guess from a timeout | Usa el taskId almacenado o el historial de la cuenta |
No se documenta un campo idempotency-key en el contrato público. El servicio llamante debe deshabilitar el envío duplicado, persistir el primer taskId y conciliar una respuesta de red incierta antes de emitir otro POST.
Política de fallos
Reintenta solo cuando la clase de fallo lo permita
| Status | Failure class | Architecture response |
|---|---|---|
| 400 | Invalid request or media | Rechaza permanentemente hasta que cambien los campos o el medio. |
| 401 / 403 | Key or account readiness | Rota la clave o completa la verificación; no hagas un bucle. |
| 402 | Insufficient credits | Agrega créditos y envía una nueva tarea solo después de la confirmación. |
| 404 | Propietario, ruta o taskId incorrectos | Concilia la identidad y los metadatos de la tarea almacenados. |
| 429 | Límite de tasa o de generación activa | Respeta Retry-After cuando se proporcione, añade jitter y limita los reintentos. |
| 500 | Aceptación temporal o fallo de lectura | Usa backoff exponencial acotado y concilia antes del envío duplicado. |
Observability and security
Rastrea las decisiones de control sin copiar medios sensibles en los registros
La telemetría recomendada de la tarea incluye un ID de correlación, taskId, identificador de cuenta, flujo de trabajo, hechos del medio sanitizados, cantidad de crédito esperada, transiciones de estado, número de reintentos, clase de error, evento de liquidación y marca de tiempo de eliminación. No registres claves API, imágenes faciales, nombres de archivo subidos completos, URL de resultados firmados o cuerpos multiparte. La Recomendación de contexto de seguimiento W3C define un contexto de solicitud interoperable; es una opción de diseño, no una afirmación sobre la implementación privada de DeepSwapAI.
Para las defensas de carga, valida los nombres de archivo decodificados, el contenido detectado, los formatos permitidos, los recuentos y los tamaños; no confíes únicamente en el Content-Type proporcionado por el navegador. La OWASP File Upload Cheat Sheet es la referencia de seguridad externa. Usa el planificador de consentimiento y divulgación para la puerta de autorización humana y la Trust Center para los límites actuales del servicio público.
Total cost of ownership
Compara gestionado, autogestionado e híbrido con la misma carga de trabajo medida
No compares un cargo de API solo con el alquiler bruto de GPU. Primero fija una ventana de carga de trabajo: mezcla de flujos de trabajo, duración y resolución del medio, concurrencia máxima, tasa de reintentos, retención, volumen de revisión y disponibilidad requerida. Luego asigna cada costo recurrente y relacionado con fallos a la misma ventana.
| Cost dimension | Managed API | Self-hosted | Hybrid | Evidence to collect |
|---|---|---|---|---|
| Processing capacity | Cargo por tarea o duración publicado | Arrendamiento o compra de GPU, capacidad inactiva, escalado y tiempo de ejecución del modelo | Línea base interna más desbordamiento externo o procesamiento especializado | Unidades completadas, duración, resolución, concurrencia y utilización |
| Engineering and operations | Integración, persistencia de tareas, sondeo, revisión y manejo de cambios de proveedor | Servicio de modelos, cola, actualizaciones, planificación de capacidad, implementación y respuesta en guardia | Orquestación, abstracción de proveedor y propiedad de la plataforma interna | Horas de ingeniería medidas, cadencia de lanzamiento y carga de guardia |
| Safety and governance | Puerta de consentimiento de la aplicación, política de cuenta, revisión y evidencia | Todos los controles de moderación, almacenamiento, eliminación, control de acceso y auditoría | Controles compartidos con un propietario explícito para cada decisión | Minutos de revisión, tasa de escalamiento, alcance de retención y propietarios de controles |
| Storage and delivery | Manejo de entrada, resultado y red del lado de la aplicación | Operaciones de entrada, intermedias, resultado, copia de seguridad, egreso y eliminación | Registros internos más transferencias acotadas al proveedor | Bytes retenidos, volumen de transferencia, tiempo de retención y trabajo de eliminación |
| Failure and reliability | Reintento, conciliación, manejo de interrupciones del proveedor y costo de cambio | Redundancia, respuesta a incidentes, trabajos fallidos, recuperación y capacidad no utilizada | Fallo de dependencia y fallo de orquestación interna | Tasa de fallos, tiempo de recuperación, trabajo duplicado y carga de soporte |
Este marco no publica ningún punto de referencia de precio autogestionado y no afirma que la opción gestionada, autogestionada o híbrida sea universalmente más barata. La decisión depende de la carga de trabajo y los controles que se puedan evidenciar para el mismo período.
Decisión de construcción
Elige gestionado, autogestionado o híbrido según los controles que debas poseer
| Model | You own | External dependency | Best fit |
|---|---|---|---|
| Managed API | Puerta de consentimiento, UX de la aplicación, persistencia de tareas, sondeo, revisión y política empresarial | API, límites, precios y comportamiento de procesamiento publicados | Equipos que priorizan la velocidad de integración sobre el control de la infraestructura |
| Self-hosted | Modelo, capacidad de GPU, cola, moderación, almacenamiento, seguridad, liquidación, eliminación y respuesta a incidentes | Cadena de suministro de modelo e infraestructura | Equipos con un requisito justificado de control o implementación y capacidad operativa |
| Hybrid | Política interna, orquestación, registro de auditoría, revisión y abstracción de proveedor | Uno o más servicios de generación acotados | Equipos que necesitan control a nivel de aplicación sin operar cada componente del modelo |
Sources and method
Hechos actuales del producto más estándares externos principales
El equipo de producto de DeepSwapAI verificó las cinco rutas públicas, la autenticación Bearer, las solicitudes multiparte, los estados de tarea, el flujo de sondeo, las respuestas de error, el límite de concurrencia, la liquidación de créditos, el derecho a imágenes de prueba y la eliminación de medios en 24 horas el 22 de julio de 2026. Los controles recomendados se basan en la Especificación OpenAPI 3.1.2, OWASP upload guidance, NIST AI RMF 1.0, y la W3C Trace Context. See the claim verification methodology para saber cómo las declaraciones actuales del producto se separan de la guía de diseño general.
Architecture questions
Conoce lo que el contrato público establece y no establece
¿Es esta la arquitectura de producción privada de DeepSwapAI?
No. Es una referencia de diseño de contrato público y no divulga la topología del proveedor, la tecnología de cola, la ubicación del modelo, el número de trabajadores, la red interna ni los objetivos a nivel de servicio.
¿Cómo sabe un cliente que una tarea finalizó?
Conserva el taskId devuelto por POST y sondea GET en la misma ruta de flujo de trabajo hasta COMPLETED, FAILED o CANCELLED. Las devoluciones de llamada webhook no están publicadas actualmente.
¿Se puede colocar la clave API en el código del cliente?
No. Trátala como un secreto del lado del servidor y mantenla fuera de los paquetes del navegador, binarios móviles, repositorios, análisis, registros y mensajes de soporte.
¿API publica una clave de idempotencia?
No se documenta ningún campo idempotency-key. Prevén el envío duplicado, persiste el primer taskId y concilia respuestas inciertas antes de otro POST.
¿Este diseño garantiza rendimiento o calidad?
No. No es un punto de referencia, SLA, puntuación de precisión o garantía de calidad.