Parámetros LLM: cómo leer el tamaño y ajustar las respuestas

Un modelo de lenguaje de gran tamaño (LLM) de 70B tiene unos 70 mil millones de parámetros aprendidos. Ajustar la temperatura a 0.2 en una API compatible cambia cómo selecciona los elementos de la respuesta, pero no cuántos pesos tiene el modelo. Por eso, hablar de parámetros LLM implica dos decisiones distintas: qué modelo ejecutar y cómo pedirle que genere una respuesta. Primero elige el modelo adecuado para la tarea; después, configura solo los controles que admitan su API y su versión exactas.

Verificado con la documentación vigente de los proveedores el 25 de octubre de 2026. Esta distinción es cada vez más importante: algunas API actuales rechazan los controles de muestreo y otras los aceptan, pero los ignoran. Copiar una configuración predefinida puede provocar un error o no cambiar nada.

Parámetros LLM: dos conceptos con funciones distintas

Los parámetros del modelo pertenecen al modelo entrenado. Los parámetros de generación pertenecen a la solicitud que le envías. Cambiar los segundos no vuelve a entrenar los primeros.

Piensa en un edificio. Su estructura de carga determina lo que puede soportar; unas lamas orientables permiten ajustar cómo se usa el espacio. Girar una lama no añade otro piso. Del mismo modo, cambiar la temperatura no convierte un modelo pequeño en uno más grande.

¿Qué son los parámetros de un LLM?

Cuando hablamos del tamaño de un modelo, los parámetros son valores numéricos aprendidos, principalmente pesos, que intervienen en sus cálculos. El entrenamiento ajusta esos valores a partir de datos. Al hablar de API, también se usa «parámetros» para referirse a los ajustes que influyen en la generación de respuestas. La explicación de IBM distingue entre los valores aprendidos y la configuración externa.

Un proveedor que dice «nuestro modelo tiene más parámetros» está hablando del modelo. Un desarrollador que propone «cambiar los parámetros para extraer datos de facturas» probablemente se refiere a los ajustes de la solicitud. Conviene aclarar qué significa en cada caso antes de interpretar cualquiera de esas frases como una afirmación sobre el rendimiento.

¿Qué representa un parámetro dentro de un LLM?

Un parámetro aprendido es un número que se utiliza dentro de la red. Puede ser, por ejemplo, un peso que determina cuánto contribuye una señal interna a otra. No es un dato perfectamente etiquetado, un documento ni una palabra guardada en su propio compartimento.

Existe además otra categoría: los hiperparámetros de entrenamiento, como la tasa de aprendizaje, que regulan cómo se desarrolla el entrenamiento. Una aplicación empresarial que llama a un modelo ya existente normalmente no controla ni esos ajustes de entrenamiento ni los pesos aprendidos.

Los tokens son otra cosa. Son las unidades en las que se dividen la entrada y la salida, a menudo fragmentos de palabras. Añadir tokens a un prompt no aumenta los parámetros del modelo. La guía sobre tokens en IA explica esa unidad; la guía del prompt de sistema muestra cómo las instrucciones orientan el comportamiento sin modificar los pesos entrenados.

Primera parte: los parámetros del modelo indican su escala

El número de parámetros ayuda a estimar el almacenamiento y el cómputo, pero no permite elegir por sí solo el mejor modelo para una tarea empresarial. Úsalo como punto de partida al planificar la infraestructura. La decisión final debe apoyarse en una evaluación de la tarea concreta.

¿Qué significan los miles de millones de parámetros de un LLM?

La «B» representa mil millones de valores aprendidos. Un modelo denominado 70B tiene aproximadamente 70 mil millones de parámetros; la «T» representa un billón. Los nombres publicados pueden estar redondeados, así que una estimación precisa del despliegue debe basarse en el checkpoint real y en su formato de almacenamiento.

Dos modelos con el mismo número de parámetros pueden tener arquitecturas, datos de entrenamiento, métodos de entrenamiento y especializaciones diferentes. Incluso un mismo modelo puede ocupar cantidades de memoria muy distintas según la precisión con la que se almacene cada peso.

Para quien compra una solución empresarial, lo útil es saber si el modelo cumple los criterios de aceptación: ¿extrae el total correcto de una factura, conserva el identificador del cliente o genera un parche que supera las comprobaciones necesarias? Una cifra de parámetros más alta no responde a esas preguntas.

