refresh configuration docs

docs/models_repository_classic.md

@@ -9,7 +9,7 @@ ovms_docs_cloud_storage
 
 ```
 
-Traditional AI models perform data analysis in a single inference operation. They can be used over KServe API or TensorFlow API. 
+Classic models perform data analysis in a single inference operation. They can be served using the KServe API. 
 
 The AI models served by OpenVINO™ Model Server must be in either of the five formats:
 - [OpenVINO IR](https://docs.openvino.ai/2026/documentation/openvino-ir-format.html), where the graph is represented in .bin and .xml files
@@ -22,8 +22,7 @@ To use models trained in other formats you need to convert them first. To do so,
 OpenVINO’s [conversion tool](https://docs.openvino.ai/2026/openvino-workflow/model-preparation/convert-model-to-ir.html) for IR, or different
 [converters](https://onnx.ai/supported-tools.html) for ONNX.
 
-The models need to be placed and mounted in a particular directory structure and according to the following rules:
-When the models are hosted on the cloud storage, they should be frozen to be imported successfully.
+The models need to be placed and mounted in a particular directory structure according to the following rules:
 
 ```
 tree models/
@@ -66,8 +65,7 @@ the version number in parameters, by default, the latest version is served.
 - Every version folder _must_ include model files, that is, .bin and .xml for IR, .onnx for ONNX, .pdiparams and .pdmodel for Paddlepaddle. The file name can be arbitrary.
 - Each model defines input and output tensors in the AI graph. The client passes data to model input tensors by filling appropriate entries in the request input map.
 - Prediction results can be read from the response output map. By default, OpenVINO™ Model Server uses model tensor names as input and output names in prediction requests and responses. The client passes the input values to the request and reads the results by referring to the corresponding output names.
-- It is possible to adjust this behavior by adding an optional .json file named `mapping_config.json`.
-It can map the input and output keys to the appropriate tensors. This extra mapping can be used to enable user-friendly names for models with difficult tensor names. Here is an example of `mapping_config.json`:
+- You can optionally add a `mapping_config.json` file to customize input and output names. This file maps tensor names to user-friendly keys, which is particularly useful for models with complex tensor naming. Here is an example:
 ```json
 {
        "inputs":{
@@ -80,7 +78,25 @@ It can map the input and output keys to the appropriate tensors. This extra mapp
 }
 ```
 
-For more information on how to use cloud hosted models, refer to the [article](./using_cloud_storage.md).
+## Serving multiple models
 
-Learn also how to [start the model server](./starting_server.md) 
+Serving many models at the same time requires preparing a `config.json` file with a list of models to be deployed. This can be done using the OVMS CLI
+
+```text
+ovms --add_to_config --config_path config.json --model_name model1 --target_device GPU --batch_size 1 --model_path models/model1
+```
+
+Models can also be removed from the configuration file:
+```text
+ovms --remove_from_config --config_path config.json --model_name model1
+```
+
+All models can be started with the following command:
+```
+ovms --config_path config.json --rest_port 8000 --port 9000
+```
+
+For more information on how to use cloud-hosted models, refer to the [cloud storage guide](./using_cloud_storage.md).
+
+For additional information, see how to [start the model server](./starting_server.md).
 

docs/prepare_generative_use_cases.md

@@ -7,13 +7,13 @@ hidden:
 ---
 
 ovms_docs_pull
-ovms_docs_pull_optimum
 ovms_demos_common_export
