¿Qué nivel de cuantificación se debe utilizar para la implementación de modelos de lenguaje grandes (LLM) en el borde?

La cuantificación de los modelos de lenguaje a gran escala (LLM) reduce la precisión de los pesos de dichos modelos, de modo que el modelo utiliza menos memoria y funciona más rápido en la fase de inferencia. La contrapartida es una cierta pérdida de calidad en la salida a cambio de unos requisitos menores de memoria de acceso aleatorio para vídeo (VRAM). Para la mayoría de las implementaciones en el borde, Q4_K_M es el valor predeterminado adecuado, ya que se sitúa en el punto óptimo de la curva que tiene en cuenta la VRAM, el rendimiento y la calidad.

Los estudios demuestran de forma sistemática que Q4_K_M ofrece una calidad cercana a la de FP16, al tiempo que reduce los requisitos de memoria lo suficiente como para funcionar de manera eficiente en hardware con recursos limitados. Pasa a Q5_K_M o Q8_0 únicamente cuando tu hardware disponga de suficiente VRAM y tu carga de trabajo exija una mayor fidelidad de salida, especialmente para la codificación y el razonamiento estructurado. Si aún estás decidiendo qué modelo implementar, utiliza la guía de selección de modelos para elegir el más adecuado para tu hardware periférico.

El problema es que los repositorios de GGUF ofrecen varias opciones, entre ellas Q4_0, Q4_K_S, Q4_K_M, Q5_K_M, Q6_K, Q8_0 e IQ4_XS, sin explicar cuál se adapta mejor a tu hardware o carga de trabajo. Esto hace que muchos ingenieros tengan que adivinar qué archivo deben descargar para una Raspberry Pi 5, un Jetson Orin Nano, un Mac Mini M4 o una unidad de procesamiento gráfico (GPU) de consumo. En la práctica, la decisión consiste en elegir el punto en el que la VRAM disponible, el rendimiento de inferencia y la calidad de salida se ajusten a tu objetivo de implementación.

En este artículo descubrirás qué significa cada nivel de cuantificación de GGUF, cuál se adapta a tu hardware y cuándo conviene elegir Q4_K_M, Q5_K_M o Q8_0. También aprenderás cuándo merece la pena optar por niveles de cuantificación más bajos para ahorrar memoria y cuándo estos reducen demasiado la calidad del resultado.

PTQ frente a QAT

En la mayoría de las implementaciones en el borde, el enfoque que se utilizará es la cuantificación posterior al entrenamiento (PTQ). La PTQ aplica el proceso de cuantificación una vez que el modelo ya se ha entrenado, lo que permite convertir un modelo existente en un modelo cuantificado sin necesidad de volver a entrenarlo. Esto convierte a la PTQ en la opción más práctica para los ingenieros que implementan modelos de lenguaje a gran escala (LLM) de peso abierto con Ollama o llama.cpp, ya que no requiere acceso a los datos de entrenamiento originales ni al proceso de entrenamiento. La PTQ genera la mayoría de los archivos GGUF, incluidas las variantes Q4_K_M y Q8_0. Reduce el tamaño del modelo, el consumo de memoria y los requisitos de computación con una pérdida mínima de calidad.

El entrenamiento sensible a la cuantificación (QAT) adopta un enfoque diferente. En lugar de realizar la cuantificación tras el entrenamiento, integra la cuantificación en el proceso de entrenamiento, de modo que el modelo aprende a compensar el error de cuantificación a medida que se actualizan sus pesos. Esto suele ofrecer una mejor retención de la precisión máxima que el PTQ, ya que la red neuronal se adapta a una menor precisión a lo largo del entrenamiento. La contrapartida es que el QAT requiere acceso a toda la configuración de entrenamiento, incluidos los datos de entrenamiento, el proceso de optimización y el proceso de ajuste fino. A menos que estés entrenando o ajustando tu propio modelo, el QAT no es una opción práctica.

El QAT también requiere recursos adicionales en cuanto a tiempo y selección de parámetros.

El mecanismo de funcionamiento de QAT y PTQ

GPTQ, AWQ y GGUF para el tiempo de ejecución

Elige el formato de cuantificación que se adapte a tu entorno de ejecución de inferencia. GPTQ, la cuantificación de pesos sensible a la activación (AWQ) y el formato unificado generado por GPT (GGUF) reducen el tamaño del modelo y el consumo de memoria, pero están pensados para entornos de implementación distintos.

