Para los equipos que llaman a la API de Whisper desde China continental, el problema no suele estar en el modelo sino en el enlace: redes transfronterizas inestables, subidas lentas, tiempos de espera en audios largos, límite de tamaño por archivo y una sola clave compartida entre proyectos que dificulta la conciliación. Un relay o proxy concentra esas molestias en una capa de acceso.
Pero un relay no es simplemente "cambiar la dirección". El audio es un dato sensible y la transcripción es una solicitud larga; al elegir hay que revisar límites de subida, tiempos de espera, reintentos, facturación y gestión de claves. Este artículo desglosa esos puntos y ofrece una lista ejecutable de verificación y migración.
Nota: OpenAI y Whisper son marcas de sus respectivos titulares; este artículo solo se ofrece para discusión técnica y no implica afiliación ni representación con los fabricantes. Los límites de la interfaz, los códigos de error y los criterios de facturación pueden cambiar; guíate por la documentación oficial y la documentación del sitio.
1. Qué hace realmente un relay
Un relay de voz suele hacer cuatro cosas: reenviar la solicitud al upstream, sustituir u hospedar la clave upstream, registrar el uso y los logs, y reintentar o cambiar de canal cuando hay fallos. Para el lado del negocio, sigues enviando una solicitud multipart a /v1/audio/transcriptions; solo cambian la URL base y la clave.
Hay tres formas habituales:
- Proxy inverso autogestionado: solo resuelve la red y la salida; la clave y los datos siguen bajo tu control, pero la estabilidad depende de tu operación.
- Puerta de enlace agregada: unifica varios proveedores upstream y ofrece cuota, logs, límites de velocidad y canales de respaldo; encaja en equipos con varios proyectos.
- Reventa o recarga por terceros: un tercero envía las solicitudes con su cuenta; los precios y las condiciones varían mucho, así que hay que revisar con especial cuidado los datos y el cumplimiento.
Los límites de responsabilidad difieren. Si falla un proxy propio, lo diagnosticas tú; con una puerta de enlace agregada hay que revisar el SLA y las notificaciones de incidentes; con un revendedor hay que confirmar que las condiciones upstream permiten ese uso.
2. Límites de subida: revisa las tres capas
La interfaz de Whisper tiene un límite de tamaño por archivo; la documentación oficial indica actualmente 25 MB, y no ofrece un límite de duración uniforme. La duración real depende de la codificación:
- WAV mono a 16 kHz y 16 bits ocupa aproximadamente 1,9 MB por minuto; 25 MB equivalen a algo más de diez minutos.
- MP3 mono a 32 kbps ocupa unos 240 KB por minuto; con 25 MB se puede superar una hora.
- Los relays, los proxies inversos y las plataformas serverless también pueden imponer límites de cuerpo de solicitud más pequeños.
Por eso, al diagnosticar un 413 o un fallo de subida, hay que revisar el límite upstream, el de la puerta de enlace y el del cliente. Comprimir el audio suele ser más sencillo que dividirlo: la transcripción de voz no necesita una frecuencia de muestreo alta; 16 kHz mono es suficiente, y MP3 u Opus reducen mucho el tamaño.
3. División, transcripción y unión
El audio que supera el límite debe dividirse. Conviene cortar en puntos de silencio para no partir una frase por la mitad; si no es posible, la división por duración fija también sirve, pero conserva un pequeño solapamiento.
ffmpeg -i input.wav -ar 16000 -ac 1 -c:a libmp3lame -b:a 32k \
-f segment -segment_time 600 -reset_timestamps 1 chunk_%03d.mp3
El proceso puede fijarse así:
- Convertir todo a 16 kHz mono para reducir tamaño y diferencias de formato.
- Dividir en tramos de 5 a 10 minutos, preferiblemente en silencios.
- Llamar a la interfaz de transcripción tramo por tramo, con indicación de idioma y un contexto breve.
- Unir el texto y añadir el desplazamiento temporal según el número de tramo.
- Revisar si hay frases repetidas o perdidas en las uniones; si es necesario, alinear con los fragmentos solapados.
Cuidado con las marcas de tiempo: a las marcas por segmento de cada tramo hay que sumarles "número de tramo × duración del tramo"; de lo contrario, al unir todo volverá al inicio. Si usas marcas por palabra, también hay que tratar las palabras que quedan cortadas entre tramos.
4. Tiempos de espera y reintentos
La transcripción de audio largo no es una solicitud instantánea. El tiempo de espera de lectura del cliente, el tiempo de inactividad del proxy inverso y el tiempo de espera upstream de la puerta de enlace: si cualquiera se configura demasiado corto, fallará. Ajusta primero los tiempos al peor caso y luego usa una cola para controlar la concurrencia.
| Fallo | Síntoma habitual | Tratamiento |
|---|---|---|
| 429 límite de velocidad | Fallos concentrados en horas pico | Retroceso exponencial con jitter aleatorio; reducir concurrencia |
| 5xx o error de puerta de enlace | Fallos intermitentes | Reintentos limitados; cambiar al canal de respaldo |
| Tiempo de espera de lectura | Corte a mitad de un audio largo | Aumentar el tiempo de espera; enviar por tramos |
| 413 solicitud demasiado grande | Falla al subir | Comprimir o dividir; revisar el límite del proxy |
| 401/403 | Clave inválida o sin permiso | Detener los reintentos; revisar clave y cuota |
| 400 error de parámetro | Formato, idioma o campo no admitido | Corregir la solicitud; no reintentar a ciegas |
Reintentar solo tiene sentido con límites de velocidad, tiempos de espera y 5xx. Reintentar errores 4xx de parámetros solo desperdicia cuota. Registra el ID de solicitud en cada reintento para evitar que el mismo audio se facture dos veces; en tareas por lotes conviene usar una cola y enviar los tramos fallidos a una cola de mensajes muertos para revisión manual.
5. Transparencia de facturación
La transcripción de voz suele facturarse por duración de audio, aunque también existe el criterio por tokens. Al comparar facturas, revisa: si se redondea al minuto hacia arriba, la duración mínima facturable, si se cobran las solicitudes fallidas, si los reintentos se facturan dos veces y si hay consumo mínimo.
El método es simple: contabiliza localmente los minutos totales de audio enviados y concílialos con los minutos de la factura; toma un día de logs y revisa solicitud por solicitud; etiqueta por separado los fallos y los reintentos. Si la diferencia se mantiene por encima de unos pocos puntos porcentuales, pide al proveedor el detalle. Los precios y tramos concretos figuran en la página de precios; los precios cambian, así que no hagas presupuestos con capturas antiguas.
6. Claves y riesgos de datos
El servicio de relay puede ver tu audio y el texto transcrito. Al elegir, pregunta: si las solicitudes y respuestas se guardan en disco, cuánto tiempo se conservan, si se usan para entrenamiento, qué subprocesadores existen, en qué región se almacenan los datos y cuál es el mecanismo de eliminación.
A nivel de ingeniería, como mínimo: asigna claves independientes por proyecto, fija límites de cuota, rota las claves periódicamente, no pongas claves en el frontend y evita registrar el texto completo de la transcripción en los logs. Si se trata de grabaciones de clientes, contenido médico o financiero, prioriza servicios que permitan firmar un acuerdo de tratamiento de datos o usa transcripción autohospedada.
7. Cómo verificar un relay
- Prueba con un audio de texto conocido y compara el resultado y la tasa de errores de caracteres.
- Revisa los campos devueltos: nombre del modelo, idioma, duración y segmentos deben ser razonables.
- Sube un archivo cercano al límite y confirma que no se trunca en silencio.
- Simula un audio largo y observa si el tiempo de espera y los mensajes de fallo son claros.
- Provoca un límite de velocidad o un parámetro erróneo y comprueba si el código de error es transparente y no genera cobros indebidos.
- Durante varios días, compara el uso y la factura para confirmar que el criterio de medición coincide.
No pruebes solo con videos cortos. Las reuniones largas, las grabaciones telefónicas y los entornos ruidosos del negocio real son donde se concentran los problemas.
8. Lista de migración
- Inventariar las interfaces, modelos, formatos de audio, duración media y concurrencia máxima actuales.
- Fijar un audio de prueba y una transcripción corregida a mano como línea base de comparación.
- Confirmar los límites de subida, tiempos de espera, concurrencia y política de reintentos del relay.
- Poner la URL base, la clave y los tiempos de espera en configuración, sin codificarlos.
- Completar la división, unión, desplazamiento de marcas de tiempo y cola de fallos.
- Hacer conciliación de facturas y alertas de uso; fijar un límite de presupuesto.
- Migrar primero el 10 % del tráfico, observar la tasa de error y el P95, y aumentar poco a poco.
- Mantener el canal antiguo y un interruptor de reversión; retirarlo cuando la estabilidad esté confirmada.
Los equipos que ya tienen código compatible con OpenAI normalmente solo necesitan cambiar la configuración; puedes empezar por la página de registro y validar con poco tráfico.
9. Preguntas frecuentes
¿Qué diferencia hay entre un relay de Whisper API, una VPN y un proxy inverso?
Una VPN solo cambia la ruta de red; un proxy inverso reenvía solicitudes; una puerta de enlace agregada además gestiona claves, facturación, límites de velocidad y reintentos. El problema determina la capa que necesitas.
¿El límite de 25 MB lo pone el relay?
No necesariamente. La interfaz upstream ya tiene un límite por archivo y el relay o proxy puede imponer uno menor. Confírmalo capa por capa; no te quedes solo con el error del cliente.
¿En qué tramos conviene dividir un audio largo?
Lo habitual son tramos de 5 a 10 minutos cortados en silencios. Tramos demasiado pequeños aumentan las solicitudes y el costo; tramos demasiado grandes se agotan por tiempo de espera. La referencia final es la medición real.
¿Los reintentos se facturan dos veces?
Depende del criterio del proveedor. Reintentar después de una respuesta exitosa, o cuando el upstream ya procesó una solicitud que expiró, puede generar doble facturación. Usa el ID de solicitud para deduplicar y confirma con la conciliación.
¿Cómo saber si el relay cambió el modelo?
Revisa el campo del modelo, el idioma y la estructura de segmentos devueltos, y compara los resultados con un conjunto de prueba fijo. Si el estilo cambia de repente o faltan campos, pide explicaciones al proveedor.
Lecturas relacionadas:
