Resumen
- Las respuestas en streaming requieren un análisis SSE robusto para manejar fragmentos incompletos y los datos de uso del último token.
- Los fallos del modo JSON suelen deberse a que el modelo genera texto adicional fuera del esquema JSON estricto.
- La ventana de contexto de 100k se comparte entre el prompt y la finalización, por lo que las salidas largas reducen el espacio de entrada disponible.
- La estimación del coste debe tener en cuenta el precio más alto de los tokens de salida en comparación con los de entrada.
Por qué tu respuesta en streaming se cuelga
Las respuestas en streaming se cuelgan cuando el cliente no lee el último fragmento de Server-Sent Events (SSE) que contiene los datos de uso de tokens. Nuestra API transmite tokens a medida que se generan, pero la conexión solo se cierra completamente después de que llega el último fragmento. Si tu código de cliente se desconecta antes o ignora el último fragmento, pierdes los recuentos exactos de tokens necesarios para la verificación de facturación.
Lee cada fragmento hasta que termine el flujo. No asumas que el último fragmento contiene solo el token final. El fragmento final en nuestro flujo SSE incluye el usage campo con los totales de tokens de entrada y salida. Si descarta estos datos, no podrá rastrear con precisión el consumo de su crédito prepagado.
Errores comunes
- Ignorar el último evento SSE.
- Los tiempos de espera establecidos demasiado bajos para las finalizaciones largas.
- No maneja JSON parcial en modo streaming.
Consume siempre el flujo completo para asegurar que el servidor sabe que el cliente recibió la respuesta completa. Esto evita fugas de recursos en nuestro lado y garantiza que tienes los datos necesarios para tus propios registros.
Manejo de errores de modo JSON en producción
Los errores del modo JSON ocurren porque el modelo puede generar texto después del corchete de cierre, violando las reglas estrictas de análisis JSON. Cuando estableces response_format para {"type": "json_object", el modelo intenta generar JSON válido, pero a menudo añade texto conversacional como 'Aquí están los datos:' después del corchete de cierre. Tu analizador luego falla con el texto adicional.
Elimina el texto final después del último corchete de cierre válido. No confíes en que el modelo se detenga exactamente al final de la estructura JSON. Debes implementar un paso de postprocesamiento para encontrar el último '}' o ']' y descartar todo lo que venga después. Esto es crítico al analizar matrices o objetos anidados.
Mejores Prácticas
- Usa una expresión regular para extraer el último bloque JSON válido.
- Valida la cadena extraída con un analizador JSON.
- Reintenta con una temperatura más baja si la salida es caótica.
Este enfoque garantiza que tu canal de producción permanezca estable incluso cuando el modelo decida ser charlatán. Los modelos sin censura están menos restringidos, por lo que pueden sentirse más 'creativos' con su formato.
Comprensión de los límites de la ventana de contexto
El límite de la ventana de contexto es de 100,000 tokens para el prompt y la completación combinados. Esto significa que si tu entrada tiene 50,000 tokens, solo puedes generar hasta 50,000 tokens antes de alcanzar el límite. El límite no es solo para la entrada; es un presupuesto compartido para toda la solicitud.
Calcula tu espacio de salida disponible restando el conteo de tokens de entrada de 100.000. Si envías un prompt de sistema grande o un historial largo de mensajes, tu espacio de salida disponible se reduce en consecuencia. Esto es crucial para aplicaciones que mantienen historiales de conversación largos.
Ejemplo de cálculo
- Ventana total: 100.000 tokens.
- Tokens de entrada: 20.000 tokens.
- Salida máxima: 80,000 tokens.
Si superas este límite, la API devuelve un error. Monitorea de cerca el uso de tokens para evitar el truncamiento inesperado de la respuesta del modelo. El modelo no trunca automáticamente; simplemente rechaza la solicitud si el total supera la ventana.
Conteo de Tokens y Estimación de Costos
La estimación del coste debe tener en cuenta la diferencia de precio entre los tokens de entrada y los de salida. Los tokens de entrada cuestan $0.15 por cada 1M de tokens, mientras que los tokens de salida cuestan $0.50 por cada 1M de tokens. Los tokens de salida son significativamente más caros, por lo que generar respuestas largas incrementará tus costes más rápido que enviar prompts largos.
Estima tus costos multiplicando el número de tokens esperados por el precio correspondiente. Por ejemplo, 10.000 tokens de entrada y 5.000 tokens de salida costarían: (10.000/1.000.000 * $0,15) + (5.000/1.000.000 * $0,50). Esto equivale a $0,0015 + $0,0025 = $0,004 por solicitud.
Tabla de precios
| Tipo de Token | Precio por 1M de Tokens |
|---|---|
| Entrada | $0.15 |
| Salida | $0.50 |
Rastrea tu uso mediante el último fragmento SSE o la respuesta de la API. Esto asegura que puedas presupuestar con precisión para aplicaciones de alto volumen. El crédito prepagado nunca expira, por lo que puedes planificar tus gastos a lo largo del tiempo sin tarifas mensuales.
Límites de Tasa: Explicación de 300 RPM
La limitación de velocidad limita tus solicitudes a 300 por minuto por clave de API. Este límite se aplica a todas las solicitudes, independientemente del tamaño de la carga útil o el recuento de tokens. Si excedes este límite, la API devuelve un error 429. Debes implementar una retroexponencial para manejar estos errores de forma elegante.
Monitora la tasa de tus solicitudes y ajusta la concurrencia en consecuencia. Si estás utilizando múltiples hilos o procesos, asegúrate de que compartan la misma clave de API y que colectivamente se mantengan por debajo del límite de 300 RPM. Exceder este límite resultará en errores temporales hasta que se restablezca el límite.
Manejo de Errores 429
- Implementa un retroceso exponencial.
- Registra las solicitudes fallidas para su análisis.
- Reduce la concurrencia si los límites son frecuentes.
Nuestra API está diseñada para un alto volumen de uso, pero el límite de velocidad asegura un uso justo entre todos los clientes. Si necesitas límites más altos, puedes generar una nueva clave de API, pero ten en cuenta que cada cuenta está limitada a una clave activa a la vez.
Solución de fallos en la llamada de funciones
Las fallas de llamada a funciones ocurren cuando la definición de herramienta del modelo no coincide con el esquema esperado o cuando el modelo no logra generar JSON válido para los argumentos de la herramienta. Asegúrate de que tus definiciones de herramientas sean precisas e incluyan todos los parámetros requeridos. Los esquemas ambiguos conducen a llamadas de herramienta mal formadas.
Valida los argumentos de la herramienta antes de ejecutar la función. El modelo puede generar argumentos que carecen de campos requeridos o contienen tipos incorrectos. Tu código cliente debe manejar estos errores reintentando con un prompt más claro o ajustando la definición de la herramienta.
Pasos de depuración
- Comprueba la sintaxis de definición de la herramienta.
- Validar los tipos y valores de los argumentos.
- Revisión la salida del modelo en busca de campos faltantes.
La llamada a funciones es una característica poderosa, pero requiere un diseño cuidadoso del esquema. Los modelos sin censura pueden ser menos consistentes con las definiciones de herramientas que sus contrapartes filtradas, por lo que la validación rigurosa es esencial.
Por qué 'sin censura' no es totalmente ilimitado
La etiqueta 'sin censura' significa que el modelo no rechaza temas adultos, ficticios o controvertidos lícitos, pero aún tiene un límite estricto sobre el contenido sexual que involucre a menores. Esta es la única restricción de contenido estricta que siempre se aplica. Las solicitudes que contengan dicho contenido serán rechazadas, incluso si el resto del prompt es perfectamente válido.
Pueden ocurrir aún algunos rechazos debido a errores técnicos o límites de tasa. El modelo no es magia; aún puede fallar al generar una respuesta si la entrada es demasiado compleja o se supera la ventana de contexto. Entiende que 'uncensored' se refiere a la política de contenido, no a la fiabilidad técnica.
Límites de contenido
- Sin contenido sexual que involucre menores.
- El contenido adulto lícito está permitido.
- Los errores técnicos aún pueden causar rechazos.
Esta distinción es importante para aplicaciones que necesitan manejar una amplia gama de temas. Conocer el límite específico te ayuda a diseñar tu lógica de filtrado correctamente.
Depuración de errores 400 vs 429
Los errores 400 indican un problema con la propia solicitud, como JSON inválido, campos obligatorios faltantes o exceder el límite de cuerpo de solicitud de 8 MB. Los errores 429 indican que has excedido el límite de velocidad de 300 solicitudes por minuto. Distinguir entre estos errores te ayuda a corregir el problema correcto rápidamente.
Para errores 400, comprueba la carga útil y el esquema de tu solicitud. Para errores 429, implementa retroceso exponencial y reduce la concurrencia. Si recibes un error 400 con un mensaje sobre el tamaño del cuerpo de la solicitud, asegúrate de no estar enviando demasiados datos en una sola solicitud. El límite de 8 MB es estricto.
Códigos de error
| Código de error | Significado |
|---|---|
| 400 | Solicitud incorrecta |
| 429 | Límite de tasa excedido |
Registrar estos errores con su contexto (carga útil, marca de tiempo) facilita mucho la depuración. Utiliza estos datos para optimizar tu integración y evitar fallos repetidos.
Siguientes pasos para la optimización de Heretic LLM
La optimización comienza monitoreando el uso de tokens y las tasas de error. Usa los datos de tokens del último chunk SSE para rastrear tu consumo real. Compara esto con tus costos estimados para garantizar la precisión. Ajusta tus estrategias de concurrencia y límites de tasa basándote en tus patrones de uso observados.
Considera usar una temperatura más baja para una salida JSON o llamada de función más consistente. Si necesitas respuestas más creativas, aumenta la temperatura pero prepárate para más errores de análisis. Experimenta con diferentes parámetros para encontrar el equilibrio adecuado para tu caso de uso.
Consejos de optimización
- Monitor el uso de tokens de cerca.
- Ajustar la temperatura para la coherencia frente a la creatividad.
- Implementa un manejo de errores robusto.
Comienza con la prueba gratuita para probar tu integración. Esta es una forma de bajo riesgo de verificar que tu código cliente maneja correctamente el streaming, el modo JSON y los límites de velocidad antes de comprometerse con el crédito prepagado.