GPTQ está diseñado para realizar inferencias rápidas en GPU de NVIDIA. Aplica la cuantificación tras el entrenamiento capa por capa, utilizando datos de calibración para minimizar el error de cuantificación y, al mismo tiempo, preservar la calidad del modelo. Los modelos GPTQ funcionan bien en implementaciones de servidor en las que se dispone de aceleración por GPU, lo que los convierte en una opción habitual para servicios de inferencia autohospedados y cargas de trabajo de aprendizaje automático que se ejecutan en hardware de GPU dedicado.

AWQ también está orientado a la inferencia en GPU, pero utiliza patrones de activación para identificar y conservar los pesos más importantesdurante el proceso de cuantificación. Esto permite que los modelos AWQ mantengan una alta precisión al tiempo que ofrecen una excelente velocidad de inferencia en el hardware compatible. AWQ es el formato preferido para las implementaciones en la nube que utilizan vLLM, ya que es más rápido que GPTQ en los sistemas compatibles.

GGUF tiene una finalidad diferente. Está optimizado para la inferencia local y en el borde con Ollama y llama.cpp, y es compatible con variantes modernas de K-quant e IQ-quant, como Q4_K_M, Q5_K_M, Q8_0 e IQ4_XS. Si vas a realizar una implementación en una Raspberry Pi, un Mac Mini, un Jetson u otros dispositivos periféricos, GGUF es la opción adecuada.

Un estudio realizado por Local AI Master compara el rendimiento de distintos formatos de cuantificación y presenta los resultados en una tabla de clasificación de cuantificación.

Cuadro de resultados de cuantificación entre GGUF, GPTQ y AWQ

Comprender la convención de nomenclatura

Puedes identificar el archivo GGUF correcto leyendo su nombre. Una vez que comprendas qué representa cada parte de la convención de nomenclatura, resultará muy sencillo comparar opciones como Q4_0, Q4_K_M, Q5_K_M, Q6_K, Q8_0 e IQ4_XS.

El número que sigue inmediatamente a la «Q» indica el número medio de bits utilizados para almacenar cada peso del modelo. Los números más bajos reducen los requisitos de VRAM y suelen aumentar el rendimiento de la inferencia, mientras que los números más altos conservan en mayor medida la calidad del modelo original. En la práctica, Q4 es la opción predeterminada para la mayoría de las implementaciones en el borde, ya que ofrece el mejor equilibrio entre el uso de memoria y la calidad de salida. Q5, Q6 y Q8 mejoran progresivamente la calidad, pero cada paso aumenta el consumo de memoria.

El sufijo identifica el método de cuantificación. La familia K representa la cuantificación moderna de precisión mixta, en la que las diferentes capas del modelo se almacenan con distintos niveles de precisión. Entre estas variantes, Q4_K_M es la recomendación estándar, ya que asigna mayor precisión a las capas sensibles a la calidad —como las matrices de atención y la proyección de salida— mientras mantiene las capas menos sensibles con una precisión menor. Este enfoque produce resultados apreciablemente mejores que los antiguos formatos uniformes de 4 bits sin un aumento significativo del consumo de memoria. Q4_K_S utiliza una estrategia de compresión ligeramente más agresiva, mientras que Q4_K_M sigue siendo la opción predeterminada preferida para la mayoría de las cargas de trabajo.

El sufijo «0», como en Q4_0 o Q8_0, indica una cuantificación simétrica sin desplazamiento del punto cero. Cada peso recibe el mismo número de bits, independientemente de su importancia para la calidad del modelo. Este diseño hace que Q4_0 sea notablemente menos preciso que Q4_K_M, aunque ambos sean formatos nominalmente de 4 bits. A menos que Q4_K_M supere la memoria disponible o no esté disponible para el modelo elegido, se debe evitar Q4_0 y seleccionar en su lugar la versión K-quant.

