Para los equipos que llaman a Whisper API para transcribir voz, la interfaz en sí no es complicada: una solicitud multipart, un archivo de audio y un texto de respuesta. Lo que realmente determina la experiencia es la ruta de red: el enlace transfronterizo durante el día, la pérdida de paquetes en la hora pico y un archivo de decenas de megabytes que se corta a mitad de la subida pueden convertir una interfaz sencilla en un problema de operaciones.

Este artículo compara tres soluciones —acceso directo, proxy y pasarela— y se centra en la carga de archivos grandes, los tiempos de espera y reintentos, la estrategia de división y la lista de verificación previa al lanzamiento.

Nota: OpenAI y Whisper son marcas de sus respectivos titulares; este artículo solo ofrece una explicación técnica y no implica subordinación, representación ni cooperación con OpenAI. Los límites de las interfaces, los modelos disponibles y los criterios de facturación se rigen por la documentación oficial y la del sitio.

1. Tres rutas y tres límites de responsabilidad

  • Directo: el código llama directamente a api.openai.com, sin capa intermedia.
  • Proxy: un VPS propio con proxy inverso, o una dirección de reenvío de un tercero.
  • Pasarela: una entrada compatible con OpenAI como ZSQH AI Gateway, que unifica claves, saldo, facturación y facturas.
Dimensión Directo Proxy propio Pasarela
Control del enlace Depende del operador Alto A cargo del proveedor
Estabilidad Bastante variable Depende del centro de datos y la línea Suele tener varias rutas
Costo de mantenimiento Bajo Alto; requiere guardia Bajo
Facturación y factura En dólares, por cuenta propia Factura del proveedor, también por cuenta propia En moneda local, factura de la plataforma
Escenario adecuado Bajo volumen, con reintentos Equipos con capacidad de operación Equipos locales y producción

La diferencia central entre las tres rutas no es "si funciona", sino quién diagnostica y quién responde cuando hay un problema. Tenerlo claro antes de elegir es más útil que comparar cifras de latencia.

2. Acceso directo: que funcione no significa que sea estable

El acceso directo elimina la capa intermedia, pero la calidad del enlace transfronterizo no está bajo tu control. Los fenómenos habituales son:

  • Funciona de día y la tasa de tiempos de espera sube en la hora pico.
  • La resolución DNS se vuelve lenta de forma ocasional y el handshake TLS se alarga.
  • La conexión se reinicia al subir archivos grandes y la retransmisión empieza desde cero.
  • El mismo código funciona en la oficina pero no en el servidor en la nube.

No basta con hacer ping desde la conexión doméstica. Hay que ejecutar un conjunto de solicitudes reales en el servidor de producción, registrar la tasa de éxito, la latencia p50 y p95 y el tiempo de subida, y observarlo durante varios días. Para tareas asíncronas el acceso directo puede ser aceptable si el negocio tolera reintentar tras un fallo; en escenarios como subtítulos en vivo o reuniones en tiempo real, la variación del enlace se convierte directamente en pausas visibles para el usuario.

3. Proxy: el servidor es barato, el mantenimiento no

Un proxy propio suele consistir en nginx sobre un VPS como proxy inverso, más dominio y certificado. Fija la ruta de las solicitudes, pero introduce nuevos puntos de fallo:

  • Ancho de banda de salida insuficiente: varias subidas de audio simultáneas empiezan a hacer cola.
  • Límite de tamaño del cuerpo sin ampliar: un archivo de decenas de megabytes devuelve 413 directamente.
  • Tiempo de espera del proxy menor que el de transcripción: el backend sigue procesando, pero la conexión ya se cortó.
  • Certificado vencido, IP limitada o cambios en la interfaz del proveedor: todo requiere intervención manual.

Al configurar hay que revisar al menos client_max_body_size, proxy_read_timeout y la configuración del búfer. Una dirección de proxy compartida añade otro riesgo: no sabes quién más usa la misma salida, y la limitación o el bloqueo puede afectar a todos los usuarios. Si la clave se reenvía en la capa de proxy, también hay que confirmar que los logs no escriben la cabecera de autenticación en texto plano.

