Para las aplicaciones LLM, se ven comúnmente dos opciones de implementación: o vamos completamente a la nube, es decir, enviamos todo a una API LLM en la nube, o vamos completamente local, es decir, ejecutamos todo con un modelo abierto servido localmente.
Los LLM en la nube razonan mejor, pero enviamos nuestro contexto sensible al exterior. Los modelos locales mantienen ese contexto privado, pero limitados por la computación local, pueden tener dificultades cuando las tareas se vuelven complejas.
Naturalmente, nos gustaría preguntar:
¿Podemos disfrutar de la capacidad de razonamiento de la nube y al mismo tiempo mantener el contexto privado local?
Un patrón híbrido de nube local podría lograrlo. Esto es lo que exploraremos en esta publicación.
Específicamente, discutiremos:
Cómo razonar sobre diseños híbridos. Examinaremos un mapa de tres ejes e ilustraremos los cinco patrones más comunes. Un estudio de caso concreto para recorrer uno de los patrones. Utilizamos tanto un modelo de lenguaje pequeño local (Gemma 4 E4B de Google) como un modelo de lenguaje grande basado en la nube (GPT-5.4 de OpenAI).
Al final, debería tener un modelo mental reutilizable y un cuaderno de trabajo para dividir una aplicación LLM entre un modelo local y uno en la nube.
1. ¿Cuándo tiene sentido un patrón LLM híbrido de nube local?
Cuando la gente habla de aplicaciones LLM híbridas de nube local, inmediatamente piensa en privacidad. Sin duda, esa es una consideración importante.
Pero la privacidad no es la única razón para optar por la tecnología híbrida.
Según mi experiencia, encuentro útil razonar sobre este patrón híbrido desde la lente de un sistema de coordenadas de tres ejes:
Dirección, que responde “¿quién actúa primero?”. Puede ser primero local o primero en la nube. Trigger, que responde “¿cuándo se usa la nube?”. En algunos escenarios de aplicación, siempre se llama a la nube. En otras ocasiones, la nube sólo se invoca de forma condicional. Propósito, que responde "¿por qué dividir el flujo de trabajo?". Como mencionamos anteriormente, la privacidad es una motivación importante. Pero otros factores pueden ser el costo y la latencia, así como la confianza y la fiabilidad.
Con estos tres ejes, podemos colocar muchos flujos de trabajo híbridos del mundo real en el mismo mapa de coordenadas. Aunque esto está lejos de ser una taxonomía perfecta, creo que hace que las opciones de diseño sean intuitivamente comprensibles. Echemos un vistazo ahora.
Patrón 1: desinfectar y resolver
Este patrón es primero local (eje 1), siempre activa el LLM en la nube (eje 2) y tiene en mente la preservación de la privacidad (eje 3).
El modelo local consume el contexto privado desordenado y desestructurado, pero lo convierte en un problema abstracto, que luego se envía al LLM en la nube. El modelo de nube sólo ve el problema abstracto y lo resuelve. Los resultados se envían de vuelta al modelo local, que puede procesar aún más los resultados y enviarlos al usuario.
Este es el patrón que implementaremos en el estudio de caso.
Patrón 2: Planificar y luego fundamentar
Este patrón se sitúa en la dirección opuesta. Es la nube primero (eje 1), el modelo de nube siempre se activa (eje 2) y aún preserva la privacidad (eje 3).
Aquí, el modelo de nube es responsable de producir un plan genérico basado en un objetivo abstracto. Este paso no implica ver los datos privados. Luego, el plan se envía al modelo local, quien desempeña el papel de ejecutor real que ejecuta el plan con datos confidenciales reales.
Patrón 3: Escalar en Difícil
Para muchas aplicaciones, no es necesario llamar al modelo de nube para cada solicitud de usuario.
Es posible que el modelo local ya sea capaz de manejar la mayoría fácil, como extracciones simples, clasificaciones, resúmenes o producción de respuestas breves. Solo se llama al modelo de nube cuando el modelo local no puede atender de manera suficiente o confiable la solicitud del usuario porque es demasiado complejo.
Este patrón es primero local (eje 1), la activación del modelo de nube es condicional (eje 2) y, a menudo, está motivada por el costo y la latencia, en lugar de por la privacidad (eje 3).
Patrón 4: Borrar y luego refinar
Otro patrón comúnmente visto es separar la velocidad de respuesta de la calidad de la respuesta.
En este patrón, el modelo local produce un borrador inmediato. Opcionalmente, el modelo en la nube puede funcionar en segundo plano para proporcionar una respuesta más cuidadosa. Si la respuesta de la nube es mejor, la aplicación puede sustituir o simplemente enriquecer la respuesta inicial que ofrece el modelo local.
Este patrón es primero local (eje 1), puede desencadenar o no el modelo de nube (eje 2) y, a menudo, también está motivado por el costo y la latencia.
Patrón 5: verificación cruzada
Otro patrón importante que vale la pena mencionar es el control cruzado.
Aquí, los modelos local y de nube se tratan más o menos por igual. Ambos pueden actuar como revisores independientes, donde un modelo propone una respuesta y el otro modelo la verifica, o ambos modelos responden a la misma pregunta, y su acuerdo/desacuerdo se convierte en la señal para el procesamiento posterior.
Este patrón fluye en ambas direcciones (eje 1), el modelo de nube siempre está activo (eje 2) y está impulsado principalmente por la confianza y la confiabilidad (eje 3).
2. Estudio de caso: ¿Debería utilizar el lavavajillas ahora o más tarde?
En esta sección, pasamos de conceptos abstractos a un estudio de caso concreto. Específicamente, veremos un problema de programación de hogares inteligentes.
2.1 Configuración del caso
Aquí, consideramos un sistema de asistente doméstico inteligente que mantiene una memoria doméstica privada.
Supongamos que el usuario le pregunta al asistente:
¿Debería funcionar el lavavajillas ahora o más tarde?
Efectivamente, el asistente necesita resolver un problema de programación.
Para solucionar ese problema, el asistente sabe que son las 18:30 y tiene acceso a la siguiente memoria del hogar, datos del dispositivo y tarifa:
Memoria del hogar: – El lavavajillas debe lavarse antes del desayuno porque los niños necesitan platos limpios, normalmente alrededor de las 06:30. – No dejar que el lavavajillas siga funcionando una vez que todos estén en la cama, normalmente alrededor de las 22:30; Está justo al lado de los dormitorios y Maya tiene el sueño ligero. – El vehículo eléctrico es el coche de Mark y hay que cargarlo antes de que salga a las 07:00. – El robot aspirador suele funcionar después del almuerzo; hoy terminó un pase de cocina sobre las 16:10. Datos del dispositivo: – Lavavajillas: tiempo de funcionamiento de aproximadamente 90 minutos, energía de aproximadamente 1,2 kWh, disponible ahora. – Cargador para vehículos eléctricos: tiempo de funcionamiento de aproximadamente 120 minutos, necesidad de energía de aproximadamente 14 kWh, disponible ahora. – Robot aspirador: último ciclo de limpieza finalizado a las 16:10; La batería está al 78% en el muelle. Tarifa: – 17:00-20:00: $0,45/kWh – 20:00-00:00: $0,22/kWh – 00:00-06:00: $0,12/kWh – 06:00-17:00: $0,25/kWh
Como podemos ver, el contexto anterior contiene bastante información privada, como nombres, rutinas domésticas, etc., que no queremos enviar directamente a un modelo en la nube.
Naturalmente, esto requiere un patrón de solución híbrida. Más concretamente, podemos diseñar un flujo de trabajo como este:
Paso 1: LLM local. Lea el contexto privado, resuma el problema de programación para que no contenga información confidencial. Paso 2: LLM en la nube. Razone el problema de programación anónima y produzca un cronograma. Paso 3: LLM local. Analice el resultado de la nube hasta el idioma familiar y presente la respuesta final al usuario.
Ese es el flujo de trabajo que crearemos a continuación.
2.2 Configuración del modelo Ollama y Gemma 4
Para este estudio de caso, utilizamos el modelo Gemma 4 E4B como nuestro LLM local.
Gemma 4 es una familia de modelos lanzada por Google este mes de abril. Está diseñado para razonamiento, codificación, comprensión multimodal y flujos de trabajo agentes. Viene en varios tamaños. Lo que nos importa son las variantes amigables con los bordes, es decir, el modelo E4B.
Lo serviremos localmente con Ollama. En caso de que no lo haya usado antes, es un tiempo de ejecución para descargar, ejecutar y servir modelos en el idioma local desde su propia máquina. Una vez configurado, Ollama expone un punto final API local.
En máquinas con Windows, puedes hacerlo desde el instalador oficial:
https://ollama.com/download
Después de la instalación, puede iniciar Ollama desde el menú Inicio de Windows.
En una máquina Linux, puedes instalar Ollama con:
"curl -fsSL https://ollama.com/install.sh | sh"
Una vez que Ollama esté en funcionamiento, podemos proceder a descargar nuestro modelo de idioma local. Podemos hacerlo a través de la línea de comando:
ollama jala gemma4:e4b
Como referencia, mi computadora portátil tiene una CPU Intel i7-13800H, 32 GB de RAM y una GPU para computadora portátil NVIDIA RTX 2000 Ada con aproximadamente 8 GB de VRAM. Puedes elegir gemma4:e2b en su lugar si E4B se siente demasiado lento.
Antes de pasar al siguiente paso, podemos hacer una prueba rápida:
ollama run gemma4:e4b "¿cuál es la capital de Francia?"
Si recuperas “Paris”, felicidades, Gemma 4 ahora está disponible en tu máquina local a través de Ollama.
2.3 Paso 1: Sanitización local
Este paso se ejecuta completamente localmente.
Aquí, el modelo local ve el contexto doméstico completo y su objetivo es preparar un problema de programación desinfectado para el modelo de nube eliminando cualquier información confidencial.
Comenzamos redactando las instrucciones del sistema:
# Nota: Este mensaje se repitió con AI LOCAL_SANITIZER_INSTRUCTIONS = """ Usted es un asistente local de hogar inteligente que se ejecuta dentro del hogar. El sistema tiene acceso a la memoria privada del hogar, datos del dispositivo e información de tarifas. Un usuario ha hecho una pregunta de programación sobre una carga del hogar. Su función es preparar el problema de programación para un modelo de razonamiento en la nube sin exponer detalles privados del hogar. El modelo en la nube razonará sobre el tiempo, el uso de energía, los plazos y la electricidad. precios No necesita conocer los nombres de los dispositivos, los nombres de las personas, los detalles de las habitaciones, las rutinas familiares o por qué existe una restricción. Cree un problema de programación anónimo para el modelo de nube. Piense en scheduling_problem como un mensaje copiado directamente en una llamada API de la nube. scheduling_problem sale del hogar. Mantenga la asignación privada de los ID de carga anónimos a los nombres de los dispositivos domésticos en local_mapping. El campo local_mapping permanece dentro del hogar y es el único lugar donde pueden aparecer los nombres de los dispositivos privados. No responda la pregunta del usuario ni resuelva la programación usted mismo. Su trabajo es traducir el contexto privado del hogar en un problema de programación anónimo utilizable en la nube. modelo de nube. – En scheduling_problem, use solo ID de carga anónimos, nunca nombres de electrodomésticos, nombres de personas, detalles de la habitación o explicaciones del hogar. No empareje los ID de carga con nombres privados; escriba "load_A:" en lugar de etiquetas como "load_A (aspiradora de robot):". mapeo de nombre de carga solo en local_mapping """.strip().
Aquí le pedimos al modelo local que haga tres cosas:
Identificar qué electrodomésticos son realmente relevantes para la pregunta del usuario; Eliminar información confidencial como nombres, detalles de la habitación, etc.; Conserve suficientes datos de programación para que el modelo de nube aún pueda razonar correctamente.
A continuación, definimos una función de creación de avisos para preparar el contexto, que combina la pregunta del usuario, el contexto del hogar privado y un contrato de salida liviano:
def build_local_sanitizer_prompt( private_context: dict[str, Any], user_question: str, ) -> str: return f""" Pregunta del usuario: {user_question} Contexto doméstico privado: {format_private_context(private_context)} Tarea: Preparar un problema de programación anónimo para que el modelo de razonamiento en la nube pueda analizar y planificar la programación. Utilice ID de carga anónimos en el problema de programación y mantenga el mapeo solo local en local_mapping. Devuelve tu respuesta como JSON con exactamente estos campos: {{ "target_load_id": "ID anónimo de la carga a la que hace referencia la pregunta del usuario", "scheduling_problem": "el problema de programación anónimo exacto que se enviará a la nube", "local_mapping": {{ "load_A": "robot Vacuum", "load_B": "" }} }} El ejemplo de local_mapping solo ilustra el dirección de mapeo. Elija los ID de carga anónimos reales según las cargas relevantes que incluya. Las claves deben ser ID de carga anónima y los valores deben ser los nombres de dispositivos domésticos originales. Devuelva solo JSON, sin un límite de rebajas "".
Finalmente, podemos llamar al modelo a través de Ollama:
# pip instalar ollama importar ollama importar json solicitud = build_local_sanitizer_prompt( private_context=private_context, user_question=USER_QUESTION, ) respuesta = ollama.chat( model="gemma4:e4b", mensajes=[ {"role": "system", "content": LOCAL_SANITIZER_INSTRUCTIONS}, {"role": "user", "content": Prompt}, ], think="alta", opciones={"temperatura": 0, "num_ctx": 32768}, ) contenido = respuesta["mensaje"]["contenido"] local_sanitizer_output = json.loads(contenido)
Un par de cosas que vale la pena mencionar:
Necesitamos instalar el cliente Ollama Python. Construimos el mensaje a partir de la pregunta del usuario y el contexto privado del hogar. Utilizamos el modo de pensamiento del modelo proporcionando el valor de pensamiento. Dado que el modelo local necesita razonar sobre un contexto local desordenado, aquí tiene sentido darle al modelo local un presupuesto más pensado.
Puede notar que le pido a Gemma que devuelva JSON directamente en el mensaje. Un enfoque más formal sería utilizar resultados estructurados. Ollama apoya eso a través del argumento de formato:
respuesta = ollama.chat( modelo=LOCAL_MODEL, mensajes=mensajes, formato=PydanticSchema.model_json_schema(),)
En teoría, esto es muy útil ya que el resultado resulta muy fácil de analizar. Sin embargo, en mis experimentos, noté que imponer la forma de salida del LLM local puede limitar su capacidad. En nuestro estudio de caso actual, el modelo a veces omitió detalles importantes de programación, como fechas límite o horas límite. Por otro lado, si solo guío suavemente la forma de salida proporcionando ejemplos en el mensaje, veo que el modelo funciona mucho mejor.
Este parece ser un problema conocido llamado impuesto de restricción.[1]: para modelos más pequeños, las restricciones estrictas de salida estructurada pueden mejorar la validez del esquema y perjudicar la corrección de la tarea.
Por lo tanto, para este estudio de caso, utilicé una guía de nivel rápido para garantizar que el LLM local pueda al menos realizar la tarea correctamente. En un sistema de producción, probablemente agregaría lógica de validación y reintento en torno a este paso.
2.4 Paso 2: Razonamiento en la nube
En este paso, enviamos el problema de programación anónimo preparado al LLM en la nube para que podamos aprovechar su sólida capacidad de razonamiento sin revelar ninguna información confidencial.
Comenzamos configurando las instrucciones del sistema para la función LLM en la nube:
# Nota: Este mensaje se repitió con AI CLOUD_REASONER_INSTRUCTIONS = """ Usted es un razonador de programación. Recibe un problema de programación anónimo con ID de carga, hora actual, duraciones de carga, uso de energía, disponibilidad, fechas límite, restricciones de último final y ventanas de tarifas eléctricas. Su tarea es decidir si la carga objetivo debe comenzar ahora o más tarde, luego proponer un cronograma factible para las cargas relevantes. Utilice solo la información en el problema de programación. Mantenga los ID de carga anónimos exactamente como se proporcionan. No invente nombres de dispositivos, detalles del hogar ni restricciones faltantes, tenga en cuenta los plazos, las restricciones de última finalización, el tiempo de ejecución, el uso de energía y los precios de las tarifas.
A diferencia del paso anterior, utilizamos directamente la salida estructurada. Aquí está el esquema de salida:
desde escribir import Literal de pydantic import BaseModel, clase de campo ScheduledLoad(BaseModel): load_id: str = Field( …, descripción="ID de carga anónimo del problema de programación, como load_A.", ) start: str = Field( …, descripción="Hora de inicio programada en formato HH:MM de 24 horas.", ) end: str = Field( …, descripción="Hora de finalización programada en 24 horas HH:MM format.", ) motivo: str = Field( …, descripción="Breve motivo para elegir esta ventana de tiempo.", ) clase CloudScheduleReasoning(BaseModel): recomendación: Literal["run_now", "run_later"] = Field( …, descripción="Si la carga objetivo debe comenzar ahora o diferirse.", ) propuesto_schedule: list[ScheduledLoad] = Field( …, descripción="Programación factible utilizando solo ID de carga anónimos del rápido.", ) razonamiento: str = Campo( …, descripción="Razonamiento conciso basado únicamente en los hechos de programación anónimos.", )
El LLM en la nube tendrá la tarea de completar esta plantilla. Luego, creamos el mensaje para el modelo de nube:
def build_cloud_reasoning_prompt(local_sanitizer_output: dict[str, Any]) -> str: return f""" Problema de programación anónimo: {local_sanitizer_output['scheduling_problem']} Carga objetivo: {local_sanitizer_output['target_load_id']} Tarea: Decida si la carga objetivo debe comenzar ahora o más tarde, luego proponga un cronograma viable para la cargas anónimas relevantes """.strip().
Tenga en cuenta que solo enviamos el problema de programación anónima al LLM en la nube. Sin memoria doméstica ni mapeo de carga.
Finalmente, llamamos Azure OpenAI:
from openai import AzureOpenAI # Configurar cliente LLM en la nube cloud_client = AzureOpenAI( api_key=os.environ["OPENAI_API_KEY"], azure_endpoint=os.environ["OPENAI_API_BASE"], api_version=os.environ["OPENAI_API_VERSION"], ) # Preparar el mensaje cloud_prompt = build_cloud_reasoning_prompt(local_sanitizer_output) respuesta = cloud_client.responses.parse( model="gpt-5.4", instrucciones=CLOUD_REASONER_INSTRUCTIONS, input=cloud_prompt, razonamiento={"effort": "medium"}, text_format=CloudScheduleReasoning,) cloud_reasoning = respuesta.output_parsed.model_dump()
En este punto, el modelo de nube ha resuelto la programación, pero el resultado aún se expresa en ID de carga anónimos. Por eso necesitamos un paso final para hacer la traducción.
2.5 Paso 3: Conexión a tierra local
Este último paso se ejecuta localmente nuevamente.
Como de costumbre, comenzamos configurando las instrucciones del sistema para el paso 3 LLM. Su objetivo es trasladar el resultado de la nube al lenguaje familiar y producir la recomendación final:
# Nota: Este mensaje se repitió con AI LOCAL_FINALIZER_INSTRUCTIONS = """ Usted es un asistente local de hogar inteligente que se ejecuta dentro de la casa. Un usuario preguntó si ejecutar una carga doméstica ahora o más tarde. El modelo de nube ya razonó sobre un problema de programación anónima y devolvió una programación propuesta utilizando ID de carga. Puede ver el contexto original del hogar y la asignación local desde las ID de carga anónimas hasta los nombres de los dispositivos domésticos. Su función es escribir la respuesta que el usuario leerá. La respuesta debe Responda la pregunta original de ahora o más tarde en el lenguaje doméstico normal, utilizando la programación en la nube como plan de programación. Utilice local_mapping para traducir los ID de carga a nombres de dispositivos domésticos. Utilice el contexto privado del hogar solo para que la respuesta sea comprensible y relevante a nivel local. No rehaga la optimización de la programación desde cero. No dé a entender que ningún dispositivo ya se haya iniciado o programado automáticamente. nombres, no ID de carga anónimos – Preservar la recomendación de tiempo importante del cronograma de la nube – Mencionar otras cargas programadas solo cuando ayuden a explicar la recomendación. – Si el resultado de la nube entra en conflicto con el contexto doméstico privado, prefiera el contexto local y dígalo brevemente. – Mantenga la respuesta concisa y centrada en la decisión del usuario.
Luego construimos el mensaje correspondiente. Aquí, el modelo local recibe un par de cosas:
Pregunta del usuario original; Contexto doméstico privado; Salida de desinfectante local; Resultado del razonamiento en la nube.
Aquí está la función del constructor:
def build_local_finalizer_prompt( private_context: dict[str, Any], user_question: str, local_sanitizer_output: dict[str, Any], cloud_reasoning: dict[str, Any], ) -> str: return f""" Pregunta del usuario: {user_question} Contexto privado del hogar: {format_private_context(private_context)} Salida del desinfectante local: {json.dumps(local_sanitizer_output, indent=2)} Razonamiento de la nube: {json.dumps(cloud_reasoning, indent=2)} Tarea: escriba la recomendación final para el usuario primero. Utilice la programación propuesta en la nube anteriormente y no mencione las cargas secundarias solo si ayudan a explicar la recomendación.
Finalmente, volvemos a llamar a Gemma:
indicador = build_local_finalizer_prompt( contexto_privado=contexto_privado, pregunta_usuario=PREGUNTA_USUARIO, local_sanitizer_output=salida_sanitizer_local, cloud_reasoning=cloud_reasoning, ) respuesta = ollama.chat( modelo=LOCAL_MODEL, mensajes=[ {"role": "sistema", "contenido": LOCAL_FINALIZER_INSTRUCTIONS}, {"rol": "usuario", "contenido": aviso}, ], think="medio", opciones={"temperatura": 0, "num_ctx": 32768}, ) final_answer = respuesta["mensaje"]["contenido"]
Esa es la implementación completa de nuestro flujo de trabajo de tres pasos.
2.6 Ejecutar el flujo de trabajo
Ahora ejecutemos el flujo de trabajo e inspeccionemos los resultados.
En el primer paso, hemos utilizado el modelo local de Gemma para convertir el contexto doméstico privado en un problema de programación anónimo. Aquí está el resultado que obtuvimos:
{ "target_load_id": "load_A", "scheduling_problem": "Hora actual: 18:30nCargas:n load_A:n Uso de energía: 1,2 kWhn Duración estimada: 90 minutosn Inicio más temprano: 18:30n Fecha límite estricta (debe finalizar antes de): 06:30n Restricción de parada suave (no se puede ejecutar después de): 22:30n load_B:n Uso de energía: 14 kWhn Duración estimada: 120 minutosn Inicio más temprano: 18:30n Fecha límite estricta (debe finalizar antes de): 07:00nHorario de tarifas:n 17:00-20:00: $0,45/kWhn 20:00-00:00: $0,22/kWhn 00:00-06:00: $0,12/kWhn 06:00-17:00: $0,25/kWh", "local_mapping": { "load_A": "lavavajillas", "load_B": "cargador de vehículos eléctricos" } }
Vemos que el modelo local filtró correctamente el contexto. El robot aspirador se mencionó en la memoria original del hogar, pero el modelo local identificó correctamente que es irrelevante para la pregunta de programación actual, por lo que no está incluido.
Más importante aún, vemos que scheduling_problem solo contiene ID de carga anónimos, y el LLM en la nube solo recibe datos abstractos de programación como duración, uso de energía, plazos, etc.
En el paso 2, el LLM en la nube devuelve el cronograma anónimo:
{ "recomendación": "run_later", "proposed_schedule": [ { "load_id": "load_A", "start": "20:00", "end": "21:30" }, { "load_id": "load_B", "start": "00:00", "end": "02:00" } ] }
Finalmente, Gemma traduce el resultado a un lenguaje fácil de usar:
Deberías utilizar el lavavajillas más tarde. Para ahorrar dinero, espere hasta las 8:00 p. m. de esta noche. Comenzar entonces le permitirá terminar a las 9:30 p. m., trasladando su uso de energía de la ventana horaria más cara a una más barata. El plan general también programa el cargador de su vehículo eléctrico para la medianoche (de 12:00 a. m. a 2:00 a. m.) para aprovechar las tarifas de electricidad más bajas.
Este es el patrón en acción: dejamos que el modelo local maneje el contexto privado y la conexión final, y el modelo de nube maneje el razonamiento pesado, pero solo sobre un problema anónimo.
3. Pensamientos finales
El ejemplo de hogar inteligente anterior muestra solo una posibilidad en el espacio de diseño más amplio de aplicaciones LLM híbridas de nube local.
Creo que la lección más general aquí es que no necesitamos tratar los modelos local y de nube como dos opciones de implementación mutuamente excluyentes. En muchas aplicaciones, pueden desempeñar diferentes funciones.
Por eso me parece útil plantear las siguientes tres preguntas:
¿Quién debería actuar primero, el modelo local o el modelo en la nube? ¿Cuándo debería llamarse al modelo de nube? ¿Qué nos aporta realmente la división?
La última pregunta es especialmente importante. La privacidad suele ser lo primero en lo que piensa la gente, pero podría haber otros factores, como el costo/latencia, la confiabilidad y la controlabilidad. No los pases por alto.
Para mí, esa es la verdadera promesa de las aplicaciones LLM híbridas de nube local: no un compromiso entre lo local y la nube, sino una forma más flexible de diseñar la aplicación en sí.
Referencia
[1]Ray (2026), El impuesto de restricción: medición de las compensaciones entre validez y corrección en resultados estructurados para modelos de lenguaje pequeño. https://arxiv.org/abs/2605.26128