WeVisOne-VL-4B findet, zählt und stellt Objekte mit einem einzigen Modell frei, und jede Aufgabe lief auf einer echten 16-GB-Karte

Tencents WeVisOne-VL-4B in unserer Cloud: Boxen, Zählen, OCR und haargenaue Freisteller mit einem Modell, 1 s pro Matte (RTX 4090), alle 7 Aufgaben auf 16 GB.

Veröffentlicht am · Von InferenceKey · 10 Min. Lesezeit + technischer Anhang

Auf dem Schachbrett in Tencents eigenem Beispielordner stehen sechzehn weiße Figuren. WeVisOne-VL-4B, zweimal mit demselben Prompt auf einer RTX 4090 gestartet, antwortete einmal 15 in 1,35 Sekunden und einmal 16 in 3,87 Sekunden. Die schnelle Antwort hat den Springer auf g5 übersehen. Dasselbe Modell, zwei Arten, es laufen zu lassen, und genau diese Lücke ist die Entscheidung, die vor dir liegt, bevor du es hinter ein Produkt stellst. Nimm die schnelle Variante und prüf ihre Zählungen, oder die langsame, die außerdem auf eine 16-GB-Karte passt. So oder so hat ein einziges offenes Modell mit 4 Milliarden Parametern benannte Objekte gefunden, sie gezählt, auf Dinge gezeigt, Text gelesen und eine Person bis aufs Haar aus einem Foto ausgeschnitten. Seine Autoren bewerben es als All-in-one. Um es hinter einer API zu betreiben, braucht es ein Custom Backend, und unseres ist am Ende verlinkt.

Das Schachfoto der Autoren, zweimal von WeVisOne-VL-4B auf einer RTX 4090 mit dem Prompt 'count the white chess pieces' gezählt, 16 stehen auf dem Brett. Links die schnelle Engine, 1,35 Sekunden, Antwort 15, falsch: ein roter Kasten und ein Pfeil mit der Beschriftung 'missed: white knight' markieren den weißen Springer auf g5, der keine Box hat. Rechts die Referenz-Engine, 3,87 Sekunden, Antwort 16, richtig: ein grüner Kasten markiert denselben Springer, jetzt erkannt

Gleiches Modell, gleiches Foto, gleicher Prompt. Die schnelle Engine (links) ist hier etwa dreimal flotter und hat eine Figur übersehen. Rechts die Referenz-Engine.

Drei Zahlen aus unserem Test von WeVisOne-VL-4B auf InferenceKey Cloud: 1,0 Sekunden für eine Alpha-Matte in voller Auflösung eines Fotos mit 1620 mal 1080 auf einer RTX 4090; 12,8 GiB Spitze im Kartenspeicher bei 14 von 14 Anfragen auf einer echten RTX 5080 mit 16 GB; 12 GB, wo Freisteller aufhören, weil unter einer strengen emulierten Grenze von 12 GB jede Maske scheiterte

Ein 4B-Modell übernimmt die Jobs von Detektor, Segmentierer und Freistell-Tool

WeVisOne-VL ("WeChat Vision All-in-One") packt in ein Modell, wofür man normalerweise eine Kette aus drei braucht. Das erste zieht Boxen um Dinge, die du benennst, zum Beispiel GroundingDINO, mit dem sich die Autoren vergleichen. Ein zweites, etwa SAM2, macht aus jeder Box einen Umriss. Ein drittes erstellt einen weichen Freisteller, die Art, die lose Haare und Kanten behält. Jedes davon ist ein eigener Download, eigener Speicher und eine eigene Art, kaputtzugehen.

Das WeChat-Vision-Team bei Tencent hat es auf einem offenen Modell von Alibaba aufgebaut. Laut Model Card findet es alles, was du benennen kannst, oder ein einzelnes beschriebenes Ding wie "the cat on the right" (die Katze rechts). Außerdem zählt es, zeigt auf Dinge, liest Text samt Position, zeichnet Umrisse und erstellt Freisteller.

Das Modell schreibt, ein kleiner Cutter zeichnet. WeVisOne-VL antwortet in Text, und eine Position ist einfach noch mehr Text. Die Autoren haben 1.001 Spezialwörter hinzugefügt, <0> bis <1000>, jedes eine Position über die Breite oder Höhe des Bildes. Eine Box sind vier dieser Wörter, ein Punkt zwei. Für Umrisse und Freisteller markiert es jede Box, und ein winziges separates Programm liest, was das Modell zu dieser Markierung gesehen hat, und malt die Pixel. Dieser Cutter hat 9,6 Millionen Parameter, etwa 500-mal weniger als das Modell neben ihm. Die Projektseite sagt, dass kein separates Umriss-Tool nötig ist, weil der Cutter wiederverwendet, was das Modell gesehen hat.

