La IA local ya no es un juguete. Tampoco es ChatGPT sin nube

Una empresa no puede enviar determinados datos a un servicio externo. Tiene informes, expedientes o documentación interna que quiere clasificar, resumir o convertir en información estructurada. La pregunta aparece cada vez más: ¿podemos instalar un modelo de IA en un ordenador propio y hacer allí el trabajo?

La respuesta honesta es menos cómoda. Para una tarea acotada —clasificar documentos, extraer campos o preparar un primer resumen— puede ser sí. Para instalar «un ChatGPT privado» que resuelva casi cualquier cosa con la misma calidad y velocidad en un portátil corriente, normalmente es no.

Entre ambos extremos existe un territorio cada vez más amplio. Ejecutar un modelo en local no garantiza que sea suficientemente bueno, que responda a una velocidad razonable ni que el sistema cumpla la normativa. Pero tampoco hace falta ya una máquina de laboratorio para obtener algo útil.

Ese territorio está cambiando rápido. Modelos que hace poco habrían parecido enormes ahora caben cuantizados en una GPU de consumo. Otros, con entre cuatro y doce mil millones de parámetros, realizan en un portátil tareas documentales concretas que sí tienen valor empresarial.

La amplitud del término se ve bien en dos equipos anunciados por Apple en agosto. El Mac mini con M6 llega hasta 32 GB de memoria unificada; el Mac Studio con M5 Ultra, hasta 512 GB y 1,2 TB/s de ancho de banda. Los dos se presentan como máquinas para IA en el dispositivo, pero no resuelven la misma clase de problema. Uno permite trabajar con modelos pequeños y medianos. El otro puede mantener en memoria modelos con cientos de miles de millones de parámetros. La comparación muestra por qué «ejecutar IA en local» es todavía una descripción demasiado imprecisa para tomar una decisión de arquitectura.

La cuestión ha dejado de ser si se puede ejecutar IA en local. Ahora hay que preguntar qué tarea, con qué nivel de error, sobre qué datos y a qué velocidad.

Qué significa realmente ejecutar un modelo en local

Durante el entrenamiento, un modelo aprende millones o miles de millones de valores numéricos llamados pesos. Son el resultado de su aprendizaje: pequeños ajustes numéricos que, combinados, determinan qué respuesta produce ante una entrada. Entrenar un modelo general sigue requiriendo una infraestructura enorme. La inferencia es otra cosa: consiste en cargar esos pesos ya aprendidos y utilizarlos, sin volver a entrenar el modelo.

Cuando descargamos un modelo de pesos abiertos y lo abrimos con herramientas como llama.cpp, Ollama o LM Studio, la inferencia puede ocurrir enteramente en nuestro equipo. El texto no tiene que viajar a los servidores del desarrollador del modelo. Para una prueba, la experiencia se parece bastante a instalar una aplicación: se descarga un programa, se elige un modelo y se empieza a conversar.

Pero conviene distinguir tres despliegues que suelen mezclarse bajo la palabra local:

• en el dispositivo, cuando el modelo se ejecuta en el portátil o móvil de una persona;
• on-premise, cuando corre en un servidor controlado por la organización;
• en una nube privada, cuando la infraestructura es remota pero está aislada y operada bajo las condiciones de la empresa.

Los tres pueden evitar enviar datos a una API pública, pero no ofrecen las mismas garantías. Una aplicación local puede conservar historiales, descargar componentes, enviar telemetría o sincronizar carpetas con una copia de seguridad externa. El modelo puede estar en la oficina mientras el OCR, la base vectorial o la observabilidad siguen fuera.

Inferencia local describe dónde se ejecuta el modelo, no toda la ruta que recorren los datos.

Que un modelo pueda ejecutarse no significa que el proceso sea viable

Al evaluar un proceso con inferencia local conviene separar tres condiciones:

1. ¿El modelo y el contexto necesario caben en la infraestructura controlada?
2. ¿La latencia y la concurrencia son aceptables para el proceso?
3. ¿El resultado alcanza el umbral de calidad y error que exige la tarea?

Cumplir la primera solo demuestra que el modelo puede cargarse. No demuestra que el sistema vaya a ser útil.

La primera se puede estimar. Un modelo de 27.000 millones de parámetros ocupa alrededor de 54 GB si se reservan 16 bits —16 dígitos binarios— para guardar cada peso. La cuantización reduce ese espacio representando los valores con menos detalle. Se parece a redondear millones de números: el modelo ocupa menos, a cambio de perder algo de precisión. En 4 bits, la cuenta teórica baja a unos 13,5 GB, aunque el archivo real y la ejecución necesitan algo más.

