Resumen Técnico: HLS-Seek

Enunciado del Problema

La Síntesis de Alto Nivel (HLS) compila descripciones algorítmicas en C/C++ hacia hardware a Nivel de Transferencia de Registro (RTL). La Calidad de Resultados (QoR)—específicamente la latencia de ejecución y la utilización de recursos (LUTs, DSPs, BRAMs, FFs)—es crítica para el despliegue de aceleradores en el mundo real. Sin embargo, la QoR está determinada por estructuras microarquitectónicas, configuraciones de pragmas y optimizaciones de código que no pueden inferirse con precisión únicamente mediante análisis de código de software; requiere una evaluación costosa de síntesis e implementación.

Los enfoques existentes de Modelos de Lenguaje Grande (LLM) para la generación de código HLS se centran principalmente en la corrección funcional (generar código compilable y ejecutable) pero son agnósticos a la QoR. Tratan todos los diseños compilables por igual, independientemente de su rendimiento en hardware. Aunque el Aprendizaje por Refuerzo (RL) con retroalimentación de síntesis real (síntesis en el bucle) ha mostrado promesa en el dominio RTL, aplicarlo a HLS es prohibitivamente costoso. Una sola ejecución de síntesis HLS puede tardar de minutos a horas, y el entrenamiento de RL típicamente requiere miles de evaluaciones, lo que hace que el enfoque sea inviable a escala.

Metodología

Los autores proponen HLS-Seek, un marco de trabajo de Lenguaje Natural a HLS consciente de la QoR que reemplaza el costoso RL de síntesis real con un modelo de recompensa proxy comparativo potenciado por un mecanismo de conmutación consciente de la incertidumbre.

1. Idea Central

Los autores observan que el RL para HLS no requiere valores absolutos de QoR (números exactos de latencia/recursos) provenientes de la síntesis. En su lugar, solo requiere comparaciones relativas entre diseños candidatos para estimar ventajas relativas al grupo. Esta idea permite entrenar un modelo proxy ligero para predecir cuál de dos diseños es mejor, evitando la necesidad de síntesis durante la mayoría de los pasos de entrenamiento.

2. Pipeline de Entrenamiento de Tres Etapas

HLS-Seek emplea un proceso de entrenamiento de tres etapas:

• Etapa 1: Ajuste Fino Supervisado (SFT) Orientado a la Diversidad: El LLM base se ajusta fino sobre un corpus amplio de HLS con descripciones de QoR para exponer al modelo a diversas configuraciones de pragmas y patrones de codificación, estableciendo una base en la sintaxis HLS.
• Etapa 2: SFT de Arranque en Frío con Rastros de Razonamiento: Utilizando un conjunto de datos curado de diseños próximos a Pareto (compromisos óptimos) aumentado con rastros de razonamiento de Cadena de Pensamiento (CoT) generados por modelos de razonamiento comerciales, el modelo aprende razonamiento estructurado de hardware y cómo seleccionar configuraciones de pragmas óptimas.
• Etapa 3: Optimización de Política Relativa de Grupo (GRPO): El modelo se refina utilizando GRPO con una señal de recompensa de cuatro componentes:
  1. Formato de Razonamiento: Asegura una salida estructurada con rastros CoT.
  2. Compilación: Verifica la corrección sintáctica (compilación GCC).
  3. Corrección Funcional: Verifica la corrección semántica contra bancos de pruebas.
  4. Recompensa Proxy de QoR: Una recompensa comparativa derivada de una red Siamesa que predice la dominancia por pares.

3. Modelo de Recompensa Proxy Comparativo

• Arquitectura: Una arquitectura Siamesa de Bradley-Terry que toma dos diseños HLS como entrada y devuelve una probabilidad de que uno domine al otro.
• Entrenamiento: Entrenado en comparaciones por pares provenientes de resultados de Exploración del Espacio de Diseño (DSE), distinguiendo entre dominancia de Pareto completa (mejor en las 5 métricas) y superioridad en latencia.
• Conmutación Consciente de la Incertidumbre: Para evitar el "hackeo de recompensas" (donde la política explota puntos ciegos en el modelo proxy), el sistema emplea dropout de Monte Carlo (MC) durante la inferencia para estimar la incertidumbre.
  • Si un diseño candidato tiene alta incertidumbre, el sistema activa síntesis real de Vitis HLS para obtener la QoR de verdad fundamental.
  • Estos resultados de síntesis real se retroalimentan para actualizar en línea el modelo de recompensa proxy, expandiendo continuamente su cobertura y fiabilidad.
  • Este mecanismo asegura que el proxy permanezca preciso mientras mantiene baja la tasa de activación de síntesis (objetivo <5% en la convergencia).