Cuánta memoria ocupan los pesos de un modelo 70B

El almacenamiento de los pesos en bruto se calcula multiplicando el número de parámetros por los bytes de cada parámetro. Para un modelo hipotético con exactamente 70 mil millones de pesos, el cálculo sería el siguiente. Son operaciones aritméticas, no mediciones de un despliegue real.

Estas cifras están expresadas en gigabytes decimales. Los 140 GB equivalen a unos 130.4 GiB, la unidad binaria que muestran algunas herramientas de memoria. La conversión cambia la unidad, no el modelo.

La documentación de Hugging Face explica cómo la cuantización, que almacena los pesos con menor precisión, reduce la memoria necesaria mientras intenta conservar la exactitud. Nuestra guía de cuantización de LLM aborda los formatos y sus ventajas e inconvenientes.

Los prompts más largos y las solicitudes simultáneas también modifican la carga al servir el modelo. La documentación del estimador de memoria de Hugging Face distingue expresamente entre cargar el modelo y ejecutar la inferencia, es decir, generar respuestas.

Qué revela el número de parámetros sobre el costo y la calidad

En igualdad de condiciones, más pesos suelen exigir más recursos para almacenar y ejecutar el modelo. Pero esa igualdad de condiciones supone mucho. La precisión, la arquitectura, el hardware, el procesamiento por lotes y la cantidad de texto procesado influyen en el resultado.

Si alojas el modelo en tu propia infraestructura, el número de parámetros ayuda a seleccionar posibles equipos. En una API alojada por un proveedor, no basta para calcular la factura: esta depende de las reglas de uso del proveedor y de tu carga de trabajo. Un modelo que exige muchos reintentos o correcciones humanas también puede ser una mala elección operativa, aunque parezca eficiente.

Para valorar la calidad, considera el tamaño como una pista sobre la capacidad, no como una puntuación. Un documento de compras debe pedir resultados con entradas representativas de tu trabajo, casos de fallo y condiciones de evaluación. No debe aceptar como prueba una estimación no publicada del número de parámetros de un modelo cerrado.

Parámetros totales y activos en los modelos MoE

Los parámetros totales describen el modelo completo; los activos, la ruta de cómputo declarada para un token. Ambas cifras importan en un modelo de mezcla de expertos, normalmente abreviado como MoE.

Un MoE contiene subredes expertas y un enrutador que decide cuáles procesan cada token. Esos «expertos» son componentes matemáticos, no especialistas a los que puedas asignar tareas contables o jurídicas. Activar solo un subconjunto puede reducir el cómputo frente a activar todo el modelo, pero los demás pesos siguen necesitando un lugar donde almacenarse. La explicación de MoE de PyTorch aborda el enrutamiento y la comunicación que requiere.

La expresión «104B activos» tiene un ejemplo concreto publicado por el fabricante: el anuncio de Kimi K3.1 Pro de Moonshot AI indica 2.8T parámetros totales y 104B activos. Al convertir el total a 2,800B, la operación es 104 ÷ 2,800, aproximadamente un 3.7% activo. Ese porcentaje es un cálculo nuestro a partir de las cifras anunciadas, no una medición de mejora de velocidad ni una clasificación de calidad.

Otro ejemplo es la ficha de Qwen3-235B-A22B de Qwen, que declara 235B parámetros totales y 22B activados. La ilustración mantiene visibles las habitaciones inactivas porque la necesidad de almacenarlas no desaparece cuando un token toma otra ruta.

Antes de desplegarlo, pregunta cómo se almacena y distribuye el modelo completo, cómo se reparten los expertos entre los equipos y qué rendimiento ofrece con tu nivel real de solicitudes simultáneas. El número de parámetros activos no especifica la memoria necesaria en el procesador gráfico (GPU). La guía sobre mezcla de expertos profundiza en esa cuestión de infraestructura.

Segunda parte: los parámetros de generación orientan la respuesta

Los ajustes de generación cambian cómo se selecciona el contenido y cuándo se detiene la respuesta, dentro de las capacidades del modelo. Una API es la interfaz a la que llama tu aplicación para solicitar una respuesta. Sus ajustes no pueden aportar fuentes que faltan, corregir una instrucción ambigua ni garantizar una respuesta correcta.

Temperatura: cuánto se concentran las probabilidades