4. Pasarela: convertir un problema de red en un problema de servicio

La pasarela ofrece una Base URL compatible con OpenAI, y el código normalmente solo necesita cambiar base_url y la clave. Para un equipo local tiene tres valores prácticos: el enlace lo mantiene el proveedor; texto, audio y embeddings comparten un solo saldo; y hay pago y factura en moneda local.

Al elegir una pasarela no basta con ver la frase "admite Whisper". Hay que confirmar:

  • Si la interfaz de transcripción de audio está completa, incluidos response_format y las marcas de tiempo.
  • Los límites de tamaño por archivo, concurrencia y tiempo de espera.
  • Cómo se facturan las solicitudes fallidas y si se proporciona un identificador de solicitud.
  • La política de retención de logs y el método de eliminación.
  • Si la página de precios explica con claridad el criterio de facturación.

La pasarela resuelve el enlace y la facturación, no todos los problemas de ingeniería. Los audios que superan el límite de tamaño siguen necesitando división, y la inestabilidad de la red sigue necesitando reintentos. Conviene tratarla como una capa de infraestructura con compromiso de servicio, no como un acelerador universal.

5. Carga de archivos grandes: por qué falla incluso por debajo de 25 MB

El límite habitual por archivo de la interfaz de Whisper es de 25 MB, según la documentación oficial. Mucha gente cree que un archivo por debajo del límite no tendrá problemas, pero los fallos suelen ocurrir en la fase de transmisión.

Con un ancho de banda de subida de 1 Mbps, un archivo de 25 MB tarda unos 200 segundos solo en transmitirse; sumando el handshake TLS, la cola del servidor y el tiempo de transcripción, es fácil chocar con el tiempo de espera del proxy o del cliente. Las redes móviles, los enlaces transfronterizos y el ancho de banda compartido alargan aún más ese tiempo.

El orden para reducir la tasa de fallos es: primero comprimir, después dividir y solo al final considerar reintentos.

  • Convertir todo a 16 kHz mono; la transcripción de voz no necesita una frecuencia de muestreo alta.
  • Usar mp3 de 64 kbps; 25 MB permiten almacenar algo más de cincuenta minutos de voz.
  • Dividir los audios de más de 10 minutos en tramos de 5 a 10 minutos, con 0,5 a 1 segundo de solapamiento.
  • Elegir puntos de corte en silencios para no partir palabras por la mitad.

Estas cifras son valores de experiencia de ingeniería, no compromisos de la interfaz; lo válido es el resultado de las pruebas en tu propio entorno.

6. Tiempos de espera, reintentos y división

La división puede hacerse con ffmpeg:

ffmpeg -i input.mp3 -f segment -segment_time 600 \
  -ac 1 -ar 16000 -b:a 64k part_%03d.mp3

La estrategia de reintentos se diseña en este orden:

  1. Reintentar solo errores de red, 408, 429 y 5xx; reintentar 400, 401 o 413 no tiene sentido.
  2. Usar espera exponencial con jitter aleatorio, por ejemplo 1, 2, 4 y 8 segundos, con un máximo de tres a cinco intentos.
  3. Registrar en cada solicitud el nombre del archivo, el número de tramo y el identificador de solicitud para facilitar la conciliación.
  4. Al unir, concatenar el texto en el orden de los tramos y sumar el desplazamiento inicial a las marcas de tiempo.
  5. Eliminar duplicados en las partes solapadas, conservando preferentemente la frase más completa.
  6. Limitar la concurrencia en trabajos por lotes para dejar margen de recuperación ante errores 429.

La interfaz de audio normalmente no tiene clave de idempotencia; tras un tiempo de espera, el servidor puede haber completado la transcripción y haberla cobrado. Antes de reintentar, revisa el registro de uso y confirma que puedes aceptar un pequeño cobro duplicado; después decide el número de reintentos. Los equipos sensibles al costo pueden guardar los tramos fallidos por separado y volver a ejecutarlos tras una confirmación manual.

