Regression 2026.0 - ovms stuck in initializing servable

[jpm-canonical]

Describe the bug
Likely a duplicate of openvinotoolkit/model_server#4059

OVMS v2026.0 gets stuck in Initializing Visual Language Model Legacy servable, using 100% on a single thread. SIGTERM (ctrl+c) is ignored, and one needs to send the SIGKILL signal to stop it.

OVMS v2025.4.1 does not have this issue.

To Reproduce
Steps to reproduce the behavior:

1. Download ovms_ubuntu24_python_on.tar.gz for release 2026.0. Extract.
2. OVMS launch command:

   #!/bin/bash
   
   # Add staged shared objects
   export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:./lib
   export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:./usr/lib/$ARCH_TRIPLET
   export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:./usr/local/lib
   #export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib
   
   # Add Python dependencies
   export PYTHONPATH=$PYTHONPATH:./lib/python # part of ovms package
   export PYTHONPATH=$PYTHONPATH:./lib/python3.12/site-packages
   
   exec bin/ovms --rest_port 8328 --rest_bind_address 127.0.0.1 \
   --source_model gemma-3-4b-it-ov-int4-fq \
   --model_repository_path /home/jpmeijers/models \
   --pipeline_type VLM --task text_generation \
   --cache_size 2 --log_level DEBUG --target_device GPU
   

3. See logs get stuck at
   [modelmanager][info][servable_initializer.cpp:448] Initializing Visual Language Model Legacy servable

Logs
TRACE enabled.

OVMS 2026.0 getting stuck: ovms-logs-2026.0.txt

OVMS 2025.4.1 working as expected: ovms-logs-2024.4.1.txt

Configuration

1. OVMS version - 2026.0 fails, 2025.4.1 works
2. OVMS config.json file - none
3. CPU, accelerator's versions if applicable:
   • Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz
   • Intel Corporation DG2 [Arc A580] (rev 08)
4. Model repository directory structure

   $ tree models/
   models/
   └── gemma-3-4b-it-ov-int4-fq
       ├── added_tokens.json
       ├── chat_template.jinja
       ├── config.json
       ├── generation_config.json
       ├── graph.pbtxt
       ├── openvino_config.json
       ├── openvino_detokenizer.bin
       ├── openvino_detokenizer.xml
       ├── openvino_language_model.bin
       ├── openvino_language_model.xml
       ├── openvino_text_embeddings_model.bin
       ├── openvino_text_embeddings_model.xml
       ├── openvino_tokenizer.bin
       ├── openvino_tokenizer.xml
       ├── openvino_vision_embeddings_model.bin
       ├── openvino_vision_embeddings_model.xml
       ├── preprocessor_config.json
       ├── processor_config.json
       ├── README.md
       ├── special_tokens_map.json
       ├── tokenizer_config.json
       ├── tokenizer.json
       └── tokenizer.model
   
   2 directories, 23 files
   

5. Model or publicly available similar model that reproduces the issue:
   git clone --depth 1 https://huggingface.co/llmware/gemma-3-4b-it-ov-int4-fq
6. OS: Ubuntu Desktop 24.04.4

[dtrawins]

@jpm-canonical I tested that this model works fine on A580 card on my side but it was with newer CPU on board. Can you try this command :
docker run -p 8000:8000 -d --device /dev/dri -u 0 -v $(pwd)/models:/models openvino/model_server:2026.0-gpu --model_repository_path /models --source_model llmware/gemma-3-4b-it-ov-int4-fq --target_device GPU --rest_port 8000 --task text_generation --log_level DEBUG
or
docker run -p 8000:8000 -d --device /dev/dri -u 0 -v $(pwd)/models:/models openvino/model_server:weekly --model_repository_path /models --source_model llmware/gemma-3-4b-it-ov-int4-fq --target_device GPU --rest_port 8000 --task text_generation --log_level DEBUG
That would exclude problems with gpu drivers.
Can you also try env variable OPENVINO_LOG_LEVEL=4. It would give more hint which model is failing to load.

[jpm-canonical]

Hi @dtrawins. Attached the logs for the two versions running in docker. The weekly build handles sigterm slightly better, but it is still broken. In both cases they get stuck with Initializing Language Model Continuous Batching servable, taking 100% CPU on one core, like the original issue description reports.

• 2026.0 ovms-docker-2026.0.txt
• weekly ovms-docker-weekly.txt

[dtrawins]

@jpm-canonical thank you for the logs. The culprit has been identified in https://github.com/openvinotoolkit/openvino.genai/blame/da0974023b43ca3db9b094d80f4b7c08918f3927/src/cpp/CMakeLists.txt#L228
I'm reassigning this issue to genai repo to apply adequate fix. It should be correcting the package in next release or at least option to build from source with native architecture

[as-suvorov]

@yangwang201911 Could you please take a look.

[yangwang201911]

@as-suvorov sure. Thanks for identifying the root cause. I‘m working on the fix. The global --mavx2 in the CMake will be removed. SIMD optimization will be moved into CDPruner's fast_dpp.cpp with runtime CPUID detection, so AVX is used only when the CPU actually supports it.

PR is coming shortly.