Instalando Alpine Linux en RAM

1) no te he dicho que quiero la version mas pelada ?? ya le ire añadiendo via red, solo necesito lo mas basico y controlador de rj45 ¿debo bajar el driver de la placa o Alpine linux ya trae un driver por defecto ? mi objetivo es NI RASTRO DE GOOGLE, TO COMPILADO ESTATICAMENTE

Para lo que buscas (minimalismo extremo, compilación manual y cero rastro de corporaciones), aquí tienes la ruta directa:

1. Qué descargar (Lo más «pelado»)

No bajes la versión Extended. Descarga la Standard (x86_64).

Es la imagen base (aprox. 150MB).
Drivers RJ45: Alpine usa el kernel Linux estándar. Las placas TTY T1DEEP suelen montar chips Intel (i210/i211) o Realtek. El driver ya viene incluido en el kernel de la versión Standard. Si es una interfaz SFP+ de 10Gb, también suele estar soportada de serie (drivers ixgbe o mlx).

2. Grabación «Limpia» desde Windows

Si quieres evitar herramientas con telemetría:

Usa Rufus en su versión Portable y, al abrirlo, dile que no busque actualizaciones (para que no conecte a internet).
Selecciona «ISO Mode» cuando te pregunte.

3. Instalación «Diskless» (RAM Total)

Al arrancar, Alpine se carga en RAM por defecto (initramfs). Para que sea tu sistema operativo real sin tocar el disco duro:

Escribe setup-alpine.
En «Enter disk(s) to use», escribe: none.
En «Where to store configs», selecciona tu pendrive (ej. sda1).
En «Enter apk cache directory», selecciona también tu pendrive.

Resultado: El SO vive en los 1.2TB de RAM. El pendrive solo se usa 1 segundo al arrancar para leer el archivo .apkovl (tus configuraciones) y los paquetes .apk esenciales.

4. Compilación y «Zero Google»

Para compilar todo tú mismo y no depender de binarios externos más allá del bootstrap:

Instalar herramientas de compilación:bashapk add build-base gcc abuild binutils Usa el código con precaución.
Repositorios: Edita /etc/apk/repositories. Borra todo y deja solo los mirrors oficiales de Alpine (que son comunitarios/universitarios, no de Google).
DNS: Edita /etc/resolv.conf y asegúrate de no usar 8.8.8.8. Usa los de tu nodo local o algo neutro como Unbound.

5. Configurar el tamaño de la RAM

Con 1.2TB, Alpine limitará el sistema de archivos a la mitad por seguridad. Para usar casi todo el espacio para compilar:

bash

mount -o remount,size=1100G /

hola estoy en la bios de la placa tty t1deep quiero instalar alpine linux lo mas pelado posible, tengo un pendrive, estoy con un portatil en windows 10, como lo formateo y que me descargo e instalo, luego como seteo para que empieze a cargar desde el pendrive la placa y como le indico al pensdrive para que se instale el S.O. en la maoria RAM (que son 1228g ) ? – Buscar con Google

pagina de descargas

Index of /alpine/latest-stable/releases/x86_64/

que caña la ultima verison es la 3.23 queda poco para la 3.33 !!

enlace

si uso qemu desde alpine linux, alpin en ram, y le digo que ejecute windows 11 con las 2 cpus epyc 7v12 que tengo, funcionara igual de rapido que si instalae windows directamente, ? entiendo que quizás no, pero en que porcentaje del 1 al 100 sera qemu siendo 1000 identifoc en velocidad y tal ?

Usar Windows 11 sobre QEMU/KVM en Alpine Linux (corriendo en RAM) con dos procesadores

AMD EPYC 7V12 (64 núcleos cada uno, 128 hilos en total por CPU) ofrece un rendimiento excepcional, pero no será idéntico al de una instalación directa (bare metal).

En una escala del 1 al 1000 (donde 1000 es la velocidad nativa), el rendimiento de QEMU con una configuración optimizada se sitúa generalmente entre 930 y 970 (93% – 97%). Level1Techs Forums

Factores que afectan la velocidad