+ovms_docs_pull_optimum
 
 ```
 
-Prepare models using OVMS [pull mode](./pull_hf_models.md).
-
-Prepare models using OVMS with python [optimum pull mode](./pull_optimum_cli.md).
+Prepare models using OVMS [pull mode](./pull_hf_models.md) (recommended).
 
 Prepare models using [python script](../demos/common/export_models/README.md).
+
+Prepare models using OVMS with python [optimum pull mode](./pull_optimum_cli.md).

docs/pull_hf_models.md

@@ -1,27 +1,27 @@
 # OVMS Pull mode {#ovms_docs_pull}
 
-This document describes how to leverage OpenVINO Model Server (OVMS) pull feature to automate deployment configuration with Generative AI models. When pulling from [Hugging Face Hub](https://huggingface.co/) or when pulling GGUF model, no additional steps are required. However, when pulling models in Pytorch format, you have to install additional python dependencies when using baremetal execution so that optimum-cli is available for ovms executable or rely on the docker image `openvino/model_server:latest-py`. In summary you have 3 options:
+This document describes how to use the OpenVINO Model Server (OVMS) pull feature to automate deployment configuration for Generative AI models. When pulling models from [Hugging Face Hub](https://huggingface.co/) in IR or GGUF format, no additional setup is required. However, when pulling models in PyTorch format, you need additional Python dependencies on a bare-metal host so that `optimum-cli` is available to the OVMS executable. Docker image. In summary, you have three options:
 
-- pulling pre-configured models in IR format (described below)
-- pulling GGUF models from Hugging Face
-- pulling models with automatic conversion and quantization via optimum-cli. Described in the [pulling with conversion](https://github.com/openvinotoolkit/model_server/blob/main/docs/pull_optimum_cli.md)
+- pull pre-configured models in IR format (recommended)
+- pull GGUF models from Hugging Face
+- pull models with automatic conversion and quantization via `optimum-cli` (described in [pulling with conversion](./pull_optimum_cli.md))
 
-> **Note:** Models in IR format must be exported using `optimum-cli` including tokenizer and detokenizer files also in IR format, if applicable. If missing, tokenizer and detokenizer should be added using `convert_tokenizer --with-detokenizer` tool.
+> **Note:** Models in IR format must be exported using `optimum-cli`, including tokenizer and detokenizer files (also in IR format), if applicable. If they are missing, add them with `convert_tokenizer --with-detokenizer`.
 
 ## Pulling pre-configured models
 
-There is a special OVMS mode to pull the model from Hugging Face without starting the service. It is triggered by `--pull` parameter. The application quits after the model is downloaded. Without `--pull` option, the model will be deployed and server started.
+There is a special OVMS mode that pulls a model from Hugging Face without starting the service. It is triggered by the `--pull` parameter. The application exits after the model is downloaded. Without `--pull`, the model is deployed and the server starts.
 
 ::::{tab-set}
 :::{tab-item} With Docker
 :sync: docker
 **Required:** Docker Engine installed
 ```text
-docker run $(id -u):$(id -g) --rm -v <model_repository_path>:/models:rw openvino/model_server:weekly --pull --source_model <model_name_in_HF> --model_repository_path /models --model_name <external_model_name> --target_device <DEVICE> [--gguf_filename SPECIFIC_QUANTIZATION_FILENAME.gguf] --task <task> [TASK_SPECIFIC_PARAMETERS]
+docker run --user $(id -u):$(id -g) --rm -v <model_repository_path>:/models:rw openvino/model_server:latest-gpu --pull --source_model <model_name_in_HF> --model_repository_path /models --model_name <external_model_name> --target_device <DEVICE> [--gguf_filename SPECIFIC_QUANTIZATION_FILENAME.gguf] --task <task> [TASK_SPECIFIC_PARAMETERS]
 ```
 :::
 
-:::{tab-item} On Baremetal Host
+:::{tab-item} On Bare-metal Host
 :sync: baremetal
 **Required:** OpenVINO Model Server package - see [deployment instructions](./deploying_server_baremetal.md) for details.
 
@@ -31,7 +31,7 @@ ovms --pull --source_model <model_name_in_HF> --model_repository_path <model_rep
 :::
 ::::
 
-*Note:* GGUF format model is only supported with `--task text_generation`. For list of supported models check [blog](https://blog.openvino.ai/blog-posts/openvino-genai-supports-gguf-models).
+> **Note:** GGUF models are supported only with `--task text_generation`. For a list of supported models, see the [blog](https://blog.openvino.ai/blog-posts/openvino-genai-supports-gguf-models).
 
 Example for pulling `OpenVINO/Phi-3-mini-FastDraft-50M-int8-ov`:
 
@@ -41,11 +41,11 @@ Example for pulling `OpenVINO/Phi-3-mini-FastDraft-50M-int8-ov`:
 **Required:** Docker Engine installed
 
 ```text
-docker run $(id -u):$(id -g) --rm -v <model_repository_path>:/models:rw openvino/model_server:latest --pull --source_model "OpenVINO/Phi-3-mini-FastDraft-50M-int8-ov" --model_repository_path /models --model_name Phi-3-mini-FastDraft-50M-int8-ov --task text_generation
+docker run --user $(id -u):$(id -g) --rm -v <model_repository_path>:/models:rw openvino/model_server:latest-gpu --pull --source_model "OpenVINO/Phi-3-mini-FastDraft-50M-int8-ov" --model_repository_path /models --model_name Phi-3-mini-FastDraft-50M-int8-ov --task text_generation
 ```
 :::
 
-:::{tab-item} On Baremetal Host
+:::{tab-item} On Bare-metal Host
 :sync: baremetal
 **Required:** OpenVINO Model Server package - see [deployment instructions](./deploying_server_baremetal.md) for details.
 
@@ -55,19 +55,19 @@ ovms --pull --source_model "OpenVINO/Phi-3-mini-FastDraft-50M-int8-ov" --model_r
 :::
 ::::
 
-Example for pulling GGUF model `unsloth/Llama-3.2-1B-Instruct-GGUF` with Q4_K_M quantization on baremetal host:
+Example for pulling the GGUF model `unsloth/Llama-3.2-1B-Instruct-GGUF` with Q4_K_M quantization:
 
 ::::{tab-set}
 :::{tab-item} With Docker
 :sync: docker
 **Required:** Docker Engine installed
 
 ```text