La temperatura modifica la distribución de probabilidades que se usa para elegir el siguiente token. Los valores bajos favorecen más las opciones probables; los altos permiten mayor variación. Resulta útil para elegir entre una redacción consistente y una gama más amplia de borradores.

En un proceso de facturación, la variedad rara vez es el objetivo. Al buscar titulares alternativos para una campaña, puede ser útil. Pero una temperatura baja no convierte en verdadero un número de factura inventado, y una temperatura alta no añade conocimientos.

Ni siquiera una solicitud con temperatura cero garantiza la reproducibilidad en todos los casos. El glosario de Anthropic advierte expresamente que unas entradas idénticas pueden producir resultados distintos con temperatura cero. La reproducibilidad debe evaluarse en el conjunto del sistema que sirve el modelo.

Top-p: qué candidatos siguen disponibles

Top-p, también llamado muestreo de núcleo, limita el conjunto de candidatos según su probabilidad acumulada. Es un umbral de probabilidad, no el número de candidatos ni un porcentaje del vocabulario.

Si usamos como ejemplo una distribución de probabilidades del siguiente token de 0.60, 0.25, 0.10 y 0.05, un umbral top-p de 0.9 necesita los tres primeros candidatos: los dos primeros suman 0.85 y los tres primeros alcanzan 0.95. Estas cifras son un ejemplo didáctico, no la salida observada de un modelo.

La temperatura modifica las probabilidades; top-p recorta el conjunto de candidatos elegibles. Para una configuración empresarial inicial, cambia un solo control de muestreo a la vez. Es también lo que recomienda OpenAI en su referencia de Chat Completions.

Límite de tokens del LLM: un máximo, no una extensión solicitada

El límite de tokens de generación fija un máximo para la respuesta. No le pide al modelo que use exactamente esa cantidad ni amplía su ventana de contexto, es decir, su capacidad para manejar la conversación.

Un límite demasiado bajo puede dejar a medias un objeto JSON, una oración o un parche de código. Un máximo elevado tampoco vuelve útil la respuesta por sí solo. Indica la extensión deseada en el prompt y deja suficiente margen bajo el límite para obtener un resultado completo.

El razonamiento exige otra distinción. La referencia de Responses de OpenAI señala que su máximo de salida incluye tanto los tokens visibles como los de razonamiento. La referencia de Messages de Anthropic también cuenta los tokens de pensamiento dentro de max_tokens. No calcules el presupuesto de una solicitud con razonamiento suponiendo que todos los tokens permitidos aparecerán en la respuesta final.

Secuencias de parada: terminar en un punto definido

Una secuencia de parada detiene la generación cuando aparece una cadena de texto determinada. Úsala solo si la aplicación dispone de un límite fiable, como un marcador de fin explícito que no pueda aparecer legítimamente en el contenido.

Un salto de línea no sirve como parada general para un informe de varias líneas. Una llave de cierre tampoco sirve como parada general para JSON anidado: la primera llave coincidente puede cortar la respuesta antes de tiempo. Para extraer datos estructurados, utiliza preferentemente el mecanismo de esquemas que admita el proveedor y valida los campos recibidos.

Lo sensato suele ser empezar sin secuencias de parada personalizadas. El límite de tokens de salida y la validación siguen siendo necesarios.

Penalizaciones: reducir la repetición con cuidado

La penalización por presencia depende de si un token ya apareció. La penalización por frecuencia depende de cuántas veces apareció. Los valores positivos desincentivan su reutilización; los negativos pueden favorecerla, siempre que el endpoint admita esos valores.

Repetir texto no siempre es un defecto. Un código de producto, un nombre de cliente, una clave JSON o un identificador de programación pueden necesitar repetirse exactamente. Penalizarlos puede perjudicar la tarea.

Para extracción y código, empieza sin penalizaciones por repetición. Para redacción, corrige primero cualquier instrucción que favorezca una estructura repetitiva. Solo después considera una penalización pequeña y compatible, y comprueba si mejora el borrador sin alterar la terminología obligatoria. La referencia de generación de Google también advierte que las penalizaciones de frecuencia negativas pueden provocar bucles de tokens repetidos.

Rangos y valores predeterminados de las API de OpenAI, Anthropic y Google

El endpoint, el modelo y la versión de la API determinan qué ajustes puedes enviar. Que un campo tenga el mismo nombre en varios SDK no demuestra que todos los proveedores implementen el mismo control.

