List of supported presets for docling-serve

[ganny-gitaa]

Hello.

I have managed to run docling-serve on a DGX-Spark as a docker container and have setup the container image with the all the models downloaded through docling-tools models download --all (using ghcr.io/docling-project/docling-serve-cu130:1.26.0 as the base image) and with the following environment variables

• DOCLING_SERVE_ENABLE_UI=1
• DOCLING_SERVE_ENABLE_MANAGEMENT_ENDPOINTS=1
• DOCLING_SERVE_ENABLE_REMOTE_SERVICES=1
• DOCLING_SERVE_ALLOW_CUSTOM_VLM_CONFIG=1
• DOCLING_SERVE_ALLOW_CUSTOM_PICTURE_DESCRIPTION_CONFIG=1
• DOCLING_SERVE_ALLOW_CUSTOM_CODE_FORMULA_CONFIG=1
• DOCLING_LOG_LEVEL=DEBUG

I am trying to use a client to make requests to this container, with the various presets. Is there a list of preset strings which are considered valid by the API? I am looking for ALL available preset strings for the following:

• ocr_preset
• picture_description_preset
• vlm_pipeline_preset
• code_formula_preset
• table_structure_preset
• layout_preset
• picture_classification_preset

Are the preset strings same as the preset ids mentioned in the model catalog page?

Or are these picked up from those defined in the preset registry in DoclingConverterManager?

Any help is appreciated.

P.S. I couldn't open a discussion under docling-serve as that repository didn't have Discussions enabled. Apologies if this is the wrong place to open this discussion.

[AliFozooni]

One image-tag detail first: the official live release image is ghcr.io/docling-project/docling-serve-cu130:v1.26.0; the literal no-v tag in the question currently returns “not found.” The official release build is multi-arch and pins docling-serve commit 80878c6; its frozen lock resolves docling-slim 2.107.0 and docling-jobkit 2.0.0. With exactly the environment shown (and no additional ALLOWED_*, CUSTOM_*, or DEFAULT_* settings), these are the recognized request strings:

Field	Count	Recognized strings	default resolution / note
ocr_preset	8	auto, easyocr, kserve_v2_ocr, nemotron-ocr, ocrmac, rapidocr, tesseract, tesserocr	The request default is auto; literal default is rejected by the service policy.
picture_description_preset	1	default	default -> smolvlm
vlm_pipeline_preset	18	default, smoldocling, deepseek_ocr, granite_vision, pixtral, got_ocr, phi4, qwen, nanonets_ocr2, gemma_12b, gemma_27b, dolphin, glm_ocr, lightonocr, falcon_ocr, chandra_ocr2, dots_ocr, dots_mocr	default -> granite_docling. Literal granite_docling is not added as a separate key when it is the configured default target.
code_formula_preset	1 registry key / 0 resolvable	default	It reaches the registry but fails Docling preset resolution; see below.
table_structure_preset	4 request strings	default, tableformer_v1_accurate, tableformer_v1_fast, tableformer_v2	The manager registry contains the three named entries; the parser special-cases default -> tableformer_v1_accurate.
layout_preset	1	default	default -> docling_layout_default
picture_classification_preset	1	default	default -> document_figure_classifier_v2

The source of truth for the API-facing strings is the jobkit manager's _build_preset_registries, after docling-serve settings are applied. In this version, VLM auto-enumerates Docling presets, whereas picture description, code/formula, layout, and picture classification add only default unless their explicit DOCLING_SERVE_ALLOWED_*_PRESETS or DOCLING_SERVE_CUSTOM_*_PRESETS settings are populated. Table structure has three manager-defined presets, and OCR comes from registered factory kinds plus a separate service-policy check.

There is one important 1.26.0 code/formula mismatch. Serve configures default_code_formula_preset = "default", so jobkit builds default -> default and passes that target to CodeFormulaVlmOptions.from_preset. But Docling 2.107.0 registers only codeformulav2 and granite_docling. Thus an explicit code_formula_preset: "default" reaches the registry but fails resolution with “Preset 'default' not found.” The safe client-side choice in this build is to omit code_formula_preset; then PdfPipelineOptions retains its verified codeformulav2 default.

The model catalog/downloader IDs are therefore not interchangeable with API preset strings. docling-tools models download --all iterates a separate finite artifact catalog containing names such as layout, tableformer, code_formula, picture_classifier, and granitedocling (exact list). Some names happen to coincide, but, for example, downloader granitedocling supports preset granite_docling, and downloader code_formula supplies the codeformulav2 artifacts. --all also does not download every repository referenced by every VLM preset.

Registry membership is not a guarantee that the preset can initialize on this platform:

• On the Linux ARM64 DGX Spark, ocrmac cannot run; nemotron-ocr requires Linux x86_64, Python 3.12, CUDA, and CUDA 13.x; and bare kserve_v2_ocr lacks its required endpoint URL. The image does include the dependencies for easyocr, rapidocr, tesserocr, and the Tesseract CLI.
• gemma_12b/gemma_27b default to MLX (not available in this Linux image), dots_ocr/dots_mocr default to vLLM (not present in the lock), and deepseek_ocr defaults to an Ollama API at localhost:11434. Enabling remote services permits remote calls; it does not start Ollama or Triton.

Finally, the three DOCLING_SERVE_ALLOW_CUSTOM_*_CONFIG=1 flags only permit the corresponding request-side *_custom_config objects. They do not add preset IDs, alter aliases, or download models. Named admin presets and built-in allowlists use the separate CUSTOM_*_PRESETS and ALLOWED_*_PRESETS settings.

There is no preset-discovery endpoint in 1.26.0: OpenAPI models these fields as strings with examples rather than enums, and the enabled management endpoints expose memory statistics/counts only.

[ganny-gitaa]

Thank you for the detailed response. I forgot to add the "v" to the version string when copying from my terminal. My bad.

I was bitten by the code/formula mismatch which I found out after looking at the source code. I'll configure it to use remote services for the models not present the artifact catalog.