El prefijo «IQ» significa «Quantization based on Importance Matrix» (cuantización basada en la matriz de importancia). En lugar de tratar todos los pesos por igual, la cuantización IQ utiliza una matriz de importancia para preservar los pesos que más contribuyen a la calidad del modelo. Como resultado, formatos como el IQ4_XS pueden alcanzar una calidad similar a la del Q4_K_M utilizando incluso menos memoria. Esa ventaja se aplica principalmente a la inferencia en GPU. En sistemas que solo cuentan con una unidad central de procesamiento (CPU), como las implementaciones de Raspberry Pi, la sobrecarga adicional de la descuantización suele contrarrestar el ahorro de memoria, por lo que K-quant resulta la mejor opción.

La precisión de coma flotante de 16 bits (FP16) sirve como punto de referencia de calidad, más que como formato de implementación predeterminado. Conserva el modelo sin pérdida por cuantificación, pero sus requisitos de memoria lo sitúan más allá de los límites prácticos de la mayoría de los dispositivos periféricos, ya que consume más ancho de banda y energía. A menos que dispongas de una gran cantidad de VRAM o estés evaluando la calidad del modelo, los formatos Q4_K_M, Q5_K_M o Q8_0 ofrecerán un mejor equilibrio entre el uso de memoria y el rendimiento de la inferencia.

El equilibrio entre la memoria VRAM, el rendimiento y la calidad

Debes considerar la cuantificación como una decisión de asignación de recursos, ya que no es posible maximizar al mismo tiempo la eficiencia de la VRAM, el rendimiento de la inferencia y la calidad de la salida. Cada nivel de cuantificación ocupa un punto diferente en esta curva. Una cuantificación con menos bits reduce el uso de memoria y aumenta la velocidad de inferencia, pero también descarta más información del modelo original. Una cuantificación con más bits conserva mejor la calidad del modelo original, pero requiere mucha más memoria y ofrece un rendimiento menor. Tu objetivo no es elegir el nivel de cuantificación más alto o más bajo. Tu objetivo es elegir el punto que mejor se adapte a tu hardware y a tu carga de trabajo.

La disyuntiva resulta evidente al comparar los requisitos de memoria del mismo modelo. Un modelo de 7.000 millones de parámetros (7B) en formato FP16 requiere aproximadamente 14 GB de VRAM, lo que descarta de inmediato a la mayoría de los dispositivos periféricos. El mismo modelo en Q4_K_M requiere entre 4 y 4,5 GB de VRAM, al tiempo que conserva entre el 97 % y el 99 % de la calidad de FP16 y ofrece un rendimiento aproximadamente entre dos y tres veces superior. En la práctica, esto suele marcar la diferencia entre un modelo que se carga correctamente y otro que falla con un error de memoria insuficiente. En el otro extremo del espectro, Q8_0 sigue siendo prácticamente sin pérdidas, con una perplejidad que se mantiene entre aproximadamente 0,02 y 0,05 puntos respecto a FP16, pero requiere aproximadamente el doble de VRAM que Q4_K_M. Esa calidad adicional solo resulta valiosa si el hardware puede soportarla.

Las investigaciones sitúan sistemáticamente a Q4_K_M como el punto óptimo para el despliegue en el borde, ya que equilibra las tres restricciones mejor que cualquier otro formato GGUF de uso generalizado. Reducir el valor por debajo de Q4 ahorra memoria adicional, pero la pérdida de calidad se hace cada vez más notable, especialmente en tareas de codificación, razonamiento estructurado y cargas de trabajo de agentes. Aumentar el valor por encima de Q4 mejora la calidad de los resultados, pero el requisito adicional de VRAM limita el hardware capaz de ejecutar el modelo de forma eficiente. Para la mayoría de los ingenieros que utilizan Ollama o llama.cpp, la cuestión es si la mejora de la calidad justifica el coste adicional de memoria en su hardware.

Compromiso de cuantificación para un modelo de 7 mil millones

Niveles de VRAM y la cuantificación adecuada para cada uno

La VRAM disponible debe determinar el nivel de cuantificación. Una vez que sepas cuánta memoria ofrece tu hardware, podrás reducir rápidamente las opciones. Para la mayoría de las implementaciones en el borde, Q4_K_M sigue siendo la mejor opción por defecto. A medida que dispongas de más VRAM, podrás pasar a niveles de cuantificación más altos que mejoren la calidad de salida, especialmente para cargas de trabajo en las que la precisión es fundamental. Las limitaciones de hardware también influyen en opciones de implementación más amplias, incluido el diseño de los agentes.

De 4 a 6 GB de VRAM