La tabla se limita a Chat Completions de OpenAI, la API Messages de Anthropic en su versión 2026-10-21 y generateContent de Gemini Developer API de Google. No traslada ajustes de Vertex AI ni de Interactions API de Google.

NS significa que la documentación del campo citada, en su versión actual, no especifica un rango numérico o un valor predeterminado. No significa cero, ilimitado ni incompatible. «Omitir» es una recomendación para la aplicación, no un valor predeterminado inventado del proveedor.

Fuentes: esquema de solicitud de OpenAI, esquema de solicitud de Anthropic, migración de versión de Anthropic, esquema de generación de Google, metadatos de modelos de Google y rango de top-p de Google.

La tabla general de solución de problemas de Google indica un rango de temperatura más estrecho que la referencia del campo de generación. Utiliza esa referencia junto con maxTemperature del modelo elegido; consulta Model.temperature, Model.topP y Model.outputTokenLimit para conocer los valores específicos del modelo. Una solicitud de ejemplo no equivale a un valor predeterminado documentado.

OpenAI: primero, comprobar la compatibilidad con el razonamiento

La guía actual de GPT-6 de OpenAI indica que hay que retirar temperature y top_p cuando el esfuerzo de razonamiento no es none. GPT-6 Astra y GPT-6.1 Sol no admiten none; GPT-6 Sol y GPT-6 Luna sí. Es una restricción de compatibilidad, no la documentación de una temperatura numérica fija.

El endpoint también importa. Responses usa max_output_tokens, cuyo mínimo en el esquema actual es 16; allí no se especifican ni un valor numérico predeterminado ni un máximo universal. Su esquema de creación no incluye los campos stop, presence_penalty ni frequency_penalty de Chat Completions. En Chat Completions, la referencia señala expresamente que o3 y o4-mini no admiten stop y declara obsoleto max_tokens en favor de max_completion_tokens.

La regla práctica es construir la solicitud para el endpoint elegido y aplicar después las reglas de compatibilidad del modelo. No copies toda la tabla en una sola solicitud.

Anthropic: una versión de la API puede eliminar el ajuste

La guía de migración del 21 de octubre de Anthropic indica que enviar temperature, top_p o top_k con la versión 2026-10-21 de la API produce un error 400, incluso si se envía un valor predeterminado. Al omitir esos campos, el comportamiento incluye una temperatura de 1.0.

Usar versiones anteriores de la API no recupera automáticamente esa flexibilidad en todos los modelos. La documentación de pensamiento de Anthropic señala que modelos como Claude Sonnet 5.5 rechazan valores de muestreo distintos de los predeterminados, esté o no activado el pensamiento. Para esos modelos, fija un top-p predeterminado de 0.99 y dice expresamente que 1 se rechaza. Un rango genérico de una versión anterior no invalida esa regla del modelo.

Para generar una respuesta, proporciona un presupuesto positivo de max_tokens dentro del límite del modelo. El mínimo documentado de cero sirve para precargar la caché sin producir una respuesta; no es una configuración útil para extracción.

Google: que un ajuste se acepte no significa que tenga efecto

La guía de migración de Gemini 3.6 Flash y 3.5 Flash-Lite de Google señala que esos modelos ignoran los ajustes obsoletos de temperatura, top-p y top-k. Indica a los desarrolladores que los retiren y advierte que las futuras generaciones de modelos los rechazarán con un error 400.

Esto genera un fallo distinto al rechazo de una solicitud: puede parecer que tu aplicación acepta un cambio de temperatura mientras el modelo se comporta exactamente igual. Revisa la documentación del modelo elegido antes de interpretar una respuesta correcta de la API como prueba de que el control surtió efecto.

Ajustes razonables para tareas empresariales

Empieza por el comportamiento que admite el proveedor y por una definición medible del éxito. Las cifras siguientes son nuestras propuestas iniciales para endpoints que permiten ajustes. No son valores predeterminados del proveedor, óptimos medidos ni configuraciones transferibles a cualquier sistema. Las reglas de compatibilidad anteriores tienen prioridad.

Extracción: conservar los valores exactos