Qwen 3.8 27B ilustra bien el cambio. Sus pesos originales ocupan 55,6 GB. Una versión Q4 —cuantizada a unos cuatro bits por peso— utilizada por Simon Willison ocupa unos 17 GB y puede analizar imágenes, generar código y pedir a otras herramientas que ejecuten acciones. Eso no quiere decir que funcione dentro de 17 GB de memoria total: también hacen falta el programa, el sistema operativo, los cálculos intermedios y la memoria de contexto.

La ventana de contexto merece especial atención. Es la cantidad de texto que el modelo puede tener presente al responder, medida en tokens: fragmentos de palabras en los que divide el texto. Un modelo puede anunciar 128.000 o 256.000 tokens y, sin embargo, no poder utilizarlos de forma razonable en un portátil. A medida que crece la conversación, necesita reservar más memoria para recordar esos fragmentos y tarda más en leer la entrada completa. El contexto máximo de la ficha técnica no es el contexto operativo de nuestro sistema.

La latencia y la capacidad de atender varias peticiones dependen mucho del ancho de banda de memoria. La capacidad determina si los pesos caben; el ancho de banda, a qué velocidad puede leerlos el procesador. Es la diferencia entre el tamaño de una estantería y la rapidez con la que podemos sacar libros de ella. Durante la generación, el equipo tiene que mover repetidamente una gran parte de los pesos. Por eso una GPU con memoria rápida suele responder mucho mejor que una CPU, aunque ambas tengan capacidad suficiente. La memoria unificada de Apple Silicon y de algunos procesadores AMD permite que CPU y GPU compartan el mismo depósito; una GPU dedicada de NVIDIA suele ofrecer más velocidad, pero está limitada a su propia memoria, la VRAM.

llama.cpp también permite repartir el modelo entre CPU y GPU. Puede servir para una prueba, pero leer pesos desde la RAM a través del bus reduce la velocidad y puede invalidar el resultado si el proceso necesita respuestas interactivas o varias peticiones simultáneas.

Estas magnitudes sirven para acotar qué clase de prueba puede tener sentido en cada entorno:

Memoria disponible en el entorno	Modelos que suelen caber cuantizados	Qué permite evaluar
16 GB de RAM sin GPU dedicada	2B–8B; 12B con ajustes	Clasificación, extracción sencilla y flujos muy acotados. Los documentos largos y la concurrencia revelan pronto el límite.
32 GB de RAM o memoria unificada	8B–14B con margen; 20B–27B con compromisos	Análisis documental, RAG —buscar primero fragmentos en documentación propia— y asistentes internos sobre los que empezar una evaluación seria.
GPU con 12–16 GB de VRAM	8B–14B completo en GPU; algunos MoE de unos 20B	Latencia interactiva con contexto moderado. Un 27B suele exigir más cuantización o descarga a RAM.
GPU con 24 GB de VRAM	20B–32B en 4 bits	Instrucciones más complejas, herramientas y código, siempre midiendo el coste de los errores y la concurrencia.
64–128 GB de memoria unificada o varias GPU	70B y algunos MoE mayores con cuantización agresiva	Casos más abiertos y excepciones difíciles; hay que comprobar si la mejora compensa coste y latencia.
192–512 GB de memoria unificada o un servidor multi-GPU	Modelos de más de 100B y grandes MoE cuantizados	El límite técnico de una estación de trabajo, no el punto de partida de una arquitectura empresarial.

Hay máquinas compactas con 128 GB de memoria unificada, como NVIDIA DGX Spark o equipos basados en Ryzen AI Max+ 395, capaces de cargar modelos mucho mayores. NVIDIA anuncia hasta 200B parámetros y AMD ha mostrado modelos de 128B. Es una demostración de capacidad de memoria, no una promesa de experiencia interactiva: cargar un modelo de 100B y querer utilizarlo todo el día siguen siendo problemas distintos.

La nueva gama de Apple también ayuda a separar capacidad y velocidad. El Mac mini M6 ofrece hasta 32 GB y 170 GB/s; el M5 Pro del mismo formato llega a 64 GB y 307 GB/s. El Mac Studio M5 Ultra sube hasta 512 GB y 1,2 TB/s. Un chip más nuevo no elimina el límite físico: si los pesos no caben, no caben. Apple los anunció el 25 de agosto de 2026 y empezará a entregarlos el 22 de septiembre, así que las cifras del M5 Ultra son todavía especificaciones del fabricante, no experiencia independiente de usuarios.

