HiVG turns SVG path data into tokens a 3B model can generate

A visual program instead of a path soup

HiVG is the official implementation of the paper Hierarchical SVG Tokenization: Learning Compact Visual Programs for Scalable Vector Graphics Modeling, published as arXiv 2604.05072 with a project page and a Hugging Face model card. The problem it attacks is that SVG is a verbose, deeply nested text format, and asking a language model to emit raw path data wastes most of its capacity on coordinates. HiVG's answer is a hierarchy. Raw SVG is first rewritten into atomic tokens, where a command and each of its numeric arguments become separate symbols, and then those atomic sequences are compressed again into segment tokens that represent recurring chunks of drawing commands. The documentation puts the compression figure at 2.76x in sequence length, and the claim attached to the model is that a 3B parameter checkpoint beats seven proprietary models, GPT-5 and Gemini 2.5 among them, on image-to-SVG. Treat that comparison as the authors' own claim, since the evaluation scripts are shipped precisely so you can check it.

Three token levels, and segment tokens you can train yourself

The tokenization scheme is the core idea and the documentation shows it compactly:

Level 0 (Raw SVG)    path d="M 100 200 c -5 0 -10 5 -10 10"
                                    ↓
Level 1 (Atomic)     <cmd_M><P_100><P_200><cmd_c><d_-5><d_0><d_-10><d_5><d_-10><d_10>
                                    ↓
Level 2 (Segment)    <cmd_M><P_100><P_200><SEG_42>

At level 1 every curve command and every number becomes its own token, so the model is reasoning over structure rather than over a character stream. At level 2, a learned segment token stands in for a whole stretch of atomic sequence, which is where the compression comes from. The important practical point is that the segments are not fixed by the authors. A segment token training guide in the docs directory walks through training BPE segments from your own SVG corpus and converting datasets, which means an organisation with thousands of internally consistent icons can teach the model their vocabulary of repeated shapes. That is a genuine difference in approach from feeding raw SVG to a general model.

One pipeline for image-to-SVG and text-to-SVG

Installation is a clone and an editable install:

git clone https://github.com/ximinng/HiVG.git
cd HiVG
pip install -e .

The Python API is a single pipeline object, and the generation settings are constructor arguments:

from hivg_infer import HiSVGInferencePipeline

pipeline = HiSVGInferencePipeline(
    model_path="/path/to/model",
    coord_range=234,
    temperature=0.7,
    top_p=0.9,
    max_new_tokens=4096,
)

Image to SVG returns a result dictionary that carries a success flag and the SVG text:

# Image-to-SVG
result = pipeline.img2svg("assets/cases/w2.png")
if result["success"]:
    print(result["svg"])

Text to SVG works the same way, and the example writes the result to a file:

# Text-to-SVG
result = pipeline.text2svg("The image features a simple, flat-style briefcase with a handle and a central plus symbol. The briefcase is outlined in black with a light teal plus sign, suggesting medical or emergency services. Small decorative dots surround the briefcase, enhancing its minimalistic design.")

if result["success"]:
    with open("output.svg", "w") as f:
        f.write(result["svg"])

The command line entry point mirrors the API, and covers single prompts, images, batch runs and a REPL:

# Text-to-SVG
python -m hivg_infer.cli --model_path /path/to/model \
    --prompt "A minimalist black phone icon with an outline style"

# Image-to-SVG
python -m hivg_infer.cli --model_path /path/to/model \
    --image photo.png

The output is editable geometry, which is the reason to care about this project at all. An SVG that a person can open, restyle and put back into a design system is a different artefact from a raster tracing.

Evaluation scripts for CLIP, SSIM and preference scores

The repository ships an evaluation harness in the hivg_metric package, and it is more useful than the headline numbers. Batch inference runs against a dataset and writes results as JSON lines, with either the HuggingFace backend or a vLLM backend that the documentation marks as faster:

# vLLM backend (faster)
python -m hivg_metric.eval \
    --model_path /path/to/model \
    --dataset test.json \
    --infer_backend vllm \
    --batch_size 32 \
    --save_name results.jsonl

Metrics are then computed from that file, and the split by task matters. Text to SVG uses CLIP score plus preference metrics, while image to SVG uses visual similarity against the source image:

# Image-to-SVG: visual similarity metrics
python -m hivg_metric.compute_metrics \
    --input results.jsonl \
    --task_type img2svg \
    --image_base_dir /path/to/images \
    --metrics basic,visual \
    --output metrics.json

The supported metric groups are listed in a table. The basic group covers success rate, SVG length and path count and applies to both tasks. The visual group covers SSIM, LPIPS and PSNR against the input image and applies to image to SVG only. The clip group covers CLIP score for text-image alignment, the preference group covers PickScore, ImageReward, HPS and Aesthetic, and the diversity group uses DINOv2 or CLIP diversity across multiple samples. A visualisation step turns the results file into an interactive HTML report with input, prediction and ground truth side by side, which is the fastest way to see where the model fails.

Only the base checkpoint is actually available

The weights table lists four checkpoints and three of them are not there yet. HiVG-3B-Base, the base model with hierarchical SVG tokenization, is downloadable from Hugging Face. HiVG-3B-Instruct, the instruction-tuned model for SVG generation, is marked coming soon, as are the Draw-with-Thought model HiVG-3B-DwT and HiVG-3B-DwT-RL, the DwT model with reinforcement learning. That gap matters for how you plan the work. Without the instruct checkpoint you are driving the base model with prompts, and the difference in behaviour between those two is likely to be large. The datasets the model expects are documented in two formats, Alpaca for text to SVG and ShareGPT for image to SVG:

[
  {"instruction": "Draw a red circle", "input": "", "output": "<svg tokens>"}
]

The ShareGPT variant carries the image paths and a label of the SVG tokens. Generation parameters are also fixed by defaults worth knowing before you tune anything: coord_range defaults to 234, described as a 224 canvas plus margin, temperature is 0.7, top_p is 0.9, top_k is 50, max_new_tokens is 4096 and repetition_penalty is 1.0. The canvas range in particular constrains the coordinate space the model can emit, so an icon designed for a 1024 pixel artboard needs attention before the output is usable.

MIT terms, a modest dependency set and a quiet last few months

The project is MIT licensed, with the licence declared in setup.py and a LICENSE file in the repository. The package is published as hivg at version 0.1.0, requires Python 3.9 or newer and lists classifiers up to Python 3.12. The runtime dependencies are ordinary for the field: torch 2.0.0 or newer, transformers 4.40.0 or newer, pyyaml, pillow, cairosvg for rasterising SVG, fire for the command line, tqdm, numpy 1.26 or newer and piqa. An optional extra pulls in vllm 0.4.0 or newer, which is what makes the faster evaluation backend possible, and the requirements file lists the same set. The repository has three Python packages, hivg_infer, hivg_metric and hivg_tokenizer, with the tokenizer's YAML configs shipped as package data. There are no GitHub releases, so there is no versioned artefact to point at beyond the tags in the repository. The last push was on 2026-04-17, which means the work described here, including the segment token training guide, is a snapshot rather than a moving target, and anyone building on it should expect to read the code rather than wait for upstream changes.

Editorial conclusion

Adopt HiVG if you need output that stays editable vector geometry rather than a raster trace, and if you are prepared to evaluate the model yourself with the included metric scripts instead of trusting the headline comparison. Do not adopt it expecting a ready instruction-tuned checkpoint, because only HiVG-3B-Base is published and the other three are listed as coming soon. Before you build anything on it, run the evaluation pipeline with the visual metrics on your own images, confirm the coord_range of 234 matches the canvas you intend to generate for, and check the last push date, which was 2026-04-17.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. ximinng/HiVG on GitHub