JEVision

JEVision

JEVision is a Qwen3.5-based system for making structured decisions from text and images. It extends the KEV/Jev-style System One interface with a visual route, so an application can send context and typed questions and receive Choice, Noul, or Score answers instead of parsing free-form prose.

The release combines a trained text adapter, a separately trained visual sidecar, pointer heads, and a bundled inference runtime. Both routes use the same pinned Qwen3.5-0.8B-Base revision. This makes the model useful for workflows that need a consistent decision API across text-only and image-bearing requests.

Capabilities

The capability graphic summarizes the separate input routes and shared response format. Its 80,000-token value is a configured request limit, not a measure of answer quality.

Compared with Jev and KEV-0.8B

This view compares output format, input modality, configured context, image support, and text-only JevBench results. JEVision’s public-panel figure is 79.3%, and its 33-question general group result is 21/33 (63.6%). The editable SVG is also included.

The serving route processed 76,999 text tokens and 76,998 image-plus-text tokens in recorded acceptance checks. The text check used the included KEV-0.8B option; the image check used the visual sidecar. These checks establish request handling near 77K, while long-context answer quality remains to be evaluated.

See the visual route

The repository includes a real photograph, the exact request sent to the visual route, and its captured response. The model selected laptop_and_coffee from three descriptions of the scene.

Photo by Shixart1985, via Wikimedia Commons, CC BY 2.0. Source photograph; the bundled file is its 960-pixel Commons thumbnail.

The saved request and full response can be inspected or replayed. The response below is taken from that recorded adapter run:

{
  "answers": {
    "scene": {
      "type": "choice",
      "choice": "laptop_and_coffee",
      "confidence": 1.0,
      "probabilities": {
        "laptop_and_coffee": 1.0,
        "bicycle_and_helmet": 0.0,
        "cat_on_sofa": 0.0
      }
    }
  },
  "usage": {"input_tokens": 674, "output_tokens": 67}
}

In these examples, model: "jevvision" is the API label echoed in the response; it does not choose the inference weights. The images field routes the request through the JEVision visual adapter and pointer head in this repository. The optional KEV-0.8B checkpoint is used only when selected for text-only requests. The saved photo response retains its recorded answer, probabilities, token counts, and latency; only its echoed model label was normalized from the older API alias.

This is one recorded example. The full response also records the latency of that CPU run; it is not a speed comparison. Run it yourself after starting the server:

python examples/real-photo/run_demo.py --endpoint http://127.0.0.1:8009

Noul answers on the same photograph

In a separate local run using the same coffee-and-laptop photograph, the three yes/no questions in the Noul request produced the response below:

• is_macbook: Does the laptop appear to be a MacBook?
• cup_touching_laptop: Is the cup physically touching the laptop?
• cup_nearly_full: Does the cup appear nearly full?

For a Noul answer, noul is the model's estimated probability of yes. Here, the model assigns 0.72 to the MacBook question, 0.01 to the cup touching the laptop, and 0.89 to the cup appearing nearly full. These are outputs from one local example, not calibrated confidence measurements.

{
  "answers": {
    "is_macbook": {
      "type": "noul",
      "noul": 0.72
    },
    "cup_touching_laptop": {
      "type": "noul",
      "noul": 0.01
    },
    "cup_nearly_full": {
      "type": "noul",
      "noul": 0.89
    }
  },
  "usage": {
    "input_tokens": 700,
    "output_tokens": 60
  }
}

To run those questions against your local server, use:

python examples/real-photo/run_demo.py --example noul --endpoint http://127.0.0.1:8009

The script prints the full response and saves it to examples/real-photo/noul-output.json. It runs the same request, but the probability values and token counts may differ from the local result shown above.

Run locally

The bundle was tested on Linux with CUDA and a Tesla T4. A 16 GB NVIDIA GPU is recommended when hosting both routes together. The Qwen base weights are fetched on first use.

git clone https://huggingface.co/divyanshx11/JEVision
cd JEVision
python -m venv .venv && source .venv/bin/activate
python -m pip install -r requirements.txt
python run_jevvision.py --port 8009

The server exposes POST /v1/systemone on localhost. To select the bundled KEV text checkpoint for requests without images, add --text-adapter kev-0.8b. Image-bearing requests automatically use the visual sidecar.

The earlier --text-adapter jevbench-m3 selection is also available for existing scripts and points to the same text weights as the default route.

Call from Python

from jevvision import JEVision, image_file_as_data_url