La misma capacidad necesita cada vez menos infraestructura

El número de parámetros dejó hace tiempo de ser una medida suficiente de inteligencia. Importan la calidad y composición de los datos, la arquitectura, el entrenamiento posterior, el aprendizaje por refuerzo y la capacidad de dedicar más cómputo a razonar en una petición difícil.

También importa la generación a la que pertenece el modelo. El AI Index de Stanford ofrece una comparación reveladora: en 2022, el modelo más pequeño que superaba el 60% en MMLU tenía 540B parámetros. En 2024, Phi-3 Mini alcanzó ese umbral con 3,8B, una reducción de 142 veces. MMLU no representa el trabajo real de una empresa, pero el desplazamiento de la frontera sí es significativo.

Un análisis de Epoch AI estimó que las mejoras algorítmicas redujeron a la mitad, aproximadamente cada ocho meses, el cómputo necesario para alcanzar un nivel dado de rendimiento en modelos de lenguaje preentrenados. El intervalo de incertidumbre es amplio y buena parte del progreso total sigue procediendo de entrenar con más datos y cómputo. Aun así, ayuda a explicar por qué comparar un modelo de 8B actual con uno de 8B de hace dos años dice poco.

La eficiencia llega por varios caminos:

• mejores datos y entrenamiento posterior permiten aprovechar más cada parámetro;
• la cuantización reduce memoria y ancho de banda con una pérdida de calidad que puede ser pequeña o importante según el modelo y la tarea;
• las arquitecturas mixture of experts dividen el modelo en grupos especializados y solo consultan algunos para cada token, aunque todos deben permanecer cargados;
• la predicción especulativa permite que un mecanismo barato proponga varios tokens y que el modelo principal los verifique;
• los programas que ejecutan los modelos aprovechan mejor la GPU, la memoria unificada y las NPU, chips dedicados a acelerar operaciones de IA;
• los modelos especializados renuncian a ser buenos en todo para resolver una función concreta con menos recursos.

Los modelos MoE introducen otra confusión habitual. gpt-oss-20b tiene 21B parámetros totales pero utiliza unos 3,6B para generar cada token. Trabaja con una parte del modelo cada vez, pero necesita conservarlo entero en memoria: su archivo de pesos cuantizado sigue ocupando 12,8 GB y OpenAI sitúa el mínimo del sistema alrededor de 16 GB. Google explica lo mismo para Gemma 4 26B A4B: utiliza 4B por token, pero los 26B deben permanecer cargados para escoger rápidamente qué grupos intervienen.

Qué tareas merece la pena probar

Los benchmarks, pruebas estandarizadas que permiten comparar modelos, sirven para descartar opciones y detectar avances. Sirven peor para responder si un sistema extraerá correctamente veinte campos de nuestros informes, mantendrá el mismo formato de salida durante 10.000 documentos o sabrá abstenerse cuando falte información.

Los usos reales dibujan una frontera irregular:

Clase aproximada de modelo	Tareas razonables para una prueba	Riesgos que hay que medir
2B–4B	Clasificación, reescritura, extracción sencilla, autocompletado, comandos locales y tareas muy repetibles	Instrucciones largas, ambigüedad, razonamiento de varios pasos y fidelidad sobre documentos extensos
8B–14B	Resumen, extracción estructurada, borradores, RAG, consultas sobre documentación, scripts de análisis y visión básica	Flujos largos con herramientas, excepciones poco frecuentes y decisiones que exigen conocimiento experto fiable
20B–32B	Asistente general competente, código sobre repositorios acotados, visión, uso de herramientas y análisis con varios pasos	Agentes prolongados, velocidad en hardware modesto y fiabilidad comparable a los mejores sistemas alojados
70B o más	Mayor robustez en tareas abiertas y complejas	Coste, latencia, operación y el hecho de que seguirán pudiendo producir errores convincentes

Estas bandas se solapan. Un modelo de 4B ajustado para una clasificación puede superar a uno general de 27B. Un modelo grande mal cuantizado, con la plantilla de conversación incorrecta o con poco contexto puede comportarse peor que uno pequeño bien servido.

Algunos modelos actuales sirven para anclar esas bandas, no para saltarse la evaluación.