Si te encuentras en el extremo superior de este rango (6 GB), un modelo 7B u 8B en Q4_K_M cabe dentro de la memoria disponible. Si solo dispones de 4 GB, opta por una clase de modelo más pequeña (como 3B) en Q4_K_M, en lugar de intentar forzar que quepa un modelo 7B o bajar a Q3 o Q2. Un modelo más pequeño que se ejecute en Q4_K_M casi siempre produce mejores resultados que un modelo más grande y muy comprimido, ya que una cuantificación agresiva supone una pérdida de calidad mucho mayor.

De 8 a 12 GB de VRAM

Q4_K_M sigue siendo la mejor opción para la mayoría de las cargas de trabajo de este rango. La VRAM adicional te ofrece más flexibilidad para ejecutar modelos más grandes, aumentar la longitud del contexto o pasar a niveles de cuantificación de mayor calidad. Si tu carga de trabajo principal implica codificación, razonamiento estructurado u otras tareas en las que la precisión es fundamental, opta por Q5_K_M. El coste adicional de memoria queda justificado por la mejora cuantificable en la calidad de los resultados para estas cargas de trabajo.

De 12 a 16 GB de VRAM

Pasa a Q5_K_M o Q6_K si tu hardware dispone de entre 12 y 16 GB de VRAM. Ambos formatos mejoran la calidad con respecto a Q4_K_M, y la mejora resulta más notable en la generación de código, el razonamiento matemático y la salida estructurada. Las investigaciones también muestran que la mejora en la calidad al pasar de Q4_K_M a Q6_K es mayor que la que se obtiene al pasar de Q6_K a Q8_0, lo que convierte a Q6_K en una opción atractiva cuando se dispone de memoria suficiente pero no se necesita la VRAM adicional que requiere Q8_0.

De 16 a 24 GB de VRAM

Q8_0 se convierte en la opción preferida una vez que tu hardware alcanza este nivel. Produce un resultado prácticamente sin pérdidas, con una perplejidad que se mantiene entre aproximadamente 0,02 y 0,05 puntos de FP16, al tiempo que evita los considerables requisitos de memoria que exige el propio FP16. Si realizas habitualmente tareas de desarrollo de software, razonamientos complejos u otras tareas en las que la precisión es fundamental, este es el punto en el que la VRAM adicional aporta beneficios cuantificables.

24 GB de VRAM o más

El FP16 resulta viable en este tipo de hardware para modelos de hasta aproximadamente 8 mil millones. Los modelos más grandes, como los de 13 mil millones, suelen implementarse en Q8_0 incluso en GPU de 24 GB. Si tu objetivo es obtener la máxima fidelidad del modelo y la memoria ya no es el factor limitante, el FP16 elimina por completo la pérdida por cuantificación. Sin embargo, para la mayoría de las implementaciones en el borde, la mejora con respecto a Q8_0 es tan pequeña que muchos ingenieros siguen optando por Q8_0 para reducir el consumo de memoria, al tiempo que mantienen una calidad de salida prácticamente idéntica.

Hay una recomendación que se mantiene constante en todos los niveles de hardware. Si tu hardware puede ejecutar tanto un modelo más grande en Q4_K_M como uno más pequeño en Q8_0, elige el modelo más grande. Los estudios demuestran sistemáticamente que un modelo más grande en Q4_K_M casi siempre ofrece mejores resultados que uno más pequeño en Q8_0 en un hardware equivalente, ya que la capacidad del modelo tiene un mayor impacto en la calidad del resultado que las pequeñas mejoras en la cuantificación.

Cuantización recomendada en función de la VRAM disponible

Cuándo apartarse del Q4_K_M

Deberías seguir utilizando Q4_K_M a menos que tu carga de trabajo o tu hardware te den una razón clara para elegir otra opción. Para la conversación general, la respuesta a preguntas, la generación aumentada por recuperación (RAG) y la llamada a herramientas de agentes, Q4_K_M funciona bien. La relación entre rendimiento y recursos cambia cuando la precisión de la salida cobra más importancia que la eficiencia de la memoria o cuando tu hardware no puede alojar el modelo sin problemas.

Programación y razonamiento estructurado