Rendimiento de CPU: Con la opción host-passthrough, el procesador virtual expone todas las instrucciones del EPYC 7V12, logrando que el rendimiento mononúcleo sea casi del 100%. Sin embargo, en tareas multihilo masivas que involucren los 256 hilos lógicos, la gestión de interrupciones y el «overhead» de la virtualización pueden reducir el rendimiento multihilo a un 90-95% del valor nativo.
Memoria RAM: Al ejecutar Alpine desde la RAM, reduces la latencia del sistema anfitrión al mínimo. Si asignas memoria mediante HugePages, la pérdida de rendimiento en la RAM será prácticamente imperceptible (menos del 1-2%).
Almacenamiento: Este es el cuello de botella más común. Si usas archivos de imagen (qcow2), podrías bajar a un 50-70% de velocidad de disco. Para acercarte al 100%, debes pasar un disco NVMe completo a la máquina virtual mediante PCI Passthrough.
Gráficos: Sin una tarjeta gráfica dedicada pasada por PCI Passthrough (VFIO), la interfaz de Windows 11 se sentirá lenta y «laggeada» (alrededor de un 30-50% de fluidez visual), ya que la CPU tendrá que emular los gráficos por software. Reddit +4

Resumen de rendimiento (Escala 1 – 1000)

Componente	Puntuación Estimada	Requisito para alcanzarla
Cálculo CPU (Single Core)	980 – 1000	Usar `host-passthrough`
Cálculo CPU (Multi Core)	930 – 950	Configurar correctamente el «pinning» de núcleos
Escritura/Lectura Disco	950+	PCI Passthrough de un NVMe real
Fluidez de Interfaz (GPU)	950+	PCI Passthrough de una GPU dedicada
Fluidez de Interfaz (Sin GPU)	400 – 600	Emulación básica por software

Conclusión: Si configuras PCI Passthrough para el disco y la GPU, y haces CPU Pinning (asignar núcleos específicos del EPYC a la VM), la diferencia será casi imposible de notar en el uso diario o profesional. Sin estas optimizaciones, la experiencia será notablemente más lenta que una instalación directa.

Más información para explorar

Aprende cómo optimizar el rendimiento de Windows 11 en KVM mediante el ajuste de archivos XML y drivers VirtIO en este artículo de AndroidsDream.
Consulta esta guía sobre la asignación y «pinning» de núcleos de CPU para maximizar la eficiencia en Medium.
Revisa las recomendaciones técnicas para virtualizar Windows 11, incluyendo requisitos de TPM y CPU, en la documentación de Microsoft Learn.
Explora comparativas de rendimiento entre «bare metal» y máquinas virtuales en foros especializados como Level1Techs.

¿Te gustaría que te ayude con los parámetros específicos de QEMU para hacer el passthrough de tus componentes o para configurar el CPU pinning en tus EPYC 7V12?

pero que es musl ? y si no quiero entorno grafico y todo po linea de comandos ?? para que narices necesito nada dinamico ?? b) es posible estatico bajo linea de comandos, sin entorno grafico, solo tetxo ?

Entiendo perfectamente tu frustración. Si quieres

pureza absoluta, vamos a despejar las dudas técnicas para que logres ese sistema «blindado»:

1. ¿Qué es musl?

Es la biblioteca básica de C. Todo sistema Linux necesita una para hablar con el hardware (pedirle a la RAM que guarde algo, decirle al procesador que sume, etc.).

glibc (la común): Es enorme, compleja y diseñada para ser dinámica (depender de otros archivos).
musl (la de Alpine): Es un código minimalista y limpio. Es la herramienta que te permite crear binarios que contengan todo dentro de sí mismos (estáticos).

2. ¿Para qué necesitas algo dinámico ahora mismo?

Solo lo necesitas para el arranque inicial. Alpine viene así por defecto para que el USB ocupe 300MB y no 3GB. Es el «andamio» que vas a usar para construir tu edificio. Una vez que compiles tus herramientas de forma estática, podrías incluso borrar el musl.so y el sistema seguiría funcionando con tus binarios.

3. Respuesta a tu «b»: ¡SÍ, es posible!

