Un agente de voz factura con cuatro medidores a la vez

La arquitectura estándar es una cascada. El audio de quien llama se transmite a un modelo de voz a texto, la transcripción va a un LLM, el texto del LLM va a un modelo de texto a voz y el audio resultante regresa por una línea telefónica. Cuatro sistemas, cuatro proveedores, cuatro unidades de facturación. Cada capa transmite a la siguiente sin esperar a terminar, porque toda la cadena tiene que caber en una pausa de conversación.

Esa pausa es corta. Quienes construyen plataformas apuntan a unos 50–100ms por fase y a un presupuesto total de voz a voz por debajo de 500–700ms: el punto a partir del cual quien llama empieza a percibir una pausa en lugar de una respuesta. La arquitectura está moldeada por esa restricción, y el costo también, porque las decisiones que reducen la latencia y las que reducen el costo con frecuencia son las mismas.

Este es el desajuste que hace más difícil presupuestar un agente de voz que uno de texto. La transcripción se factura por minuto de audio. El modelo se factura por millón de tokens, dividido entre entrada y salida. El texto a voz se factura por carácter pronunciado. La telefonía se factura por minuto de llamada conectada. La plataforma de orquestación que va encima suele cobrar una tarifa fija por minuto.

Solo dos de esas crecen con el tiempo de reloj. Las otras dos crecen con la cantidad de texto que pasa por el sistema, que depende de su configuración y de la forma de la conversación. Una llamada de diez minutos en la que el agente casi no habla y una de diez minutos en la que monologa cuestan lo mismo en transcripción y telefonía, y pueden diferir varias veces en TTS y en el LLM.

La primera partida que no es obvia: un agente de voz transcribe al asistente además de a quien llama. Se facturan los dos canales. Eso significa que el medidor de transcripción corre a unas 2× los minutos de reloj de la llamada, no a 1×.

También es el menos controlable de los cuatro. No se puede acortar con ingeniería de prompts: crece solo con la duración de la llamada. Las únicas palancas reales son elegir un transcriptor más barato y mantener las llamadas cortas, y por eso la optimización más barata en voz casi siempre es terminar antes la llamada, ya que rebaja todos los medidores al mismo tiempo.

El texto a voz se factura por caracteres. Eso convierte el estilo de redacción en una decisión de costo de una forma que no tiene equivalente en los agentes de texto, donde nadie paga de más por una respuesta conversadora más allá de sus tokens de salida. Aquí se paga dos veces: una en tokens de salida del modelo, otra en caracteres con el proveedor de voz, y una tercera vez de forma indirecta, porque un enunciado más largo ocupa más minutos de reloj en los medidores de transcripción y telefonía.

Las voces premium agravan esto. Las estimaciones por componente suelen poner el TTS en unos $0.04 por minuto en los niveles premium, frente a más o menos $0.01 de la transcripción: la voz puede costar cuatro veces lo que cuestan los oídos. Esas tarifas por componente son estimaciones de terceros, no cifras publicadas por los proveedores; sustitúyalas por las tarifas de sus propios proveedores antes de tomar la proporción como definitiva.

Ahora, el medidor que domina. El costo de entrada del LLM es tokens de entrada por minuto × tarifa de entrada efectiva, y el primer término es donde la voz se separa claramente del texto.

Un turno de conversación no es una sola llamada al modelo. Las invocaciones de herramientas, los reintentos, la extracción de salida estructurada y los pasos intermedios de razonamiento emiten cada uno su propia solicitud, y cada solicitud vuelve a enviar el prompt de sistema completo y las definiciones de herramientas. El modelo de costos publicado por Vapi supone 5 solicitudes por turno, y cada una de esas cinco lleva su prompt completo.

Póngale una cifra. A 4 turnos de conversación por minuto (un supuesto, no una cifra publicada, así que ajústelo con los datos de sus propias llamadas) son 20 solicitudes por minuto. Un prompt de sistema de 3,000 tokens más el esquema de herramientas envía entonces 20 × 3,000 = 60,000 tokens de entrada por cada minuto de conversación. Su prompt se factura unas veinte veces por minuto, y se factura aunque nadie haya dicho nada interesante.

Sigamos con el ejemplo con tarifas comunes de gama media de $1 por millón de tokens de entrada y $5 por millón de salida. El caché de prompts importa aquí: un prefijo grande y estable califica para una tarifa reducida en caché, y el modelo de Vapi combina la tarifa estándar y la de caché con una tasa de aciertos supuesta de 50%. Tome la tarifa en caché como 10% de la estándar (un supuesto mío, dicho para que usted lo pueda cambiar) y la tarifa de entrada efectiva queda en (0.5 × $1.00) + (0.5 × $0.10) = $0.55 por millón.

El costo de entrada es entonces 60,000 × $0.55/M ≈ $0.033 por minuto. La salida es pequeña en comparación: los datos de producción ponen el habla generada en unos 150 tokens de salida por minuto, así que 150 × $5/M ≈ $0.00075. La entrada pesa más de 40× lo que pesa la salida.