Das Team hat es mit etwa 100 Millionen Bildern trainiert und SAM2 nur benutzt, um die Trainingsumrisse zu zeichnen, nicht zur Laufzeit. Veröffentlicht haben sie das 4B und ein 2B, mit einem Code-Paket, das beide ausführt. Die Hugging-Face-Repos wurden am 22. Oktober 2026 angelegt, und der öffentliche Release-Commit des Codes ist auf den 23. Oktober datiert. Wir haben es im News-Video von AI Search vom 25. Oktober entdeckt.

Die Autoren berichten, dass das 4B bei mehr als 30 Benchmarks vorn liegt. In ihrem Test zum Finden benannter Objekte erreicht es 55,3 von 100, GroundingDINO 38,8. Bei Porträt-Freistellern ist sein Fehler halb so groß wie der eines Setups auf Basis von SAM2 (7,3 gegen 15,4). Die Idee "ersetzt drei Modelle" stützt sich auf diese Tabellen, nicht auf einen direkten Vergleich, den wir selbst gefahren hätten.

Die Gewichte auf Hugging Face stehen unter Apache 2.0, was kommerzielle Nutzung erlaubt. Die Model Card ergänzt, das Release sei "intended for research" und "not intended to make autonomous high-impact decisions or to identify individuals". Unsere Lesart: Die Apache-Freigabe ist die Lizenz, die Zeilen zum vorgesehenen Einsatz sind eine Orientierung, und die Zeile zur Identifizierung von Personen zählt, wenn dein Produkt mit Gesichtern arbeitet.

Der Test: Das Modell passt in etwa 10 GB, und das schnelle Setup hält es doppelt

Das schnelle Setup hält das Modell zweimal auf einer Karte. Die veröffentlichte Datei hat 19,3 GB, weil sie jede Zahl in voller Präzision speichert. Wir haben sie in halber Präzision geladen, wie man ein Modell üblicherweise serviert, und damit kommt sie auf etwa 10 GB. Das Code-Paket kann es auf zwei Arten laufen lassen: mit einer schnellen Engine, die fürs Serving gebaut ist, und mit der schlichten Referenz-Engine. Selbst wenn die schnelle Engine die Antwort schreibt, hält das Paket eine zweite Kopie in der Referenz-Engine, um den Cutter zu füttern.

Wir haben das 4B über unsere Plattform deployt und ihm in jedem Setup dieselben 14 Anfragen geschickt, ein Bild nach dem anderen. Sie decken sieben Arten von Jobs ab: mehrere benannte Dinge finden, zählen, ein beschriebenes Ding finden (und ein fehlendes ablehnen), zeigen, Text lesen, umreißen und freistellen. Die Bilder sind die eigenen Beispiele der Autoren plus öffentliche Fotos. Die meisten Läufe nutzten eine RTX 4090 mit 24 GB Speicher, und eine echte RTX 5080 mit 16 GB hat geprüft, ob eine kleinere Karte mithält.

Ergebnisse: ein Freisteller in voller Auflösung in etwa einer Sekunde, und 'nichts da', wenn nichts da ist

Der Freisteller ist die Schlagzeile. Ein Porträt mit 1620 x 1080 aus den Beispielen der Autoren kam als Freisteller in voller Auflösung zurück, und die windzerzausten Haarsträhnen bleiben erhalten.

Freisteller von WeVisOne-VL-4B aus dem Seabreeze-Porträt der Autoren auf einer RTX 4090. Links das Foto mit der Personen-Box und der Maske in Rosa. Rechts der Freisteller auf einem Transparenz-Schachbrettmuster, die windzerzausten Haarsträhnen sind erhalten

Der Rest, in den Zeiten, die ein Mensch spürt:

JobRTX 4090, schnellRTX 4090, ReferenzRTX 5080 16 GB, Referenz
Eine Person freistellen, 1620 x 10801,0 s1,1 s2,1 s
"the cat on the right" finden0,21 s0,55 s0,68 s
12 Personen zählen0,78 s2,7 s2,8 s
Ein Straßenschild lesen (gefundene Wörter)3,7 s (29)9,1 s (21)9,5 s (22)
5 Arten von Objekten in einer Küche finden1,9 s7,4 s8,3 s
Spitze im Kartenspeicher (GiB)23,012,312,8

Zeit auf der Karte, aus unseren Logs. Speicher in GiB, der Einheit, die die Anzeige der Karte selbst nutzt. Wie viele Wörter auf dem Schild gefunden werden, hängt vom Setup ab.