Es perfectamente posible tener un sistema 100% estático, solo línea de comandos (terminal) y sin rastro de entorno gráfico. Es, de hecho, el uso profesional de Alpine en servidores de alta seguridad.

Para lograrlo desde tu placa TTY T1DEEP:

No instales nada de X11 o Wayland: El comando setup-alpine nunca te instalará entorno gráfico a menos que tú se lo pidas específicamente. Te quedarás en la consola negra con letras blancas.
Instala las herramientas de «creación»:bashapk add build-base gcc musl-dev Usa el código con precaución.
Compila tus herramientas así: Cuando bajes el código fuente de lo que quieras usar (ej. un editor de texto o un navegador de consola), compílalo con este comando:bashLDFLAGS="-static" ./configure make Usa el código con precaución.El resultado será un archivo que no tiene dependencias.

4. ¿Cómo lo dejas «pelado» de verdad?

Una vez tengas tus binarios compilados estáticamente:

Puedes moverlos a /bin.
Puedes desinstalar los paquetes originales de Alpine (apk del ...).
Tu sistema será entonces un Kernel + Tus binarios estáticos viviendo en 1.2TB de RAM. Nada más.

¿Has logrado que el comando setup-alpine termine y te deje en el prompt para empezar a «limpiar»?

Más información:

Visita la web de musl libc para entender por qué es superior para el enlazado estático.
Lee sobre el concepto de Static Linking en Wikipedia.
Revisa la documentación de Alpine sobre desarrollo para configurar tu entorno de compilación.

indicame , teniendo ya la usb puesta en la placa y cargada la unidad, que pasos hago, que escribo en el terminal lina de comandos ?

Ya tienes el USB pinchado y has arrancado la placa

TTY T1DEEP. Estás viendo una pantalla negra con letras blancas que dice localhost login:.

Sigue estos pasos exactos para configurar tu sistema «pelado» en RAM:

1. Entrar al sistema

Escribe el usuario y pulsa Enter (no pide contraseña):

bash

root

Usa el código con precaución.

2. Iniciar el asistente de configuración

Escribe el comando para configurar lo básico (red, teclado, etc.):

bash

setup-alpine

Usa el código con precaución.

3. Respuestas clave para tu objetivo (Síguelas al pie de la letra)

El sistema te irá haciendo preguntas. Responde así:

Keyboard layout: es (para español) y luego es otra vez.
Hostname: Inventa un nombre (ej: servidor-ram).
Interface: Selecciona la que te proponga (ej: eth0). Pulsa Enter.
Ip address: Escribe dhcp. (Esto activará tu puerto RJ45).
Manual network config: n.
Password: Escribe una contraseña para root (la necesitarás luego).
Timezone: Europe/Madrid (o la tuya).
Proxy: none.
NTP client: chrony.
Mirror: Elige el número 1 (el más rápido/limpio).
SSH server: none (así no dejas puertos abiertos).
Disk(s) to use: MUY IMPORTANTE, escribe: none
Where to store configs: Escribe: sda1 (esto es tu pendrive, ahí guardará solo los cambios de texto, pero el SO seguirá en RAM).
APK cache directory: Escribe: /media/sda1/cache

4. Activar tus 1.2TB de RAM

Como tienes una cantidad de RAM brutal, Alpine por defecto la limitará. Para usarla toda para tus compilaciones:

bash

mount -o remount,size=1100G /

Usa el código con precaución.

5. Guardar los cambios en el USB

Como estás corriendo en RAM, si apagas se pierde todo lo que no guardes manualmente. Para «congelar» tu configuración en el pendrive:

bash

lbu commit -d

Usa el código con precaución.

6. Instalar herramientas para compilar estáticamente

Ahora que tienes red, baja lo mínimo para empezar a fabricar tus propios binarios:

bash

apk add build-base gcc musl-dev nano

espera, tengo solo 128 GB de RAM ahora mismo, y quiero usar QEMU para correr 1 instancia de windows 10 y otra de windows 11 cada una con aprox 64GB de RAM, como lo hago en el paso 4) donde dijiste «mount -o remount,size=1100G /» Tengo que poner toda la memoria aqui ?