model = JEVision.from_pretrained(".", device="cuda:0")
result = model.system_one(
    state="Use the attached photo as visual context.",
    images=[image_file_as_data_url("examples/real-photo/coffee-and-laptop.jpg")],
    questions={
        "scene": {
            "type": "choice",
            "instructions": "Which description best matches the photo?",
            "criteria": {
                "laptop_and_coffee": "A laptop beside a cup of coffee on a table.",
                "bicycle_and_helmet": "A bicycle parked beside a helmet.",
                "cat_on_sofa": "A cat sitting on a sofa.",
            },
        }
    },
)
print(result["answers"]["scene"])

The image API accepts up to four images per request, each no larger than 10 MiB and 25 megapixels. Text-only requests use the selected text adapter. Image-bearing requests use the visual sidecar; the two adapters are routed separately.

Long-context example

The runnable request recipe builds an archived help-desk state of roughly 76,000 tokens and asks for the code in its final record. With the server running, use:

python examples/long-context/run_demo.py --endpoint http://127.0.0.1:8009

The runner writes its generated state and saves the server's response only after checking that usage.input_tokens is at least 75,000. A separate recorded text-route acceptance summary documents a 76,999-token request on the bundled KEV-0.8B option; it is a request-handling check, not a result for the default JEVision text adapter.

The original archived request recipe and response summary are preserved at their earlier paths.

Architecture and training

The base is Qwen/Qwen3.5-0.8B-Base at revision dc7cdfe2ee4154fa7e30f5b51ca41bfa40174e68. This repository supplies the adapters and heads, not a merged base-model checkpoint.

The default text adapter was fitted to public JevBench decision examples, starting from a KEV text checkpoint. Those public examples informed training and selection, so results on them are not an independent evaluation. The visual sidecar was trained separately with photos from the Beans training split and programmatically generated, labeled visual tasks. The generated tasks supplement the real images; they are training data, not claimed evaluation measurements. The visual route is not scored by JevBench.

Self-reported visual evaluations

These development results use the visual sidecar shipped in this repository. The adapter and pointer-head SHA-256 hashes in the recorded runs match the release manifest. Each result is a narrow task probe, not an estimate of general image accuracy.

These are self-reported development runs. The Beans and generated-task panels share task families with training; the 64-photo VSR panel is small. The figures do not establish broad real-image performance or calibrated probabilities. They measure the visual sidecar, not the separately routed text adapter. Recorded counts, checkpoint hashes, and run identifiers are provided for provenance.

Evaluation scope

JEVision currently has functional checks for typed responses, image routing, and long request acceptance, plus the recorded real-photo example above. The public JevBench examples were used to fit and select the text adapter, so accuracy on those examples is not an independent benchmark result. A separate 33-question grouped text test recorded 21 correct (63.6%) with a 4,096-token cap. This small test does not measure the visual route or long-context answer quality. The 80,000-token value is a service limit, and requests beyond it are rejected instead of silently truncated. The comparisons below describe these specific text panels; they are not a broad accuracy, latency, or cost claim.

The JevBench result for JEVision is 183/231 (79.3%). The grouped test is the separate 33-question check. Neither panel evaluates the visual route.

The manifest identifies the components, their source revisions, hashes, and serving limit. Users should assess the model on their own images and decision tasks before relying on its outputs.

What's next

JEVision's next phase targets a purpose-built decision architecture and a faster production inference path. The work below is planned for future releases; the measurements above describe the current one.

JEV-style parallel decision architecture

The architectural direction is to move from sequential, decoder-style question handling toward a shared-state decision engine. A common context representation would feed multiple question branches concurrently, with typed heads for Choice, Noul, and Score outputs. This makes multi-question calls a first-class model workload: shared context computation can be reused, independent questions can run in parallel, and the system can spend less compute repeatedly generating answer scaffolding. The goal is higher question throughput and more predictable latency as a request grows.

Inference engineered for low latency

The serving roadmap focuses on the full request path: context prefill, question scheduling, batching, adapter dispatch, and typed-answer readout. For the current Qwen-based backbone, we plan to profile and optimize reusable context work and cache behavior; for the evolving decision architecture, we plan to schedule question branches and text/visual routes with less synchronization and data movement. The target is a responsive decision API with lower end-to-end and tail latency under multi-question load. We will report p50/p95 latency, throughput, and output-quality checks when these changes are implemented.

License

The adapter bundle and runtime are published under Apache-2.0. The Qwen3.5 base model is also Apache-2.0; follow the base model's terms and the terms of any datasets you use.