WeVisOne-VL-4B finds, counts and cuts out objects with one model, and every task ran on a real 16 GB card

The chessboard in Tencent's own example folder has sixteen white pieces on it. WeVisOne-VL-4B, run twice on one RTX 4090 with the same prompt, answered 15 in 1.35 seconds and 16 in 3.87 seconds. The quick answer skipped the knight on g5. Same model, two ways of running it, and that gap is the choice you face before putting it behind a product. Take the quick one and check its counts, or the slow one, which also fits a 16 GB card. Either way, one open model of 4 billion parameters found named objects, counted them, pointed, read text and cut a person out of a photo down to the hair. Its authors pitch it as all-in-one. Serving it behind an API takes a custom backend, and the one we wrote is linked at the end.

The authors' chess photo counted twice by WeVisOne-VL-4B on one RTX 4090 with the prompt 'count the white chess pieces', 16 on the board. Left, fast engine, 1.35 seconds, answer 15, wrong: a red box and arrow labelled 'missed: white knight' mark the white knight on g5, which has no box. Right, reference engine, 3.87 seconds, answer 16, right: a green box marks the same knight, now detected

Same model, photo and prompt. The fast engine (left) is about three times quicker here, and missed one piece. The reference engine is on the right.

Three numbers from our test of WeVisOne-VL-4B on InferenceKey Cloud: 1.0 second for a full-resolution alpha matte of a 1620 by 1080 photo on an RTX 4090; 12.8 GiB peak card memory with 14 of 14 requests on a real 16 GB RTX 5080; 12 GB, where cut-outs stop, since every mask failed under a strict emulated 12 GB cap

One 4B model covers the jobs of a detector, a segmenter and a cut-out tool

WeVisOne-VL ("WeChat Vision All-in-One") folds into one model the jobs that usually take a chain of three. The first draws boxes around things you name, for example GroundingDINO, which the authors compare against. A second, such as SAM2, turns each box into an outline. A third makes a soft cut-out, the kind that keeps loose hair and edges. Each one is its own download, its own memory and its own way to break.

The WeChat Vision team at Tencent built it on an open Alibaba model. According to the model card, it finds anything you can name, or one described thing like "the cat on the right". It also counts, points, reads text with its position, draws outlines and makes cut-outs.

The model writes, a small cutter draws. WeVisOne-VL answers in text, and a position is just more text. The authors added 1,001 special words, <0> to <1000>, each a position across the image's width or height. A box is four of those words, a point is two. For outlines and cut-outs, it tags each box, and a tiny separate program reads the model's view of that tag and paints the pixels. That cutter has 9.6 million parameters, about 500 times smaller than the model it sits next to. The project page says no separate outline tool is needed, because the cutter reuses what the model saw.

The team trained it on about 100 million images, using SAM2 only to draw the training outlines, not at run time. They released the 4B and a 2B, with a code package that runs both. The Hugging Face repos were created on 22 October 2026, and the code's public release commit is dated 23 October. We spotted it in the AI Search news video of 25 October.

The authors report that the 4B leads on more than 30 benchmarks. On their test of finding named objects, it scores 55.3 out of 100, GroundingDINO 38.8. On portrait cut-outs, its error is half that of a SAM2-based setup (7.3 against 15.4). The "replaces three models" idea rests on those tables, not on a side-by-side we ran.

The weights on Hugging Face are Apache 2.0, which allows commercial use. The model card adds that "the release is intended for research" and is "not intended to make autonomous high-impact decisions or to identify individuals". Our reading: the Apache grant is the licence, the intended-use lines are guidance, and the line on identifying people matters if your product handles faces.

The test: the model fits in about 10 GB, and the fast setup holds it twice

The fast setup holds the model twice on one card. The published file is 19.3 GB because it stores every number at full precision. We loaded it at half precision, the usual way to serve a model, which brings it to about 10 GB. The code package can run it two ways: a fast engine built for serving, and the plain reference engine. Even when the fast engine writes the answer, the package keeps a second copy in the reference engine to feed the cutter.

We deployed the 4B through our platform and sent it the same 14 requests, one image at a time, in each setup. They cover seven kinds of job: find several named things, count, find one described thing (and refuse an absent one), point, read text, outline, and cut out. The images are the authors' own examples plus public photos. Most runs used an RTX 4090 with 24 GB of memory, and a real RTX 5080 with 16 GB checked whether a smaller card holds up.