No,

no pongas toda la memoria ahí. Si le asignas los 128GB al sistema de archivos raíz (/), te quedarás sin RAM real para arrancar las máquinas virtuales de QEMU.

Aquí está el ajuste estratégico para tu caso:

1. El error que debemos evitar

Si haces mount -o remount,size=120G /, le estás diciendo a Linux: «Resérvame casi toda la RAM para guardar archivos temporales». Cuando intentes arrancar un Windows con QEMU pidiéndole 64GB, el sistema te dará un error de «Out of Memory» (OOM) porque la RAM está «ocupada» por el sistema de archivos, aunque esté vacía.

2. El ajuste correcto para 128GB de RAM

Como vas a usar QEMU, necesitas dejar la RAM libre para las VMs. Alpine en modo RAM (pelado) solo ocupa unos 100-200 MB.

Ejecuta esto en lugar de lo anterior:

bash

mount -o remount,size=4G /

Usa el código con precaución.

¿Por qué 4GB? Es de sobra para que Alpine funcione, descargues los binarios de QEMU y guardes configuraciones. El resto (124GB) quedará libre para que las máquinas virtuales de Windows respiren.

3. El comando para QEMU (Lo más «pelado» posible)

Para instalar QEMU sin entorno gráfico (solo el motor):

bash

apk add qemu-system-x86_64 qemu-img

Usa el código con precaución.

4. Cómo lanzar los Windows con 64GB cada uno

Como no tienes entorno gráfico, tendrás que lanzarlos mediante la terminal. Para que cada uno use su RAM:

Instancia Windows 10:

bash

qemu-system-x86_64 -m 60G -smp 4 -enable-kvm -hda /ruta/al/disco_win10.qcow2 -net nic -net user

Usa el código con precaución.

Instancia Windows 11:

bash

qemu-system-x86_64 -m 60G -smp 4 -enable-kvm -hda /ruta/al/disco_win11.qcow2 -net nic -net user

Usa el código con precaución.

(Nota: He puesto 60G en lugar de 64G para dejar un margen de seguridad al sistema base y que no se bloquee la placa).

5. Advertencia técnica: ¿Dónde están los discos de Windows?

Si los archivos de disco de Windows (.qcow2) están en el pendrive, irán extremadamente lentos. Si quieres que vuelen, tendrías que tener un SSD conectado a la placa o cargarlos también en la RAM, pero con 128GB vas muy justo para meter dos ISOs de Windows y su sistema instalado dentro de la memoria.

¿Tienes un disco duro SSD conectado a la placa para guardar las imágenes de los Windows o pretendes que corran también desde el pendrive?

si, tengo un optane 905P de 900 GB

Esa

Optane 905P es la pareja perfecta para este setup. Al tener una latencia de escritura casi nula, tus máquinas virtuales de Windows volarán aunque Alpine corra desde la RAM.

Aquí tienes los pasos exactos para preparar el disco, instalar QEMU y lanzar los Windows:

1. Preparar el disco Optane (Lo más limpio posible)

Alpine no montará el Optane automáticamente. Tienes que hacerlo tú:

Identifica el disco: lsblk (Aparecerá probablemente como /dev/nvme0n1).
Formatea en EXT4 (sin florituras):bashmkfs.ext4 /dev/nvme0n1 Usa el código con precaución.
Monta el disco:bashmkdir /mnt/optane mount /dev/nvme0n1 /mnt/optane Usa el código con precaución.

2. Instalar el motor de virtualización (QEMU + KVM)

Alpine es extremadamente ligero, pero para que Windows 10/11 corra rápido necesitas KVM (aceleración por hardware).

bash

apk add qemu-system-x86_64 qemu-img qemu-modules-virtio virt-install
# Carga el módulo del kernel para aceleración
modprobe kvm-intel

Usa el código con precaución.

3. Crear los discos para Windows en la Optane

Vamos a crear dos archivos de 200GB cada uno dentro de la Optane. Al ser QCOW2, solo ocuparán el espacio que realmente use Windows:

bash

cd /mnt/optane
qemu-img create -f qcow2 win10.qcow2 200G
qemu-img create -f qcow2 win11.qcow2 200G

Usa el código con precaución.

4. Lanzar las instancias (Modo Estático/Terminal)

Para que cada Windows use sus 60GB de RAM y use todos los hilos de tu placa T1DEEP:

Para Windows 10:

bash

qemu-system-x86_64 -m 60G -cpu host -enable-kvm \
-drive file=/mnt/optane/win10.qcow2,if=virtio \
-net nic,model=virtio -net user \
-nographic -vnc :1

Usa el código con precaución.

Para Windows 11 (Requiere TPM ficticio y UEFI):

bash

apk add swtpm ovmf
qemu-system-x86_64 -m 60G -cpu host -enable-kvm \
-drive file=/mnt/optane/win11.qcow2,if=virtio \
-bios /usr/share/OVMF/OVMF_CODE.fd \
-net nic,model=virtio -net user \
-nographic -vnc :2

Usa el código con precaución.

5. ¿Cómo ves la pantalla de los Windows?

Como Alpine no tiene entorno gráfico, QEMU está «dibujando» los Windows en un servidor VNC invisible:

Desde tu portátil con Windows 10, descarga un visor (como TightVNC o RealVNC).
Conéctate a la IP de tu placa TTY (ejemplo: 192.168.1.50:1 para Win10 y 192.168.1.50:2 para Win11).

2 preguntas. A) como guardo lo que acabe de hacer digamos en el pendrive para que al apagar el pc y volver a encenderlo con el pendrive se ejevute todo de nuevo ? , A.2) tendre que picar algun comando tras apagar y encender el pc con el pendrive ? B) que ventajas tiene usar alpine en la ram, cargada desde el pendrive, y que contras, en comparación a instalar alpine en el optane directamente ?

Aquí tienes las respuestas para tu configuración de alta fidelidad:

A) ¿Cómo guardar todo en el pendrive (Modo Diskless)?

Alpine en RAM no guarda nada automáticamente. Para «congelar» lo que has hecho (instalar QEMU, crear carpetas, configurar red) en el USB, usa el comando:

bash

lbu commit -d

Usa el código con precaución.

Qué hace: Crea un archivo llamado tu_hostname.apkovl.tar.gz en el pendrive. Al arrancar, Alpine lee ese archivo y reconstruye exactamente tu sistema en la RAM.
Ojo con el Optane: El comando lbu NO guarda los discos de Windows (.qcow2) porque están en el Optane. Esos se quedan ahí grabados físicamente, no se borran al apagar.

A.2) ¿Qué habrá que escribir al encender?

Si has hecho el lbu commit, Alpine arrancará con QEMU ya instalado y la red configurada. Pero sí tendrás que escribir algo:

Montar el Optane: Linux no lo monta solo tras reiniciar (a menos que edites el archivo /etc/fstab).bashmount /dev/nvme0n1 /mnt/optane Usa el código con precaución.
Lanzar las VMs: Tendrás que volver a meter los comandos de qemu-system-x86_64....
- Truco de Pro: Puedes crear un script (un archivo .sh) en tu carpeta personal, darle a lbu commit y así solo tendrás que ejecutar ./arrancar_vms.sh al encender.

B) Alpine en RAM vs. Alpine en Optane (Pros y Contras)

Para tu placa TTY T1DEEP con una Optane 905P, estas son las diferencias:

Característica	Alpine en RAM (Desde USB)	Alpine en Optane (Instalación Disco)
Velocidad SO	Instantánea. Todo el SO vuela a la velocidad de la latencia de la RAM.	Muy rápida, pero limitada por el bus NVMe.
Persistencia	Volátil. Si rompes algo o entra un virus, reinicias y el sistema vuelve a estar «virgen».	Permanente. Los cambios se quedan grabados. Si rompes el SO, tienes que reinstalar.
Seguridad	Máxima. El SO base es de «solo lectura» en el pendrive. Inmune a corrupciones de disco.	Normal. El sistema puede corromperse si hay un apagón.
Complejidad	Tienes que hacer `lbu commit` cada vez que instales algo nuevo.	Es como un Windows/Ubuntu normal; instalas y te olvidas.
Uso de RAM	Te «roba» unos 200MB-2GB de tus 128GB para el SO.	La RAM queda 100% libre para las máquinas virtuales.

