Pipeline de video de formato corto
Automatización local de scripts a render con GPU: CUDA en casa, solo CPU para demo pública
Resumen
Contexto, enfoque y resultado.
Problema
Producir video de formato corto de manera constante es un problema de agenda disfrazado de uno creativo. Yo quería que la parte mecánica — guion, metraje emparejado, subtítulos, pista musical, render — estuviera automatizada y corriera en hardware que ya tengo, en vez de pagar por minuto en generación alojada.
Mi rol
Este es un fork del proyecto open-source MoneyPrinterTurbo de harry0703, que provee el generador principal. Los autores originales tienen la mayoría del historial de commits y merecen el crédito por la base. Mi aporte es la integración en homelab y un conjunto de extensiones: un pool de música licenciada para que el audio esté autorizado para uso, "content packs" que separan la identidad de una cuenta del motor de generación, medición de insights que va más allá del simple conteo de hashtags, y un pool de clips en movimiento limitado por tiempo de reloj.
Restricciones
- Una sola GPU, compartida con un stack local de LLM y un segundo cerebro que ejecuta un briefing matutino. La generación de video no debe dejar sin recursos a los procesos que corren en horario programado.
- El demo público no tiene GPU, así que la misma base de código debe poder degradarse a solo CPU.
Arquitectura
De tema a guion, a metraje emparejado, a subtítulos, a música, a short renderizado. Codificación acelerada por hardware y speech-to-text local en la workstation; el mismo stack desplegado solo con CPU detrás del reverse proxy del homelab como demo público.
Resultado
Dos despliegues en vivo desde una sola base de código. Aproximadamente 57 commits propios sobre el upstream, enfocados en la parte de scheduling, licenciamiento y manejo de recursos, más que en el generador en sí.
Qué haría diferente
El bug que recuerdo es uno de manejo de recursos, y me enseñó algo general: un job encolado por un scheduler hereda un presupuesto de duración nuevo, no la ventana de tiempo de reloj restante. Algo que debía correr durante la noche se extendió cuatro horas dentro del horario laboral, acaparando la GPU que el briefing matutino necesitaba. Un límite de duración nunca puede acotar el reloj — si un job debe terminar antes de cierta hora, esa hora debe ser la restricción que realmente codifiques.
Aprendizajes
Lo que me llevo.
Hacer un fork de algo bueno e integrarlo correctamente suele valer más que construirlo desde cero; el valor que aporté estuvo en la programación, licenciamiento y manejo de recursos, nada de eso es la parte interesante del generador. Además: nunca dejes que un trabajo de GPU sin límites comparta hardware con algo que corre en un horario.
Stack
Herramientas y plataformas.
Conversemos
¿Quieres platicar de este tipo de trabajo?
Si estás contratando para trabajo backend, AWS, voz o integraciones similares —o simplemente quieres comparar notas de arquitectura— escríbeme directo.