Results: a full-resolution cut-out in about a second, and 'nothing here' when nothing is there

The cut-out is the headline. A 1620 by 1080 portrait from the authors' examples came back as a full-resolution cut-out, and the wind-blown hair strands survive.

WeVisOne-VL-4B cut-out of the authors' seabreeze portrait on an RTX 4090. Left, the photo with the person box and the mask in pink. Right, the cut-out on a transparency checkerboard, with the wind-blown hair strands kept

The rest, in the times a person feels:

Job	RTX 4090, fast	RTX 4090, reference	RTX 5080 16 GB, reference
Cut out a person, 1620 x 1080	1.0 s	1.1 s	2.1 s
Find "the cat on the right"	0.21 s	0.55 s	0.68 s
Count 12 people	0.78 s	2.7 s	2.8 s
Read a street sign (words found)	3.7 s (29)	9.1 s (21)	9.5 s (22)
Find 5 kinds of object in a kitchen	1.9 s	7.4 s	8.3 s
Peak card memory (GiB)	23.0	12.3	12.8

Time on the card, from our logs. Memory in GiB, the unit the card's own readout uses. Words found on the sign vary by setup.

We asked for "the dog" in a photo of cats. The model answered that there was none in every setup we ran, on the one photo we tried, in 0.11 seconds on the fast engine. A detector that invents a dog when there is none is the bug that makes a product team stop trusting the feature.

On the authors' photo of boys holding microphones, it boxed both singers. The kitchen boxes, the point on a baseball catcher, the bicycle outline and the portrait and cat cut-outs were right when we checked them by eye. We did not check the count of 12 tennis players against a ground truth.

WeVisOne-VL-4B finding 'boys holding microphone' in the authors' example photo: two boxes, one on each singer

The fast engine is about three times quicker on object jobs, and it got the chessboard wrong

On object jobs, the fast engine is one and a half to four times quicker, about three times on most. On cut-outs the picture is mixed. The bicycle outline was slower on the fast engine (1.2 to 1.8 seconds against 0.9).

Both engines used greedy decoding, so the chessboard miss is not sampling noise. The likely cause is that the low-level maths differs slightly between the two programs, and a borderline box fell on the other side. They also differed on the street sign (29 words against 21) and on hanging pots and pans (19 against 20). One miss in 14 requests is not a rate. It is a reason to test your own images on the engine you will ship, the way you soundcheck on the PA you will actually play through.

There is one more speed trap. On the fast engine, the very first request after a start took 14.5 to 15.5 seconds for a detection that takes 1.9 seconds afterwards. Send one warm-up request before real traffic.

Where it does not fit: the model card warns that fine edges in a cut-out depend on resolution, hidden parts, transparency and wording. It answers one question about one image, and the cutter rejects video.

Which GPU: every task on a real 16 GB card, and cut-outs need more than 12 GB

The smallest card that passed every task was a real RTX 5080 with 16 GB, running the reference engine. It was about twice as slow as the 4090's fast engine on the big cut-out, and up to about four times on object jobs. The 24 GB card of our main run is a speed choice, not a requirement.

Card	Setup	Result
RTX 4090 24 GB, real	4B, fast engine plus reference copy	14 of 14, the fastest
RTX 5080 16 GB, real	4B, reference only	14 of 14
About 12.5 GB, emulated	4B, reference only	13 of 14: only the big portrait cut-out fails
12 GB, emulated strictly	4B, reference only	Boxes, counts, points and text work. Every outline and cut-out fails

The 12 GB and 8 GB results come from capping memory on the 4090, not from real cards of those sizes. Below 16 GB, the cutter is the wall. It grabs about 0.8 GB in one go, whatever the size of the photo, so under the strict cap it failed even on a 640-pixel photo. The 2B model under an 8 GB cap passed 12 of 14: the big cut-out ran out of memory and one text-position answer came back malformed. It also found 25 boxes in the kitchen where the 4B found 32. Its small cut-outs and the bicycle outline worked, but we did not compare their quality with the 4B, so whether the 2B keeps cut-outs as clean is untested.

On InferenceKey: one endpoint for seven jobs, answering 87 seconds after a fresh start on 16 GB

A fresh RTX 5080 that had never seen the model was answering after 87 seconds, download included. On a 4090 with the model already on disk, the fast engine was ready in 49 to 82 seconds, the reference engine in 14 to 15.