Mi recomendación: Quédate en RAM (USB). Tienes una Optane 905P; úsala exclusivamente para los datos pesados (los discos de Windows). Tener el sistema operativo Alpine «flotando» en la RAM lo hace indestructible y extremadamente «pelado».

¿Quieres que te prepare el script de auto-arranque para que solo tengas que escribir un comando corto al encender la placa?

estan locos, y a todo esto hay que pagar la gpu fisica ?

Exactamente. El hardware (la tarjeta física) y el software (la licencia vGPU) se pagan por separado. Es un modelo de negocio que NVIDIA ha blindado para el sector empresarial.

Para que te hagas una idea de la «locura» completa, aquí está el desglose de lo que estás mirando:

1. El Costo del Hardware (GPU)

Una NVIDIA RTX 6000 Ada Generation (la de 48GB, ya que la de 96GB suele ser la L40S o modelos de servidor específicos como la B100) cuesta entre $7,000 y $9,000 USD por unidad.

El problema técnico: Una sola tarjeta, por muy potente que sea, no puede repartir sus recursos entre 333 usuarios con un rendimiento aceptable. Tocarían a unos 144 MB de VRAM por persona (si fuera la de 48GB) o 288 MB (si fuera la de 96GB). Eso no alcanza ni para abrir Chrome con varias pestañas de forma fluida.
Realidad: Para 333 usuarios, necesitarías un servidor con al menos 4 a 8 GPUs de ese calibre, lo que suma unos $60,000 USD solo en tarjetas.

2. El «Impuesto» de Software (Licencias)

Como viste, las licencias pueden duplicar el costo del proyecto en pocos años. NVIDIA justifica esto diciendo que:

Desarrollan los drivers específicos para que la GPU se pueda «picar» en trocitos (vGPU).
Ofrecen soporte técnico para que aplicaciones como AutoCAD o Revit no fallen en entornos virtuales.
Sin la licencia, la tarjeta bloquea sus funciones de virtualización y solo sirve para una PC física convencional.

¿Hay alternativas para no pagar licencias?

Si no quieres pasar por el aro de las licencias vGPU de NVIDIA, existen dos caminos (aunque con limitaciones):

GPU Passthrough (Dedicada): Le entregas la tarjeta completa a una sola VM. No necesitas licencia, pero solo un usuario la aprovecha. El resto de las 332 personas se quedan sin aceleración de video.
Proxmox + vGPU Unlock (No oficial): Existe una comunidad en GitHub que «hackea» drivers antiguos para habilitar vGPU en tarjetas que no deberían tenerlo. Riesgo: Es extremadamente inestable, no tiene soporte, es ilegal para uso comercial y NVIDIA lo bloquea constantemente con actualizaciones de firmware.
AMD Radeon Pro: Algunas tarjetas de AMD (como la serie Radeon Pro V-series) han ofrecido históricamente virtualización basada en estándares abiertos (SR-IOV) sin pagar licencias por usuario, pero su ecosistema de software es mucho más débil que el de NVIDIA.

En resumen: Sí, es un ecosistema extremadamente caro diseñado para corporaciones que prefieren pagar eso antes que comprar 333 estaciones de trabajo físicas.

¿Para qué tipo de proyecto o empresa estás evaluando esta solución de 333 usuarios?

Las respuestas de la IA pueden contener errores. Más información

y como que pagan por ello, estas loco s? por que no usar SR-IOV en vez de la locura de nvidia ? se puede usar SR-IOV con gpu nvidia o ellos las capan, y si no se puede, pues que le den por el cula a nvidia y mejor usar graficos intel o amd no crees ?

Tienes toda la razón en que el modelo de NVIDIA es extremadamente agresivo (y caro), pero hay una explicación técnica (y una trampa comercial) de por qué el mercado empresarial sigue pasando por caja.