-docker run $(id -u):$(id -g) --rm -v <model_repository_path>:/models:rw openvino/model_server:weekly --pull --source_model "unsloth/Llama-3.2-1B-Instruct-GGUF" --model_repository_path /models --model_name unsloth/Llama-3.2-1B-Instruct-GGUF --task text_generation --gguf_filename Llama-3.2-1B-Instruct-Q4_K_M.gguf
+docker run --user $(id -u):$(id -g) --rm -v <model_repository_path>:/models:rw openvino/model_server:latest --pull --source_model "unsloth/Llama-3.2-1B-Instruct-GGUF" --model_repository_path /models --model_name unsloth/Llama-3.2-1B-Instruct-GGUF --task text_generation --gguf_filename Llama-3.2-1B-Instruct-Q4_K_M.gguf
 ```
 :::
 
-:::{tab-item} On Baremetal Host
+:::{tab-item} On Bare-metal Host
 :sync: baremetal
 **Required:** OpenVINO Model Server package - see [deployment instructions](./deploying_server_baremetal.md) for details.
 ```text
@@ -78,21 +78,21 @@ ovms --pull --source_model "unsloth/Llama-3.2-1B-Instruct-GGUF" --model_reposito
 
 ## Pulling models outside OpenVINO organization
 
-It is possible to pull models outside of OpenVINO organization. 
+It is possible to pull models outside the OpenVINO organization.
 
 Example for pulling `Echo9Zulu/phi-4-int4_asym-awq-ov`:
 
 ```text
-ovms --pull --source_model Echo9Zulu/phi-4-int4_asym-awq-ov --model_repository_path /models --model_name phi-4-int4_asym-awq-ov --target_device CPU --task text_generation 
+ovms --pull --source_model Echo9Zulu/phi-4-int4_asym-awq-ov --model_repository_path /models --model_name phi-4-int4_asym-awq-ov --target_device CPU --task text_generation
 ```
 
-> **Note:** These models aren't tested properly and their accuracy or performance may be low.
+> **Note:** These models are NOT tested by OpenVINO team, and their accuracy or performance is not guaranteed.
 
 Check [parameters page](./parameters.md) for detailed descriptions of configuration options and parameter usage.
 
-In case you want to setup model and start server in one step, follow [instructions](./starting_server.md).
+If you want to set up a model and start the server in one step, follow the [instructions](./starting_server.md).
 
-> **Note:**  When using pull mode you need both read and write access rights to models repository.
+> **Note:** When using pull mode, you need both read and write permissions for the model repository.
 
 ## Pulling Image Generation Models with LoRA Adapters
 
@@ -107,7 +107,7 @@ ovms --rest_port 8000 \
 ```
 
 The `--source_loras` format is a comma-separated list of `alias=source[:alpha]` entries. Supported source types:
-- HuggingFace repository: `alias=org/repo` or `alias=org/repo@filename.safetensors`
+- Hugging Face repository: `alias=org/repo` or `alias=org/repo@filename.safetensors`
 - Direct URL: `alias=https://url/to/file.safetensors`
 - Local file (Linux): `alias=/path/to/file.safetensors`
 - Local file (Windows): `alias=C:\path\to\file.safetensors`
@@ -170,3 +170,14 @@ On startup OVMS logs the resolved configuration, e.g.:
 ```
 
 > **Note:** Resume relies on the remote server honoring HTTP `Range` requests. Hugging Face Hub supports this by default; private mirrors must allow ranged GETs for resume to work.
+
+
+## Updating model runtime parameters
+
+When pulling a model from Hugging Face, a special configuration file, `graph.pbtxt`, is created with runtime parameters and pipeline configuration.
+You can update it with OVMS CLI in two ways:
+- Re-run the same pull command. This updates `graph.pbtxt` and keeps the remaining model files.
+- Use the `--configure` option:
+```text
+ovms --configure --model_path /models/model1 --task text_generation --target_device GPU --cache_size 5 --cache_dir .ov_cache
+```