Wir haben in einem Foto von Katzen nach "the dog" gefragt. Das Modell antwortete in jedem Setup, das wir gefahren sind, dass es keinen gibt, auf dem einen Foto, das wir probiert haben, in 0,11 Sekunden auf der schnellen Engine. Ein Detektor, der einen Hund erfindet, wo keiner ist, ist genau der Bug, nach dem ein Produktteam dem Feature nicht mehr traut.

Auf dem Foto der Autoren mit Jungen, die Mikrofone halten, hat es beide Sänger mit einer Box markiert. Die Küchen-Boxen, der Punkt auf dem Baseball-Catcher, der Fahrradumriss und die Freisteller von Porträt und Katze waren richtig, als wir sie mit bloßem Auge geprüft haben. Die Zählung von 12 Tennisspielern haben wir nicht gegen eine Ground Truth geprüft.

WeVisOne-VL-4B findet 'boys holding microphone' im Beispielfoto der Autoren: zwei Boxen, eine auf jedem Sänger

Die schnelle Engine ist bei Objekt-Jobs etwa dreimal schneller, und beim Schachbrett lag sie falsch

Bei Objekt-Jobs ist die schnelle Engine anderthalb- bis viermal schneller, meist etwa dreimal. Bei Freistellern ist das Bild gemischt. Der Fahrradumriss war auf der schnellen Engine langsamer (1,2 bis 1,8 Sekunden gegen 0,9).

Beide Engines nutzten Greedy-Decoding, das Verfehlen beim Schachbrett ist also kein Zufallsrauschen aus dem Sampling. Die wahrscheinliche Ursache: Die Rechnerei auf unterster Ebene unterscheidet sich leicht zwischen den beiden Programmen, und eine Box auf der Kippe ist auf die andere Seite gefallen. Uneinig waren sie sich auch beim Straßenschild (29 Wörter gegen 21) und bei hängenden Töpfen und Pfannen (19 gegen 20). Ein Fehler in 14 Anfragen ist keine Quote. Er ist ein Grund, deine eigenen Bilder auf der Engine zu testen, die du ausliefern wirst, so wie du den Soundcheck auf der PA machst, über die du dann tatsächlich spielst.

Es gibt noch eine Tempofalle. Auf der schnellen Engine brauchte die allererste Anfrage nach einem Start 14,5 bis 15,5 Sekunden für eine Erkennung, die danach 1,9 Sekunden dauert. Schick vor dem echten Traffic eine Warm-up-Anfrage.

Wo es nicht passt: Die Model Card warnt, dass feine Kanten in einem Freisteller von Auflösung, verdeckten Teilen, Transparenz und Formulierung abhängen. Es beantwortet eine Frage zu einem Bild, und der Cutter lehnt Video ab.

Welche GPU: jede Aufgabe auf einer echten 16-GB-Karte, und Freisteller brauchen mehr als 12 GB

Die kleinste Karte, die jede Aufgabe bestanden hat, war eine echte RTX 5080 mit 16 GB, mit der Referenz-Engine. Beim großen Freisteller brauchte sie etwa doppelt so lange wie die schnelle Engine der 4090, bei Objekt-Jobs bis zu etwa viermal so lange. Die 24-GB-Karte unseres Hauptlaufs ist eine Tempo-Entscheidung, keine Voraussetzung.

KarteSetupErgebnis
RTX 4090 24 GB, echt4B, schnelle Engine plus Referenzkopie14 von 14, die schnellste
RTX 5080 16 GB, echt4B, nur Referenz14 von 14
Etwa 12,5 GB, emuliert4B, nur Referenz13 von 14: nur der große Porträt-Freisteller scheitert
12 GB, streng emuliert4B, nur ReferenzBoxen, Zählen, Punkte und Text funktionieren. Jeder Umriss und jeder Freisteller scheitert

Die Ergebnisse für 12 GB und 8 GB stammen aus einer Speichergrenze auf der 4090, nicht von echten Karten dieser Größe. Unter 16 GB ist der Cutter die Wand. Er greift sich etwa 0,8 GB auf einen Schlag, egal wie groß das Foto ist, deshalb scheiterte er unter der strengen Grenze sogar an einem Foto mit 640 Pixeln. Das 2B-Modell bestand unter einer Grenze von 8 GB 12 von 14: Beim großen Freisteller ging der Speicher aus, und eine Antwort mit Textposition kam fehlerhaft zurück. Außerdem fand es in der Küche 25 Boxen, wo das 4B 32 fand. Seine kleinen Freisteller und der Fahrradumriss funktionierten, aber wir haben ihre Qualität nicht mit dem 4B verglichen, also ist ungetestet, ob das 2B die Freisteller genauso sauber hinbekommt.

Auf InferenceKey: ein Endpoint für sieben Jobs, antwortbereit 87 Sekunden nach einem frischen Start auf 16 GB