Para extraer campos de facturas, clasificar solicitudes de soporte u obtener metadatos de contratos, prueba una temperatura de 0 o 0.2 solo si el modelo la admite. Deja top-p como está. Omite las paradas personalizadas y las penalizaciones por repetición; en un modelo compatible de OpenAI Chat Completions, establecer expresamente ambas penalizaciones en 0 es otra forma de definir una configuración de referencia sin penalizaciones.

En las solicitudes actuales de Anthropic y en los modelos Gemini Flash mencionados, omite los controles de muestreo. Incluye definiciones explícitas de los campos, categorías permitidas, ejemplos de datos ausentes y la función de salida estructurada que admita el proveedor. Valida el resultado independientemente de su formato.

Para un registro extraído breve, un máximo inicial de 1,000 tokens de salida puede servir como primera prueba en una solicitud compatible sin razonamiento. No es un límite universal: revisa los cortes y el consumo real, y reserva por separado el presupuesto de razonamiento cuando corresponda. Pide un marcador de valor ausente en lugar de un número de factura inventado.

Criterio de aceptación: están presentes todos los campos obligatorios, los valores coinciden con la fuente y la información ausente sigue ausente. Superar la validación de JSON no basta.

Redacción: variar la forma sin alterar los hechos

Para un correo de contacto comercial o una descripción de producto, empieza con el comportamiento predeterminado que admita el modelo. En un endpoint ajustable, compáralo con una temperatura de 0.7 y mantén top-p sin cambios. Especifica en el prompt el público, la extensión, el tono, los hechos obligatorios y las afirmaciones prohibidas.

Empieza sin penalizaciones. Si un modelo compatible de OpenAI Chat Completions repite expresiones que quieres evitar, una penalización de frecuencia de 0.2 es una prueba moderada dentro de su rango documentado. Consérvala solo si la revisión demuestra una mejora; los nombres de producto obligatorios deben mantenerse intactos.

En los modelos que eliminan los controles de muestreo, pide explícitamente enfoques distintos, como un borrador breve y factual y otro narrativo. Evalúa las diferencias en los textos resultantes.

Criterio de aceptación: variación útil sin nuevas afirmaciones de hecho. «Más sorprendente» no equivale a «mejor texto comercial».

Código: dar margen para terminar y comprobar el comportamiento

Para un parche acotado en un endpoint ajustable, una temperatura de 0 o 0.2 es un punto de comparación razonable. En un modelo de razonamiento, sigue la configuración admitida y omite los campos de muestreo incompatibles. Deja fuera las penalizaciones por repetición y las paradas personalizadas, salvo que las exija un protocolo probado.

Proporciona el código pertinente, las restricciones y el comportamiento esperado. Deja suficiente margen de salida para un parche completo. Si la respuesta alcanza su límite, considera incompleto el resultado en lugar de dar por hecho que la parte visible se puede aplicar con seguridad.

Criterio de aceptación: el parche cumple la especificación y supera las comprobaciones adecuadas. Repetir identificadores es normal en el código, y una respuesta que parece convincente no demuestra que funcione.

Lo que ni el número de parámetros ni los ajustes pueden garantizar

La promesa exagerada es que una sola cifra puede sustituir una evaluación. No puede, tanto si hablamos del número de pesos como de la temperatura.

Un modelo más grande no es automáticamente mejor para tu proceso específico. Una cifra menor de parámetros activos en un MoE no significa que el modelo completo quepa en esa cantidad de memoria. Una temperatura baja no garantiza veracidad. Un límite de salida alto no garantiza un argumento completo, y una llamada exitosa a la API no demuestra que se hayan aplicado todos los ajustes enviados.

La evidencia útil consiste en una entrada representativa, una condición de éxito definida y un resultado revisado. Si vas a comprar, pide al proveedor que demuestre el proceso con la configuración que realmente usarás. Si vas a desarrollar, registra el modelo, el endpoint, la versión de la API, el prompt y los ajustes para poder entender qué cambió cuando cambie el comportamiento.

Próximos pasos para quienes compran, operan y desarrollan

Quienes compran deben comparar resultados; quienes operan, definir qué constituye un fallo; quienes desarrollan, retirar la configuración incompatible. Esas responsabilidades convergen en el mismo pequeño conjunto de evaluación.

Quien elige un servicio alojado puede avanzar sin conocer el número de parámetros si el servicio demuestra los resultados necesarios. Antes de comprar hardware para alojar el modelo, espera a dimensionar el checkpoint completo, la precisión y la carga de trabajo. Quien ya tiene un proceso que funciona no necesita sustituirlo porque otro modelo anuncie una cifra más alta.

