# IA que se ejecuta en el dispositivo, no en la cloud Curso exprés sobre IA on-device y edge — ejecutar modelos directamente en el teléfono, el portátil o el sensor en lugar de en un centro de datos. 20 conceptos — round-trip, privacidad, uso sin conexión, latencia, SLM, cuantización, destilación, fine-tuning, hybrid routing y más — cada uno con su nombre en inglés, un diagrama, un ejemplo y una ficha. La esencia: un modelo pequeño que se ejecuta localmente desbloquea privacidad, uso sin conexión, respuesta instantánea y coste cero por llamada — al precio de la capacidad bruta. Al final, una hoja de referencia de una página con todos los conceptos. - **Author:** Fedor Chishchin - **Level:** intermediate - **Reading time:** ~30 minutos de lectura - **Published:** 2026-06-13 - **Source:** https://fedorthinks.com/es/learn/edge-ai-express --- ## 1. Cloud frente a on-device Todo el tema se reduce a una pregunta: ¿dónde se ejecuta realmente el modelo? Entiende esa bifurcación — y lo que cuesta cada lado — y todo lo demás encaja. ### El mapa: 20 conceptos en seis grupos > Un mapa de metro: primero ves todas las líneas juntas, luego recorres estación por estación. Primero tres **bases**: la cloud AI, la on-device AI y el round-trip por la red que las separa. Después seis grupos, uno por capítulo: **por qué** ejecutarlo localmente, cómo hacer un modelo **pequeño**, el **sacrificio** honesto de capacidad, la **especialización**, el patrón **hybrid** y cómo **usarlo bien**. Cada concepto recibe después el mismo tratamiento: su **nombre en inglés** (apréndelo — es el término), una imagen de la vida cotidiana, un **diagrama** y una **ficha** con campos: _problema_, _idea_, _ejemplo_, _coste_, _cuándo usarlo_ y _relaciones_. _Diagram: Arriba, las bases; debajo, seis grupos que recorren los capítulos 2–7._ ### Cloud AI — el modelo en un centro de datos, a través de la red > Llamar a una oficina lejana para cada respuesta — tu pregunta viaja hasta allí, un experto responde y la respuesta vuelve, cada una de las veces. Por defecto, un modelo se ejecuta en la **cloud (cloud AI)** — en servidores potentes de un centro de datos — y tu dispositivo lo alcanza por internet. Envías la petición, se procesa de forma remota y la respuesta vuelve. Así funciona la mayoría de la IA, y es lo que hace posibles los modelos más grandes e inteligentes: necesitan hardware muy por encima de un teléfono. Pero también significa que cada llamada hace un viaje por la red hasta el ordenador de otra persona. _Diagram: Cloud: la petición viaja al centro de datos y la respuesta vuelve — en cada llamada._ #### Cloud AI (modelo en servidores remotos) - **Qué es:** El modelo se ejecuta en servidores de un centro de datos; el dispositivo lo llama por la red. - **Por qué:** Los modelos más grandes necesitan hardware muy por encima de un teléfono. - **Ejemplo:** Un asistente de chat en el navegador: cada pregunta va al servidor del proveedor. - **Coste:** Cada llamada es un round-trip, una línea en la factura y datos que salen del dispositivo. - **Relaciones:** Lo opuesto a **On-device AI**; el **round-trip** es lo que las separa. ### On-device AI / Edge AI — el modelo justo donde estás > Un experto que vive en tu casa en lugar de al otro lado de la ciudad — simplemente preguntas y la respuesta llega de inmediato, sin llamada, sin viaje. La **on-device AI**, o **edge AI**, ejecuta el modelo localmente — en el teléfono, el portátil, el sensor, el coche — sin ningún viaje a un servidor. El cómputo ocurre justo donde están los datos, en el hardware que tienes en la mano. **Edge** significa el borde de la red: lejos del centro de datos central, allí donde están los usuarios y los dispositivos. En lugar de enviar tu petición para que la respondan en otra parte, la respuesta se calcula en el sitio. _Diagram: On-device: los datos y un modelo pequeño están juntos; no hace falta centro de datos._ #### On-device AI (edge AI) - **Qué es:** El modelo se ejecuta localmente — en el teléfono, el portátil, el sensor o el coche. - **Idea:** Calcular la respuesta donde viven los datos, sin viaje a un servidor. - **Ejemplo:** El autocompletado del teclado del teléfono que funciona sin red. - **Coste:** Estás limitado a lo que el dispositivo puede ejecutar. - **Relaciones:** Necesita **modelos pequeños**; da **privacidad, uso sin conexión, latencia, $0 por llamada**. ### Round-trip — toda la diferencia es un viaje por la red > Cocinar en casa frente a pedir a domicilio — la comida puede ser la misma, pero una implica que un repartidor cruce la ciudad cada vez y la otra no. La diferencia central entre cloud y on-device no es la IA en sí — es el **round-trip**: si tus datos salen del dispositivo y si esperas a la red. Esa única distinción impulsa cada beneficio y cada sacrificio de este curso. Mantén el trabajo local y ganas privacidad, uso sin conexión y velocidad, pero estás limitado a lo que el dispositivo puede ejecutar. Envíalo a la cloud y obtienes los modelos más grandes, pero lo pagas en round-trips, coste y datos que salen. Dónde se ejecuta el modelo decide casi todo. _Diagram: A la izquierda, la cloud: ida y vuelta en cada llamada. A la derecha, el dispositivo: la respuesta en el sitio._ #### Round-trip (el viaje por la red) - **Qué es:** El viaje de la petición al servidor y el de la respuesta de vuelta. - **Por qué importa:** De él crece cada sacrificio: latencia, coste, datos que salen. - **Ejemplo:** Una llamada a la cloud: teléfono → internet → servidor → internet → teléfono. Una llamada local: nada de eso. - **Relaciones:** **Cloud AI** siempre lo paga; **On-device AI** lo evita. > **La pregunta de encuadre:** «¿Esto necesita hacer un round-trip a la cloud — o podría el modelo ejecutarse directamente en el dispositivo, y cambiaría eso algo que importe aquí?» > La cloud AI se ejecuta en servidores lejanos a los que se llega por la red; la IA on-device (edge) se ejecuta localmente, sin round-trip. Que los datos salgan o no, y que esperes o no a la red, impulsa cada sacrificio. ## 2. Por qué ejecutarlo localmente Ejecutar un modelo en el dispositivo no es solo una curiosidad técnica — desbloquea cuatro beneficios concretos que la cloud no puede igualar, y cualquiera de ellos puede ser la razón decisiva para ir en local. ### Privacy — los datos nunca salen > Guardar tu diario en un cajón cerrado en casa frente a enviar cada página por correo a una empresa para que la lea — uno guarda el secreto contigo, el otro no. La mayor razón para ejecutar en local es la **privacidad (privacy)**: si el modelo está en el dispositivo, los datos que procesa nunca tienen que salir — sin enviar fotos personales, mensajes privados o registros sensibles a un servidor. Para todo lo que los usuarios prefieren mantener en su propio hardware, o que la normativa prohíbe enviar a un tercero, la respuesta es on-device. Procesar los datos donde viven, en lugar de enviarlos al ordenador de otro, es una garantía de privacidad que ningún servicio en la cloud puede igualar del todo. _Diagram: Fotos, mensajes y notas se procesan dentro del dispositivo — nada va a un servidor de terceros._ #### Privacy (los datos se quedan en el dispositivo) - **Problema:** Los datos personales o regulados no pueden (o no deberían) enviarse a un servidor. - **Idea:** Procesar los datos donde viven — en el dispositivo. - **Ejemplo:** Buscar en fotos personales u ordenar mensajes privados sin subirlos a la cloud. - **Cuándo usarlo:** Datos sensibles, límites regulatorios, confianza del usuario. - **Relaciones:** En un **hybrid**, esta parte queda tras la **privacy boundary**. ### Offline — funciona sin conexión > Un mapa de papel sigue funcionando en un túnel donde el mapa en línea se queda en blanco — lo local no depende de la señal. Un modelo on-device funciona **sin conexión (offline)** — en un avión, en un túnel, en una zona remota, en cualquier sitio sin conexión fiable — porque no necesita un servidor. La cloud AI simplemente se detiene cuando se cae la red. Para funciones que tienen que funcionar en todas partes, o donde no se puede dar por hecha la conectividad, ejecutar en local no es una optimización, es la única opción. La independencia de la red es una capacidad que la cloud no puede ofrecer en esencia. _Diagram: Sin señal, la función en la cloud se detiene — el modelo on-device sigue respondiendo._ #### Offline (funciona sin red) - **Problema:** Sin conexión, la cloud AI no funciona en absoluto. - **Idea:** Un modelo en el dispositivo no depende de la red. - **Ejemplo:** Un avión, un túnel, una app de campo en una zona remota. - **Cuándo usarlo:** La función debe funcionar en todas partes y no se puede dar por hecha la conectividad. - **Relaciones:** Junto con la **privacy**, algo que la cloud no puede ofrecer en esencia. ### Latency — sin round-trip, sin esperas > Responder de memoria frente a llamar a alguien cada vez — de memoria es instantáneo. La **latencia (latency)** es el tiempo desde la petición hasta la respuesta. Sin round-trip por la red, un modelo on-device puede responder casi al instante, sin el retraso de llegar a un servidor lejano y volver. Para funciones donde cada instante cuenta — autocompletado, reaccionar a lo que se escribe — es un beneficio decisivo. _Diagram: En la cloud, la red de ida y vuelta se suma al cómputo. En el dispositivo, solo está el cómputo._ #### Latency (retraso de respuesta) - **Qué es:** El tiempo desde la petición hasta la respuesta. - **Cómo funciona:** En local no hay camino por la red — solo queda el cálculo. - **Ejemplo:** Las sugerencias del teclado aparecen mientras sigues escribiendo. - **Cuándo usarlo:** La función es sensible a la latencia y se llama a menudo. - **Relaciones:** Viene directamente de no tener **round-trip**. ### Per-call cost — sin factura por cada llamada > Responder de memoria es gratis. Llamar a un consultor de pago pone un cargo en cada llamada. El modelo se ejecuta en hardware que el usuario ya posee, así que no hay **coste por llamada (per-call cost)** — no le pagas a un proveedor por cada petición. Para una función de alto volumen, «instantáneo y gratis por llamada» es una combinación poderosa que la cloud, con su round-trip y su contador, no puede ofrecer. _Diagram: En la cloud la factura crece con cada petición. En el dispositivo una llamada cuesta cero — el hardware ya está pagado._ #### Per-call cost (cero en el dispositivo) - **Problema:** En la cloud, cada petición es una línea en la factura del proveedor. - **Idea:** Calcular en el hardware del usuario: una llamada cuesta cero. - **Ejemplo:** Una función llamada millones de veces al día no infla la factura. - **Cuándo usarlo:** Alto volumen de llamadas en una tarea rutinaria. - **Relaciones:** Va de la mano de la **latency**: «instantáneo y gratis por llamada». > **La pregunta del beneficio:** «¿Es la privacidad, el uso sin conexión, la respuesta instantánea o el coste cero por llamada el factor decisivo aquí — porque cualquiera de ellos puede ser la razón para ejecutar on-device?» > Ejecutar en local desbloquea cuatro cosas que la cloud no puede igualar: privacidad (los datos nunca salen), uso sin conexión (no hace falta red), respuesta instantánea (sin round-trip) y coste cero por llamada (el hardware del propio usuario). ## 3. Hacer los modelos pequeños Un teléfono no puede ejecutar un modelo de frontera gigante. Así que la IA on-device depende de hacer modelos lo bastante pequeños para caber — y hay unas pocas formas estándar de reducir uno. ### SLM — los modelos pequeños caben donde los grandes no > Una guía de bolsillo en lugar de una pared de enciclopedias — mucho menos completa, pero cabe en el bolsillo y está ahí cuando la necesitas. Un dispositivo tiene memoria y potencia de procesamiento limitadas, así que la IA on-device usa **modelos de lenguaje pequeños (SLM, small language models)** — modelos con muchos menos **parámetros** que los gigantes, construidos deliberadamente para ser compactos. No pueden saber ni hacer todo lo que hacen los modelos más grandes, pero son lo bastante pequeños para ejecutarse en un teléfono o un portátil. Todo el campo de la edge AI descansa en ellos: la tendencia hacia modelos pequeños capaces fue lo que hizo práctico ejecutar IA de verdad en local. _Diagram: Un modelo de frontera vive en el centro de datos. Un SLM tiene muchos menos parámetros y cabe en la memoria de un teléfono._ #### SLM (small language model) - **Problema:** Un modelo gigante no cabe en la memoria ni en el cómputo del dispositivo. - **Idea:** Un modelo con muchos menos parámetros, compacto por diseño. - **Ejemplo:** Un modelo pequeño incluido en una app de teléfono o portátil. - **Coste:** Menos conocimiento y más débil en tareas difíciles. - **Relaciones:** Se reduce más con la **quantization**, y un modelo grande lo enseña mediante **distillation**. ### Quantization — menos precisión, mucho más pequeño > Guardar una medida como «unos 3,1» en lugar de «3,14159265» — pierdes un poco de exactitud, pero el número ocupa mucho menos y, para casi todo, sirve igual. Una técnica clave para reducir un modelo es la **cuantización (quantization)**: guardar sus números internos (los **pesos**, o **weights**) con menor precisión — más o menos, menos dígitos — de modo que todo el modelo ocupa muchísima menos memoria y corre más rápido. Sacrificas un poco de exactitud a cambio de una gran reducción de tamaño, lo que suele ser un gran trato para caber en un dispositivo. La cuantización es cómo un modelo que no cabría en un teléfono se comprime hasta uno que sí, a menudo con una pérdida de calidad apenas perceptible. _Diagram: Los mismos pesos con menor precisión: 4 bits en lugar de 16 — cuatro veces menos memoria._ #### Quantization (pesos de menor precisión) - **Problema:** El modelo es demasiado pesado para la memoria del dispositivo. - **Idea:** Guardar los pesos con menor precisión — menos bits por número. - **Ejemplo:** Pesos de 4 bits en lugar de 16 — un modelo cuatro veces más ligero y rápido. - **Coste:** Un poco de exactitud; a menudo la pérdida apenas se nota. - **Relaciones:** Se aplica a **SLM** y a modelos **destilados** para reducirlos aún más. ### Distillation — un modelo pequeño aprende de uno grande > Un aprendiz que aprende el oficio del maestro para un trabajo concreto — no todo lo que sabe el maestro, pero lo bastante para hacer ese trabajo casi igual de bien, en una fracción del tamaño. Otra técnica es la **destilación (distillation)**: entrenar a un modelo pequeño para que imite a uno grande, de modo que el pequeño capture buena parte de la capacidad del grande en una forma mucho más compacta. El comportamiento del modelo grande, el **teacher** (maestro), se transfiere a un **student** (alumno) pequeño, lo bastante barato para ejecutarse en local. Entre los SLM construidos compactos desde el principio, la cuantización para reducirlos más y la destilación para transferir capacidad, se puede lograr que un modelo útil sea lo bastante pequeño para vivir en un dispositivo. _Diagram: El modelo teacher grande produce respuestas; el student pequeño aprende a imitarlas._ #### Distillation (teacher → student) - **Problema:** Un modelo pequeño desde cero es débil, y el grande no cabe. - **Idea:** Entrenar al modelo pequeño con las respuestas del grande — para que lo imite. - **Ejemplo:** El modelo grande etiqueta ejemplos; el pequeño aprende a producir lo mismo. - **Coste:** El student captura mucho, pero no todo, de lo que puede hacer el teacher. - **Relaciones:** Junto con **SLM** y **quantization** — las tres formas de hacer pequeño un modelo. > **La pregunta de la reducción:** «¿Puede un modelo lo bastante pequeño — compacto por diseño, cuantizado o destilado — caber en mi dispositivo objetivo y aun así hacer bien el trabajo?» > La IA on-device se apoya en modelos pequeños: SLM construidos compactos, quantization para guardarlos con menor precisión y distillation para transferir la capacidad de un modelo grande a uno pequeño que cabe en un dispositivo. ## 4. Pequeño significa menos capaz Reducir un modelo no sale gratis — un modelo pequeño de verdad no puede hacer todo lo que hace un gigante. Ser honesto con esa brecha es cómo decides qué pertenece al dispositivo. ### Capability Trade-off — no hay almuerzo gratis > Una calculadora de bolsillo frente a un laboratorio de investigación — la calculadora es instantánea y siempre contigo, pero no le pedirías que diseñe un puente. Este es el **sacrificio de capacidad (capability trade-off)**: un modelo pequeño es realmente menos capaz que uno grande. Tiene menos conocimiento general, maneja el razonamiento complejo con menos fiabilidad y es más débil en tareas difíciles y abiertas. La compacidad que le permite correr en un teléfono se paga con capacidad bruta. Así que la IA on-device no es simplemente la cloud AI hecha local — es un modelo deliberadamente más débil a cambio de privacidad, uso sin conexión y velocidad. Fingir que el modelo pequeño es igual de listo es como las funciones edge decepcionan. _Diagram: Cuanto más grande el modelo, más capaz — y más lejos del dispositivo. Cada extremo de la escala da algo y cuesta algo._ #### Capability Trade-off (tamaño frente a capacidad) - **Qué es:** Un modelo más pequeño significa menos conocimiento y razonamiento más débil. - **Qué obtienes:** Privacidad, uso sin conexión, velocidad y coste cero por llamada. - **Ejemplo:** Un modelo local completa bien una frase, pero no puede con un análisis complejo. - **Trampa:** Fingir que el modelo pequeño equivale a un gigante es el camino a la decepción. - **Relaciones:** En parte se recupera con la **specialization**, lo cubre el **hybrid**. ### Task Fit — lo rutinario en el dispositivo, lo difícil en la cloud > Un manitas local experto resuelve perfectamente la mayoría de los trabajos de la casa, y solo llamas al especialista para el raro caso realmente difícil. Un modelo pequeño on-device encaja bien con **tareas rutinarias y bien acotadas** — clasificar texto, extracción sencilla, transcripción, autocompletado, ayuda directa — el mismo tipo de trabajo que de todos modos no necesita un modelo de frontera. Le cuestan los problemas realmente difíciles, nuevos y de varios pasos, donde los modelos más grandes se ganan el sueldo. Esto se ajusta bien a la dificultad: la mayoría de las tareas cotidianas están muy al alcance de un modelo pequeño, y solo la minoría difícil necesita de verdad al gigante de la cloud. Así que la disciplina es el **ajuste a la tarea (task fit)**: emparejar la tarea con el modelo que el dispositivo puede ejecutar. Si el trabajo de una función es lo bastante rutinario, on-device gana en privacidad, uso sin conexión, latencia y coste. Si de verdad necesita razonamiento de nivel frontera, el dispositivo no puede dárselo y necesitas la cloud. Saber dónde cae esa línea es el criterio central de la edge AI. Si empujas trabajo demasiado difícil a un modelo pequeño, la calidad sufre; si dejas en local trabajo digno de la cloud, la función rinde por debajo de lo posible. _Diagram: A la izquierda, la mayoría: tareas rutinarias para un modelo pequeño. A la derecha, la minoría difícil para la cloud._ #### Task Fit (emparejar la tarea con el modelo) - **Problema:** Una tarea demasiado difícil en un modelo pequeño da mala calidad. - **Idea:** Lo rutinario y bien acotado va al dispositivo; lo difícil de nivel frontera va a la cloud. - **Ejemplo:** Clasificación, extracción, transcripción, autocompletado — en local; un análisis nuevo de varios pasos — en la cloud. - **Cuándo usarlo:** Cada vez que decides qué poner en el dispositivo. - **Relaciones:** La línea entre tareas es la base del **hybrid routing**. > **La pregunta de la capacidad:** «¿Es esta tarea lo bastante rutinaria para que un modelo pequeño la haga bien — o necesita de verdad razonamiento de nivel frontera que el dispositivo no puede dar?» > Un modelo pequeño es realmente menos capaz — menos conocimiento, más débil en razonamiento difícil. Es genial para trabajo rutinario y bien acotado y malo para problemas difíciles de nivel frontera, así que empareja la tarea con lo que el dispositivo puede ejecutar de verdad. ## 5. La especialización supera al tamaño Esta es la idea que hace a la edge AI mucho más potente de lo que sugiere «pequeño significa débil»: un modelo pequeño centrado en un solo trabajo puede rivalizar con un gigante generalista en ese trabajo. ### Specialization — un modelo pequeño enfocado frente a uno grande y general > Un cirujano local que ha hecho una sola operación miles de veces supera a un generalista brillante que la hace rara vez — el dominio estrecho gana al conocimiento amplio en la tarea concreta. Un modelo pequeño es débil como _generalista_, pero en una tarea específica y bien definida puede igualar o incluso superar a un modelo general mucho más grande. Eso es la **especialización (specialization)**. Un modelo gigante reparte su capacidad entre todo; un modelo pequeño entrenado para un solo trabajo concentra su capacidad limitada justo ahí. Así que para una tarea estrecha — tu clasificación concreta, tu extracción particular — un modelo pequeño especializado puede ser a la vez lo bastante bueno y lo bastante diminuto para ejecutarse en local. La especialización recupera buena parte de lo que se perdió al reducir. _Diagram: El gigante reparte su capacidad entre todo. El pequeño especialista da toda su capacidad a una tarea._ #### Specialization (un modelo estrecho) - **Problema:** Un modelo pequeño es débil como generalista. - **Idea:** Dirigir toda su capacidad a una tarea estrecha. - **Ejemplo:** Un modelo que solo clasifica tickets de soporte en tus temas. - **Coste:** Fuera de su tarea, el modelo sigue siendo débil. - **Relaciones:** Se logra con el **fine-tuning**; recupera el **capability trade-off**. ### Fine-tuning — afilar un modelo pequeño para su trabajo > Entrenar a un aprendiz de forma intensiva en la única tarea que hará cada día — se vuelve excelente en eso, incluso sin la amplia experiencia del maestro. La forma de hacer que un modelo pequeño rinda por encima de su peso es hacerle **fine-tuning** para tu tarea concreta (hay un curso aparte sobre ello): entrenarlo con ejemplos de justo el trabajo que hará, grabando a fondo esa única habilidad. Un modelo pequeño ajustado a tu uso estrecho puede superar a un modelo general mucho más grande en ese uso — y sigue siendo lo bastante pequeño para el dispositivo. No un generalista débil, sino un especialista afilado que además es diminuto. _Diagram: Un SLM base más ejemplos de tu tarea → fine-tuning → un especialista afilado que sigue cabiendo en el dispositivo._ #### Fine-tuning (entrenamiento adicional en tu tarea) - **Problema:** El modelo pequeño base no es lo bastante bueno en tu tarea. - **Idea:** Entrenarlo más con ejemplos de justo este trabajo. - **Ejemplo:** Un SLM con fine-tuning en tus correos etiquetados los ordena como un gigante. - **Coste:** Necesitas buenos ejemplos y el propio entrenamiento; el modelo sigue siendo estrecho. - **Relaciones:** El camino a la **specialization**; el resultado es **narrow + local**. ### Narrow + Local — una combinación poderosa > Una herramienta hecha para un solo trabajo, a mano — no es lo más versátil que tienes, pero sí lo más rápido y fiable para esa tarea. El patrón ganador de la IA on-device es **narrow + local**: un modelo pequeño que hace una sola cosa muy bien, ejecutándose justo en el dispositivo. Renuncias a la generalidad, que una función de un solo propósito de todos modos no necesitaba, y ganas privacidad, uso sin conexión, respuesta instantánea y coste cero. Para una función concreta, esta combinación puede vencer de lleno a un gigante de la cloud — más rápida, más barata, más privada e igual de buena en lo único para lo que sirve. La especialización es lo que convierte «pequeño y débil» en «pequeño y excelente donde cuenta». _Diagram: Donde una tarea estrecha se une con la ejecución local — esa es la zona ganadora._ #### Narrow + Local (un trabajo, en el dispositivo) - **Problema:** Como generalista, un modelo pequeño pierde frente a la cloud. - **Idea:** Una tarea, hecha de forma excelente, justo en el dispositivo. - **Ejemplo:** Un modelo local que solo transcribe notas de voz. - **Coste:** La generalidad — que una función de un solo propósito no necesitaba. - **Relaciones:** Une la **specialization** con los beneficios de **on-device**. > **La pregunta de la especialización:** «¿Es esta una tarea estrecha y específica donde un modelo pequeño con fine-tuning podría igualar a un gigante — haciendo que on-device no solo sea viable sino mejor?» > Un modelo pequeño con fine-tuning para una tarea específica puede rivalizar con un gigante generalista en esa tarea. Narrow más local — un especialista afilado ejecutándose en el dispositivo — convierte «pequeño y débil» en «pequeño y excelente». ## 6. El patrón hybrid No tienes que elegir cloud o dispositivo para todo. Los sistemas más fuertes usan ambos — resuelven en local lo que pueden y recurren a la cloud solo cuando deben. ### Hybrid Routing — local para el caso común, cloud para el difícil > Una clínica donde una enfermera atiende las visitas rutinarias en el sitio y deriva solo los casos complejos a un hospital especializado lejano — la mayoría de las necesidades cubiertas en local, los pocos casos difíciles escalados. El patrón más fuerte es el **hybrid**: ejecutar un modelo pequeño en el dispositivo para el trabajo común, rutinario o privado, y **escalar (escalate)** a un potente modelo de la cloud solo para los casos realmente difíciles. Como la mayoría de las peticiones son fáciles, la mayoría se resuelve en local — rápido, gratis y privado — y solo la minoría difícil hace el round-trip hasta el gigante de la cloud. Es la idea de **routing** de la economía de modelos, aplicada a través de la frontera dispositivo-cloud: por defecto la opción más barata y local, el peso pesado solo cuando se lo gana. _Diagram: Un router en el dispositivo envía la mayoría de las peticiones al modelo local y las difíciles a la cloud._ #### Hybrid Routing (primero local, escalar a la cloud) - **Problema:** Solo dispositivo — falta capacidad; solo cloud — sin privacidad ni uso sin conexión. - **Idea:** Lo común y simple va en local; lo raro y difícil escala a la cloud. - **Ejemplo:** Un asistente responde preguntas simples en el teléfono y envía un análisis complejo a un modelo en la cloud. - **Coste:** Un router y dos modelos; tienes que decidir qué cuenta como «difícil». - **Relaciones:** La idea de **routing** de la economía de modelos; se apoya en el **task fit**. ### Privacy Boundary — mantener en el dispositivo lo privado y lo que funciona sin conexión > Gestionas tus papeles sensibles en casa y envías fuera solo las partes que de verdad necesitan a un experto externo — manteniendo privado lo que puede seguir siéndolo. Un diseño hybrid te permite poner en el dispositivo las partes sensibles a la privacidad y las que deben funcionar sin conexión, y a la vez seguir usando la cloud para el razonamiento pesado que lo necesita. Los datos personales pueden procesarse en local y nunca salir; solo sale el trabajo no sensible y realmente difícil. Así que no tienes que sacrificar privacidad por capacidad ni capacidad por privacidad — diseñas el sistema para que cada pieza se ejecute donde encaja con sus necesidades. La frontera misma — la **privacy boundary** — se convierte en una herramienta de diseño. _Diagram: Los datos personales se procesan a la izquierda de la frontera. Solo la parte pesada no sensible la cruza._ #### Privacy Boundary (qué puede salir del dispositivo) - **Problema:** Necesitas a la vez privacidad y la potencia de la cloud. - **Idea:** Lo sensible se queda en el dispositivo; solo sale el trabajo pesado no sensible. - **Ejemplo:** Los datos personales se manejan en local, y solo una subtarea difícil anonimizada va a la cloud. - **Coste:** Tienes que decidir con cuidado qué cuenta como sensible. - **Relaciones:** Combina **privacy** y **hybrid routing**. ### Device–Cloud Split — la frontera como decisión de arquitectura > Decidir qué trabajo se queda en la sucursal local y cuál va a la oficina central — una división deliberada del trabajo, no una elección de todo o nada. El enfoque maduro es tratar «dónde se ejecuta esto» como una decisión **por función** — como las capas de una arquitectura en la cloud o los peldaños de la escalera de LLM. Esa es la **división dispositivo-cloud (device–cloud split)**. Algo del trabajo pertenece al dispositivo por privacidad, uso sin conexión, latencia o coste; algo pertenece a la cloud por capacidad; y un buen sistema coloca cada cosa donde encaja. No es una elección global única — es una arquitectura que diseñas, pieza a pieza. _Diagram: Cada función tiene su propio lugar y su propia razón: latencia, privacidad, uso sin conexión — dispositivo; capacidad — cloud._ #### Device–Cloud Split (ubicación por función) - **Problema:** Una sola elección — «todo cloud» o «todo dispositivo» — no sirve para todas las funciones de ningún producto. - **Idea:** Decidir dónde se ejecuta cada función según su necesidad principal. - **Ejemplo:** Autocompletado — en el dispositivo (latencia); una tarea difícil de varios pasos — en la cloud (capacidad). - **Cuándo usarlo:** Cualquier producto con funciones de IA tanto rutinarias como difíciles. - **Relaciones:** Generaliza el **hybrid routing** al nivel de la arquitectura. > **La pregunta hybrid:** «¿Podría resolver el trabajo rutinario y privado en el dispositivo y escalar a la cloud solo los casos realmente difíciles — obteniendo privacidad y capacidad en lugar de elegir una?» > El patrón más fuerte es el hybrid: un modelo local pequeño para el trabajo común, privado y sin conexión, que escala a un gigante de la cloud solo para los casos difíciles. La división dispositivo-cloud es una arquitectura que diseñas, pieza a pieza. ## 7. Usarla bien Usar bien la edge AI se reduce a reconocer cuándo lo local gana de verdad, y a ser honesto sobre la capacidad que cambias por ello. ### Decisive Benefit — ve on-device cuando lo local gana de verdad > Eliges mantener una tarea en casa cuando la privacidad, la velocidad, el uso sin conexión o el coste la hacen claramente mejor allí — y subcontratas solo cuando de verdad necesitas al experto externo. Ve on-device cuando uno de sus beneficios es **decisivo (decisive)**: los datos deben seguir siendo privados, la función debe funcionar sin conexión, la respuesta debe ser instantánea o el coste por llamada debe ser cero — y la tarea es lo bastante rutinaria (o lo bastante especializada) para que un modelo pequeño la maneje. No fuerces una tarea realmente difícil y general en un modelo local débil solo por evitar la cloud, y no envíes datos privados a la cloud cuando podrían haberse quedado en casa. Empareja la ubicación con lo que de verdad importa para la función. _Diagram: ¿Hay un beneficio decisivo? ¿Basta un modelo pequeño? Las respuestas llevan a la cloud, al dispositivo o a un hybrid._ #### Decisive Benefit (la razón para ir en local) - **Pregunta 1:** ¿Es decisiva aquí la privacidad, el uso sin conexión, la latencia o el coste cero? - **Pregunta 2:** ¿Es la tarea lo bastante rutinaria o especializada para un modelo pequeño? - **Ejemplo:** Transcripción de notas sin conexión: dos síes — el dispositivo. - **Trampa:** Ir en local «solo para evitar la cloud» — y perder calidad. - **Relaciones:** Reúne los **cuatro beneficios**, el **task fit** y el **hybrid**. ### Honest Scoping — sé honesto sobre el trueque > Aceptas que la herramienta de bolsillo no es el taller — y solo la eliges para trabajos que de verdad puede hacer, sin fingir que es algo que no es. La disciplina es el **alcance honesto (honest scoping)**: un modelo local te da privacidad, uso sin conexión, velocidad y coste a cambio de capacidad real. No finjas que un modelo pequeño es tan listo como un gigante; en cambio, acota la función on-device a lo que el modelo pequeño puede hacer bien de verdad — estréchala, especialízala o mantenla rutinaria — y deriva las partes difíciles a la cloud. Usada donde sus fortalezas coinciden con la necesidad, la edge AI transforma; llevada más allá de lo que un modelo pequeño puede hacer, solo decepciona. Elígela con los ojos abiertos. _Diagram: La idea de la función se divide: la parte estrecha, rutinaria y especializada va al dispositivo; la parte difícil va a la cloud._ #### Honest Scoping (acotar a lo que el modelo puede hacer) - **Problema:** La función se promete «como la cloud», y el modelo pequeño no puede cumplir. - **Idea:** Acotar la función a lo que el modelo pequeño hace bien de verdad. - **Cómo:** Estrecharla, especializarla, mantenerla rutinaria; enviar la parte difícil a la cloud. - **Trampa:** «Pequeño = gigante» es un camino seguro a la decepción. - **Relaciones:** Una consecuencia directa del **capability trade-off**. ### Cómo se conectan los conceptos > Una balanza: la capacidad de la cloud en un plato, los beneficios del dispositivo en el otro. Cada concepto del curso mueve un plato — o te ayuda a tener ambos. La **Cloud AI** paga el **round-trip**; la **on-device AI** lo evita, y por eso da los cuatro beneficios. Pero el dispositivo necesita **modelos pequeños** — SLM, quantization, distillation — y estos cuestan **capacidad**. La **specialization** (fine-tuning, narrow + local) recupera buena parte de ella, y la cloud cubre el resto mediante el **hybrid**. _Diagram: El dispositivo evita el round-trip y da los beneficios, pero necesita modelos pequeños y paga en capacidad. La especialización la recupera; el hybrid cubre el resto con la cloud._ #### Antes de construir on-device - **¿Hay un beneficio decisivo** — privacidad, uso sin conexión, latencia o coste cero — que la cloud no pueda igualar? - **¿Es la tarea lo bastante rutinaria o especializada** para que un modelo pequeño la haga bien? - **¿Puede caber un modelo** — pequeño por diseño, cuantizado o destilado — en el dispositivo objetivo? - **¿Haría el fine-tuning** que un pequeño especialista iguale a un gigante en esta tarea estrecha? - **¿Debería ser hybrid** — local para el caso común, cloud para el difícil? - **¿Soy honesto** sobre la capacidad que cambio por los beneficios locales? #### Señales de que usas bien la edge AI - Vas en local cuando un **beneficio es decisivo** — privacidad, uso sin conexión, latencia o coste. - Usas un **modelo lo bastante pequeño** — por diseño, cuantizado o destilado — que cabe en el dispositivo. - **Especializas o haces fine-tuning** a un modelo pequeño para rivalizar con un gigante en una tarea estrecha. - Diseñas una división **hybrid**, manteniendo en local el trabajo privado y sin conexión, y escalando los casos difíciles. - Eres **honesto sobre el sacrificio de capacidad** y acotas la función a lo que el modelo pequeño puede hacer. ## Hoja de referencia: los 20 conceptos ### Bases - **Cloud AI** (modelo en un centro de datos): El modelo se ejecuta en servidores remotos; el dispositivo lo alcanza por la red. - **On-device AI** (edge AI): El modelo se ejecuta localmente — en el teléfono, el portátil o el sensor. - **Round-trip** (el viaje por la red): Ida y vuelta al servidor. De él crece cada sacrificio. ### Por qué en local - **Privacy** (los datos se quedan): Los datos nunca salen del dispositivo. - **Offline** (sin necesidad de red): Funciona en un avión, en un túnel, en una zona remota. - **Latency** (retraso de respuesta): Sin round-trip — la respuesta es casi instantánea. - **Per-call cost** (cero en el dispositivo): En el hardware del usuario, una llamada no cuesta nada. ### Hacerlo pequeño - **SLM** (small language model): Un modelo compacto con muchos menos parámetros. - **Quantization** (menor precisión): Pesos con menor precisión — varias veces más pequeño y rápido. - **Distillation** (teacher → student): Un student pequeño aprende a imitar a un teacher grande. ### El sacrificio - **Capability Trade-off** (tamaño frente a capacidad): Un modelo más pequeño significa menos conocimiento y razonamiento más débil. - **Task Fit** (emparejar la tarea): Lo rutinario va al dispositivo; lo difícil de nivel frontera va a la cloud. ### Especialización - **Specialization** (un modelo estrecho): Un modelo pequeño y estrecho rivaliza con un gigante en su única tarea. - **Fine-tuning** (entrenamiento en tu tarea): Entrenarlo con ejemplos de justo este trabajo. - **Narrow + Local** (un trabajo, en el dispositivo): Una sola cosa hecha de forma excelente, justo en el dispositivo. ### Hybrid - **Hybrid Routing** (primero local): Lo común va en local; lo difícil escala a la cloud. - **Privacy Boundary** (qué puede salir): Lo sensible se queda en el dispositivo; solo sale el trabajo no sensible. - **Device–Cloud Split** (ubicación por función): Dónde se ejecuta cada función se decide función por función. ### Usarla bien - **Decisive Benefit** (la razón para ir en local): On-device cuando un beneficio lo decide y un modelo pequeño puede hacer el trabajo. - **Honest Scoping** (acotar al modelo): Dar forma a la función según lo que el modelo pequeño puede hacer de verdad. > La edge AI ejecuta un modelo pequeño justo en el dispositivo, cambiando capacidad bruta por privacidad, uso sin conexión, respuesta instantánea y coste cero. Especialízalo para rivalizar con un gigante en una tarea estrecha, ve hybrid para quedarte con ambos y sé honesto sobre el trueque. Fin del curso exprés · 7 capítulos · 20 conceptos Lo siguiente es la práctica: toma una tarea rutinaria — una clasificación, un poco de extracción — y ejecútala con un modelo pequeño en tu propia máquina, sin ninguna llamada a la cloud. Fíjate en que es instantáneo, gratis y privado. Luego fuérzalo con un problema realmente difícil y siente dónde están los límites del modelo pequeño. Por último, esboza un hybrid: qué se queda en local, qué escala a la cloud. El trueque se vuelve concreto en el momento en que un modelo local diminuto resuelve tu caso rutinario a la perfección sin tocar nunca la red. Pero guarda una idea por encima de las demás: un modelo pequeño que se ejecuta en el dispositivo compra privacidad, uso sin conexión, velocidad y coste cero al precio de la capacidad bruta — así que especialízalo donde puedas, ve hybrid donde debas y sé honesto sobre lo que estás cambiando.