Eine frische RTX 5080, die das Modell nie gesehen hatte, antwortete nach 87 Sekunden, Download inklusive. Auf einer 4090 mit dem Modell schon auf der Platte war die schnelle Engine in 49 bis 82 Sekunden bereit, die Referenz-Engine in 14 bis 15.

Um jeden Job zu servieren, Cutter inklusive, braucht es ein Custom Backend. Das ist ein kleines Python-Programm, das unsere Plattform auf deiner GPU-Maschine statt eines Standard-Modellservers ausführt. Ein Standard-Server würde nur den Text, die Boxen und die Punkte des Modells zurückgeben. Der Cutter liegt außerhalb davon, deshalb steuert unseres das Paket der Autoren direkt, schreibt mit der einen Engine und malt mit der anderen. Jede Antwort kommt als Bild mit eingezeichneten Boxen und den rohen Koordinaten für deinen Code zurück, plus, bei Umrissen und Freistellern, einem Freisteller mit transparentem Hintergrund.

Wenn du das Paket der Autoren auf einer 24-GB-Karte laufen lässt, stößt du darauf. Seine Standardeinstellungen für die schnelle Engine reservieren Platz für zehn Bilder und zehn Videos pro Anfrage. Für den Arbeitsspeicher des Modells bleibt nichts übrig, und die schnelle Engine verweigert den Start. Unser Beispiel behebt das, indem es die schnelle Engine auf ein Bild und kürzere Anfragen auslegt. Außerdem wählt es die Engine nach Kartengröße: schnell ab 22 GiB, darunter Referenz. Die aktuelle Version des Beispiels macht nur die Werte, die wir getestet haben, zu Standardwerten. Genau diese Version ist noch nicht auf einer GPU gelaufen. Die früheren schon, mit denselben Werten von Hand gesetzt. Die anderen Probleme stehen im Anhang.

Solltest du es nutzen? Ja für Vision-Features auf einer 16-GB-Karte, und teste deine Zählungen

  • Du lieferst heute Erkennung, Umrisse oder Freisteller aus: Ein 4B-Modell auf einer Karte hat in unserem Test alles davon erledigt. Prüf vorher die Zeilen der Model Card zum vorgesehenen Einsatz.
  • Du brauchst Zählungen, die stimmen: Nimm die Referenz-Engine, oder prüf die schnelle Engine vorher mit deinen eigenen Bildern. Auf unserem Schachbrett lag die langsame Engine richtig.
  • Du hast eine 16-GB-Karte: Jede Aufgabe lief auf einer echten RTX 5080. Mit 12 GB plan nur Boxen und Text ein.
  • Du brauchst Tempo: Eine 24-GB-Karte mit der schnellen Engine liefert Freisteller in einer Sekunde und Funde in unter einer Sekunde. Wir haben eine Anfrage nach der anderen geschickt und nicht mehrere Nutzer gleichzeitig getestet. Schick zuerst eine Warm-up-Anfrage.

Führ python publish.py und dann python main.py aus unserem SDK-Beispiel für WeVisOne-VL-4B aus, und du hast dieselben sieben Jobs hinter einer API auf deinem eigenen NVIDIA-Worker. Es braucht eine ausgefüllte .env und eine 16-GB-Karte (24 GB für die schnelle Engine), und es löscht das Deployment beim Beenden.

Für Ingenieure

Modell und Dateien

  • tencent/WeVisOne-VL-4B, sha 4a7bed92750ac9d8b8a124cede14759036932dc2, angelegt 2026-10-22T09:48Z, lastModified 2026-10-23, nicht gated, Lizenz apache-2.0. model.safetensors 19.322.413.240 Bytes, alles F32 (4.830.581.248 Parameter); mask_decoder.pt 38.534.741 Bytes, 9.609.764 Parameter. Qwen3VLForConditionalGeneration. Die LICENSE auf HF führt Qwen3-VL-4B-Instruct (Alibaba Cloud, Apache-2.0, von Tencent modifiziert) als Abhängigkeit auf.
  • tencent/WeVisOne-VL-2B, sha 3dad9ce8bcb6fbe0aea945bf8860bd2cfc3663bf, angelegt 2026-10-22T09:47Z: model.safetensors 9.767.053.328 Bytes F32 (2.441.744.384 Parameter); mask_decoder.pt 38.141.525 Bytes, 9.511.460 Parameter; Apache-2.0.
  • Code: Tencent/WeVisOne-VL bei 40f735b8 (2026-10-23T10:35Z; erstes Release 23447828 um 08:14Z). Lizenzerkennung von GitHub: NOASSERTION, obwohl das README Tencents Code als Apache 2.0 deklariert. Pins: torch 2.11.0, transformers 5.12.1, vllm 0.23.0, triton 3.6.0, accelerate 1.14.0.
  • Gehostete Demo: https://huggingface.co/spaces/hugging-apps/wevisone-vl-4b