4. Curación de Datos

El marco utiliza una estrategia de Muestreo de Calidad-Diversidad Próximo a Pareto. En lugar de usar solo diseños estrictamente óptimos de Pareto (que son demasiado pocos), incluye diseños cerca de la frontera de Pareto, clasificados por su distancia euclidiana a la frontera, asegurando que el modelo aprenda compromisos finos entre recursos y latencia.

Contribuciones Clave

1. Insight de Recompensa Relativa: Identificación de que el RL para HLS requiere solo señales de QoR relativas, no resultados de síntesis absolutos, lo que permite el uso de un modelo proxy comparativo.
2. Sistema Proxy Consciente de la Incertidumbre: Un mecanismo novedoso que combina un modelo de recompensa comparativo Siameso con estimación de incertidumbre mediante dropout MC y actualizaciones en línea mediante síntesis real selectiva. Esto previene el hackeo de recompensas y asegura la auto-mejora.
3. Marco HLS-Seek: Un pipeline completo de NL a HLS que logra un rendimiento de vanguardia con solo 7 mil millones de parámetros, utilizando una estrategia de entrenamiento de tres etapas (SFT de Diversidad $\to$ SFT de Arranque en Frío con Razonamiento $\to$ GRPO de Recompensa Proxy).

Resultados Experimentales

Evaluado en el benchmark HLS-eval y un conjunto de pruebas ForgeHLS:

• Corrección Sintáctica y Funcional:

  • Logró un 81.5% de pass@1 en corrección sintáctica y un 81.4% de pass@5 en corrección funcional en HLS-eval.
  • Superó a modelos de vanguardia (incluyendo GPT-5.1, DeepSeek-V3.2 y Qwen3-235B) y a baselines especializados en HLS (SAGE-HLS, Gai et al.) a pesar de tener significativamente menos parámetros (7B vs. 235B+ o modelos de código más grandes).
  • Específicamente, superó a GPT-5.1 en +2.3 puntos porcentuales en la corrección funcional pass@5 en HLS-eval.

• Calidad de Resultados (QoR):

  • Logró la latencia más baja en 16 de 30 núcleos.
  • Domina en Pareto a las baselines específicas de HLS (SAGE-HLS y Gai et al.) en 9 núcleos (5 vs. SAGE-HLS, 4 vs. Gai et al.) con solo 1 victoria inversa.
  • Demostró la capacidad de realizar reestructuración algorítmica de código (por ejemplo, expansión escalar y fisión de bucles) en lugar de solo inserción de pragmas, lo que llevó a reducciones significativas de latencia (por ejemplo, una reducción de 4.1x en GEMVER).

• Eficiencia de Entrenamiento:

  • Logró una aceleración de 8.5x en el entrenamiento en comparación con el RL de recompensa real.
  • En un presupuesto de tiempo de reloj de 73 horas, HLS-Seek completó 12,500 pasos de entrenamiento, mientras que un enfoque de recompensa real completó solo 1,460 pasos.
  • El mecanismo de recompensa proxy mantuvo una alta precisión (99.53% de precisión en dominancia de Pareto) mientras reducía la sobrecarga de síntesis a menos del 5% en la convergencia.

Significado y Afirmaciones

El artículo afirma que HLS-Seek demuestra que el RL específico de dominio con recompensas de QoR aprendidas es un camino viable hacia la generación de código HLS totalmente automatizada y eficiente en hardware. Al desacoplar la necesidad de resultados de síntesis absolutos del bucle de entrenamiento de RL, los autores superan el cuello de botella de escalabilidad de los enfoques de síntesis en el bucle.

El trabajo destaca que:

1. La conciencia de QoR es alcanzable sin síntesis costosa en el bucle aprovechando comparaciones relativas.
2. Los modelos pequeños (7B) pueden superar a modelos masivos de vanguardia en tareas de generación de hardware especializada cuando se entrenan con señales de QoR apropiadas y rastros de razonamiento.
3. La reestructuración algorítmica es una capacidad clave aprendida mediante este proceso, yendo más allá del simple ajuste de pragmas para optimizar fundamentalmente la estructura del código para el paralelismo de hardware.

Los autores concluyen que su sistema de recompensa proxy consciente de la incertidumbre equilibra exitosamente la compensación entre la velocidad de entrenamiento y la fidelidad de la recompensa, permitiendo la generación de diseños de hardware que no solo son funcionalmente correctos, sino también optimizados para latencia y uso de recursos.