Serving every job, cutter included, takes a custom backend. That is a small Python program our platform runs on your GPU machine instead of a standard model server. A standard server would only return the model's text, boxes and points. The cutter lives outside that, so ours drives the authors' package directly, writes with one engine and paints with the other. Each answer comes back as a picture with the boxes drawn and the raw coordinates for your code, plus, for outlines and cut-outs, a cut-out with a transparent background.

Run the authors' package on a 24 GB card and you will hit this. Its default fast-engine settings reserve room for ten images and ten videos per request. Nothing is left for the model's working memory, and the fast engine refuses to start. Our example fixes it by sizing the fast engine for one image and shorter requests. It also picks the engine by card size: fast on 22 GiB or more, reference below. The example's current version only turns the values we tested into defaults. That exact version has not run on a GPU yet. The earlier ones did, with the same values set by hand. The other problems are in the appendix.

Should you use it? Yes for vision features on a 16 GB card, and test your counts

You ship detection, outlines or cut-outs today: one 4B model on one card did all of them in our test. Check the model card's intended-use lines first.
You need counts that are right: use the reference engine, or check the fast engine against your own images first. On our chessboard, the slow engine was the right one.
You have a 16 GB card: every task ran on a real RTX 5080. On 12 GB, plan for boxes and text only.
You need speed: a 24 GB card with the fast engine gives one-second cut-outs and sub-second finds. We sent one request at a time and did not test several users at once. Send a warm-up request first.

Run python publish.py, then python main.py, from our WeVisOne-VL-4B SDK example to get the same seven jobs behind an API on your own NVIDIA worker. It needs a filled-in .env and a 16 GB card (24 GB for the fast engine), and it deletes the deployment on exit.

For engineers

Model and files

tencent/WeVisOne-VL-4B, sha 4a7bed92750ac9d8b8a124cede14759036932dc2, created 2026-10-22T09:48Z, lastModified 2026-10-23, not gated, licence apache-2.0. model.safetensors 19,322,413,240 bytes, all F32 (4,830,581,248 parameters); mask_decoder.pt 38,534,741 bytes, 9,609,764 parameters. Qwen3VLForConditionalGeneration. The HF LICENSE lists Qwen3-VL-4B-Instruct (Alibaba Cloud, Apache-2.0, modified by Tencent) as a dependency.
tencent/WeVisOne-VL-2B, sha 3dad9ce8bcb6fbe0aea945bf8860bd2cfc3663bf, created 2026-10-22T09:47Z: model.safetensors 9,767,053,328 bytes F32 (2,441,744,384 parameters); mask_decoder.pt 38,141,525 bytes, 9,511,460 parameters; Apache-2.0.
Code: Tencent/WeVisOne-VL at 40f735b8 (2026-10-23T10:35Z; initial release 23447828 at 08:14Z). GitHub licence detection: NOASSERTION, although the README declares Tencent's code Apache 2.0. Pins: torch 2.11.0, transformers 5.12.1, vllm 0.23.0, triton 3.6.0, accelerate 1.14.0.
Hosted demo: https://huggingface.co/spaces/hugging-apps/wevisone-vl-4b

How the pixel path works

Coordinates are vocabulary tokens <0> to <1000> (normalised). Box = 4 tokens, point = 2. None for an absent target. Dense tasks emit <OBJ> (token ID 152678) after each box.
Pixel decoder: a Visual Feature Adapter over pre-merge Qwen3-VL ViT features from layers 5, 11, 17 and 23; a Box-Guided Query Decoder (6 deformable cross-attention blocks, initialised from the <OBJ> hidden state plus a Fourier-encoded box prior); an Instance-Conditioned Dense Head with FullCanvasAlphaCascadeHead refining S/4, S/2, S/1 to full-resolution alpha. Decoder input resized to 1024 x 1024 (cnn_image_size 1024).
Package API: WeVisOneVL(model, backend="transformers"|"vllm", dtype="bfloat16", gpu_memory_utilization=0.45, max_model_len=8192, max_pixels=2025*32*32). With backend="vllm" it creates vllm.LLM with limit_mm_per_prompt image 10 / video 10 and still loads the full Transformers model; decode_masks teacher-forces the generated response through it to capture the <OBJ> hidden states and ViT features. Hence two copies of the weights on the vLLM path.
Tasks in prompts.py: detection, referring, point, count_box, count_point, ocr, ocr_grounding, segmentation, matting, plus visual_prompt and freeform.
Card limitations: fine alpha boundaries sensitive to resolution, occlusion, transparency and prompt phrasing; no chain-of-thought; single-turn image perception (video grids are rejected by the pixel decoder). The package allows 10 images per prompt; our backend cuts that to one.
Training (project page): three-stage curriculum SFT (90.2M, 40.5M, 41.8M samples), then mixed-task RL with GRPO (178K samples), about 100M images. SAM2 extends verified boxes to masks in the data engine. At inference, the project page says: "No SAM, no external segmentation backbone: the pixel decoder reuses the VLM's own multi-level ViT features."

