Reducir costos de llamadas de IA desde Android
Implementa límites de entrada, caché, debounce y medición por función.
Evitar solicitudes duplicadas y medir el costo real por acción del usuario.
Por qué es importante
La mayor parte de los costos de una integración de IA proviene de la cantidad de llamadas, el tamaño del contexto y los modelos elegidos. Una interfaz que envía una solicitud por cada pulsación de tecla puede generar consumo accidental. Un presupuesto técnico debe proteger tanto la experiencia como el gasto.
Requisitos
- Una pantalla Kotlin con ViewModel y corrutinas.
- Acceso a cuotas o métricas de consumo del proveedor de IA.
Trabaja en un proyecto de pruebas. Revisa las versiones y condiciones específicas de la documentación oficial, ya que las APIs y las políticas evolucionan.
Implementación
Define una acción explícita de enviar en lugar…
Define una acción explícita de enviar en lugar de ejecutar una petición con cada cambio de texto. Mide tiempo y tamaño promedio del prompt.
Limita la cantidad de caracteres de entrada, valida…
Limita la cantidad de caracteres de entrada, valida si el texto está vacío y evita adjuntar historiales extensos innecesariamente.
Utiliza una clave lógica para solicitudes repetibles (por…
Utiliza una clave lógica para solicitudes repetibles (por ejemplo, un resumen de contenido no sensible). No guardes respuestas personales en una caché compartida.
Bloquea envíos concurrentes equivalentes y cancela tareas anteriores…
Bloquea envíos concurrentes equivalentes y cancela tareas anteriores solo si tu flujo lo permite. Muestra un indicador de carga y reintento controlado.
Define topes de cuota por usuario o cuenta…
Define topes de cuota por usuario o cuenta en el servidor/proveedor. Si una cuota se agota, explica el problema sin reintentar en bucle.
Registra métricas agregadas como cantidad de solicitudes, latencia…
Registra métricas agregadas como cantidad de solicitudes, latencia, errores y costo estimado; examínalas semanalmente para ajustar el modelo.
Fragmento de referencia
class PuertaSolicitudes {
private var enCurso = false
suspend fun <T> ejecutar(bloque: suspend () -> T): T? {
if (enCurso) return null
enCurso = true
return try { bloque() } finally { enCurso = false }
}
}
// Para producción prefiere Mutex si hay concurrencia real.Ejemplo educativo: cuando se indique, añade las importaciones, dependencias, claves de prueba o clases de tu proyecto. No se presenta como proyecto Android completo y compilado.
Ponlo a prueba
Simula 20 pulsaciones y dos toques seguidos de Enviar; comprueba que el número de llamadas coincida con las acciones permitidas y no con los cambios del teclado.
Lista de comprobación
- La implementación cumple el objetivo: evitar solicitudes duplicadas y medir el costo real por acción del usuario.
- El comportamiento se verificó con datos de prueba y se documentaron los casos de fallo.
- Los recursos, dependencias y políticas se comprobaron contra las referencias oficiales.
- No se registran datos sensibles ni se da por probada una mejora sin evidencia.
Errores habituales
- No cachear respuestas que contengan información personal de otros usuarios.
- No depender de controles en el cliente para imponer cuotas económicas.
- No comparar solo precio por token: mide también calidad, latencia y reintentos.
¿Debo usar siempre el modelo más barato?
No necesariamente. Evalúa calidad por tarea, tasa de error y costo por resultado útil.
Referencias para ampliar
Consulta las versiones, limitaciones y requisitos vigentes antes de integrar los ejemplos en producción.