Pasa a Q5_K_M o Q8_0 si dispones de suficiente VRAM, para cargas de trabajo que requieran una mayor precisión en los resultados. La diferencia de calidad entre Q4_K_M y los niveles de cuantificación superiores suele ser imperceptible en tareas de conversación, pero se hace apreciable en la generación de código, el razonamiento matemático, la salida estructurada y las tareas que requieren un formato coherente. Si tu hardware dispone de suficiente VRAM, el coste adicional de memoria merece la pena, ya que mejora la precisión en aquellos casos en los que los pequeños errores son más propensos a afectar a los sistemas posteriores.

Sistemas que solo cuentan con CPU y menos de 4 GB de memoria

Elige un modelo más pequeño en lugar de una versión cuantificada de forma más agresiva de uno más grande. Si un modelo de 7B en Q4_K_M supera la memoria disponible, pasar a Q3 o Q2 puede permitir que el modelo se cargue, pero la reducción de calidad es significativa para las cargas de trabajo de tipo «agente». Un modelo de 3 000 millones en Q4_K_M suele generar respuestas más fiables que un modelo de 7 000 millones forzado a Q3 o Q2, ya que conserva en mayor medida las capacidades aprendidas por el modelo. Si tu hardware no puede ejecutar sin problemas el modelo en Q4_K_M, reduce el tamaño del modelo en lugar del nivel de cuantificación.

Chat general y carga de trabajo de los agentes

Opta por Q4_K_M para cargas de trabajo de conversación generales. Q4_K_M resulta prácticamente imperceptible en el chat diario, la respuesta a preguntas, el RAG y las llamadas a herramientas de agente. Para la mayoría de los chatbots en producción y los asistentes de IA integrados en el dispositivo, Q4_K_M ofrece el mejor equilibrio entre calidad de respuesta, rendimiento y eficiencia de memoria.

Elige el formato adecuado para tu tiempo de ejecución

Utiliza GGUF para la inferencia local y la cuantificación de pesos sensible a la activación (AWQ) para la ejecución en la nube. El nivel de cuantificación que elijas es solo una parte de la decisión de implementación. También debes seleccionar un formato de modelo que se adapte a tu entorno de ejecución de inferencia. Si utilizas un formato incorrecto, el modelo no se cargará o se reducirá el rendimiento de la inferencia.

Si vas a realizar una implementación con Ollama o llama.cpp en hardware periférico, descarga la versión GGUF de tu modelo. GGUF está optimizado para la inferencia local y es el formato nativo compatible con ambos entornos de ejecución. Admite métodos modernos de cuantificación, como Q4_K_M, Q5_K_M, Q6_K y Q8_0, lo que lo convierte en la opción estándar para Raspberry Pi, Jetson Orin Nano y Mac Mini M4. No es necesario convertir los modelos manualmente, ya que Ollama puede obtener modelos GGUF compatibles directamente de su biblioteca de modelos.

Utiliza AWQ a la hora de ejecutar modelos con vLLM en entornos en la nube optimizados para GPU. AWQ está diseñado para la inferencia en GPU de alto rendimiento y se integra con entornos de ejecución creados para la ejecución en producción. Si intentas cargar un modelo GGUF en vLLM, se producirá una incompatibilidad de formatos o un rendimiento significativamente inferior al de los entornos de ejecución nativos de GGUF, como llama.cpp.

La regla es sencilla: adapta el formato del modelo al entorno de ejecución. Utiliza GGUF para Ollama y llama.cpp en hardware local y periférico, y utiliza AWQ para vLLM en implementaciones de GPU en la nube. Elegir el formato correcto garantiza que las ventajas de rendimiento del nivel de cuantificación seleccionado no se pierdan debido a un entorno de ejecución incompatible.

Conclusión

Elige Q4_K_M a menos que tu hardware o tu carga de trabajo te den motivos para hacer lo contrario. Ofrece el mejor equilibrio entre el uso de VRAM, el rendimiento de inferencia y la calidad de salida para la mayoría de las implementaciones en el borde, lo que lo convierte en la opción predeterminada adecuada para Ollama y llama.cpp. Cambia a Q5_K_M o Q8_0 solo cuando tu hardware disponga de suficiente VRAM y tu aplicación se beneficie de la precisión adicional, como en el caso de la programación, el razonamiento estructurado u otras tareas en las que la precisión sea fundamental.

