ByteDance LatentSync no debe tratarse como un único servicio con una sola puerta de entrada. La primera decisión es quién controla el código, dónde están los pesos, en qué máquina corre la inferencia, a qué proveedor llegan el video y el audio, quién cobra por el trabajo y quién responde cuando falla.
Si el material incluye una cara real, una voz identificable, un clip de cliente o un archivo interno, empieza por el repositorio oficial de ByteDance y los pesos de Hugging Face. La ejecución local ofrece más control sobre archivos y versiones. Una API alojada ahorra GPU y configuración, pero también traslada confianza al proveedor: precio, límites, cola, retención, borrado y soporte.
Elige la ruta de ejecución antes de probar
LatentSync resuelve una tarea concreta: toma un video fuente y un audio objetivo para alinear el movimiento visible de la boca con ese audio. La operación parece simple, pero cada ruta de ejecución implica un contrato distinto.
| Ruta | Cuándo usarla | Primera comprobación | No asumir |
|---|---|---|---|
| Fuente oficial | Necesitas código, pesos, versión y método | GitHub bytedance/LatentSync, Hugging Face ByteDance/LatentSync-1.6, arXiv 2412.09262 | Que un sitio envoltorio sea oficial |
| Ejecución local | Tienes GPU y necesitas controlar archivos | VRAM, versión de pesos, setup script, Gradio o CLI | Que la versión más nueva sirva en cualquier equipo |
| API alojada | No tienes GPU y quieres llamar un endpoint | Campos de entrada, dueño de cobro, límites, retención, soporte | Que fal o Replicate sean API oficial de ByteDance |
| Playground | Solo quieres ver el flujo con material ficticio | Operador, fuente del modelo, reglas de subida | Que un formulario gratuito sea seguro para caras y voces reales |
Separar las rutas evita diagnósticos falsos. Un fallo local suele estar en Python, CUDA, checkpoint, VRAM, formato de video o formato de audio. Un fallo de API alojada pertenece a la cola del proveedor, la accesibilidad de la URL, los nombres de parámetros, el billing o el output URI. Un playground puede no ofrecer datos suficientes si el operador no explica el origen del modelo ni el manejo de archivos.
La frontera importante es práctica: ByteDance mantiene el proyecto open-source, las rutas de pesos y la investigación publicada; muchas páginas de API públicas son servicios de terceros alrededor de LatentSync. Pueden ser útiles, pero no conviene llamarlas API oficial de ByteDance sin prueba oficial separada.
LatentSync es lip sync, no video generativo general
LatentSync no es un modelo text-to-video ni un producto completo de avatar digital. Trabaja con un video existente y un audio objetivo. Su salida intenta ajustar la boca al audio sin cambiar todo el contexto visual. La calidad del rostro, el tamaño de la boca, la iluminación, las oclusiones, la claridad del audio y la duración del clip importan mucho.
El paper oficial se titula Taming Stable Diffusion for Lip Sync y se vincula con arXiv 2412.09262. El método usa audio-conditioned latent diffusion, embeddings de audio derivados de Whisper, U-Net cross-attention, supervisión tipo SyncNet y trabajo de consistencia temporal con StableSyncNet y TREPA. Para un equipo de producto, esos detalles sirven para marcar límites: LatentSync sincroniza labios en video existente; no genera una escena completa desde texto ni resuelve consentimiento, derechos de imagen o derechos de voz.
Ese límite debe cambiar el orden de evaluación. Un flujo de lip sync combina rostro y voz. Un resultado técnicamente correcto puede parecer una declaración real de una persona. Para pruebas internas usa material sintético o autorizado. Para trabajo de cliente registra origen del archivo, base de consentimiento, uso esperado, destino de subida, ruta de salida y regla de borrado.
La fuente oficial se divide en GitHub, Hugging Face y arXiv
No basta con que una página diga LatentSync. La verificación sólida se reparte entre código, pesos y método.
GitHub bytedance/LatentSync es el ancla del código. Allí se revisan estructura del proyecto, README, setup, scripts de inference, notas de actualización y license metadata. En la comprobación del 17 de mayo de 2026, el repositorio era público, el owner era ByteDance, el lenguaje principal era Python, la metadata de licencia del código era Apache-2.0 y GitHub Releases no era la fuente principal de versiones. Por eso la versión se lee en el README y las referencias a checkpoints, no solo en Releases.
Hugging Face es el ancla de los pesos. ByteDance/LatentSync-1.6 contiene archivos como latentsync_unet.pt, stable_syncnet.pt y whisper/tiny.pt; el repo anterior ByteDance/LatentSync sigue siendo útil para pesos previos y Spaces relacionados. La metadata del model card usa openrail++, así que no se debe resumir todo como "el código es Apache, por tanto todo es Apache". Código, pesos, medios de entrada y uso de salida son controles separados.
arXiv es el ancla del método. Ayuda a entender la clase de modelo y sus límites, pero no ejecuta inferencia. Usa el paper para entender capacidad, GitHub para instalación y versión, Hugging Face para pesos, y las páginas de proveedores solo para el comportamiento de ese proveedor.
v1.5 o v1.6 se decide por VRAM primero
En local, no elijas v1.6 solo por ser más nueva. El README da una primera regla clara: LatentSync 1.5 requiere al menos 8 GB de VRAM para inferencia, mientras LatentSync 1.6 requiere al menos 18 GB. Esa diferencia decide más que el número de versión en muchos equipos.
La versión 1.6 existe por calidad: la nota del 11 de junio de 2025 dice que fue entrenada en videos 512x512 para mitigar blur. La nota de v1.5 del 14 de marzo de 2025 destaca mejor consistencia temporal, mejor rendimiento en videos chinos y menor VRAM en stage-two training. No es una pelea entre viejo y nuevo; es un intercambio entre memoria disponible, calidad de entrada, tiempo aceptable y nivel de salida necesario.
El primer ensayo local debe ser aburrido. Un video corto, un audio corto, el checkpoint elegido, una GPU con margen y una carpeta de salida clara. El objetivo inicial es probar entorno, carga de pesos, formato de entrada y escritura de salida. Después llegan batch, clips largos, colas, GPU en la nube o cambio a v1.6.
Si ninguna versión encaja con tu máquina, no inviertas horas en reinstalar CUDA sin margen de VRAM. Prueba una API alojada con archivos no sensibles y decide si el resultado y las condiciones del proveedor justifican invertir en hardware local.
La ejecución local conviene cuando el control importa
La ejecución local no es automáticamente mejor; es más controlable. Los archivos quedan en tu entorno, puedes fijar commit, versión de pesos, dependencias, logs, carpeta de salida y limpieza de temporales. Para datos privados, material de cliente o archivos con consentimiento sensible, ese control suele valer la carga operativa.
La ruta local del README empieza así:
bashgit clone https://github.com/bytedance/LatentSync.git cd LatentSync source setup_env.sh python gradio_app.py
Para inference por script, el repositorio también expone ./inference.sh. No empieces con un clip largo ni con una cola de clientes. Usa un video corto y un audio corto para confirmar codec, formato de audio, ruta de checkpoint, VRAM, directorio de salida y limpieza de archivos. Si el trabajo será compartido por un equipo, registra commit o fecha, versión de pesos, comando, GPU, origen del video, origen del audio y base de consentimiento.
El costo de control también es real. Te ocupas de dependency drift, CUDA, descargas de pesos, espacio en disco, preprocesamiento de videos largos, retries y limpieza. Para archivos sensibles, suele ser la elección correcta. Para una demo puntual, puede ser más pesado que una API alojada.
Una API alojada es contrato del proveedor
Una API alojada es útil cuando no quieres operar GPU. Pero el endpoint, la cola, el billing, el almacenamiento, los límites, el esquema de respuesta y el soporte pertenecen al proveedor.
En la comprobación del 17 de mayo de 2026, fal exponía fal-ai/latentsync con endpoint https://fal.run/fal-ai/latentsync. Sus entradas obligatorias eran video_url y audio_url; las opcionales incluían guidance_scale, seed y loop_mode. El archivo del proveedor también listaba precio: \$0.20 para videos de hasta 40 segundos y \$0.005 por segundo de salida después. Eso debe tratarse como precio de fal en esa fecha, no como precio de ByteDance.
Replicate exponía bytedance/latentsync con entradas video y audio, además de guidance_scale y seed; la salida vuelve como URI. Sus notas mencionaban video mp4 y audio mp3, aac, wav y m4a. Como no se verificó un precio actual estable de Replicate en el mismo pase, cualquier presupuesto debe volver a revisar la página del proveedor.
| Ruta alojada | Entrada comprobada | Útil para | Antes de producción |
|---|---|---|---|
fal fal-ai/latentsync | video_url, audio_url | llamada rápida con URL accesibles | fecha de precio, privacidad de URL, duración máxima, fallo con cobro, retención |
Replicate bytedance/latentsync | video, audio | inference alojada en Replicate | precio actual, cola, límites de archivo, retención de salida, soporte |
| Wrapper playground | varía por sitio | prueba manual con material ficticio | operador, origen del modelo, política de borrado, cuenta, derechos de salida |
La razón para usar una API alojada no es que sea más oficial. La razón es mover la inferencia a un proveedor. Eso puede ser correcto si el archivo no es sensible, los términos son claros y el proveedor ofrece un camino de soporte. No reemplaza consentimiento, derechos ni revisión de almacenamiento.
Define una regla de parada antes de subir caras y voces reales
La pareja de entrada de LatentSync puede identificar a una persona: rostro en video y voz en audio. Una salida convincente puede hacer creer que alguien dijo algo. Por eso la decisión de subida merece una regla de parada antes de cualquier recomendación de herramienta.
| Control | Por qué importa | Detenerse cuando |
|---|---|---|
| Consentimiento | La salida puede parecer habla real de una persona | No hay permiso para rostro, voz o uso |
| Retención | El proveedor puede guardar input, output, logs o URL | No explica almacenamiento, borrado o acceso |
| Derechos | Código, pesos, material y salida tienen reglas distintas | No puedes explicar uso comercial o público |
| Límites de entrada | Clips largos y formatos no soportados fallan distinto | No hay límites de duración, tamaño o formato |
| Cobro por fallo | Retry o fallo parcial puede costar dinero | No están claros cargos, reembolso o repetición |
| Soporte | Un flujo de producción necesita escalamiento | No hay docs, issue tracker, ticket o contacto |
Para pruebas internas, usa medios sintéticos o autorizados. Para clientes, registra route owner, model version, source media, consent basis, upload destination, output path, deletion plan y reviewer. Ese registro ayuda a explicar calidad, facturación y derechos cuando el flujo deja de ser una prueba.
Recomendación práctica
Empieza por GitHub y Hugging Face si necesitas probar que el proyecto es oficial y entender versiones. Elige local si los archivos son privados o la salida debe repetirse. Usa API alojada cuando la falta de GPU pesa más que el costo de confianza del proveedor. Deja playgrounds para material ficticio.
| Prioridad | Empieza por | Por qué |
|---|---|---|
| Confirmar fuente oficial | GitHub más Hugging Face | separa hechos de ByteDance y reclamos de terceros |
| Proteger archivos privados | local v1.5 o v1.6 | los inputs quedan en tu entorno |
| Ejecutar sin GPU | API alojada | el proveedor opera inferencia |
| Ver el flujo rápido | playground con material ficticio | alcanza para entender input y output |
| Preparar producción | local o proveedor con términos claros | necesitas logs, límites, retries, retención y soporte |
No hay una respuesta universal. Un equipo con archivos sensibles puede preferir local v1.5. Otro con GPU fuerte puede probar v1.6. Un prototipo sin datos sensibles puede usar una API alojada. Lo importante es que la ruta coincida con archivos, hardware, riesgo y responsable operativo.
Preguntas frecuentes
¿LatentSync es oficial de ByteDance?
Sí. El ancla open-source oficial es GitHub bytedance/LatentSync, y ByteDance mantiene rutas de pesos en Hugging Face. Sitios envoltorio y proveedores pueden servir, pero deben tratarse como rutas separadas salvo prueba formal.
¿ByteDance ofrece una API pública oficial de LatentSync?
No se verificó una API pública operada directamente por ByteDance. fal, Replicate y rutas parecidas deben describirse como API alojadas de terceros alrededor de LatentSync, no como API oficial de ByteDance.
¿Qué versión conviene usar en local?
Empieza por VRAM. Cerca de 8 GB, v1.5 es más realista para validar. Con unos 18 GB y necesidad de reducir blur, prueba v1.6. Si la máquina no llega, usa una ruta alojada con archivos no sensibles para evaluar.
¿El código de GitHub y los pesos de Hugging Face tienen la misma licencia?
No lo asumas. GitHub muestra metadata Apache-2.0 para el código, mientras Hugging Face muestra openrail++ para los pesos. Despliegue comercial, redistribución y entrega a clientes requieren revisar ambos.
¿Puedo usar un playground gratuito con videos reales?
Solo si el operador explica origen del modelo, retención, borrado, cuenta, derechos de salida y soporte. Si no, úsalo con material ficticio; no con una cara o voz real.
¿Qué debe registrarse para producción?
Registra route owner, model version o provider model name, source media, consent basis, upload destination, output URI o file path, failure/retry reason, billing owner y retention/deletion policy. Es el mínimo para revisar calidad, cobro y derechos después.