WeVisOne-VL-4B encuentra, cuenta y recorta objetos con un solo modelo, y todas las tareas funcionaron en una tarjeta real de 16 GB
WeVisOne-VL-4B de Tencent en nuestra nube: cajas, conteos, OCR y recortes hasta el pelo con un modelo, un recorte en 1 s en una RTX 4090, las 7 tareas en 16 GB.
El tablero de ajedrez de la carpeta de ejemplos de la propia Tencent tiene dieciséis piezas blancas. WeVisOne-VL-4B, ejecutado dos veces en una RTX 4090 con el mismo prompt, respondió 15 en 1,35 segundos y 16 en 3,87 segundos. La respuesta rápida se saltó el caballo de g5. El mismo modelo, dos formas de ejecutarlo, y esa diferencia es la decisión que tienes delante antes de ponerlo detrás de un producto. O te quedas con la rápida y revisas sus conteos, o con la lenta, que además entra en una tarjeta de 16 GB. En cualquier caso, un único modelo abierto de 4B de parámetros encontró objetos por su nombre, los contó, señaló puntos, leyó texto y recortó a una persona de una foto hasta el pelo. Sus autores lo venden como todo en uno. Servirlo detrás de una API exige un backend a medida, y el que escribimos está enlazado al final.
Mismo modelo, misma foto y mismo prompt. El motor rápido (izquierda) es unas tres veces más veloz aquí, y se dejó una pieza. El motor de referencia está a la derecha.
Un modelo de 4B hace el trabajo de un detector, un segmentador y una herramienta de recorte
WeVisOne-VL ("WeChat Vision All-in-One") mete en un solo modelo los trabajos que normalmente necesitan una cadena de tres. El primero dibuja cajas alrededor de las cosas que nombras, por ejemplo GroundingDINO, con el que se comparan los autores. Un segundo, como SAM2, convierte cada caja en un contorno. Un tercero hace un recorte suave, el que conserva el pelo suelto y los bordes. Cada uno es su propia descarga, su propia memoria y su propia forma de romperse.
El equipo de WeChat Vision de Tencent lo construyó sobre un modelo abierto de Alibaba. Según la ficha del modelo, encuentra cualquier cosa que puedas nombrar, o una cosa concreta descrita como "el gato de la derecha". También cuenta, señala puntos, lee texto con su posición, dibuja contornos y hace recortes.
El modelo escribe, un pequeño recortador dibuja. WeVisOne-VL responde en texto, y una posición no es más que más texto. Los autores añadieron 1.001 palabras especiales, de <0> a <1000>, cada una una posición a lo ancho o a lo alto de la imagen. Una caja son cuatro de esas palabras, un punto son dos. Para contornos y recortes, etiqueta cada caja, y un programa aparte, diminuto, lee lo que el modelo ve en esa etiqueta y pinta los píxeles. Ese recortador tiene 9,6 millones de parámetros, unas 500 veces menos que el modelo al que acompaña. La página del proyecto dice que no hace falta una herramienta de contornos aparte, porque el recortador reutiliza lo que vio el modelo.
El equipo lo entrenó con unos 100 millones de imágenes, y usó SAM2 solo para dibujar los contornos de entrenamiento, no al ejecutarlo. Publicaron el 4B y un 2B, con un paquete de código que ejecuta los dos. Los repos de Hugging Face se crearon el 22 de octubre de 2026, y el commit de publicación del código tiene fecha del 23 de octubre. Lo vimos en el vídeo de noticias de AI Search del 25 de octubre.
Los autores afirman que el 4B va en cabeza en más de 30 benchmarks. En su prueba de encontrar objetos por su nombre, saca 55,3 sobre 100, y GroundingDINO 38,8. En recortes de retrato, su error es la mitad que el de un montaje basado en SAM2 (7,3 frente a 15,4). La idea de que "sustituye a tres modelos" se apoya en esas tablas, no en una comparación que hayamos hecho nosotros.
Los pesos en Hugging Face son Apache 2.0, que permite el uso comercial. La ficha del modelo añade que "the release is intended for research" y que "not intended to make autonomous high-impact decisions or to identify individuals". Nuestra lectura: la concesión Apache es la licencia, las líneas de uso previsto son orientaciones, y la de identificar personas importa si tu producto trabaja con caras.
La prueba: el modelo ocupa unos 10 GB, y el montaje rápido lo carga dos veces
El montaje rápido carga el modelo dos veces en una sola tarjeta. El fichero publicado pesa 19,3 GB porque guarda cada número a precisión completa. Lo cargamos a media precisión, la forma habitual de servir un modelo, lo que lo deja en unos 10 GB. El paquete de código puede ejecutarlo de dos maneras: un motor rápido pensado para servir y el motor de referencia, sin más. Incluso cuando el motor rápido escribe la respuesta, el paquete mantiene una segunda copia en el motor de referencia para alimentar al recortador.
Desplegamos el 4B a través de nuestra plataforma y le enviamos las mismas 14 peticiones, una imagen cada vez, en cada montaje. Cubren siete tipos de trabajo: encontrar varias cosas por su nombre, contar, encontrar una cosa descrita (y rechazar una que no está), señalar, leer texto, sacar contornos y recortar. Las imágenes son los ejemplos de los propios autores más fotos públicas. Casi todas las ejecuciones usaron una RTX 4090 con 24 GB de memoria, y una RTX 5080 real con 16 GB comprobó si una tarjeta más pequeña aguanta.
Resultados: un recorte a resolución completa en un segundo, y 'aquí no hay nada' cuando no hay nada
El recorte es lo más llamativo. Un retrato de 1620 por 1080 de los ejemplos de los autores volvió como recorte a resolución completa, y los mechones de pelo agitados por el viento se conservan.
El resto, en los tiempos que nota una persona:
| Trabajo | RTX 4090, rápido | RTX 4090, referencia | RTX 5080 16 GB, referencia |
|---|---|---|---|
| Recortar a una persona, 1620 x 1080 | 1,0 s | 1,1 s | 2,1 s |
| Encontrar "el gato de la derecha" | 0,21 s | 0,55 s | 0,68 s |
| Contar 12 personas | 0,78 s | 2,7 s | 2,8 s |
| Leer un cartel de calle (palabras encontradas) | 3,7 s (29) | 9,1 s (21) | 9,5 s (22) |
| Encontrar 5 tipos de objeto en una cocina | 1,9 s | 7,4 s | 8,3 s |
| Pico de memoria de la tarjeta (GiB) | 23,0 | 12,3 | 12,8 |
Tiempo en la tarjeta, sacado de nuestros logs. Memoria en GiB, la unidad que usa la propia lectura de la tarjeta. Las palabras encontradas en el cartel varían según el montaje.
Pedimos "el perro" en una foto de gatos. El modelo respondió que no había ninguno en todos los montajes que probamos, en la única foto que probamos, en 0,11 segundos con el motor rápido. Un detector que se inventa un perro cuando no lo hay es el bug que hace que un equipo de producto deje de fiarse de la función.
En la foto de los autores de unos chicos con micrófonos, enmarcó a los dos cantantes. Las cajas de la cocina, el punto sobre el receptor de béisbol, el contorno de la bicicleta y los recortes del retrato y del gato estaban bien cuando los revisamos a ojo. No comprobamos el conteo de 12 tenistas contra una referencia verificada.
El motor rápido es unas tres veces más veloz en tareas de objetos, y se equivocó con el tablero de ajedrez
En tareas de objetos, el motor rápido es entre una vez y media y cuatro veces más veloz, unas tres veces en la mayoría. En los recortes el panorama es mixto. El contorno de la bicicleta fue más lento con el motor rápido (de 1,2 a 1,8 segundos frente a 0,9).
Los dos motores usaron decodificación greedy, así que el fallo del ajedrez no es ruido de muestreo. La causa probable es que las operaciones de bajo nivel difieren un poco entre los dos programas, y una caja que estaba en el límite cayó del otro lado. También discreparon en el cartel de la calle (29 palabras frente a 21) y en las ollas y sartenes colgadas (19 frente a 20). Un fallo en 14 peticiones no es una tasa. Es un motivo para probar tus propias imágenes en el motor que vas a poner en producción, igual que haces la prueba de sonido con el equipo con el que vas a tocar de verdad.
Hay otra trampa de velocidad. Con el motor rápido, la primera petición tras un arranque tardó de 14,5 a 15,5 segundos en una detección que después tarda 1,9 segundos. Envía una petición de calentamiento antes del tráfico real.
Dónde no encaja: la ficha del modelo avisa de que los bordes finos de un recorte dependen de la resolución, las partes ocultas, la transparencia y la forma de pedirlo. Responde a una pregunta sobre una imagen, y el recortador rechaza el vídeo.
Qué GPU: todas las tareas en una tarjeta real de 16 GB, y los recortes necesitan más de 12 GB
La tarjeta más pequeña que pasó todas las tareas fue una RTX 5080 real con 16 GB, con el motor de referencia. Fue unas dos veces más lenta que el motor rápido de la 4090 en el recorte grande, y hasta unas cuatro veces en tareas de objetos. La tarjeta de 24 GB de nuestra ejecución principal es una elección por velocidad, no un requisito.
| Tarjeta | Montaje | Resultado |
|---|---|---|
| RTX 4090 24 GB, real | 4B, motor rápido más copia de referencia | 14 de 14, el más rápido |
| RTX 5080 16 GB, real | 4B, solo referencia | 14 de 14 |
| Unos 12,5 GB, emulada | 4B, solo referencia | 13 de 14: solo falla el recorte del retrato grande |
| 12 GB, emulada de forma estricta | 4B, solo referencia | Cajas, conteos, puntos y texto funcionan. Todos los contornos y recortes fallan |
Los resultados de 12 GB y 8 GB salen de limitar la memoria en la 4090, no de tarjetas reales de esos tamaños. Por debajo de 16 GB, el recortador es el muro. Pide unos 0,8 GB de golpe, sea cual sea el tamaño de la foto, así que con el límite estricto falló incluso con una foto de 640 píxeles. El modelo 2B con un límite de 8 GB pasó 12 de 14: el recorte grande se quedó sin memoria y una respuesta de posición de texto salió mal formada. También encontró 25 cajas en la cocina donde el 4B encontró 32. Sus recortes pequeños y el contorno de la bicicleta funcionaron, pero no comparamos su calidad con la del 4B, así que no hemos probado si el 2B saca recortes igual de limpios.
En InferenceKey: un endpoint para siete trabajos, respondiendo 87 segundos después de un arranque en limpio con 16 GB
Una RTX 5080 recién arrancada que nunca había visto el modelo ya respondía a los 87 segundos, descarga incluida. En una 4090 con el modelo ya en disco, el motor rápido estuvo listo en 49 a 82 segundos, y el de referencia en 14 a 15.
Servir todos los trabajos, recortador incluido, exige un backend a medida. Es un pequeño programa en Python que nuestra plataforma ejecuta en tu máquina con GPU en lugar de un servidor de modelos estándar. Un servidor estándar solo devolvería el texto, las cajas y los puntos del modelo. El recortador queda fuera de eso, así que el nuestro usa directamente el paquete de los autores, escribe con un motor y pinta con el otro. Cada respuesta vuelve como una imagen con las cajas dibujadas y las coordenadas en bruto para tu código, y, en contornos y recortes, un recorte con fondo transparente.
Si ejecutas el paquete de los autores en una tarjeta de 24 GB, te vas a encontrar con esto. Su configuración por defecto del motor rápido reserva sitio para diez imágenes y diez vídeos por petición. No queda nada para la memoria de trabajo del modelo, y el motor rápido se niega a arrancar. Nuestro ejemplo lo arregla dimensionando el motor rápido para una imagen y peticiones más cortas. También elige el motor según el tamaño de la tarjeta: el rápido con 22 GiB o más, el de referencia por debajo. La versión actual del ejemplo solo convierte en valores por defecto los que probamos. Esa versión exacta todavía no se ha ejecutado en una GPU. Las anteriores sí, con los mismos valores puestos a mano. El resto de problemas están en el apéndice.
¿Deberías usarlo? Sí para funciones de visión en una tarjeta de 16 GB, y comprueba tus conteos
- Ya ofreces detección, contornos o recortes: un modelo de 4B en una sola tarjeta los hizo todos en nuestra prueba. Revisa antes las líneas de uso previsto de la ficha del modelo.
- Necesitas conteos correctos: usa el motor de referencia, o compara antes el motor rápido con tus propias imágenes. En nuestro tablero de ajedrez, el motor lento fue el que acertó.
- Tienes una tarjeta de 16 GB: todas las tareas funcionaron en una RTX 5080 real. Con 12 GB, cuenta solo con cajas y texto.
- Necesitas velocidad: una tarjeta de 24 GB con el motor rápido da recortes en un segundo y búsquedas de menos de un segundo. Enviamos una petición cada vez y no probamos varios usuarios a la vez. Envía antes una petición de calentamiento.
Ejecuta python publish.py y después python main.py desde nuestro ejemplo del SDK de WeVisOne-VL-4B para tener los mismos siete trabajos detrás de una API en tu propio worker de NVIDIA. Necesita un .env rellenado y una tarjeta de 16 GB (24 GB para el motor rápido), y borra el despliegue al salir.
Para ingenieros
Modelo y ficheros
tencent/WeVisOne-VL-4B, sha4a7bed92750ac9d8b8a124cede14759036932dc2, creado el 2026-10-22T09:48Z, lastModified 2026-10-23, sin acceso restringido, licencia apache-2.0.model.safetensorsde 19.322.413.240 bytes, todo F32 (4.830.581.248 parámetros);mask_decoder.ptde 38.534.741 bytes, 9.609.764 parámetros.Qwen3VLForConditionalGeneration. ElLICENSEde HF lista Qwen3-VL-4B-Instruct (Alibaba Cloud, Apache-2.0, modificado por Tencent) como dependencia.tencent/WeVisOne-VL-2B, sha3dad9ce8bcb6fbe0aea945bf8860bd2cfc3663bf, creado el 2026-10-22T09:47Z:model.safetensorsde 9.767.053.328 bytes F32 (2.441.744.384 parámetros);mask_decoder.ptde 38.141.525 bytes, 9.511.460 parámetros; Apache-2.0.- Código:
Tencent/WeVisOne-VLen40f735b8(2026-10-23T10:35Z; publicación inicial23447828a las 08:14Z). Detección de licencia de GitHub:NOASSERTION, aunque el README declara el código de Tencent como Apache 2.0. Versiones fijadas: torch 2.11.0, transformers 5.12.1, vllm 0.23.0, triton 3.6.0, accelerate 1.14.0. - Demo alojada: https://huggingface.co/spaces/hugging-apps/wevisone-vl-4b
Cómo funciona la ruta de píxeles
- Las coordenadas son tokens del vocabulario de
<0>a<1000>(normalizadas). Caja = 4 tokens, punto = 2.Nonepara un objetivo ausente. Las tareas densas emiten<OBJ>(token ID 152678) después de cada caja. - Decodificador de píxeles: un Visual Feature Adapter sobre las features del ViT de Qwen3-VL antes del merge, de las capas 5, 11, 17 y 23; un Box-Guided Query Decoder (6 bloques de cross-attention deformable, inicializados a partir del hidden state de
<OBJ>más un prior de caja codificado con Fourier); un Instance-Conditioned Dense Head conFullCanvasAlphaCascadeHeadque refina S/4, S/2 y S/1 hasta un alfa a resolución completa. La entrada del decodificador se redimensiona a 1024 x 1024 (cnn_image_size1024). - API del paquete:
WeVisOneVL(model, backend="transformers"|"vllm", dtype="bfloat16", gpu_memory_utilization=0.45, max_model_len=8192, max_pixels=2025*32*32). Conbackend="vllm"creavllm.LLMconlimit_mm_per_promptimage 10 / video 10 y aun así carga el modelo completo de Transformers;decode_maskshace teacher forcing de la respuesta generada a través de él para capturar los hidden states de<OBJ>y las features del ViT. De ahí las dos copias de los pesos en la ruta de vLLM. - Tareas en
prompts.py:detection,referring,point,count_box,count_point,ocr,ocr_grounding,segmentation,matting, másvisual_promptyfreeform. - Limitaciones según la ficha: bordes alfa finos sensibles a la resolución, la oclusión, la transparencia y la redacción del prompt; sin chain-of-thought; percepción de imagen de un solo turno (el decodificador de píxeles rechaza las rejillas de vídeo). El paquete permite 10 imágenes por prompt; nuestro backend lo reduce a una.
- Entrenamiento (página del proyecto): SFT con currículo en tres etapas (90,2M, 40,5M y 41,8M muestras), después RL multitarea con GRPO (178K muestras), unos 100M de imágenes. SAM2 extiende las cajas verificadas a máscaras en el motor de datos. En inferencia, la página del proyecto dice: "No SAM, no external segmentation backbone: the pixel decoder reuses the VLM's own multi-level ViT features."
Cifras principales del 4B según los autores frente a la mejor referencia abierta de sus tablas (no reproducidas por nosotros): LVIS F1 55,3 (50,7), Dense200 71,3 (58,7), RefCOCOg 81,8 (77,6), rechazo en WeRef-Bench 96,4 (73,0), PixMo-Count 89,6 (82,8), PointBench 71,9 (69,9), TotalText 52,0 (43,3), ReasonSeg gIoU 71,2 (65,0), P3M-500-NP MAD 7,3 (15,4), WeRefMat referring MAD 9,8 (22,4). GroundingDINO-T: COCO 56,6, LVIS 38,8 (4B: 57,1 y 55,3). El 2B supera al 4B en P3M-500-NP (6,6 frente a 7,3) y en PPM-100.
Nuestro montaje
- GPU en nuestra nube: RTX 4090 de 24 GB (driver 595.91.07, CUDA 13.2) para las ejecuciones principales; RTX 5080 de 16 GB (driver 580.178.04, CUDA 13.0) para la comprobación con tarjeta real.
- Un manager local de InferenceKey (nunca producción) arrancó los dos workers. El workload se ejecutó como el backend a medida en Python
wevisone-vl-perception, llamado a través de/v1/images/generationsy del probador de imágenes del panel. - Motores (el motor rápido del artículo es vLLM, el de referencia es Transformers): vLLM 0.23.0 para el texto más una copia de Transformers 5.12.1 que alimenta
mask_decoder.pt, o Transformers solo. bf16 en todo.
Despliegue paso a paso
El ejemplo está en https://github.com/inferencekey/inferencekey-sdk/tree/main/examples/wevisone-vl-4b-perception-custom-backend-private-nvidia (commit e54c22cd22f710e981b22504031f57782c0a5a56): backend.py, requirements.txt, publish.py, main.py, README.md, .env.example.
Necesitas: INFERENCEKEY_SDK_TOKEN, INFERENCEKEY_API_KEY, INFERENCEKEY_PROJECT, IK_WORKER_ID (tu worker de NVIDIA) y, opcionalmente, INFERENCEKEY_TENANT_ID / INFERENCEKEY_USER_TOKEN para publish.py. En el worker: un driver de NVIDIA para CUDA 13.0 (580 o posterior), Python 3.12, 16 GB de VRAM para todas las tareas y 24 GB para el motor vLLM.
git clone https://github.com/inferencekey/inferencekey-sdk.git
cd inferencekey-sdk/examples/wevisone-vl-4b-perception-custom-backend-private-nvidia
cp .env.example .env # fill in tokens, project and worker id
python3 -m venv .venv && . .venv/bin/activate
pip install maturin requests
(cd ../../bindings/python && maturin develop --release)
python publish.py # packages and uploads the custom backend
python main.py # ensure -> wait_until_ready -> 8 requests -> delete
IK_KEEP_ALIVE=1 python main.py # same, but keeps the workload running
main.py despliega el workload WeVisOne-VL-4B con el slug del backend a medida, task_type text2image, ExecutionPolicy.FIXED con 1 réplica fijada a IK_WORKER_ID, ready_timeout_secs 2400, request_timeout_secs 600, y reenvía todas las variables WEVIS_* como env.
Para llamarlo (el ejemplo usa https://cloud.inferencekey.com por defecto cuando INFERENCEKEY_BASE_URL no está definida; el .env no se carga en tu shell, así que exporta lo que necesite la llamada):
set -a; . ./.env; set +a
export INFERENCEKEY_BASE_URL="${INFERENCEKEY_BASE_URL:-https://cloud.inferencekey.com}"
curl -s "$INFERENCEKEY_BASE_URL/endpoint/$INFERENCEKEY_PROJECT/wevisone-vl-4b/v1/images/generations" \
-H "Authorization: Bearer $INFERENCEKEY_API_KEY" \
-H "Content-Type: application/json" \
-d '{"task": "matting", "query": "person", "image": "https://example.com/photo.jpg"}'
image acepta una URL https, una data URL o base64. El probador del panel acepta un prompt con la forma task: query image_url, por ejemplo matting: person https://.../photo.jpg. La respuesta trae data[0] (JPEG anotado), data[1] (PNG RGBA del recorte, solo en segmentation y matting), predictions (cajas o puntos en píxeles por etiqueta), count, rejected, masks (máscaras alfa en PNG de escala de grises), timings y vram_peak_gib.
Entorno del backend (versión 0.1.3):
| Variable | Por defecto | Significado |
|---|---|---|
WEVIS_ENGINE | auto | vllm con 22 GiB o más de VRAM total, si no transformers |
WEVIS_MODEL | 4B | 4B o 2B, revisiones fijadas |
WEVIS_GPU_MEMORY_UTILIZATION | (9,4 + 1,75) / total, 0,465 con 24 GB | fracción de vLLM; 4,6 GiB de pesos para el 2B |
WEVIS_MAX_MODEL_LEN | 3072 | contexto de vLLM |
WEVIS_MAX_NUM_SEQS | 4 | concurrencia de vLLM |
WEVIS_VRAM_LIMIT_GIB | sin definir | límite de PyTorch para emular una tarjeta más pequeña |
WEVIS_MAX_PIXELS | 20253232 | límite de la imagen de entrada |
El backend también pone PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True. La versión 0.1.3 convierte en valores por defecto los que probamos por env; la 0.1.3 en sí no se ejecutó en una GPU (de la 0.1.0 a la 0.1.2 sí, con valores sobrescritos por env).
Tiempo hasta estar listo
- RTX 4090, primer arranque (0.1.0): venv del backend en unos 67 s, descarga de 18,0 GiB en 14 s, carga de pesos en vLLM 7,0 s (9,37 GiB),
torch.compile36 s, profiling de CUDA graphs 93 s, y después el fallo de la caché KV (problema 1). - RTX 4090 en caliente, motor vLLM: 82 s, 82 s, 49 s; reciclado en caliente con un paquete nuevo, 58 s.
- RTX 4090 en caliente, motor Transformers: de 14 a 15 s (carga 12,4 s). 2B: 21 s incluida su primera descarga de 9,8 GB.
- RTX 5080 en una máquina nueva, motor Transformers: 87 s (descarga 38,0 s, carga 16,9 s).
Mediciones completas
Tiempo de GPU dentro del backend. Las idas y vueltas añaden de 0,9 a 2,5 s (descarga de la imagen en el worker más la plataforma). Los ids de imagen de COCO, entre paréntesis.
| Petición | 4090 vLLM (util 0,465) | 4090 Transformers | 4090 TF, límite 11,5 GiB | 5080 16 GB TF | 2B TF, límite 7,2 GiB |
|---|---|---|---|---|---|
| detectar en cocina: person, pot, bottle, bowl, knife (397133) | 33 cajas; 14,5-15,5 s la primera llamada, 1,93 s en caliente | 32, 7,44 s | 32, 7,62 s | 32, 8,31 s | 25, 5,09 s |
| contar personas, tenis (1000) | 12, 0,78 s | 12, 2,68 s | 12, 2,68 s | 12, 2,77 s | 11, 1,97 s |
| referir: the cat on the right (39769) | 1 caja, 0,21 s | 0,55 s | 0,57 s | 0,68 s | 0,46 s |
| rechazar: the dog (misma foto) | None, 0,11 s | None, 0,36 s | None, 0,34 s | None, 0,47 s | None, 0,29 s |
| señalar: catcher (46252) | 1 punto, 0,16 s | 0,38 s | 0,38 s | 0,50 s | 0,30 s |
| OCR cartel de calle (252219) | 29 palabras, 3,69 s | 21, 9,13 s | 21, 9,05 s | 22, 9,49 s | 25, 8,91 s |
| segmentar: the blue bicycle (174482, 640x388) | 1,20-1,84 s | 0,89 s | 0,91 s | 1,21 s | 0,78 s |
| recorte: person (seabreeze.jpg de los autores, 1620x1080) | 0,97-1,11 s | 1,11 s | OOM | 2,05 s | OOM |
| recorte: the cat on the right | 0,38 s | 0,76 s | 0,84 s | 1,13 s | 0,66 s |
| recorte: skier (785) | 0,36 s | 0,65 s | 0,69 s | 0,99 s | 0,58 s |
| referir: boys holding microphone (boys.jpg de los autores) | 2 cajas, 0,53 s | 0,80 s | 0,80 s | 1,18 s | 0,63 s |
| contar: white chess pieces (chess.jpg de los autores, 16 reales) | 15, 1,35 s | 16, 3,87 s | 16, 3,70 s | 16, 4,20 s | 16, 2,78 s |
| OCR con posición: PROCTER (11197) | 1 caja, 0,20 s | 0,50 s | 0,50 s | 0,60 s | mal formada |
| contar: pots and pans hanging (397133) | 19, 1,11 s | 20, 4,12 s | 20, 4,20 s | 19, 4,11 s | 19, 3,10 s |
| pico de la tarjeta (nvidia-smi) | 23.539 MiB, 23,0 GiB (20.329 en reposo) | 12.546 MiB | unos 12,5 GB incl. contexto CUDA | 13.148 MiB | 7.242 MiB |
- La detección de 14,5 a 15,5 s es calentamiento: con el motor ya caliente y
max_new_tokens512 y 2048, las mismas 33 cajas tardaron 1,94 s y 1,93 s. - El tiempo de segmentación en vLLM se reparte en unos 0,19 s de texto y de 1,0 a 1,6 s de máscara; el recorte grande, en 0,53 a 0,64 s de texto y 0,44 a 0,48 s de máscara.
- Revisado a ojo: cajas de la cocina, gato, punto del receptor, bicicleta y recortes del retrato correctos; rechazo correcto en todas las configuraciones; ajedrez contado a mano (16), vLLM se dejó el caballo blanco de g5. Sin comprobar contra una referencia verificada: tenis (12), ollas (19 o 20) y el OCR del cartel (29, 21, 22 o 25 palabras, según el montaje).
- Idas y vueltas del probador del panel en la demo (motor vLLM): recorte 2.367 ms, conteo del ajedrez 2.140 ms, referring 1.087 ms.
Escalera de VRAM, cifras completas
| GPU o límite | Config | Pico | ¿Salida correcta? | Real o emulada |
|---|---|---|---|---|
| RTX 4090 24 GB | 4B, vLLM util 0,5 + copia de Transformers (backend 0.1.1) | OOM en el recorte de 1620x1080: Tried to allocate 768.00 MiB, 630,44 MiB libres (EngineCore 11,50 GiB + Transformers 11,39 GiB) | no, las otras 7 peticiones de main.py bien | real |
| RTX 4090 24 GB | 4B, vLLM util 0,465, max_model_len 3072, max_num_seqs 4 + copia de Transformers | 23.539 MiB | sí, 14/14 (ajedrez 15 de 16) | real |
| RTX 4090 24 GB | 4B, solo Transformers | 12.546 MiB | sí, 14/14 | real |
| RTX 5080 16 GB | 4B, solo Transformers | 13.148 MiB | sí, 14/14 | real |
| 12 GB (límite 11,5 GiB) | 4B, Transformers, WEVIS_VRAM_LIMIT_GIB=11.5 | unos 12,5 GB en la tarjeta incl. contexto CUDA | no, 13/14: OOM en el recorte grande Tried to allocate 768.00 MiB ... 11.27 GiB allowed | emulada, optimista |
| 12 GB estricto (límite 10,8 GiB) | 4B, Transformers, WEVIS_VRAM_LIMIT_GIB=10.8, WEVIS_MAX_PIXELS=1048576 | 11.026 MiB al fallar | no: tareas de objetos bien, OOM en la segmentación de una imagen de 640x388 (768 MiB), sin máscaras | emulada |
| 8 GB (límite 7,2 GiB) | 2B, Transformers, WEVIS_MODEL=tencent/WeVisOne-VL-2B | 7.242 MiB | no, 12/14: OOM en el recorte grande, OCR con posición <ref>PROCTER</ref><box><368><0><1000></ref></box>; detección 25 frente a 32, tenis 11 frente a 12 | emulada |
Los límites solo restringen las reservas de PyTorch; emulan la memoria, no el cómputo ni el ancho de banda de una tarjeta más pequeña, y el contexto CUDA queda fuera de ellos. Sin probar: tarjetas reales de 12 GB u 8 GB, fp8 o int8, descarga a CPU.
Problemas encontrados
- La configuración de vLLM de los autores no deja caché KV en 24 GB.
Encoder cache will be initialized with a budget of 16384 tokens, despuésAvailable KV cache memory: -0.87 GiByValueError: No available memory for the cache blockscon util 0,471. Arreglado en el backend envolviendovllm.LLM:limit_mm_per_promptuna imagen al límite de entrada, video 0, tamaño enmm_processor_kwargs,max_model_len,max_num_seqs4. - Dos copias de los pesos en 24 GB van justas. Con util 0,5 el recorte grande se quedó sin memoria (ver la escalera). Util 0,465 con
max_model_len4096 dio0.56 GiB KV cache is needed, which is larger than the available KV cache memory (0.44 GiB); 3072 funciona. Arreglado con los valores por defecto. - Los resultados de más de 8 MB se descartan y quien llama espera hasta un 504. Worker:
job result refused by JetStream for good (code max_payload: ... exceeded by message size of 9145132); cliente:504 ... inference_timeout. El worker vuelve a codificar en base64 el JSON del backend en la ruta de imágenes (x1,33). Arreglado en el backend (overlay en JPEG, recorte de 1280 px, presupuesto de 5,2 MB). Abierto en el lado de la plataforma: el worker sabe que el resultado se rechazó, pero el cliente sigue esperando el timeout completo. - Los motores no coinciden en algunas respuestas. Ajedrez 15 frente a 16, OCR 29 frente a 21 palabras, ollas 19 frente a 20. Greedy en los dos. Abierto, inherente a los dos motores; elige el motor según el caso de uso.
- La primera petición de vLLM tras un arranque es lenta (de 14,5 a 15,5 s para una detección de 1,9 s). Envía una petición de calentamiento.
- El empaquetador del SDK no tiene
image2image.PackagingError: unknown task_type 'image2image'; expected one of ('text2text', 'embedding', 'text2image', ...), aunque el manager lo acepta. El backend declaratext2image, que solo selecciona la ruta de imágenes. Abierto. - El probador del panel solo envía un prompt (más los campos de tamaño, pasos y guidance, que este modelo ignora), así que el backend extrae
task: query urlde él. - Nuestros errores. La ejecución 3 falló porque
main.pyno reenviabaWEVIS_MAX_MODEL_LEN(arreglado).
Resto de muestras
Todas de la ejecución con vLLM en la RTX 4090. Usan fotos de COCO val2017 (Flickr, licencias Creative Commons variadas, algunas no comerciales).
Vídeo de demo
Demo de despliegue narrada, 99,6 s, 1920 x 1080: el workload en una RTX 4090, después un recorte de retrato (2.367 ms de ida y vuelta), el conteo del ajedrez con el caballo que falta a la vista (2.140 ms) y "boys holding microphone" (1.087 ms) desde el probador de imágenes del panel.
Fuentes
- Fichas del modelo: https://huggingface.co/tencent/WeVisOne-VL-4B y https://huggingface.co/tencent/WeVisOne-VL-2B (README,
LICENSE,config.json, API de HF con blobs) - Código: https://github.com/Tencent/WeVisOne-VL en
40f735b8(README,engine.py,prompts.py,requirements.txt,configs/wevisone_vl_v1_decoder.json) - Página del proyecto: https://tencent.github.io/WeVisOne-VL/
- Dónde lo vimos: AI Search, https://www.youtube.com/watch?v=EfyQOAJjx1A (25 de octubre de 2026, capítulo de 01:01 a 03:10)
- Imágenes de prueba: los ejemplos de los autores (seabreeze, chess, boys) y COCO val2017
- Nuestro ejemplo del SDK: https://github.com/inferencekey/inferencekey-sdk/tree/main/examples/wevisone-vl-4b-perception-custom-backend-private-nvidia