7. Pagos, facturas y cumplimiento

La combinación habitual para un equipo local es: recarga en moneda local en la pasarela, factura local emitida por la plataforma y transferencia empresarial dentro del proceso de compras. Antes de pagar hay que confirmar que la entidad del contrato y la cuenta de cobro coinciden, si el monto de la factura se calcula sobre lo pagado o sobre el crédito abonado, y dónde están escritas las reglas de reembolso y emisión posterior. El proceso detallado puede consultarse en la guía de recarga del sitio.

En cumplimiento hay que prestar atención a tres puntos:

  • El audio puede contener nombres, teléfonos, datos de salud o información de transacciones; hay que informar y obtener autorización antes de subirlo.
  • El contenido sensible debe anonimizarse primero, o bien optar por una solución desplegable de forma privada.
  • Confirmar si los datos se transfieren entre países y cuál es el mecanismo de retención y eliminación del proveedor.

La titularidad de los derechos sobre el resultado de la transcripción depende del contenido del audio y de las condiciones de la plataforma. Cuando se trata de grabaciones de reuniones, cursos o llamadas de atención al cliente que implican derechos de terceros, hay que confirmar la autorización antes del uso comercial.

8. Lista de verificación antes del lanzamiento

  • Ejecutar un audio de diez segundos y obtener una respuesta 200.
  • Probar un audio de cinco minutos y confirmar el reconocimiento del chino y la puntuación.
  • Probar un archivo cercano a 25 MB para medir el tiempo de subida y los tiempos de espera.
  • Simular errores 429 y 5xx para confirmar que la espera exponencial funciona.
  • Simular un corte de red para confirmar que los reintentos no entran en un bucle infinito.
  • Verificar el desplazamiento de las marcas de tiempo tras unir los tramos.
  • Revisar el límite de concurrencia y la longitud de la cola.
  • Confirmar las alertas de saldo, la facturación y el proceso de conciliación.
  • Confirmar que la clave solo existe en el servidor y que se puede rotar y revocar.

La lista no es larga, pero cada punto corresponde a una falla real. Es más estable empezar con poco tráfico durante una semana y luego aumentar la concurrencia que saturar todo de una vez.

Preguntas frecuentes

¿Es estable el acceso directo a Whisper API desde China?

No hay una respuesta única; depende del operador, la franja horaria y la ubicación del servidor. Hay que medir durante varios días en el entorno de producción y observar la tasa de éxito y la latencia p95, no una sola solicitud.

¿Cuál es la diferencia entre una pasarela y un proxy?

Un proxy normalmente solo reenvía tráfico, y la facturación y la operación siguen en el proveedor; una pasarela suele ofrecer además cuentas, saldo, gestión de claves, pago local y facturas, con un límite de responsabilidad más completo.

¿Qué hago si el audio supera los 25 MB?

Primero convertirlo a mp3 mono a 16 kHz para comprimir el tamaño y después dividirlo en tramos de 5 a 10 minutos. Elegir silencios como puntos de corte y recuperar el desplazamiento temporal al unir.

Si una transcripción agota el tiempo de espera y reintento, ¿me cobran dos veces?

Es posible, porque el servidor puede haber completado la transcripción. Revisa el registro de uso antes de reintentar y pon un límite al número de reintentos.

¿Qué aspectos de cumplimiento hay que considerar?

Sobre todo los datos personales contenidos en el audio, la transferencia internacional de datos, la política de retención del proveedor y la autorización del contenido. Con datos sensibles conviene anonimizar o desplegar de forma privada.

Siguiente paso

Primero valida el enlace con un audio corto, después prueba la división y la unión con una grabación larga real y solo entonces integra los trabajos por lotes. Los equipos que necesitan recarga en moneda local, facturación unificada y facturas pueden registrarse en ZSQH AI Gateway; los modelos de audio y los criterios de facturación figuran en precios de modelos.

Lecturas relacionadas: