ShadowPEFT en PEFT: el mapa de decisiones de exportacion de adaptadores

La misma API get_peft_model, un contrato de despliegue diferente

El entrenamiento todavia empieza con get_peft_model. Esa familiaridad ayuda, pero tambien puede ocultar la pregunta de despliegue que mas importa: que vas a enviar exactamente?

Con ShadowPEFT, la respuesta no es un modelo base fusionado. La inferencia acoplada mantiene el modelo base en el circuito. La inferencia separada de modelos de lenguaje usa un calculo diferente. Ambas pueden ser opciones legitimas, pero necesitan empaquetados diferentes, pruebas diferentes y evidencia de aceptacion diferente.

Que cambia la integracion del 15 de septiembre

El anuncio de integracion del 15 de septiembre de 2026 de los autores informa que ShadowPEFT se ha fusionado en la rama principal de PEFT. El articulo de abril ofrece contexto util, pero no es un articulo nuevo de septiembre. En el momento del anuncio, probar la integracion implica instalar PEFT desde el codigo fuente; la documentacion principal separa esa ruta del paquete estable. La fecha del anuncio no es evidencia independiente de la fecha exacta de fusion.

Fija las revisiones de PEFT y Transformers que probaste. Fija tambien las revisiones del modelo base y del modelo shadow. Una instalacion sin fijar desde la rama principal no es un plan de lanzamiento reproducible.

El anuncio explica el metodo y reporta experimentos. La referencia de API documenta las operaciones. Este articulo conecta esas piezas con una decision de despliegue: que artefacto existe, que dependencias deben estar presentes y que evidencia prueba que el artefacto esta listo para enviarse. Es una guia de planificacion, no una reproduccion de Optijara de los resultados de los autores.

Por que una trayectoria shadow no puede fusionarse con los pesos base

La documentacion de ShadowPEFT describe un backbone pequeno que produce un estado shadow inicial. A traves de bloques decodificadores contiguos, la discrepancia h-s pasa por una correccion de bajo rango hacia la entrada base. Despues, actualizaciones con compuerta avanzan el estado shadow usando las salidas de los bloques. Solo una trayectoria de adaptador puede estar activa a la vez.

Ese comportamiento depende de la entrada. No es un delta fijo que pueda incorporarse a los pesos base. Como resultado, merge, merge_adapter y merge_and_unload generan errores. Los metodos familiares de guardado y carga de PEFT no eliminan esa restriccion.

Mantén separados tres inventarios: el adaptador guardado, la configuracion de inferencia acoplada base-mas-shadow y el checkpoint completo separado del modelo de lenguaje. No son tres nombres de archivo para lo mismo. Son productos diferentes.

El mapa de decisiones de exportacion de adaptadores: elige el artefacto antes de entrenar

Cuatro rutas de despliegue y su evidencia de aceptacion

El mapa de decisiones de exportacion de adaptadores de Optijara es una ayuda de planificacion original para este articulo, no un estandar de proveedor. Empieza con la ruta que necesitas en produccion, y despues elige pasos de entrenamiento, exportacion y validacion que realmente puedan producirla.

La ruta separada merece una inspeccion atenta. Un archivo de adaptador pequeno no es lo mismo que un checkpoint con una tabla de embeddings, proyeccion, backbone, head de salida, tokenizador y configuracion. Registra que componentes comparte, entrena y guarda la configuracion elegida. Ese inventario tambien es util al revisar detalles de artefactos en vez de nombres de archivo, aunque este articulo no afirma compatibilidad de conversion a GGUF para ShadowPEFT.

Para Diffusers, la documentacion separa el backend de arquitectura Flux2 registrado de una ruta alternativa token-wise residual MLP para arquitecturas compatibles. Ninguna ruta admite la descarga independiente. Esa limitacion se aplica ampliamente a los modelos Diffusers, no solo a arquitecturas sin un backend registrado.

Entrenamiento, inferencia acoplada y exportacion separada son ramas diferentes

Las ramas siguientes muestran decisiones de ShadowPEFT y las comprobaciones asociadas. La rama Diffusers esta explicitamente sin soporte. No describen un router edge-cloud implementado.

Este resumen compacto es JSON descriptivo. No es una configuracion de PEFT y no realiza comprobaciones de compatibilidad.

{
  "framework": "Adapter Export Decision Map",
  "shadow_merge_supported": false,
  "attached_requires_base": true,
  "detached_lm_requires_separate_evaluation": true,
  "independent_export_copy": true,
  "diffusers_standalone_supported": false
}

Exporta un modelo de lenguaje separado sin perder el contrato del artefacto

Entrena la ruta independiente deliberadamente

El calculo separado de Transformers documentado es head(projection(backbone(x))). No es el estado shadow final entre capas sL, porque sL depende de interacciones con el decodificador base. Por lo tanto, unos buenos resultados acoplados no prueban la calidad de tarea separada.

Trata la calidad del predictor como una pregunta de aceptacion separada. Una exportacion puede ser tecnicamente valida y aun asi ser el predictor equivocado para la tarea. Un guardado exitoso no resuelve esa pregunta.

La perdida auxiliar de tarea supervisa el estado shadow inicial s0, la ruta disponible sin esas interacciones base. La configuracion documenta auxiliary_loss_weight=0.05 como valor predeterminado, con la perdida anadida cuando se proporcionan etiquetas. Comprueba que el trabajo de entrenamiento proporcione etiquetas y gestione el head de tarea segun lo previsto. Definir un valor en la configuracion no es lo mismo que verificar la ruta de perdida.

Para modelado de lenguaje causal, se reutiliza el head de salida base. Incluye modules_to_save=['lm_head'] cuando ese head deba entrenarse y guardarse a traves de PEFT. No conviertas el entrenamiento del head en un reflejo. Registra el tamano del vocabulario del head y su relacion con el tokenizador y la tabla de embeddings.

Usa unload_shadow(copy=True) para la exportacion independiente

El siguiente fragmento sigue la interfaz de exportacion documentada. Es ilustrativo y no se ha ejecutado aqui. peft_model significa un modelo PEFT de Transformers compatible y ya entrenado, no un pipeline arbitrario de Diffusers.

# Solo ilustrativo: no ejecutado para este articulo.
detached_model = peft_model.base_model.unload_shadow(copy=True)
detached_model.save_pretrained("standalone-shadow")

De forma predeterminada, copy=False comparte modulos con el modelo PEFT. Si shadow usa embeddings de entrada base congelados mediante una referencia fuera de su arbol de submodulos registrado, guardar ese objeto separado puede omitir la tabla de embeddings. La documentacion recomienda copy=True al guardar o publicar un modelo independiente porque adjunta una copia privada de embeddings. El compromiso es memoria adicional durante la exportacion.

Ese indicador resuelve una dependencia de serializacion. No prueba que el tokenizador se haya guardado, que el cargador sea compatible ni que la calidad separada cumpla el requisito de la tarea. Usa la interfaz de carga para la implementacion fijada. No infieras la clase de recarga a partir de un nombre conveniente.

Lista de comprobacion de recarga en frio, explicitamente no ejecutada aqui

Usa esta lista de comprobacion prospectiva antes de llamar desplegable a una exportacion. Optijara no ha entrenado, exportado, recargado ni evaluado el modelo para este articulo. La documentacion y la inspeccion del codigo fuente no sustituyen la evidencia de una prueba local de serializacion.

Conserva el artefacto acoplado mientras pruebas la exportacion. Una carga limpia no debe reemplazar automaticamente al candidato de despliegue acoplado. Solo despeja la comprobacion de serializacion. Rechaza los artefactos incompletos antes de interpretar diferencias de calidad, especialmente cuando los ajustes del tokenizador o pesos faltantes puedan explicar el comportamiento.

Mide la inferencia acoplada y separada como productos distintos

Cuatro lineas base en la misma carga de trabajo reservada

Planifica una comparacion de base-only, LoRA, Shadow acoplado y Shadow separado. Usa las mismas tareas reservadas, prompts, reglas de puntuacion y ajustes de generacion cuando tenga sentido. Registra diferencias de tokenizador, tamanos de modelo y presupuestos de entrenamiento. Una arquitectura separada mas pequena no es identica a la base, y la evaluacion no deberia fingir lo contrario.

Define umbrales de aceptacion antes de mirar los resultados. Una tarea hipotetica de etiquetado de documentos podria priorizar la correccion de etiquetas y una salida estructurada estable. Un asistente interactivo tambien necesita comprobaciones de latencia. Estas son opciones de evaluacion propuestas, no resultados reportados de ShadowPEFT.

El tamano del adaptador no es memoria de servicio

La generacion acoplada usa caches KV emparejadas de base y shadow. La referencia de API describe ShadowCache como intencionadamente no compilable; la conversion a tuplas heredadas no es compatible. No prometas compatibilidad con torch.compile ni con motores de inferencia solo porque generate() parezca familiar. La implementacion del modelo define por separado la ruta de exportacion independiente y su restriccion para Diffusers.