Authors' headline 4B numbers against the best open baseline in their tables (not reproduced by us): LVIS F1 55.3 (50.7), Dense200 71.3 (58.7), RefCOCOg 81.8 (77.6), WeRef-Bench rejection 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). The 2B beats the 4B on P3M-500-NP (6.6 vs 7.3) and PPM-100.

Our setup

GPUs on our cloud: RTX 4090 24 GB (driver 595.91.07, CUDA 13.2) for the main runs; RTX 5080 16 GB (driver 580.178.04, CUDA 13.0) for the real-card check.
A local InferenceKey manager (never production) bootstrapped both workers. The workload ran as the custom Python backend wevisone-vl-perception, called through /v1/images/generations and the panel's image tester.
Engines (the narrative's fast engine is vLLM, the reference engine is Transformers): vLLM 0.23.0 for the text plus a Transformers 5.12.1 copy feeding mask_decoder.pt, or Transformers alone. bf16 throughout.

Deploy step by step

The example lives at 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.

Needs: INFERENCEKEY_SDK_TOKEN, INFERENCEKEY_API_KEY, INFERENCEKEY_PROJECT, IK_WORKER_ID (your NVIDIA worker), optionally INFERENCEKEY_TENANT_ID / INFERENCEKEY_USER_TOKEN for publish.py. On the worker: an NVIDIA driver for CUDA 13.0 (580 or newer), Python 3.12, 16 GB of VRAM for every task, 24 GB for the 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 deploys workload WeVisOne-VL-4B with the custom backend slug, task_type text2image, ExecutionPolicy.FIXED with 1 replica pinned to IK_WORKER_ID, ready_timeout_secs 2400, request_timeout_secs 600, and forwards every WEVIS_* variable as env.

Calling it (the example falls back to https://cloud.inferencekey.com when INFERENCEKEY_BASE_URL is unset; .env is not loaded into your shell, so export what the call needs):

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 takes an https URL, a data URL or base64. The dashboard tester takes a prompt in the form task: query image_url, for example matting: person https://.../photo.jpg. The response carries data[0] (annotated JPEG), data[1] (RGBA cut-out PNG, segmentation and matting only), predictions (pixel boxes or points by label), count, rejected, masks (grayscale PNG mattes), timings and vram_peak_gib.

Backend environment (version 0.1.3):

Variable	Default	Meaning
`WEVIS_ENGINE`	`auto`	`vllm` at 22 GiB or more of total VRAM, else `transformers`
`WEVIS_MODEL`	4B	4B or 2B, pinned revisions
`WEVIS_GPU_MEMORY_UTILIZATION`	(9.4 + 1.75) / total, 0.465 on 24 GB	vLLM share; 4.6 GiB of weights for the 2B
`WEVIS_MAX_MODEL_LEN`	3072	vLLM context
`WEVIS_MAX_NUM_SEQS`	4	vLLM concurrency
`WEVIS_VRAM_LIMIT_GIB`	unset	PyTorch cap to emulate a smaller card
`WEVIS_MAX_PIXELS`	20253232	input image cap

The backend also sets PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True. Version 0.1.3 makes the values we tested through env the defaults; 0.1.3 itself was not run on a GPU (0.1.0 to 0.1.2 were, with env overrides).

Time to ready

RTX 4090, first start (0.1.0): backend venv about 67 s, download of 18.0 GiB in 14 s, vLLM weight load 7.0 s (9.37 GiB), torch.compile 36 s, CUDA graph profiling 93 s, then the KV cache failure (problem 1).
RTX 4090 warm, vLLM engine: 82 s, 82 s, 49 s; hot recycle on a new package 58 s.
RTX 4090 warm, Transformers engine: 14 to 15 s (load 12.4 s). 2B: 21 s including its 9.8 GB first download.
RTX 5080 fresh machine, Transformers engine: 87 s (download 38.0 s, load 16.9 s).

Full measurements

GPU time inside the backend. Round trips add 0.9 to 2.5 s (image download on the worker plus the platform). COCO image ids in brackets.

Request	4090 vLLM (util 0.465)	4090 Transformers	4090 TF, 11.5 GiB cap	5080 16 GB TF	2B TF, 7.2 GiB cap
detect kitchen: person, pot, bottle, bowl, knife (397133)	33 boxes; 14.5-15.5 s first call, 1.93 s warm	32, 7.44 s	32, 7.62 s	32, 8.31 s	25, 5.09 s
count people, tennis (1000)	12, 0.78 s	12, 2.68 s	12, 2.68 s	12, 2.77 s	11, 1.97 s
refer: the cat on the right (39769)	1 box, 0.21 s	0.55 s	0.57 s	0.68 s	0.46 s
reject: the dog (same photo)	`None`, 0.11 s	`None`, 0.36 s	`None`, 0.34 s	`None`, 0.47 s	`None`, 0.29 s
point: catcher (46252)	1 point, 0.16 s	0.38 s	0.38 s	0.50 s	0.30 s
OCR street sign (252219)	29 words, 3.69 s	21, 9.13 s	21, 9.05 s	22, 9.49 s	25, 8.91 s
segment: the blue bicycle (174482, 640x388)	1.20-1.84 s	0.89 s	0.91 s	1.21 s	0.78 s
matte: person (authors' seabreeze.jpg, 1620x1080)	0.97-1.11 s	1.11 s	OOM	2.05 s	OOM
matte: the cat on the right	0.38 s	0.76 s	0.84 s	1.13 s	0.66 s
matte: skier (785)	0.36 s	0.65 s	0.69 s	0.99 s	0.58 s
refer: boys holding microphone (authors' boys.jpg)	2 boxes, 0.53 s	0.80 s	0.80 s	1.18 s	0.63 s
count: white chess pieces (authors' chess.jpg, 16 true)	15, 1.35 s	16, 3.87 s	16, 3.70 s	16, 4.20 s	16, 2.78 s
OCR grounding: PROCTER (11197)	1 box, 0.20 s	0.50 s	0.50 s	0.60 s	malformed
count: 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
card peak (nvidia-smi)	23,539 MiB, 23.0 GiB (20,329 idle)	12,546 MiB	about 12.5 GB incl. CUDA context	13,148 MiB	7,242 MiB

The 14.5 to 15.5 s detection is warm-up: on the warm engine with max_new_tokens 512 and 2048 the same 33 boxes took 1.94 s and 1.93 s.
The vLLM segmentation time splits into about 0.19 s of text and 1.0 to 1.6 s of mask; the big matte into 0.53 to 0.64 s of text and 0.44 to 0.48 s of mask.
Checked by eye: kitchen boxes, cat, catcher point, bicycle and portrait mattes correct; rejection correct in every configuration; chess counted by hand (16), vLLM missed the white knight on g5. Not checked against ground truth: tennis (12), pots (19 or 20) and the street-sign OCR (29, 21, 22 or 25 words, depending on the setup).
Panel tester round trips in the demo (vLLM engine): matting 2,367 ms, chess count 2,140 ms, referring 1,087 ms.

VRAM ladder, full figures

GPU or cap	Config	Peak	Output OK?	Real or emulated
RTX 4090 24 GB	4B, vLLM util 0.5 + Transformers copy (backend 0.1.1)	1620x1080 matte OOM: `Tried to allocate 768.00 MiB`, 630.44 MiB free (EngineCore 11.50 GiB + Transformers 11.39 GiB)	no, the other 7 `main.py` requests OK	real
RTX 4090 24 GB	4B, vLLM util 0.465, `max_model_len` 3072, `max_num_seqs` 4 + Transformers copy	23,539 MiB	yes, 14/14 (chess 15 of 16)	real
RTX 4090 24 GB	4B, Transformers only	12,546 MiB	yes, 14/14	real
RTX 5080 16 GB	4B, Transformers only	13,148 MiB	yes, 14/14	real
12 GB (11.5 GiB cap)	4B, Transformers, `WEVIS_VRAM_LIMIT_GIB=11.5`	about 12.5 GB on the card incl. CUDA context	no, 13/14: big matte OOM `Tried to allocate 768.00 MiB ... 11.27 GiB allowed`	emulated, optimistic
12 GB strict (10.8 GiB cap)	4B, Transformers, `WEVIS_VRAM_LIMIT_GIB=10.8`, `WEVIS_MAX_PIXELS=1048576`	11,026 MiB at failure	no: object tasks OK, segmentation of a 640x388 image OOM (768 MiB), no masks	emulated
8 GB (7.2 GiB cap)	2B, Transformers, `WEVIS_MODEL=tencent/WeVisOne-VL-2B`	7,242 MiB	no, 12/14: big matte OOM, OCR grounding `<ref>PROCTER</ref><box><368><0><1000></ref></box>`; detection 25 vs 32, tennis 11 vs 12	emulated

The caps limit PyTorch's allocations only; they emulate memory, not a smaller card's compute or bandwidth, and the CUDA context sits outside them. Not tried: real 12 GB or 8 GB cards, fp8 or int8, CPU offload.

Problems found

Authors' vLLM settings leave no KV cache on 24 GB. Encoder cache will be initialized with a budget of 16384 tokens, then Available KV cache memory: -0.87 GiB and ValueError: No available memory for the cache blocks at util 0.471. Fixed in the backend by wrapping vllm.LLM: limit_mm_per_prompt one image at the input cap, video 0, mm_processor_kwargs size, max_model_len, max_num_seqs 4.
Two copies of the weights on 24 GB are tight. util 0.5 ran the big matte out of memory (see ladder). util 0.465 with max_model_len 4096 gave 0.56 GiB KV cache is needed, which is larger than the available KV cache memory (0.44 GiB); 3072 works. Fixed through the defaults.
Results over 8 MB are dropped and the caller waits for a 504. Worker: job result refused by JetStream for good (code max_payload: ... exceeded by message size of 9145132); client: 504 ... inference_timeout. The worker base64-encodes the backend JSON again on the images route (x1.33). Fixed in the backend (JPEG overlay, 1280 px cut-out, 5.2 MB budget). Open on the platform side: the worker knows the result was refused, but the client still waits for the full timeout.
Engines disagree on some answers. Chess 15 vs 16, OCR 29 vs 21 words, pots 19 vs 20. Greedy on both. Open, inherent to the two engines; pick the engine per use case.
First vLLM request after a start is slow (14.5 to 15.5 s for a 1.9 s detection). Send a warm-up request.
The SDK packager has no image2image. PackagingError: unknown task_type 'image2image'; expected one of ('text2text', 'embedding', 'text2image', ...), although the manager accepts it. The backend declares text2image, which only selects the images route. Open.
Dashboard tester sends only a prompt (plus size, steps and guidance fields this model ignores), so the backend parses task: query url from it.
Our mistakes. Run 3 failed because main.py did not forward WEVIS_MAX_MODEL_LEN (fixed).

Remaining samples

All from the RTX 4090 vLLM run. These use COCO val2017 photos (Flickr, mixed Creative Commons licences, some non-commercial).

Detection of person, pot, bottle, bowl and knife in a COCO kitchen photo: 33 boxes

Counting people on a tennis court in a COCO photo: answer 12, one box per person

Segmentation of 'the blue bicycle' in a 640 by 388 COCO photo, mask overlaid on the bike

Cut-out of 'the cat on the right' in a COCO photo, overlay and transparent cut-out

Pointing at the catcher in a COCO baseball photo: a single point on the catcher

OCR of a street sign in a COCO photo: 29 words read, each with its box

Demo video

Narrated deploy demo, 99.6 s, 1920 x 1080: the workload on one RTX 4090, then a portrait cut-out (2,367 ms round trip), the chess count with the missing knight visible (2,140 ms) and "boys holding microphone" (1,087 ms) from the panel's image tester.

Sources

Model cards: https://huggingface.co/tencent/WeVisOne-VL-4B and https://huggingface.co/tencent/WeVisOne-VL-2B (README, LICENSE, config.json, HF API with blobs)
Code: https://github.com/Tencent/WeVisOne-VL at 40f735b8 (README, engine.py, prompts.py, requirements.txt, configs/wevisone_vl_v1_decoder.json)
Project page: https://tencent.github.io/WeVisOne-VL/
Where we spotted it: AI Search, https://www.youtube.com/watch?v=EfyQOAJjx1A (25 October 2026, chapter 01:01 to 03:10)
Test images: the authors' examples (seabreeze, chess, boys) and COCO val2017
Our SDK example: https://github.com/inferencekey/inferencekey-sdk/tree/main/examples/wevisone-vl-4b-perception-custom-backend-private-nvidia