Capítulo 8 — Arquitectura de computadores
Mapa de la lección
Lección 08 publicada. Mapa, ejemplo, EX022.
flowchart TD
N0["Resultados de aprendizaje"]
N1["8.1 Procesadores y aceleradores"]
N2["8.2 Formatos numéricos"]
N3["8.3 Superficies de ataque arquitectónicas"]
N4["8.4 Ejecución confiable y atestación"]
N5["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX022"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje"]
N1["8.1 Procesadores y aceleradores"]
N2["8.2 Formatos numéricos"]
N3["8.3 Superficies de ataque arquitectónicas"]
N4["8.4 Ejecución confiable y atestación"]
N5["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX022"]
[Resultados de aprendizaje]
|
v
[8.1 Procesadores y aceleradores]
|
v
[8.2 Formatos numéricos]
|
v
[8.3 Superficies de ataque arquitectónicas]
|
v
[8.4 Ejecución confiable y atestación]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX022]
Resultados de aprendizaje
Usted será capaz de (1) describir las CPU, las jerarquías de memoria, las GPU y los aceleradores que se usan para el aprendizaje automático; (2) explicar los formatos numéricos y su efecto sobre el comportamiento del modelo; (3) identificar superficies de ataque arquitectónicas (aislamiento de memoria, canales laterales, firmware); y (4) razonar sobre la ejecución confiable para cargas de trabajo de IA.
8.1 Procesadores y aceleradores
Las CPU ejecutan instrucciones generales con cachés profundas. Las GPU y los aceleradores de IA ejecutan miles de operaciones sencillas en paralelo, lo ideal para la multiplicación de matrices. Los modelos se trasladan entre la memoria del anfitrión y la del dispositivo; en entornos de nube, los datos en la memoria del dispositivo pueden compartirse entre procesos o clientes, así que el aislamiento importa. Las copias son el problema de seguridad: los pesos cargados en una GPU, las entradas guardadas en un búfer compartido y los resultados a la espera de devolverse existen brevemente en lugares que otro cliente o un controlador descuidado podrían leer. Los proveedores de nube aíslan a sus clientes, pero los ingenieros siguen preguntando si la memoria del dispositivo se borra entre trabajos y quién puede verla, y registran las respuestas en el modelo de amenazas del despliegue.
8.2 Formatos numéricos
El entrenamiento suele usar coma flotante de 32 o 16 bits; la inferencia puede usar enteros de 8 bits (cuantización). Una precisión menor cambia ligeramente las salidas y puede cambiar decisiones cerca de las fronteras. Las evaluaciones de seguridad deben usar la precisión desplegada: un ataque o una defensa medidos en 32 bits pueden comportarse de otro modo en 8 bits, y viceversa. La cuantización asigna cada valor al más cercano de un pequeño conjunto de niveles, de modo que las entradas próximas al umbral de decisión pueden pasar al otro lado. Los gradientes calculados sobre una copia de 32 bits pueden no coincidir con el comportamiento del modelo de 8 bits, lo que puede hacer que los ataques parezcan más fuertes o más débiles de lo que son en servicio.
8.3 Superficies de ataque arquitectónicas
Los fallos de seguridad de memoria en el código que sirve el modelo pueden exponer pesos o entradas. Las cachés compartidas y los tiempos pueden filtrar información entre procesos (canales laterales). Los fallos de hardware, incluidos los inducidos deliberadamente, como las inversiones de bits al estilo rowhammer, pueden corromper los pesos; la investigación ha mostrado que unos pocos bits invertidos en los parámetros de una red pueden degradarla o desviarla de forma drástica. El firmware y los controladores forman parte de la base de cómputo confiable.
Para un ingeniero, cada elemento sugiere un control: lenguajes con seguridad de memoria o una revisión cuidadosa del código de servicio, aislamiento entre clientes, memoria con corrección de errores y comprobaciones de integridad de los pesos cargados. Calcular el hash del archivo de pesos antes de cargarlo detecta cambios en disco, pero no bits invertidos después en memoria, así que los despliegues críticos también comparan periódicamente las salidas sobre un conjunto de comprobación fijo.
8.4 Ejecución confiable y atestación
Los entornos de ejecución confiable (TEE) y las GPU de computación confidencial pretenden proteger el código y los datos en uso frente al operador del anfitrión, y la atestación remota permite a un cliente verificar qué código se está ejecutando. Reducen algunos riesgos (un operador de nube curioso), pero no otros (un servidor de modelos vulnerable dentro del enclave, la inyección de prompts). La atestación responde a una pregunta limitada: ¿es este el código esperado sobre hardware genuino? No dice nada sobre si ese código es seguro. Por eso los ingenieros tratan un TEE como una capa que protege frente a un operador curioso, y mantienen la validación de entradas, los límites de privilegios y la monitorización para los ataques que llegan por la interfaz normal del modelo.
8.5 Ejemplo resuelto (caso sintético de NRS)
TrackEye se ejecuta en un ordenador en el borde del tren de inspección con un modelo cuantizado a 8 bits. Sam descubrió que las pruebas de robustez se habían hecho con el modelo de 32 bits en el laboratorio; repetirlas con la compilación desplegada de 8 bits cambió los falsos negativos al amanecer del 9,0 % al 9,6 %. Sam añadió como requisito «evaluar sobre el artefacto y el hardware desplegados» y anotó que el puerto de mantenimiento del ordenador en el borde da acceso físico al firmware, un elemento del modelo de amenazas.
Una subida de 0,6 puntos porcentuales es pequeña, pero muestra que el resultado del laboratorio no describía el sistema que realmente funciona en el tren. El nuevo requisito hace que cada cifra de robustez futura indique el hash del artefacto y el hardware sobre los que se midió.
8.6 Errores y límites
- Evaluar con una precisión numérica distinta de la desplegada.
- Suponer que los TEE resuelven los ataques a nivel de aplicación.
- Ignorar el firmware y los puertos físicos de mantenimiento.
Estos errores tienen una causa común: evaluar un sistema idealizado en lugar del desplegado. La precisión usada en las pruebas es fácil de contrastar con la compilación. Las afirmaciones sobre los TEE deben leerse fijándose en lo que excluyen. Los puertos de mantenimiento suelen quedar habilitados por comodidad; la lista de comprobación de Sam pregunta, para cada puerto, si es necesario en servicio, quién puede llegar a él y si su uso queda registrado.
Ejercicios — capítulo 8
- EX022 — Precisión numérica. ¿Por qué debe probarse la robustez sobre el modelo cuantizado desplegado? Rúbrica: 3 = la cuantización cambia las salidas cerca de las fronteras; los resultados pueden diferir; 2 = parcial; 1 = vago; 0 = incorrecto.
- EX023 — Límites de los TEE. Nombre una amenaza que un TEE mitiga y otra que no mitiga en un servicio de LLM. Rúbrica: 3 = el operador del anfitrión leyendo datos frente a la inyección de prompts/fallos del servidor; 2 = una; 1 = vago; 0 = incorrecto.
- EX024 — Inversiones de bits. Explique por qué las comprobaciones de integridad de los pesos en el momento de la carga no resuelven del todo los ataques por fallos. Rúbrica: 3 = los fallos pueden producirse en memoria después de la carga; hacen falta comprobaciones en tiempo de ejecución/ECC/redundancia; 2 = parcial; 1 = vago; 0 = incorrecto.
Síntesis del capítulo
La IA se ejecuta sobre hardware real con precisión finita, recursos compartidos y firmware. Los ingenieros prueban el artefacto desplegado en la plataforma desplegada e incluyen las amenazas a nivel de arquitectura en el modelo.
Siga estudiando — capítulo 08 de 50
← Capítulo 07 (borrador) · Índice de capítulos del curso · Capítulo 09 (borrador) →