Esa proporción es toda la lección. En un producto de chat, los tokens de salida suelen ser la mitad cara. En un agente de voz el modelo casi no escribe nada (una o dos frases por minuto), pero lee su prompt completo veinte veces. Optimizar la longitud de la salida casi no sirve de nada; optimizar la longitud del prompt es donde está el dinero.

Haga el análisis de sensibilidad. Agregar 1,000 tokens a su prompt de sistema (unos cuantos ejemplos más, un esquema de herramienta más, un párrafo de instrucciones de cortesía) agrega 20 × 1,000 = 20,000 tokens de entrada por minuto, o 20,000 × $0.55/M = $0.011 por minuto.

Frente a una tarifa de plataforma típica de $0.05, es un aumento de 22% en la partida de orquestación por un solo párrafo de prompt. En 50,000 minutos al mes son $550. Los equipos suelen pasar semanas negociando tarifas de telefonía que valen una fracción de eso mientras tratan el prompt de sistema como texto gratis.

Cualquier cifra por minuto publicada descansa en supuestos que fallan en sentidos opuestos. La tasa de aciertos de caché supuesta de 50% es conservadora para prompts grandes y estables, donde las tasas reales son más altas y el costo real queda por debajo de la estimación. Mientras tanto, la estimación suele ignorar que el historial de la conversación crece, y el historial se vuelve a enviar en cada solicitud, así que en llamadas largas el costo real queda por encima.

El segundo efecto es casi cuadrático y poco apreciado. El minuto diez de una llamada lleva nueve minutos de transcripción acumulada en cada una de sus veinte solicitudes. Dos agentes con una configuración idéntica pueden diferir bastante en costo por minuto solo por la distribución de la duración de sus llamadas, y por eso un promedio combinado de llamadas de prueba cortas subestima una factura de producción hecha de llamadas largas.

La historia de la medición refleja la del costo. Las latencias por componente suelen reportarse como medianas (el tiempo que tarda el transcriptor en producir texto, el tiempo hasta el primer token del modelo, el tiempo hasta el primer audio del proveedor de voz) y un total que se muestra suele ser solo la suma de esas tres medianas.

Esa suma es un piso, no una estimación. Excluye la detección del fin del turno (decidir que quien llama de verdad terminó de hablar, que es una cuestión de criterio y con frecuencia el mayor contribuyente individual) y excluye el transporte por la red. Las medianas además esconden la cola, y la calidad de la voz es una propiedad de la cola: quien llama no nota la respuesta mediana, nota la que tardó dos segundos. Compare el p95, no el p50, cuando la cifra importe.

Una restricción más moldea cada decisión de configuración. Los agentes de voz corren sus LLM con el razonamiento desactivado, porque los tokens de razonamiento se generan antes del primer token de salida y el presupuesto de latencia no puede absorberlos. Eso significa que las puntuaciones de benchmark publicadas con razonamiento activado no describen el modelo que usted de verdad está corriendo.

Sin razonamiento, incluso las configuraciones de voz más fuertes quedan en una franja estrecha: Vapi pone a las más inteligentes alrededor de 20–30 en el índice de inteligencia de Artificial Analysis y dice explícitamente que las puntuaciones deben leerse en términos relativos, no absolutos. La implicación práctica: elegir modelo le da menos diferencia de capacidad en voz que en texto, así que el beneficio marginal de pagar por un modelo de frontera es menor aquí, mientras que el costo marginal es el mismo.

La topología alternativa es un solo modelo multimodal que recibe audio y emite audio, y se salta por completo los pasos de transcribir y sintetizar. Quita dos saltos de red del presupuesto de latencia y dos proveedores de la factura, y sustituye cuatro medidores por un solo medidor de tokens de audio.

El precio es el control. Un proceso en cascada le permite cambiar cualquier componente por separado, inspeccionar la transcripción en cada frontera, aplicar un diccionario de pronunciación o pasar a un transcriptor de respaldo si el principal falla a mitad de la llamada. De voz a voz le da una caja negra con mejor latencia y peor observabilidad, y los tokens de audio suelen costar bastante más que los de texto, así que no es automáticamente más barato, solo más simple. El precio de los tokens de audio varía lo suficiente entre proveedores como para que valga la pena calcular el de su propia carga de trabajo en lugar de suponer cualquiera de los dos sentidos.

Presupueste un agente de voz preguntando qué medidor mueve cada decisión. La duración de la llamada afecta a los cuatro. El tamaño del prompt afecta solo al medidor del modelo, pero lo afecta veinte veces por minuto. La verborrea afecta a tres. El nivel del modelo afecta a uno y le da menos de lo que sugiere el titular del benchmark, porque usted corre con el razonamiento desactivado.

La tarifa de la plataforma (la cifra de la página de precios) suele ser la partida más pequeña y, por mucho, la más predecible de la factura. La decisión cara es la que se toma en un editor de texto, al escribir el prompt de sistema.