Los desarrolladores que cambien de modelo o de versión de API deben comprobar la compatibilidad desde ahora. A quienes operan mediante una interfaz gestionada que no muestra controles de generación, la sintaxis de los campos de solicitud les afecta poco, pero siguen teniendo que validar la salida.

1. 1

   Reúne los casos que deben resolverse bien

   El próximo lunes, reúne 20 ejemplos representativos de un mismo proceso, incluidas entradas incompletas, ambiguas y especialmente largas. Define el resultado esperado o los criterios de revisión antes de comparar modelos.

2. 2

   Deja explícita la configuración de la solicitud

   Registra el endpoint, el modelo y la versión de la API. Comprueba qué controles se admiten, retira los demás y elige un presupuesto de salida que permita obtener un resultado completo. Incluye en el prompt la terminología obligatoria y cómo tratar los datos ausentes.

3. 3

   Cambia una sola cosa y evalúa el resultado

   Compara la configuración de referencia con un único ajuste compatible. En extracción, comprueba la correspondencia con la fuente; en borradores, la exactitud de los hechos y la utilidad; en código, el comportamiento y las comprobaciones. Conserva la configuración más sencilla salvo que el cambio demuestre su valor.

Preguntas frecuentes

¿Cómo funciona el parámetro de temperatura en un LLM?

Modifica cuánto se concentra la distribución de probabilidades del siguiente token. Los valores bajos favorecen las opciones probables; los altos permiten más variedad. Cambia el muestreo, no los pesos aprendidos, y algunas API actuales rechazan o ignoran este ajuste.

¿Cuánto ocupa aproximadamente un modelo 70B?

Para exactamente 70 mil millones de pesos, el almacenamiento en bruto es de unos 140 GB a 16 bits, 70 GB a 8 bits o, en condiciones ideales, 35 GB a 4 bits. Estas cifras decimales excluyen la memoria de ejecución y la sobrecarga de cuantización. El checkpoint real y la carga de trabajo determinan los requisitos del despliegue.

¿Cuáles son los cuatro tipos de parámetros?

No existe una clasificación universal de cuatro tipos para los LLM. Una distinción útil separa los parámetros aprendidos del modelo, los ajustes de arquitectura, los de entrenamiento y los de generación. Son categorías para entender el sistema, no una afirmación de que todas las API tengan cuatro controles.

¿Qué diferencia hay entre GPT y LLM?

LLM significa modelo de lenguaje de gran tamaño y es la categoría general. GPT significa transformador generativo preentrenado y designa una familia de modelos y un enfoque concreto dentro de esa categoría. Otras familias de modelos de lenguaje también son LLM.

¿Cuáles son los cuatro tipos de LLM?

No existe una única lista estándar de cuatro tipos. Denso frente a mezcla de expertos describe la arquitectura; pesos abiertos frente a cerrados describe la disponibilidad. Esas distinciones responden a preguntas diferentes y no deben mezclarse en una supuesta clasificación de calidad.

¿ChatGPT es un LLM o una IA?

ChatGPT es una aplicación de IA que utiliza modelos. Conviene distinguir la aplicación, el modelo seleccionado dentro de ella y los ajustes de API disponibles para los desarrolladores: son capas distintas.

¿Qué tipos de IA no son LLM?

La IA abarca más que los modelos de lenguaje. Un clasificador de fraude o un sistema de visión por computadora pueden usar métodos de aprendizaje automático sin recurrir a un LLM. El número de parámetros tampoco es un concepto exclusivo de los modelos de lenguaje.

¿Cuál es el LLM de IA más inteligente?

El número de parámetros no permite dar una respuesta válida para todas las tareas. Compara modelos con ejemplos representativos del trabajo, los mismos criterios de aceptación y una configuración documentada. Un resultado en una prueba de referencia no resuelve todas las tareas empresariales.

¿A qué rama de la IA pertenecen los LLM?

Los LLM son modelos de aprendizaje profundo que se utilizan para procesar y generar lenguaje. Sus parámetros aprendidos pertenecen al modelo; la temperatura y otros controles de la solicitud corresponden a la forma en que la aplicación lo utiliza.

Para recibir explicaciones prácticas sobre sistemas de IA y las decisiones que implican, suscríbete al boletín.