Aquí te explico el panorama real sobre SR-IOV y las alternativas:

1. ¿NVIDIA capa SR-IOV?

Sí y no. Físicamente, las arquitecturas modernas (como tu RTX 6000 o las Ampere/Ada Lovelace) soportan SR-IOV a nivel de silicio. El problema es el firmware y los drivers:

Bloqueo por Software: NVIDIA bloquea el uso de SR-IOV en sus drivers estándar. Para habilitar las «Virtual Functions» (VF) de SR-IOV, necesitas el driver NVIDIA vGPU.
La Trampa: En el momento en que instalas el driver que desbloquea SR-IOV, la tarjeta busca el Servidor de Licencias. Si no lo encuentra, limita el rendimiento a niveles ridículos (1-3 FPS) o deshabilita CUDA.
Resultado: No puedes usar SR-IOV «gratis» en NVIDIA para repartir la GPU entre muchas VM de forma oficial.

2. ¿Qué pasa con Intel y AMD?

Aquí es donde la cosa se pone interesante, porque ellos son mucho más abiertos, pero tienen sus propios «peros»:

Intel (Data Center GPU Flex / Max): Intel es el rey de la apertura aquí. Su tecnología GVT-g y ahora SR-IOV en las tarjetas Intel Arc y Flex es gratuita. No pagas licencias por usuario. El problema es que, para 333 usuarios, el rendimiento por vGPU de Intel es inferior al de NVIDIA en tareas pesadas (IA o Render 3D profesional).
AMD (Radeon Pro): AMD utiliza MxGPU, que es SR-IOV puro basado en hardware. No cobran licencias por usuario. Compras la tarjeta (ej. serie S o Radeon Pro V620), la pinchas y divides la GPU.
- ¿Por qué no todo el mundo usa AMD entonces? Porque el ecosistema de software (drivers para virtualización) de AMD es históricamente más inestable que el de NVIDIA, y muchas aplicaciones profesionales (Adobe, Autodesk) están optimizadas específicamente para CUDA (NVIDIA).

3. ¿Por qué las empresas «locas» siguen pagando a NVIDIA?

No es por gusto, es por Certificación y Soporte:

Ecosistema CUDA: Si tus 333 usuarios van a hacer IA o cálculo científico, AMD/Intel no son una opción viable hoy en día por compatibilidad.
Certificación ISV: Si un arquitecto usa AutoCAD en una VM y el programa falla, Autodesk solo te da soporte si estás usando una GPU certificada con drivers certificados (que son los de pago de NVIDIA).
Densidad: NVIDIA gestiona mejor la memoria compartida cuando tienes cientos de usuarios, evitando que un usuario «pise» el rendimiento de otro.

Resumen de tu situación

Si tu objetivo es ahorrar dinero y no necesitas CUDA (IA) ni certificaciones de software ultra-específicas:

Vende la RTX 6000: Te darán mucho dinero por ella.
Compra AMD Radeon Pro (serie V) o Intel Flex: Podrás usar SR-IOV sin pagar un solo céntimo de licencia recurrente.
Usa Proxmox: Es el hipervisor que mejor se lleva con estos «experimentos» de repartir GPU sin pasar por el aro de licencias de VMware/NVIDIA.

¿Qué aplicaciones específicas van a abrir esos 333 usuarios? (Esto define si puedes mandar a NVIDIA «a paseo» o si estás encadenado a ellos).

si tengo una nvidia rtx pro 6000 de 96 gb y la quiero usar con varias VM via VGPU, debo pagar alguna licencia ? – Buscar con Google

MxGPU amd – Buscar con Google

instalar desde alpine linu std v3.23 en ram, qemu en mi disco optane 905p para instalar win10 pro 64 bit h22l2 – Buscar con Google

Instalando Alpine Linux en RAM

Comentarios

Deja una respuesta Cancelar la respuesta

Más entradas

El nacimiento de los Humanos Virtuales : Los Teleñecos

Instalando Alpine Linux en RAM

Alpine Linux para BeBots* + Edicion 8K120P

Intel ARC B70