Wie der Pixelpfad funktioniert

  • Koordinaten sind Vokabular-Tokens <0> bis <1000> (normalisiert). Box = 4 Tokens, Punkt = 2. None für ein fehlendes Ziel. Dichte Aufgaben geben nach jeder Box <OBJ> (Token-ID 152678) aus.
  • Pixel-Decoder: ein Visual Feature Adapter über die Qwen3-VL-ViT-Features vor dem Merge aus den Layern 5, 11, 17 und 23; ein Box-Guided Query Decoder (6 Blöcke mit deformierbarer Cross-Attention, initialisiert aus dem Hidden State von <OBJ> plus einem Fourier-kodierten Box-Prior); ein Instance-Conditioned Dense Head mit FullCanvasAlphaCascadeHead, der S/4, S/2, S/1 bis zu Alpha in voller Auflösung verfeinert. Decoder-Eingabe auf 1024 x 1024 skaliert (cnn_image_size 1024).
  • Paket-API: WeVisOneVL(model, backend="transformers"|"vllm", dtype="bfloat16", gpu_memory_utilization=0.45, max_model_len=8192, max_pixels=2025*32*32). Mit backend="vllm" erzeugt es vllm.LLM mit limit_mm_per_prompt image 10 / video 10 und lädt trotzdem das volle Transformers-Modell; decode_masks schickt die generierte Antwort per Teacher Forcing hindurch, um die Hidden States von <OBJ> und die ViT-Features abzugreifen. Daher zwei Kopien der Gewichte auf dem vLLM-Pfad.
  • Aufgaben in prompts.py: detection, referring, point, count_box, count_point, ocr, ocr_grounding, segmentation, matting, plus visual_prompt und freeform.
  • Einschränkungen laut Model Card: feine Alpha-Grenzen empfindlich gegenüber Auflösung, Verdeckung, Transparenz und Prompt-Formulierung; kein Chain-of-Thought; Bildwahrnehmung in einem einzigen Durchgang (Video-Grids lehnt der Pixel-Decoder ab). Das Paket erlaubt 10 Bilder pro Prompt; unser Backend kürzt das auf eins.
  • Training (Projektseite): dreistufiges Curriculum-SFT (90,2M, 40,5M, 41,8M Samples), dann Mixed-Task-RL mit GRPO (178K Samples), etwa 100M Bilder. SAM2 erweitert in der Data Engine verifizierte Boxen zu Masken. Zur Inferenz sagt die Projektseite: "No SAM, no external segmentation backbone: the pixel decoder reuses the VLM's own multi-level ViT features."

Die Spitzenwerte der Autoren für das 4B gegen die beste offene Baseline in ihren Tabellen (von uns nicht reproduziert): LVIS F1 55,3 (50,7), Dense200 71,3 (58,7), RefCOCOg 81,8 (77,6), WeRef-Bench Ablehnung 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, 55,3). Das 2B schlägt das 4B bei P3M-500-NP (6,6 gegen 7,3) und PPM-100.

Unser Setup

  • GPUs in unserer Cloud: RTX 4090 24 GB (Treiber 595.91.07, CUDA 13.2) für die Hauptläufe; RTX 5080 16 GB (Treiber 580.178.04, CUDA 13.0) für den Check mit echter Karte.
  • Ein lokaler InferenceKey-Manager (nie Produktion) hat beide Worker gebootstrappt. Der Workload lief als Custom Python Backend wevisone-vl-perception, aufgerufen über /v1/images/generations und den Bildtester des Panels.
  • Engines (die schnelle Engine im Text ist vLLM, die Referenz-Engine ist Transformers): vLLM 0.23.0 für den Text plus eine Transformers-5.12.1-Kopie, die mask_decoder.pt füttert, oder Transformers allein. Durchgehend bf16.

Deployment Schritt für Schritt

Das Beispiel liegt unter 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.

Benötigt: INFERENCEKEY_SDK_TOKEN, INFERENCEKEY_API_KEY, INFERENCEKEY_PROJECT, IK_WORKER_ID (dein NVIDIA-Worker), optional INFERENCEKEY_TENANT_ID / INFERENCEKEY_USER_TOKEN für publish.py. Auf dem Worker: ein NVIDIA-Treiber für CUDA 13.0 (580 oder neuer), Python 3.12, 16 GB VRAM für jede Aufgabe, 24 GB für die vLLM-Engine.

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 deployt den Workload WeVisOne-VL-4B mit dem Slug des Custom Backends, task_type text2image, ExecutionPolicy.FIXED mit 1 Replica, festgelegt auf IK_WORKER_ID, ready_timeout_secs 2400, request_timeout_secs 600, und reicht jede WEVIS_*-Variable als env weiter.