Mide el crecimiento de cache bajo la carga de trabajo que pretendes servir. Separa bytes de adaptador, bytes de exportacion, picos de carga y memoria de servicio en estado estable. Sigue la misma disciplina usada para probar el artefacto exacto en el runtime y dispositivo objetivo. Una descarga mas pequena no establece un runtime acoplado mas pequeno.

Lee el benchmark de los autores sin un atajo de costos

El benchmark de integracion de los autores reporta los siguientes resultados de entrenamiento en MetaMathQA y evaluacion en GSM8K para Llama 3.2 3B en una NVIDIA A100 80GB. Su tabla etiqueta la columna de almacenamiento como "Checkpoint"; estos son artefactos experimentales reportados, no exportaciones independientes verificadas.

En ese experimento, ShadowPEFT tiene una puntuacion mayor y un checkpoint mas pequeno, con memoria pico mayor y entrenamiento mas largo. Inspecciona la configuracion de Shadow y la configuracion de LoRA enlazadas. El anuncio llama predeterminados a los ajustes, pero el archivo de Shadow especifica auxiliary_loss_weight=0.01 y shadow_alpha=0.5, en lugar de los valores predeterminados de API de 0.05 y 0.1. Usa los archivos enlazados para entender el experimento; no asumas una busqueda de hiperparametros equivalente. Un resultado reportado sin incertidumbre no establece superioridad amplia. Tampoco dice nada por si solo sobre memoria de servicio separada, latencia o exactitud de inferencia separada.

Que evitar en el despliegue de ShadowPEFT

Tratar todo adaptador PEFT como fusionable

Los siguientes son errores de implementacion anticipados, no incidentes del trabajo de Optijara con clientes. Un script de despliegue que llama merge_and_unload para cada tipo de adaptador necesita una rama especifica por metodo. Reemplazar esa llamada por la descarga de shadow tambien cambia el predictor que se envia, asi que el informe de aceptacion anterior no puede simplemente trasladarse.

Los modos de fallo potenciales incluyen tratar el tamano del checkpoint como memoria pico, asignar puntuaciones del benchmark acoplado a un modelo separado y validar la serializacion en un proceso donde la base original permanece disponible. Los modulos compartidos pueden hacer que un experimento en memoria parezca completo aunque deje sin probar una exportacion independiente.

Confundir entrenamiento auxiliar de imagen con un denoiser desmontable

Una ruta auxiliar de entrenamiento de eliminacion de ruido no crea un producto Diffusers independiente compatible. El soporte del backend Flux2 se refiere a como se construye el calculo shadow. No elimina el NotImplementedError en la descarga independiente.

Los autores tambien reportan una comparacion de generacion de imagenes usando un conjunto DreamBooth pequeno de un solo gato. Ese experimento especifico del modelo no prueba generalizacion a todos los sujetos, calidad de imagen universal ni calidad de denoiser independiente. Mantén esas afirmaciones fuera de una propuesta de despliegue.

Para equipos que se mueven entre herramientas de imagen, los controles familiares no prueban paridad de ejecucion. Aqui se aplica la misma logica. Los nombres de API compartidos son ergonomia util, no evidencia de que dos metodos exporten modelos equivalentes.

Salvedades antes de adoptar la integracion de la rama principal

Compatibilidad, costo de implementacion y limites de evaluacion

El comportamiento de la rama principal depende de la revision. Registra la arquitectura, el cargador, las versiones de dependencias y las restricciones de runtime cubiertas por tus pruebas. La descripcion de soporte de la documentacion es donde empieza el trabajo. No es una certificacion para cada motor de servicio.

Presupuesta verificacion de exportacion, evaluacion, almacenamiento y mantenimiento ademas del entrenamiento. Hardware, precios de proveedores, longitud de contexto, concurrencia y eleccion del modelo afectan el resultado medido. Un adaptador mas pequeno no puede sostener por si solo una afirmacion de ahorro. Mantén visible la incertidumbre en las comparaciones y vuelve a ejecutar las comprobaciones relevantes despues de cambios de dependencias.

Las comprobaciones de privacidad y licencia siguen siendo especificas del artefacto

Revisa los terminos del modelo base, checkpoint shadow, conjunto de datos, tokenizador y head de tarea antes de distribuir. El checkpoint shadow proyectado de Qwen es una configuracion concreta para inspeccionar, no un permiso general para cada despliegue derivado. La separacion no concede derechos de redistribucion ni elimina preocupaciones de privacidad de datos de entrenamiento.

Elige una ruta compatible, conserva su inventario de dependencias y evalua el artefacto que realmente llegara al entorno objetivo. Deja la exportacion independiente de Diffusers sin soporte fuera del plan de lanzamiento hasta que la implementacion la admita explicitamente.