원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
Probablemente te ha pasado que, basándote únicamente en las puntuaciones de los benchmarks, implementaste un modelo de alta precisión y terminaste llevándote una desagradable sorpresa. En el momento en que se supera la capacidad de VRAM, una parte de los pesos se desplaza hacia la RAM del sistema y, al producirse el intercambio en el bus PCIe, la velocidad de generación de tokens se desploma a menos de 1 por segundo. Tomando como referencia un entorno con una RTX 4090, si utilizas el formato GGUF Q4_K_M, la memoria de los pesos consume 18.3 GB y, con un contexto de 8K, utiliza un total de 22.1 GB de VRAM para funcionar de manera apenas estable.
El total de memoria debe calcularse sumando la memoria de los pesos, la caché KV y los elementos de sobrecarga (overhead) del framework para obtener un resultado correcto. Los pesos se obtienen multiplicando el número de parámetros por los bits efectivos de cuantización y dividiéndolo por 8, mientras que el formato EXL2 4.0 bpw consume 0.50 bytes por parámetro. Si a esto le sumas la caché KV que aumenta según la longitud del contexto y una sobrecarga del framework de más de 1.5 GB, se necesita un margen libre de al menos 2 GB para evitar errores OOM (Out Of Memory).
En el primer paso, verifica la capacidad de VRAM de tu propia GPU y calcula la proporción de ocupación de los pesos y la caché KV. En el segundo paso, descarga el archivo del modelo en formato GGUF Q4_K_M o EXL2 4.0 bpw e intégralo en tu entorno local. En el tercer paso, comprueba directamente en 30 minutos si la velocidad de generación de tokens se mantiene en 30 o más por segundo al introducir un prompt de 8K o más. Siguiendo este proceso, podrás elegir un modelo que realmente funcione en tu equipo sin dejarte llevar por las cifras de los benchmarks.
Cuando a los modelos de código abierto de menos de 30B se les pide que creen estructuras JSON complejas, suelen cometer errores como olvidar los corchetes o insertar etiquetas de Markdown. Si todo el pipeline del backend se detiene porque el modelo da una respuesta errónea, no podrás dormir por la noche en paz. Es necesario escribir conjuntamente un código de defensa que fuerce la sintaxis desde la fase de generación de tokens y capture los errores de análisis (parsing) a nivel de aplicación.
En el entorno de llama.cpp debes aplicar la gramática GBNF y en vLLM utilizar Guided Decoding para evitar por completo que se generen tokens que no coincidan con el esquema. Incorpora la librería Pydantic para vincular la salida del modelo a un modelo de datos y, si se produce un JSONDecodeError, introduce el contenido del error en el historial de conversación para crear un bucle de retroalimentación que lo induzca a corregirse a sí mismo. Para evitar bucles infinitos, debes limitar el número de intentos a 3 y, si aun así falla, es imprescindible una arquitectura Fallback que devuelva un objeto de modo seguro estático.
En el primer paso, usa Pydantic para crear una clase de esquema de validación que incluya los campos obligatorios y los tipos de datos. En el segundo paso, combina expresiones regulares y bloques de manejo de excepciones para extraer únicamente la cadena JSON real de la respuesta original del modelo y capturar los errores de análisis en tiempo real. En el tercer paso, añade la lógica de reintento con la librería tenacity y, si falla hasta el final, devuelve los datos de Fallback estáticos para evitar la interrupción del servicio. Al implementar esta estructura, puedes elevar la tasa de cumplimiento del esquema de llamadas a herramientas a más del 95%.
Al extraer automáticamente código de interfaz web o recopilar datos de archivos de transcripción gigantescos, los modelos de menos de 30B revelan su limitación de omitir todo el contenido intermedio. Debes poner grilletes en el prompt del sistema para evitar que el modelo divague con saludos innecesarios o comentarios en Markdown, y lograr que devuelva resultados exclusivamente con la estructura exacta que deseas.
Debes incorporar los esquemas de salida y las restricciones en el prompt del sistema para que trabaje como un compilador. Los documentos de decenas de páginas deben dividirse en unidades de 2,000 tokens ajustadas a la longitud máxima de contexto seguro del modelo, y para evitar que se pierdan los datos de los límites, los últimos 200 tokens del chunk anterior deben superponerse al principio del siguiente chunk. Solo después de pasar por una fase de mapeo (map) que extraiga los datos de cada chunk por separado y una fase de reducción (reduce) para unirlos en una sola estructura, se obtendrán resultados realmente útiles.
En el primer paso, crea una plantilla de prompt de sistema para bloquear la salida de saludos e incrustar restricciones específicas como el uso de clases de Tailwind CSS. En el segundo paso, divide el documento de entrada mediante una ventana deslizante (sliding window) que incluya una sección de superposición del 10%. En el tercer paso, implementa un LLMProviderInterface aplicando el patrón Strategy para completar una capa de abstracción que te permita cambiar fácilmente de motor de modelo cuando sea necesario. Al aplicar este proceso, puedes ahorrar más de 5 horas de tiempo de depuración innecesario por semana.
