Entrenar en un servidor con GPU, un clúster SLURM o una máquina tras NAT

Novedad de la v2.14.0

Este tutorial saca el entrenamiento de modelos de Potato del servidor de anotación y lo lleva a una máquina con GPU. El tutorial está pensado para quien administra un estudio cuyo servidor de anotación es una pequeña máquina virtual en la nube o un portátil, y cuyas GPU están en un servidor del laboratorio, en un clúster universitario o en una estación de trabajo a la que el servidor no puede conectarse. Para cada uno de los tres backends remotos, la página explica cuándo elegirlo, qué debe estar instalado en la máquina remota, la configuración, el comando de comprobación, qué ocurre durante una ejecución, cómo cancelarla y los fallos que es más probable que veas. El tutorial parte de un proyecto que ya entrena en el servidor de anotación, como el proyecto de reseñas de Entrena tu primer modelo.

Cuatro lugares donde puede ejecutarse una ejecución

Un backend es el lugar donde se ejecuta una ejecución de entrenamiento. Potato siempre dispone del backend local, un subproceso en el servidor de anotación. Los demás backends se nombran en model_training.backends:

Elige ssh cuando el servidor de anotación pueda iniciar sesión en la máquina con GPU con una clave ssh. Elige slurm cuando las GPU estén detrás del planificador SLURM y la máquina en la que puedes iniciar sesión sea un nodo de acceso. Elige agent cuando no pueda abrirse ninguna conexión desde el servidor hacia la máquina con GPU, porque el agente abre todas las conexiones por sí mismo. Una estación de trabajo tras un router doméstico o un cortafuegos de campus es el caso habitual de un agente. Las predicciones y el resultado de la ejecución llegan al servidor desde todos los backends, así que la escritura de vuelta y la puntuación sobre ítems reservados funcionan igual dondequiera que se ejecutara el entrenador. Todos los entrenadores salvo decision-calibrate se ejecutan en cualquier backend.

La configuración del proyecto

La configuración siguiente es el proyecto de reseñas del primer tutorial con los tres backends remotos añadidos. Un proyecto real solo necesita los backends que use, y cada backend tiene su propia sección más abajo. max_wall_seconds: 3600 detiene cualquier ejecución que no haya terminado en una hora. En un backend ssh o agent, el servidor comprueba el límite cada segundo, así que una ejecución que se cuelga en una máquina remota no retiene la cola de ejecuciones más tiempo que el límite:

annotation_task_name: "Review Sentiment"
task_dir: "."
data_files:
  - "data/reviews.json"
item_properties:
  id_key: "id"
  text_key: "text"
output_annotation_dir: "annotation_output"
admin_api_key: "change-me"
 
annotation_schemes:
  - annotation_type: "radio"
    name: "sentiment"
    description: "Is this review positive or negative?"
    labels: ["positive", "negative"]
 
model_training:
  enabled: true
  backend: gpu-server        # the default for runs; leave out to keep runs local
  max_wall_seconds: 3600
  writeback:
    schemas: ["sentiment"]
    include_unlabeled: true
    min_confidence: 0.6
  backends:
    gpu-server:
      type: ssh
      host: gpu.example.org
      python: /opt/conda/bin/python3
      gpus: auto
      min_free_gpu_mb: 4000
    cluster:
      type: slurm
      host: login.cluster.example.org
      python: /opt/conda/bin/python3
      job_python: /shared/envs/train/bin/python
      remote_dir: /shared/projects/me/potato-training
      gres: gpu:1
      time: "04:00:00"
      prelude: ["module load cuda/12.4"]
    lab-workstation:
      type: agent
      queue_timeout_s: 3600

Valida la configuración antes de iniciar el servidor:

potato validate config.yaml --strict

El validador informa de una clave que el tipo de backend no admite, de un backend ssh o slurm sin host, de un remote_dir de SLURM bajo /tmp y de un model_training.backend que no nombra ningún backend. El servidor tampoco arranca con esos mismos errores, así que un pyhton mal escrito detiene el servidor al arrancar en lugar de enviar las ejecuciones al python3 predeterminado.

El menú Runs on y la API

La página Training en /admin/training tiene un menú Runs on que lista todos los backends con su tipo y su host, p. ej., gpu-server (ssh to gpu.example.org). model_training.backend fija la entrada que el menú selecciona primero, y la tabla de ejecuciones registra dónde se ejecutó cada una en su columna Ran on. Una ejecución iniciada por la API nombra su backend en el campo backend del cuerpo de la petición:

curl -X POST -H "X-API-Key: $KEY" -H "Content-Type: application/json" \
  http://localhost:8000/admin/training/api/runs \
  -d '{"trainer": "hf-text-classification", "schemas": ["sentiment"], "backend": "cluster"}'

Un nombre de backend que no está en la configuración se rechaza con 409. El reentrenamiento automático usa model_training.backend salvo que auto_retrain.backend nombre otro backend, y El modelo en el ciclo cubre auto_retrain por completo. Solo se ejecuta una ejecución a la vez, sea cual sea el backend, y una ejecución iniciada mientras otra está en curso espera en la cola.

Entrenar en esta máquina

Comprueba qué dispositivo recibe una ejecución local antes de llevar las ejecuciones a otro sitio. Con el valor predeterminado device: auto, una ejecución local toma primero CUDA, después Metal de Apple (mps) y por último la CPU, y device: cuda:1 nombra una GPU concreta. El comando de comprobación imprime el dispositivo que usaría una ejecución local:

potato training check local config.yaml

En un Mac con Apple silicon, el comando imprime local: this machine, Apple Metal (mps). Un dispositivo que pides y no está presente recurre a la CPU o a otro acelerador, con una advertencia en el registro de la ejecución. Cuando la respuesta es CPU y el entrenador ajusta un transformer, pasa la ejecución a uno de los backends remotos siguientes. Configuración lista device, num_threads y max_ram_mb para las ejecuciones locales.

Un servidor con GPU por ssh

Un backend ssh ejecuta el entrenador en una máquina a la que el servidor de anotación llega por ssh, normalmente un servidor con GPU del laboratorio. Potato inicia por sí mismo todo lo que hace falta en el lado remoto, así que allí no se instala ni se inicia nada a mano aparte de Python y los paquetes del entrenador. El host con GPU no necesita tener Potato instalado, porque Potato copia su propio código fuente de Python al host en la primera ejecución y reutiliza la copia hasta que el código fuente cambia.

Requisitos de un backend ssh

La cuenta con la que se ejecuta el servidor de anotación necesita una clave ssh que inicie sesión en el host con GPU sin pedir nada. Potato ejecuta ssh con BatchMode=yes, así que una petición de contraseña hace que la ejecución falle de inmediato en lugar de quedarse colgada. Ejecutar ssh gpu.example.org true con esa cuenta debe tener éxito, y una clave con frase de paso funciona cuando ssh-agent guarda la clave. El valor de host es cualquier nombre que ssh acepte, y sirve un alias de ~/.ssh/config. Las claves user, port y identity_file se pasan a ssh como -l, -p y -i.

El host con GPU necesita Python 3.8 o posterior y los paquetes del entrenador que ejecutes. Para hf-text-classification, esos paquetes son torch, transformers y peft, el contenido del extra potato-annotation[train-text]. La página de Entrenadores nombra la instalación de cada entrenador. Cuando al intérprete del host le falta un paquete, apunta python a un intérprete que lo tenga, o lista el paquete en packages. Con packages definido, Potato crea un entorno virtual bajo remote_dir con --system-site-packages e instala en él una sola vez los paquetes listados. La compilación de torch con CUDA del propio host sigue visible dentro del entorno:

model_training:
  enabled: true
  backends:
    gpu-server:
      type: ssh
      host: gpu.example.org
      python: /opt/conda/bin/python3
      packages: ["transformers>=4.46.0", "peft>=0.13.0"]
      gpus: auto
      min_free_gpu_mb: 4000
      num_threads: 8

Con gpus: auto, cada ejecución toma la GPU con más memoria libre y se niega a empezar cuando ninguna GPU tiene libres min_free_gpu_mb (2000 de forma predeterminada). Potato compara la memoria libre y no la utilización, porque una tarjeta con baja utilización en un servidor compartido puede tener aun así poca memoria libre. Fija min_free_gpu_mb cerca de la memoria que necesita tu entrenador. gpus: "1" fija la GPU 1, "0,1" fija dos GPU y gpus: none entrena en la CPU. Un host sin ninguna GPU también entrena en su CPU con auto. num_threads fija OMP_NUM_THREADS, MKL_NUM_THREADS y OPENBLAS_NUM_THREADS para la ejecución. Algunos servidores compartidos fijan OMP_NUM_THREADS=1 en los shells de inicio de sesión, y num_threads sustituye el valor del shell de inicio de sesión.

El comando de comprobación de un backend ssh

Ejecuta la comprobación desde el servidor de anotación, con la cuenta con la que se ejecuta el servidor:

potato training check gpu-server config.yaml

El comando se conecta e informa de la versión de Python remota, de cada GPU con su memoria libre y su utilización, de la GPU que recibiría una ejecución y de los paquetes de entrenamiento que le faltan al intérprete remoto. Una GPU para la que el torch instalado no tiene kernels se marca con (torch there has no kernels for it), y gpus: auto omite esa GPU. --json imprime el mismo informe en JSON. El comando termina con 0 cuando una ejecución podría empezar y con 1 en caso contrario. El botón Check junto al menú Runs on ejecuta la misma comprobación desde la página Training.

Pasos de una ejecución ssh

Para cada ejecución, Potato realiza estos pasos:

1. Se conecta con ssh y abre un reenvío inverso desde un socket unix en el /tmp remoto hasta el servidor de anotación.
2. Comprueba el intérprete, lee nvidia-smi y elige la GPU.
3. Copia el código fuente de Potato a remote_dir/code/<hash> cuando el host no tiene esa versión, y crea el entorno virtual cuando packages está definido y falta el entorno. remote_dir es ~/.cache/potato-training de forma predeterminada.
4. Inicia python -m potato.training.agent para la ejecución. El token de la ejecución llega al agente por stdin y nunca aparece en una línea de comandos, porque las líneas de comandos son visibles para todas las cuentas de un servidor compartido.
5. El agente descarga el paquete de ítems, etiquetas y medios de la ejecución. El agente ejecuta el mismo proceso de entrenamiento que ejecuta el backend local y devuelve por el socket el progreso, las predicciones y el resultado.
6. Cuando la ejecución termina bien, Potato copia el directorio de artefactos de vuelta a artifacts/ de la ejecución, borra el directorio remoto del trabajo y cierra la conexión.

La línea de pasos de la página Training sigue esas etapas, p. ej., copying Potato's code to gpu.example.org y waiting for the agent on gpu.example.org. El registro de la ejecución nombra el Python del host y la GPU que recibió la ejecución.

Un ajuste fino completo copia de vuelta el modelo entero, y por un enlace lento un modelo de 330 MB tarda minutos. La línea de pasos muestra cuánto del modelo ha llegado. Los archivos mayores que max_artifact_mb (2048 de forma predeterminada) se quedan en el host con GPU y se nombran en el registro de la ejecución. fetch_artifacts: false deja todos los archivos del modelo en el host con GPU, y keep_remote: true conserva el directorio remoto del trabajo para inspeccionarlo. La publicación en Hugging Face Hub desde la página de la ejecución necesita los archivos del modelo en el servidor de anotación, así que un modelo que se queda en el host con GPU no se publica desde la página de la ejecución.

El socket unix se crea con el modo 0600, así que solo la cuenta con la que Potato inició sesión puede conectarse a través del socket. Las peticiones a través del socket llegan al servidor de anotación como peticiones de loopback. Un servidor iniciado con debug: true concede acceso de administrador a las peticiones de loopback. Cualquiera que pueda usar esa cuenta en el host con GPU tiene entonces acceso de administrador a un servidor en modo debug mientras hay una ejecución en curso. Mantén debug desactivado en un servidor que entrena por ssh.

Cancelación y tiempo de espera del latido

Cancel run en la página Training llega al agente por el socket, en la respuesta al siguiente informe de progreso del agente. El agente envía SIGTERM al proceso de entrenamiento, y SIGKILL si el proceso sigue en marcha tras model_training.grace_seconds (20 de forma predeterminada), valor que el servidor envía con el trabajo. Un trabajo de un servidor Potato más antiguo no lleva grace_seconds, y entonces el agente espera 20 segundos. En el servidor, la ejecución termina como cancelada cuando han pasado grace_seconds, y el servidor cierra la sesión ssh del agente. Una ejecución cuyo agente no envía nada durante heartbeat_timeout_s (120 de forma predeterminada) falla, y agent.log en el directorio de la ejecución contiene la última salida del agente.

Un clúster SLURM

Un backend slurm sirve para un clúster cuyas GPU están detrás del planificador SLURM. En un clúster así, la máquina a la que Potato llega por ssh es un nodo de acceso sin GPU, y los nodos de cómputo no pueden llegar a Potato en absoluto. Por eso Potato inicia el agente en el nodo de acceso, como hace un backend ssh, y el agente envía solo el proceso de entrenamiento a un nodo de cómputo con sbatch. El progreso vuelve a través de un archivo en un almacenamiento que el nodo de acceso y los nodos de cómputo comparten.

Requisitos de un backend SLURM

El nodo de acceso necesita una clave ssh sin petición y Python 3.8 o posterior para el agente, igual que el host de un backend ssh. El nodo de acceso también necesita sbatch, squeue y scancel en el PATH. El agente también llama a scontrol cuando el clúster dispone del comando. Potato nunca llama a srun ni a sacct, así que funciona un clúster con srun desactivado y sin base de datos de contabilidad. remote_dir es obligatorio y debe estar en un almacenamiento que los nodos de cómputo compartan, porque el trabajo lee allí el paquete y escribe allí el modelo. El validador informa de un error para un remote_dir bajo /tmp o /var/tmp, porque esos directorios son locales a cada nodo.

Los nodos de cómputo necesitan un intérprete con los paquetes del entrenador, nombrado por job_python. packages no se admite en un backend SLURM, porque un entorno virtual creado en el nodo de acceso puede no funcionar en los nodos de cómputo. Apunta job_python a un entorno que tengan los nodos de cómputo, y pon la carga de módulos o la activación de un entorno en prelude:

model_training:
  enabled: true
  backends:
    cluster:
      type: slurm
      host: login.cluster.example.org
      python: /opt/conda/bin/python3                    # on the login node, for the agent
      job_python: /shared/envs/train/bin/python         # on the compute nodes, for the worker
      remote_dir: /shared/projects/me/potato-training   # storage the compute nodes share
      partition: gpu
      gres: gpu:1
      time: "04:00:00"
      prelude: ["module load cuda/12.4"]

Todas las claves de ssh se aplican a un backend SLURM salvo gpus y packages. Las GPU salen de gres, y el planificador fija CUDA_VISIBLE_DEVICES para las GPU que concede. Un trabajo sin gres no recibe GPU. Los ajustes de SLURM se corresponden con las opciones de sbatch:

Un time superior a 6 horas hace que potato validate y el arranque del servidor informen de model_training.backends.cluster.time is 12:00:00. A job that holds a GPU for more than 6 hours is long on a shared cluster; check its policy, y potato validate --strict falla con esa advertencia. Cuando la política del clúster permita el trabajo más largo, reconoce la advertencia para ese backend en un bloque validation de nivel superior, que solo lee potato validate:

validation:
  acknowledge:
    - "model_training.backends.cluster.time is"

Cada entrada se compara con el texto de la advertencia como subcadena con distinción de mayúsculas de al menos 12 caracteres, y una advertencia que coincide pasa a la lista de reconocidas y deja de hacer fallar --strict. Una entrada que nombra el backend reconoce la advertencia solo para ese backend. Una entrada demasiado corta o que no coincide con ninguna advertencia se convierte en una advertencia propia.

El comando de comprobación de un backend SLURM

potato training check cluster config.yaml

La comprobación inicia sesión en el nodo de acceso y confirma que sbatch, squeue y scancel están en el PATH y que remote_dir no está bajo /tmp. El informe nombra la versión de Python del nodo de acceso y el job_python que ejecutará el trabajo. La comprobación no puede ver qué paquetes tienen los nodos de cómputo, así que un paquete ausente en un nodo de cómputo aparece como una ejecución fallida con el error de importación en el registro de la ejecución. Ejecuta un primer trabajo corto con un time pequeño para encontrar esos problemas pronto.

Pasos de una ejecución SLURM

Potato se conecta al nodo de acceso y copia allí su código, como en un backend ssh. Después el agente realiza estos pasos:

1. Descarga el paquete en remote_dir/jobs/<run>/.
2. Escribe job.sh y envía el script con sbatch --parsable. El registro de la ejecución anota Submitted SLURM job con el id del trabajo y las opciones.
3. En el directorio del trabajo, el proceso de entrenamiento del nodo de cómputo escribe sus eventos en events.jsonl, sus errores en stderr.log y su código de salida en exit_code. La propia salida de SLURM va a slurm.out.
4. El agente lee events.jsonl a medida que el archivo crece y retransmite el progreso al servidor. El agente ejecuta squeue una vez por cada poll_interval_s, y el registro de la ejecución anota cada cambio en el estado del trabajo en la cola, p. ej., SLURM job 4242: PENDING (Priority) y después RUNNING on node07.
5. Cuando el trabajo termina, el agente sube las predicciones e informa del resultado. Los artefactos vuelven al servidor y el directorio del trabajo se elimina, como en un backend ssh.

Cancel run envía scancel --full --signal=TERM al trabajo, y después un scancel simple si el proceso de entrenamiento no se ha detenido. Cuando se cae la sesión ssh con el nodo de acceso, el agente cancela su trabajo y se libera la asignación de GPU. Cuando el planificador termina un trabajo por su cuenta, la ejecución falla con el motivo del planificador, leído de scontrol show job o de slurm.out. Entre los motivos que Potato informa están el límite de tiempo, el fallo de un nodo, la expropiación, quedarse sin memoria y un scancel ajeno a Potato.

El conjunto de pruebas de Potato ejecuta la secuencia de SLURM contra un sustituto de sbatch, squeue y scancel, y cubre el envío de trabajos, el estado de la cola, la retransmisión del progreso y la cancelación. Los límites de las particiones y la política de expropiación difieren de un clúster a otro, así que observa el registro de la ejecución de tu primer trabajo en un clúster nuevo.

Un agente iniciado a mano en un nodo de acceso que llegue al servidor también puede enviar trabajos a SLURM, con potato training agent --server ... --backend <name> --workdir <shared dir> --slurm-config slurm.json. El archivo slurm.json contiene como objeto JSON los ajustes de la tabla anterior, y --workdir debe estar en un almacenamiento que los nodos de cómputo compartan.

Una máquina a la que Potato no llega

Un backend agent sirve para una máquina a la que el servidor de anotación no puede conectarse, como una estación de trabajo tras NAT. Alguien inicia potato training agent en esa máquina, y el agente consulta al servidor en busca de trabajos. El agente no necesita ningún puerto de entrada, porque el agente abre todas las conexiones. Una cancelación llega al agente en la respuesta del servidor al siguiente informe de progreso del agente. Los archivos del modelo se quedan en la máquina de entrenamiento, y solo vuelven las predicciones y el resultado.

Requisitos de un backend agent

La máquina de entrenamiento necesita Potato instalado, los paquetes del entrenador que ejecutes y una ruta de red hasta la URL del servidor de anotación. Para hf-text-classification, una sola instalación cubre Potato y los paquetes del entrenador:

pip install "potato-annotation[train-text]"

El servidor solo necesita la entrada del backend. Un backend agent admite type, description, heartbeat_timeout_s (120 de forma predeterminada) y queue_timeout_s, y ninguna otra clave:

model_training:
  enabled: true
  backends:
    lab-workstation:
      type: agent
      queue_timeout_s: 3600

Registrar e iniciar el agente

Emite un token para el backend en el servidor de anotación:

potato training register lab-workstation config.yaml

El comando imprime el token una sola vez, con los comandos que hay que ejecutar en la máquina de entrenamiento:

Token for backend 'lab-workstation' (shown once; registering again replaces it):
 
  <token>
 
On the training machine:
 
  export POTATO_TRAINING_TOKEN=<token>
  potato training agent --server http://<this-server>:8000 --backend lab-workstation

Inicia el agente en la máquina de entrenamiento con la URL real del servidor:

export POTATO_TRAINING_TOKEN=<the token>
potato training agent --server https://annotate.example.org --backend lab-workstation

El agente ejecuta los trabajos de su backend hasta que lo detengas. --token-file lee el token de un archivo en lugar de POTATO_TRAINING_TOKEN, y --python nombra el intérprete en el que se ejecuta el proceso de entrenamiento, que de forma predeterminada es el del propio agente. --once termina tras un trabajo, --workdir mueve los archivos del agente desde ~/.cache/potato-training, y --keep conserva el paquete de cada trabajo. Registrar de nuevo el mismo nombre emite un token nuevo e invalida el anterior.