Aufruf (das Beispiel fällt auf https://cloud.inferencekey.com zurück, wenn INFERENCEKEY_BASE_URL nicht gesetzt ist; .env wird nicht in deine Shell geladen, also exportier, was der Aufruf braucht):

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 nimmt eine https-URL, eine Data-URL oder Base64. Der Tester im Dashboard nimmt einen Prompt in der Form task: query image_url, zum Beispiel matting: person https://.../photo.jpg. Die Antwort enthält data[0] (annotiertes JPEG), data[1] (RGBA-Freisteller als PNG, nur bei Segmentierung und Matting), predictions (Pixel-Boxen oder Punkte nach Label), count, rejected, masks (Graustufen-PNG-Matten), timings und vram_peak_gib.

Backend-Umgebung (Version 0.1.3):

VariableStandardBedeutung
WEVIS_ENGINEautovllm ab 22 GiB VRAM insgesamt, sonst transformers
WEVIS_MODEL4B4B oder 2B, festgelegte Revisionen
WEVIS_GPU_MEMORY_UTILIZATION(9,4 + 1,75) / gesamt, 0.465 auf 24 GBAnteil von vLLM; 4,6 GiB Gewichte beim 2B
WEVIS_MAX_MODEL_LEN3072Kontext von vLLM
WEVIS_MAX_NUM_SEQS4Parallelität von vLLM
WEVIS_VRAM_LIMIT_GIBnicht gesetztPyTorch-Grenze, um eine kleinere Karte zu emulieren
WEVIS_MAX_PIXELS20253232Obergrenze fürs Eingabebild

Das Backend setzt außerdem PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True. Version 0.1.3 macht die Werte, die wir per env getestet haben, zu Standardwerten; 0.1.3 selbst lief nicht auf einer GPU (0.1.0 bis 0.1.2 schon, mit env-Overrides).

Zeit bis bereit

  • RTX 4090, erster Start (0.1.0): venv des Backends etwa 67 s, Download von 18,0 GiB in 14 s, Laden der vLLM-Gewichte 7,0 s (9,37 GiB), torch.compile 36 s, Profiling der CUDA-Graphen 93 s, dann der Fehler beim KV-Cache (Problem 1).
  • RTX 4090 warm, vLLM-Engine: 82 s, 82 s, 49 s; Hot Recycle auf ein neues Paket 58 s.
  • RTX 4090 warm, Transformers-Engine: 14 bis 15 s (Laden 12,4 s). 2B: 21 s inklusive seines ersten Downloads von 9,8 GB.
  • RTX 5080, frische Maschine, Transformers-Engine: 87 s (Download 38,0 s, Laden 16,9 s).

Vollständige Messungen

GPU-Zeit im Backend. Round Trips kommen mit 0,9 bis 2,5 s dazu (Bild-Download auf dem Worker plus die Plattform). COCO-Bild-IDs in Klammern.

Anfrage4090 vLLM (util 0.465)4090 Transformers4090 TF, Grenze 11,5 GiB5080 16 GB TF2B TF, Grenze 7,2 GiB
Erkennung Küche: person, pot, bottle, bowl, knife (397133)33 Boxen; 14,5-15,5 s erster Aufruf, 1,93 s warm32, 7,44 s32, 7,62 s32, 8,31 s25, 5,09 s
Zählen people, Tennis (1000)12, 0,78 s12, 2,68 s12, 2,68 s12, 2,77 s11, 1,97 s
Refer: the cat on the right (39769)1 Box, 0,21 s0,55 s0,57 s0,68 s0,46 s
Ablehnung: the dog (gleiches Foto)None, 0,11 sNone, 0,36 sNone, 0,34 sNone, 0,47 sNone, 0,29 s
Punkt: catcher (46252)1 Punkt, 0,16 s0,38 s0,38 s0,50 s0,30 s
OCR Straßenschild (252219)29 Wörter, 3,69 s21, 9,13 s21, 9,05 s22, 9,49 s25, 8,91 s
Segmentierung: the blue bicycle (174482, 640x388)1,20-1,84 s0,89 s0,91 s1,21 s0,78 s
Matte: person (seabreeze.jpg der Autoren, 1620x1080)0,97-1,11 s1,11 sOOM2,05 sOOM
Matte: the cat on the right0,38 s0,76 s0,84 s1,13 s0,66 s
Matte: skier (785)0,36 s0,65 s0,69 s0,99 s0,58 s
Refer: boys holding microphone (boys.jpg der Autoren)2 Boxen, 0,53 s0,80 s0,80 s1,18 s0,63 s
Zählen: white chess pieces (chess.jpg der Autoren, 16 korrekt)15, 1,35 s16, 3,87 s16, 3,70 s16, 4,20 s16, 2,78 s
OCR Grounding: PROCTER (11197)1 Box, 0,20 s0,50 s0,50 s0,60 sfehlerhaft
Zählen: pots and pans hanging (397133)19, 1,11 s20, 4,12 s20, 4,20 s19, 4,11 s19, 3,10 s
Spitze der Karte (nvidia-smi)23.539 MiB, 23,0 GiB (20.329 im Leerlauf)12.546 MiBetwa 12,5 GB inkl. CUDA-Kontext13.148 MiB7.242 MiB
  • Die Erkennung mit 14,5 bis 15,5 s ist Warm-up: Auf der warmen Engine brauchten dieselben 33 Boxen mit max_new_tokens 512 und 2048 1,94 s und 1,93 s.
  • Die Segmentierungszeit von vLLM teilt sich in etwa 0,19 s Text und 1,0 bis 1,6 s Maske auf; die große Matte in 0,53 bis 0,64 s Text und 0,44 bis 0,48 s Maske.
  • Mit bloßem Auge geprüft: Küchen-Boxen, Katze, Catcher-Punkt, Fahrrad- und Porträt-Matten korrekt; Ablehnung in jeder Konfiguration korrekt; Schach von Hand gezählt (16), vLLM übersah den weißen Springer auf g5. Nicht gegen Ground Truth geprüft: Tennis (12), Töpfe (19 oder 20) und das OCR des Straßenschilds (29, 21, 22 oder 25 Wörter, je nach Setup).
  • Round Trips im Panel-Tester in der Demo (vLLM-Engine): Matting 2.367 ms, Schach-Zählung 2.140 ms, Referring 1.087 ms.

VRAM-Leiter, vollständige Zahlen

GPU oder GrenzeKonfigurationSpitzeAusgabe OK?Echt oder emuliert
RTX 4090 24 GB4B, vLLM util 0.5 + Transformers-Kopie (Backend 0.1.1)Matte 1620x1080 OOM: Tried to allocate 768.00 MiB, 630,44 MiB frei (EngineCore 11,50 GiB + Transformers 11,39 GiB)nein, die anderen 7 Anfragen von main.py OKecht
RTX 4090 24 GB4B, vLLM util 0.465, max_model_len 3072, max_num_seqs 4 + Transformers-Kopie23.539 MiBja, 14/14 (Schach 15 von 16)echt
RTX 4090 24 GB4B, nur Transformers12.546 MiBja, 14/14echt
RTX 5080 16 GB4B, nur Transformers13.148 MiBja, 14/14echt
12 GB (Grenze 11,5 GiB)4B, Transformers, WEVIS_VRAM_LIMIT_GIB=11.5etwa 12,5 GB auf der Karte inkl. CUDA-Kontextnein, 13/14: große Matte OOM Tried to allocate 768.00 MiB ... 11.27 GiB allowedemuliert, optimistisch
12 GB streng (Grenze 10,8 GiB)4B, Transformers, WEVIS_VRAM_LIMIT_GIB=10.8, WEVIS_MAX_PIXELS=104857611.026 MiB beim Fehlernein: Objekt-Aufgaben OK, Segmentierung eines Bildes mit 640x388 OOM (768 MiB), keine Maskenemuliert
8 GB (Grenze 7,2 GiB)2B, Transformers, WEVIS_MODEL=tencent/WeVisOne-VL-2B7.242 MiBnein, 12/14: große Matte OOM, OCR Grounding <ref>PROCTER</ref><box><368><0><1000></ref></box>; Erkennung 25 gegen 32, Tennis 11 gegen 12emuliert

Die Grenzen beschränken nur die Allokationen von PyTorch; sie emulieren den Speicher, nicht Rechenleistung oder Bandbreite einer kleineren Karte, und der CUDA-Kontext liegt außerhalb. Nicht ausprobiert: echte Karten mit 12 GB oder 8 GB, fp8 oder int8, CPU-Offload.

Gefundene Probleme

  1. Die vLLM-Einstellungen der Autoren lassen auf 24 GB keinen KV-Cache übrig. Encoder cache will be initialized with a budget of 16384 tokens, dann Available KV cache memory: -0.87 GiB und ValueError: No available memory for the cache blocks bei util 0.471. Im Backend behoben, indem es vllm.LLM umhüllt: limit_mm_per_prompt ein Bild bis zur Eingabegrenze, Video 0, mm_processor_kwargs size, max_model_len, max_num_seqs 4.
  2. Zwei Kopien der Gewichte auf 24 GB sind knapp. Mit util 0.5 ging der großen Matte der Speicher aus (siehe Leiter). util 0.465 mit max_model_len 4096 ergab 0.56 GiB KV cache is needed, which is larger than the available KV cache memory (0.44 GiB); 3072 funktioniert. Über die Standardwerte behoben.
  3. Ergebnisse über 8 MB werden verworfen, und der Aufrufer wartet auf einen 504. Worker: job result refused by JetStream for good (code max_payload: ... exceeded by message size of 9145132); Client: 504 ... inference_timeout. Der Worker kodiert das JSON des Backends auf der Bild-Route noch einmal in Base64 (x1,33). Im Backend behoben (JPEG-Overlay, Freisteller mit 1280 px, Budget 5,2 MB). Offen auf Seiten der Plattform: Der Worker weiß, dass das Ergebnis abgelehnt wurde, aber der Client wartet trotzdem den vollen Timeout ab.
  4. Die Engines sind sich bei manchen Antworten uneinig. Schach 15 gegen 16, OCR 29 gegen 21 Wörter, Töpfe 19 gegen 20. Greedy auf beiden. Offen, liegt in den zwei Engines selbst; wähl die Engine je nach Anwendungsfall.
  5. Die erste vLLM-Anfrage nach einem Start ist langsam (14,5 bis 15,5 s für eine Erkennung von 1,9 s). Schick eine Warm-up-Anfrage.
  6. Der Packager des SDK kennt kein image2image. PackagingError: unknown task_type 'image2image'; expected one of ('text2text', 'embedding', 'text2image', ...), obwohl der Manager es akzeptiert. Das Backend deklariert text2image, was nur die Bild-Route auswählt. Offen.
  7. Der Tester im Dashboard schickt nur einen Prompt (plus Felder für Größe, Steps und Guidance, die dieses Modell ignoriert), deshalb parst das Backend task: query url daraus.
  8. Unsere Fehler. Lauf 3 scheiterte, weil main.py WEVIS_MAX_MODEL_LEN nicht weitergereicht hat (behoben).

Weitere Beispiele

Alle aus dem vLLM-Lauf auf der RTX 4090. Sie nutzen Fotos aus COCO val2017 (Flickr, gemischte Creative-Commons-Lizenzen, teils nicht kommerziell).

Erkennung von Person, Topf, Flasche, Schüssel und Messer in einem Küchenfoto aus COCO: 33 Boxen

Personen auf einem Tennisplatz in einem COCO-Foto gezählt: Antwort 12, eine Box pro Person

Segmentierung von 'the blue bicycle' in einem COCO-Foto mit 640 mal 388, Maske über dem Fahrrad

Freisteller von 'the cat on the right' in einem COCO-Foto, Overlay und transparenter Freisteller

Zeigen auf den Catcher in einem Baseball-Foto aus COCO: ein einzelner Punkt auf dem Catcher

OCR eines Straßenschilds in einem COCO-Foto: 29 Wörter gelesen, jedes mit seiner Box

Demovideo

Frame bei Sekunde 45 der Deploy-Demo: das Matting-Ergebnis für das Porträt der Autoren im Bildtester des InferenceKey-Panels, Overlay und Freisteller. Klicken, um das 1 Minute 40 Sekunden lange Video mit Sprecher abzuspielen

Deploy-Demo mit Sprecher, 99,6 s, 1920 x 1080: der Workload auf einer RTX 4090, dann ein Porträt-Freisteller (2.367 ms Round Trip), die Schach-Zählung mit sichtbar fehlendem Springer (2.140 ms) und "boys holding microphone" (1.087 ms) aus dem Bildtester des Panels.

Quellen

  • Model Cards: https://huggingface.co/tencent/WeVisOne-VL-4B und https://huggingface.co/tencent/WeVisOne-VL-2B (README, LICENSE, config.json, HF-API mit Blobs)
  • Code: https://github.com/Tencent/WeVisOne-VL bei 40f735b8 (README, engine.py, prompts.py, requirements.txt, configs/wevisone_vl_v1_decoder.json)
  • Projektseite: https://tencent.github.io/WeVisOne-VL/
  • Wo wir es entdeckt haben: AI Search, https://www.youtube.com/watch?v=EfyQOAJjx1A (25. Oktober 2026, Kapitel 01:01 bis 03:10)
  • Testbilder: die Beispiele der Autoren (seabreeze, chess, boys) und COCO val2017
  • Unser SDK-Beispiel: https://github.com/inferencekey/inferencekey-sdk/tree/main/examples/wevisone-vl-4b-perception-custom-backend-private-nvidia