Gemma 4 12B necesita, según Google, unos 6,7 GB para los pesos en Q4 antes de añadir contexto y runtime. Puede recibir texto, imagen y audio, y Google muestra análisis local de archivos mediante scripts de Python. Que quepa en un portátil con 16 GB y funcione bien en una demostración no prueba que mantenga un esquema, use herramientas o trate excepciones con la fiabilidad que necesita un proceso.

gpt-oss-20b cabe en unos 16 GB, es solo texto y está orientado a razonamiento, salidas estructuradas y herramientas. Su arquitectura MoE lo hace relativamente ligero en cómputo para su tamaño total. Puede ser atractivo para procesos controlados, aunque necesita una integración que implemente las herramientas; descargar los pesos no añade por sí solo búsqueda, ejecución de código ni acceso a archivos.

Qwen 3.8 27B es una referencia útil para la franja de 20B–32B. Es multimodal, tiene licencia Apache 2.0 y una cuantización de unos 17 GB entra en una GPU de 24 GB o en un equipo con suficiente memoria unificada. En las pruebas de Willison pudo inspeccionar un repositorio, construir y probar una utilidad, localizar objetos en imágenes y conducir un agente de código. Obtuvo entre 15 y 30 tokens por segundo —una medida del ritmo al que aparece la respuesta, no de su inteligencia— en un MacBook Pro con M5 Max y en un DGX Spark. Eso demuestra una combinación de capacidades; no garantiza la fiabilidad de un proceso concreto.

DeepSeek V4 Flash sirve para observar el extremo opuesto: el límite de lo que una estación de trabajo de gama alta puede cargar. Es un MoE con 284B parámetros totales, unos 13B activos por token y una ventana anunciada de un millón de tokens. No es «un poco más grande» que Qwen 27B: mueve una cantidad de cómputo por token mucho menor que un modelo denso de 284B, pero todos sus expertos deben permanecer en memoria. Una cuantización experimental de 2,44 bits para MLX ocupa 92,8 GB y alcanzó unos 32–36 tokens por segundo con contexto corto en un MacBook Pro M5 Max de 128 GB. La misma prueba midió una pérdida apreciable frente al modelo alojado, y las cuantizaciones cercanas a cuatro bits rondan los 150–170 GB. Es una demostración técnicamente relevante, pero depende de equipos, cuantizaciones y runtimes muy concretos. No describe una opción disponible en cualquier ordenador ni una base que una empresa deba adoptar por defecto.

Los dos ejemplos representan decisiones distintas. Qwen 27B muestra lo que empieza a ser operativo con recursos razonables. DeepSeek V4 Flash muestra hasta dónde llega hoy una estación de trabajo de varios miles de euros. Que ambos se llamen «IA local» no los convierte en la misma decisión de arquitectura.

La variación entre pruebas reales refuerza la misma idea. Hay usuarios que completan flujos de decenas de llamadas a herramientas sobre una RTX 3090; otros encuentran errores importantes al revisar el código del mismo modelo. No es ruido que un benchmark vaya a eliminar. Es el efecto de cambiar la tarea, el prompt, la cuantización, el runtime y las herramientas.

La única prueba relevante para una empresa termina siendo una batería propia con casos reales, incluidos los casos raros y los fallos costosos.

Un ejemplo: analizar informes médicos sin sacarlos de la organización

Imaginemos que el objetivo no es diagnosticar, sino convertir informes heterogéneos en un conjunto de campos revisables: fecha, especialidad, medicación, pruebas realizadas y referencias a antecedentes.

Un prototipo puede consistir en arrastrar un PDF a una aplicación local y pedir un resumen. Un sistema operativo necesita separar responsabilidades. Primero, un OCR convierte en texto las páginas que solo contienen una imagen; después, el modelo devuelve los campos en JSON, un formato estructurado que el resto del software puede leer y validar:

documento
   ↓
OCR y extracción de texto locales
   ↓
modelo local → JSON + fragmentos que justifican cada campo
   ↓
validaciones deterministas
   ↓
revisión humana de errores y casos dudosos
   ↓
sistema de registro de la organización

El sistema debe permitir que el modelo devuelva null cuando el informe no contiene un valor y exigir que cite el fragmento de origen. Fechas, códigos y formatos se validan después con reglas convencionales que producen siempre el mismo resultado ante el mismo dato. Los casos dudosos se envían a revisión mediante comprobaciones externas, no confiando únicamente en la seguridad con la que el propio modelo redacta su respuesta. Una muestra representativa permite medir precisión y, sobre todo, falsos negativos: datos que sí estaban en el informe pero que el sistema no detectó.