La cuantización es solo una de las capas que conforman una implementación exitosa en el borde. Una vez seleccionados el modelo y el archivo GGUF adecuados, sigue siendo necesaria una capa de recuperación eficiente para impulsar los flujos de trabajo de RAG y de los agentes. Esto cobra especial importancia en dispositivos periféricos con recursos limitados, donde la combinación de modelos como Gemma 2 con una base de datos vectorial optimizada para el borde, como Actian VectorAI DB, permite una recuperación rápida y precisa, al tiempo que se mantienen bajos la latencia y el consumo de recursos.

Empieza hoy mismo a utilizar Actian VectorAI DB Community Edition. Consulta la documentación para obtener instrucciones de implementación y uso, y únete a la comunidad de Discord para recibir ayuda y participar en los debates.

Preguntas frecuentes

¿Es Q4_K_M lo suficientemente adecuado para las cargas de trabajo de los agentes de producción?

Sí. Q4_K_M conserva aproximadamente entre el 97 % y el 99 % de la calidad de FP16, al tiempo que utiliza mucha menos VRAM. Es una configuración predeterminada razonable para chatbots, RAG y llamadas a herramientas de agentes. Si tu carga de trabajo se centra en la generación de código, el razonamiento matemático o la salida estructurada, cambia a Q5_K_M o Q8_0 (si tu hardware dispone de recursos suficientes para soportarlo).

¿Debería utilizar Q4_0 si Q4_K_M no está disponible?

Solo si no tienes otra alternativa. Q4_K_M utiliza precisión mixta, asignando más bits a las capas sensibles a la calidad, como las matrices de atención y la proyección de salida. Q4_0 utiliza una cuantificación uniforme más antigua de 4 bits, que produce una calidad notablemente inferior. Siempre que ambas opciones estén disponibles, elige Q4_K_M.

¿Qué pasa si me quedo por debajo del Q4?

Bajar a Q3 o Q2 reduce el consumo de memoria, pero la pérdida de calidad se hace notable. Aunque estos formatos pueden permitir que un modelo más grande quepa en una memoria limitada, a menudo dan lugar a un razonamiento más débil, un seguimiento de instrucciones menos preciso y un comportamiento del agente menos fiable. Si Q4_K_M no cabe, elegir un modelo más pequeño suele ser una mejor decisión que utilizar Q3 o Q2.

Problemas habituales

El modelo genera un error de falta de memoria en Q4_K_M

Comprueba si tu hardware dispone de suficiente VRAM para el modelo y su ventana de contexto. Si la memoria sigue siendo insuficiente, elige un modelo más pequeño en lugar de bajar por debajo de Q4. Este enfoque preserva la calidad de la salida de forma más eficaz que una cuantificación agresiva.

El rendimiento es inferior al previsto

Comprueba que tu entorno de ejecución utilice la aceleración por GPU en lugar de recurrir a la CPU. Si la aceleración por GPU no está disponible, comprueba que los controladores necesarios y la configuración del entorno de ejecución estén correctamente instalados antes de reducir el nivel de cuantificación.

La calidad de los resultados es deficiente en las tareas de razonamiento

Si tu trabajo implica la generación de código, el razonamiento matemático o la generación de resultados estructurados, actualiza de Q4_K_M a Q5_K_M o Q8_0 si tu hardware dispone de suficiente VRAM. Los estudios demuestran que estos niveles de cuantificación más altos proporcionan mejoras cuantificables en la calidad para tareas en las que la precisión es fundamental.

Acerca del autor

Acerca de Alex Novotny

Alex Novotny es el responsable de Crecimiento de Desarrolladores en Actian, donde dirige la estrategia para captar el interés de los desarrolladores y acelerar la adopción de las tecnologías de datos e inteligencia artificial de Actian, incluida VectorAI DB. Con más de 10 años de experiencia en el sector tecnológico y más de cinco años en relaciones con desarrolladores, Alex combina contenidos técnicos, promoción entre desarrolladores, comunidad y crecimiento para facilitar el descubrimiento, la comprensión y el desarrollo de tecnologías complejas. Anteriormente, como promotor sénior de desarrolladores en Box, creó aplicaciones de IA y RAG, integraciones MCP, herramientas para desarrolladores y contenidos técnicos en colaboración con plataformas tecnológicas líderes. Le apasiona crear experiencias para desarrolladores que conviertan la curiosidad en adopción y los prototipos en productos en producción.