potato training check lab-workstation config.yaml imprime el registro del token del backend, con last_seen rellenado cuando un agente se ha conectado. Antes del registro, el comando imprime no token issued yet y el comando de registro que hay que ejecutar.

Pasos de una ejecución agent

Una ejecución para un backend agent espera en el estado queued hasta que un agente pide trabajo. Con queue_timeout_s: 3600, la ejecución falla tras una hora sin agente, y sin queue_timeout_s la ejecución espera hasta que la canceles. El agente descarga el paquete como un archivo tar.gz y reanuda una descarga interrumpida desde donde se detuvo, hasta cinco intentos. Después el agente ejecuta el proceso de entrenamiento, envía el progreso, sube predictions.jsonl e informa del código de salida. El servidor responde 413 a un archivo de predicciones mayor que max_predictions_mb (512 de forma predeterminada).

Los archivos del modelo se quedan en la máquina de entrenamiento bajo --workdir, y el artifact_uri del registro de la ejecución nombra el host y el directorio. Si el agente no puede llegar al servidor durante 300 segundos en una ejecución, el agente cancela la ejecución por sí mismo. Una ejecución cuyo agente no envía nada durante heartbeat_timeout_s falla en el servidor con No word from the agent on lab-workstation for 120 seconds.

Fallos habituales

Cada entrada da el mensaje del registro de la ejecución o del informe de comprobación, y después la solución. La lista completa para todos los backends y entrenadores está en la sección de solución de problemas del repositorio original.

• ssh to gpu.example.org failed: Permission denied. Potato necesita una clave que funcione sin petición. ssh gpu.example.org true desde la cuenta del servidor debe tener éxito.
• /opt/conda/bin/python3 was not found on gpu.example.org. Define python en el backend con un intérprete que exista en el host.
• No GPU has 4000 MB free. Todas las GPU del host están más ocupadas de lo que permite min_free_gpu_mb. potato training check gpu-server config.yaml lista las GPU. Espera, baja el umbral o fija una GPU con gpus: "1".
• Trainer 'hf-text-classification' could not be imported. Al intérprete remoto le falta un paquete que necesita el entrenador. Apunta python a un intérprete que tenga el paquete, o lista el paquete en packages. En un backend SLURM, arregla el entorno que nombra job_python.
• This host's torch has no kernels for any of its GPUs. El torch remoto se compiló para GPU más nuevas que las del host. Instala una compilación de torch para esas GPU, o usa otro host.
• No word from the agent on gpu-server for 120 seconds. La máquina remota o la red dejaron de responder. En un backend ssh, agent.log en el directorio de la ejecución contiene la última salida del agente.
• The copy from gpu.example.org sent nothing for 180 s. La red hacia el host se detuvo mientras se copiaba el modelo de vuelta. Las predicciones de la ejecución ya están almacenadas, y solo faltan en artifacts/ los archivos del modelo.
• login.cluster.example.org has no sbatch on PATH, so it cannot submit jobs. El host no es el nodo de acceso del clúster, o los comandos están en un PATH que solo fija un shell de inicio de sesión. Define PATH en el env del backend.
• SLURM job 4242 ended before the worker finished: it reached its time limit. Sube time en el backend, o entrena con menos ítems. Define keep_remote: true para conservar slurm.out y poder leerlo tras otros fallos del planificador.
• Una ejecución en un backend agent se queda en cola. Ningún agente con ese nombre de backend está consultando al servidor. Inicia un agente con potato training agent --backend lab-workstation y comprueba el token con Check en la página Training.
• nvrtc: error: failed to open libnvrtc-builtins.so.13.0. El torch del host y su paquete nvidia-cuda-nvrtc son de versiones de CUDA distintas. Instala el nvidia-cuda-nvrtc que corresponda a la compilación de torch, o apunta python a otro intérprete.

Más información

• La visión general del entrenamiento de modelos cubre la página Training, el ciclo de entrenamiento y la publicación de un modelo en Hugging Face Hub.
• Configuración lista todas las claves de model_training, las puntuaciones sobre ítems reservados y dónde se almacenan las ejecuciones.
• Ajuste fino de LLM cubre los entrenadores que con más frecuencia necesitan una GPU remota, con LoRA y pesos base de 4 bits.
• La referencia original sobre dónde se ejecutan las ejecuciones tiene la tabla completa de claves de cada backend, y la sección del protocolo del agente documenta las rutas para quien escriba su propio agente.