En este tipo de proceso, un modelo de 8B o 12B puede ser suficiente si el esquema es estable y los documentos son previsibles. Aumentar a 27B puede mejorar instrucciones complejas, documentos difíciles y excepciones, pero también reduce velocidad y capacidad concurrente. Dimensionar la infraestructura antes de fijar el error tolerable invierte el orden correcto: primero se define el umbral y se prueba el modelo más pequeño que lo cumple.

El ejemplo también muestra que la privacidad no depende solo del LLM. Hay que comprobar el OCR, el almacenamiento temporal, los logs, la interfaz, las copias de seguridad y el destino del resultado.

Ejecutar en local reduce una exposición, no concede una excepción legal

Si los datos no salen de una infraestructura controlada, desaparece o se reduce un riesgo importante: la entrega de información a un tercero. La CNIL francesa recomienda considerar soluciones locales, seguras y especializadas cuando se introducen datos personales o documentación sensible. No dice que instalar un modelo resuelva el cumplimiento.

Procesar datos personales sigue siendo procesar datos personales aunque ocurra sin Internet. La organización continúa necesitando una finalidad definida, una base jurídica, minimización, plazos de conservación, control de accesos, seguridad y atención a los derechos de las personas. Con datos de salud se añade el régimen de categorías especiales del artículo 9 del RGPD. Según la escala, el riesgo y el uso, puede ser necesaria una evaluación de impacto.

También hay que separar tres capas legales:

1. La licencia del modelo. Pesos descargables no significa ausencia de condiciones. Qwen 3.8 y Gemma 4 se publican bajo Apache 2.0; gpt-oss combina Apache 2.0 con su política de uso. Otros modelos tienen licencias comunitarias, límites de redistribución o políticas de usos prohibidos. La cuantización descargada de un tercero debe conservar y acreditar la licencia adecuada.
2. La protección de los datos introducidos. El RGPD se aplica a la finalidad y al tratamiento, no al país en el que se fabricó la GPU. Los historiales, los embeddings —representaciones numéricas de los documentos usadas para buscarlos— y los registros de instrucciones también pueden contener datos personales.
3. La regulación del sistema y su uso. El Reglamento de IA clasifica por finalidad prevista. Resumir documentación para ayudar a una persona no es lo mismo que recomendar un tratamiento o convertirse en software médico. Un sistema que sea un producto sanitario, un componente de seguridad o que participe en determinadas decisiones puede quedar sujeto a obligaciones de alto riesgo y a normativa sectorial.

La exención que el Reglamento de IA contempla para cierto software libre tampoco es un permiso general. No cubre de la misma manera sistemas prohibidos, de alto riesgo o sujetos a determinadas obligaciones de transparencia.

Para un caso médico, laboral, financiero o legal, la revisión jurídica tiene que hacerse sobre el sistema completo y su finalidad. La pregunta no es solo «¿qué licencia tiene Qwen?», sino «¿qué decisión toma nuestro proceso, con qué datos y quién responde por ella?».

Los pesos descargados no son un sistema de producción

La facilidad para abrir un chat puede ocultar el trabajo que aparece después.

En una empresa harán falta, según el caso, autenticación, permisos por usuario, cifrado, aislamiento de red, gestión de secretos, colas, límites de uso, trazas auditables, actualización de modelos, pruebas de regresión y un procedimiento para volver atrás. Si varias personas comparten una estación de trabajo, también hay que dimensionar concurrencia: una máquina que responde bien a una conversación puede degradarse cuando recibe diez.

Además, los modelos de pesos abiertos suelen llegar con menos producto alrededor. Un servicio como ChatGPT no es solo un archivo de pesos. Incluye búsqueda, herramientas, filtros, un entorno de ejecución, gestión de contexto, infraestructura y actualizaciones. En local, alguien debe construir o elegir esas piezas y mantenerlas.

Ese control es precisamente parte del valor. Se puede fijar una versión, impedir salidas de red, observar cada llamada y retirar capacidades que no hacen falta. Pero el coste se desplaza desde el precio por token hacia hardware, electricidad, integración, seguridad y operación.

Cuándo encaja en una arquitectura

La inferencia local suele tener sentido cuando coinciden varias condiciones:

• los datos son sensibles o existen requisitos estrictos de residencia y control;
• la tarea está bien definida y se puede evaluar con ejemplos reales;
• un modelo local alcanza la calidad necesaria, aunque no sea el mejor modelo disponible;
• el volumen es estable y suficiente para aprovechar el hardware;
• se valora trabajar sin conexión, reducir latencia de red o fijar una versión;
• la organización puede operar el sistema y asumir sus actualizaciones.

Tiene menos sentido cuando el uso es esporádico, se necesita siempre la máxima capacidad, el conocimiento más reciente es esencial o no existe equipo para mantener la infraestructura. Una API empresarial bien contratada y configurada puede ser más segura que un servidor local improvisado. La ubicación física no sustituye a una arquitectura seria.

En muchos casos aparecerá un diseño híbrido. Un modelo pequeño puede clasificar, redactar o eliminar información identificativa en local. Los casos difíciles pasan a un modelo mayor dentro de una nube privada o, cuando sea jurídicamente posible, a un servicio externo. El sistema conserva en local la recuperación documental y solo escala lo necesario.

La decisión no debería presentarse como una elección ideológica entre nube y soberanía. Es una decisión de arquitectura basada en riesgo, calidad, latencia y coste total.

Qué está cambiando de verdad

La tendencia más importante no es que un portátil vaya a ejecutar el mejor modelo del mundo. Los modelos de frontera también seguirán creciendo, utilizando más cómputo durante la respuesta e integrándose con sistemas que ningún portátil puede reproducir.

Lo importante es que el nivel de capacidad que una empresa considera suficiente baja de tamaño cada año.

Veremos más modelos diseñados desde el principio para dispositivos: arquitecturas con pocos parámetros activos, cuantización incorporada al entrenamiento, memorias de contexto más pequeñas y predicción de varios tokens a la vez. Los fabricantes seguirán aumentando la memoria compartida y el ancho de banda. Los programas de inferencia aprovecharán mejor GPU y NPU sin que cada proyecto tenga que desarrollar optimizaciones específicas para su hardware.

También veremos menos chats locales genéricos y más funciones invisibles dentro de productos: clasificar una incidencia, extraer datos de una factura, buscar en documentación, preparar una respuesta o transcribir y ordenar una reunión. Un modelo pequeño que resuelve una sola tarea de forma predecible puede ser más valioso que un asistente general impresionante en una demostración.

Para las empresas, el efecto más interesante será arquitectónico. Parte de la inferencia se acercará a los datos y se convertirá en una capa más de la aplicación. Los modelos mayores quedarán como escalado para excepciones, igual que hoy no enviamos todo el procesamiento a la misma base de datos o al mismo servicio.

La inferencia local no elimina los problemas difíciles de la IA. Cambia cuál aparece primero. Ya no es necesario empezar preguntando si existe una máquina capaz de ejecutar el modelo. Podemos empezar por la pregunta que debería haber estado delante desde el principio:

¿qué parte concreta del proceso merece confiar a este modelo, y cómo sabremos cuándo se equivoca?

Fuentes

• Stanford HAI: Technical Performance, AI Index Report 2025
• Epoch AI: Algorithmic progress in language models
• Qwen: Qwen 3.8 27B, ficha y pesos oficiales
• Simon Willison: pruebas prácticas con Qwen 3.8 27B
• LocalLLaMA: experiencias de uso de Qwen 3.8 27B en programación real
• LocalLLM: modelos que los usuarios mantienen como asistentes diarios
• Google: requisitos de memoria de Gemma 4
• Google Developers: Gemma 4 12B en portátiles
• OpenAI: presentación de gpt-oss
• OpenAI: model card de gpt-oss
• llama.cpp: inferencia y cuantización en hardware de consumo
• NVIDIA: especificaciones de DGX Spark
• AMD: ejecución local de modelos grandes con Ryzen AI Max+ 395
• Apple: Mac mini con M6 y M5 Pro
• Apple: Mac Studio con M5 Max y M5 Ultra
• DeepSeek: ficha y pesos oficiales de DeepSeek V4 Flash
• MLX Community: cuantización de 2,44 bits y pruebas en M5 Max
• CNIL: preguntas y respuestas sobre despliegue de IA generativa
• Comité Europeo de Protección de Datos: Dictamen 28/2024 sobre modelos de IA y datos personales
• Comisión Europea: guía para navegar el Reglamento de IA
• EUR-Lex: Reglamento General de Protección de Datos