Mia Experts is a new generation medical software platform designed by a physician, for physicians. From the very beginning, the product was built to integrate artificial intelligence in a way that is useful, secure, and aligned with the realities of medical practice.

Today, many doctors spend a significant part of their day dealing with administrative tasks rather than focusing on patient care and clinical decision-making. Existing medical software is often outdated, poorly designed, and disconnected from how physicians actually work.

Mia Experts aims to change that. By leveraging artificial intelligence, the platform automates repetitive tasks and structures medical data in a meaningful and usable way. The goal is simple: give physicians back their time.

The solution primarily targets private practitioners, particularly in general medicine and surgical specialties, where efficient data management, reliability, and time savings are critical.

Built from Real Medical Experience

The idea behind Mia Experts originated from the daily experience of Vincent Salabi, a surgeon who repeatedly encountered the same issue: medical software that was slow, repetitive, and time-consuming.

Instead of helping doctors, these tools often added friction to their workflow.

At the same time, a major technological shift was occurring: artificial intelligence was becoming accessible in a way that could be deployed securely and within a sovereign regulatory framework.

Mia Experts was born from the collaboration of three co-founders with complementary expertise — medical, technical, and entrepreneurial — united by a shared ambition: to fundamentally rethink the physician’s digital workspace.

Early Milestones and Key Achievements

From the earliest stages, several key milestones helped shape the development of Mia Experts.

One of the first successes was designing the software architecture. The team built a simple, modular, and scalable architecture capable of intelligently interacting with both patient and physician data.

The objective was clear: eliminate unnecessary repetition, ensure every piece of data has meaning, and enable reliable data usage — whether for prescription generation or reducing medical errors.

Operating in the highly regulated healthcare sector also required building an infrastructure compliant with Health Data Hosting (HDS) regulations. Mia Experts chose OVHcloud, ensuring health data sovereignty and providing a robust and secure cloud foundation.

Infrastructure management is handled in partnership with Lecpac Consulting, allowing the team to meet regulatory requirements while focusing on product development and innovation.

Another major milestone came through early presentations at medical conferences, particularly in orthopedic and urological surgery. The response from physicians was extremely positive. The software’s usability and clinical logic quickly generated word-of-mouth interest — even among doctors who had not been directly approached.

Mia Experts also achieved several regulatory and technological milestones:

• LAP certification for prescription software, obtained in collaboration with healthtech company Posos
• INSi compliance, enabling integration with national health identity standards

Even before official product launch, the startup received around 50 pre-orders purely through demonstrations and conference discussions.

The platform is now entering its beta testing phase, with the first deployments planned soon.

Core Values Driving the Product

The development of Mia Experts is guided by a set of strong principles:

• Simplicity – intuitive interfaces designed for real medical workflows
• Pragmatism – AI must deliver measurable time savings
• Data sovereignty – full control over hosting and infrastructure
• Health data security – non-negotiable protection standards
• Intelligent data structuring – ensuring reliable and actionable medical information

Business, Technical and Regulatory Complexity

Building a medical software platform involves navigating a unique combination of business, technological, and regulatory challenges.

From a business perspective, the first hurdle was securing funding while preserving technological independence. Mia Experts achieved this through an initial funding round involving physician investors, complemented by support from Bpifrance and the French Tech Grant program.

On the technical side, the strict healthcare regulatory environment posed significant challenges. Compliance with HDS standards required implementing strong guarantees around security, traceability, service availability, and access governance from the very beginning.

Another critical challenge involved health data interoperability. Medical data must follow standardized national frameworks and coding systems. Mia Experts needed to structure and transform this data so it could interact seamlessly with national health services such as secure messaging systems and health data platforms.

Yet the biggest challenge was balancing all these constraints with a smooth user experience.

The ambition was never to create software that was simply compliant but difficult to use. Instead, the goal was to design a platform that remains intuitive, efficient, and truly supportive of physicians’ daily work.

Why Mia Experts Chose the Cloud

Cloud infrastructure quickly became a natural choice for the project.

First, artificial intelligence requires scalable computing resources. Running AI endpoints, fine-tuning models, and processing medical voice data demand infrastructure that can scale dynamically while protecting sensitive data.

Second, the cloud offers strong advantages for security and regulatory compliance. As a medical software publisher, Mia Experts needed an infrastructure capable of guaranteeing both data sovereignty and regulatory compliance within the European framework.

Finally, the cloud enables a much more agile product strategy. Unlike traditional locally installed medical software, cloud-based architecture allows centralized updates and continuous product improvement without disrupting physicians’ workflows.

For a fast-growing startup, this flexibility is essential.

Leveraging OVHcloud to Build a Sovereign Health Infrastructure

Choosing OVHcloud was a strategic decision for Mia Experts, especially in a context where health data sovereignty is a critical issue.

Many solutions rely on non-European cloud providers. OVHcloud allowed the startup to build its infrastructure on a secure, sovereign European cloud, fully compliant with French and EU regulations.

This has become a strong differentiator — both from a regulatory standpoint and in terms of trust with physicians.

The OVHcloud Startup Program also played a key role during the early development phase by helping offset the high technical costs associated with innovation.

Mia Experts relies heavily on speech-to-text and AI models for generating medical reports. Fine-tuning these models to understand medical vocabulary requires substantial computing power. The program allowed the team to train and test these models without immediate financial pressure.

The Infrastructure Behind Mia Experts

Today, the platform runs on a robust cloud architecture built on OVHcloud services, including:

• Managed Kubernetes for Dev, Pre-production, and Production environments
• S3-compatible object storage for medical documents and AI models
• GPU instances supporting real-time medical speech transcription
• AI Endpoints for LLMs such as Mistral, Llama, and GPT-OSS
• Dedicated Public Cloud instances hosting GitHub CI/CD runners

All infrastructure is hosted in France, ensuring compliance with GDPR and HDS requirements.

One major advantage of OVHcloud AI endpoints is transparency: customer data is not used to train external models, a key concern in healthcare environments.

Tangible Results and Impact

The collaboration with OVHcloud has enabled several concrete achievements.

First, Mia Experts successfully deployed an infrastructure fully compliant with HDS health data hosting standards, guaranteeing high levels of security, availability, and traceability.

Second, the startup has been able to build and control its own AI capabilities, particularly around speech recognition and medical text generation. The voice recognition system has already been adapted to medical vocabulary, delivering strong accuracy in clinical contexts.

Another key outcome is AI sovereignty. By hosting AI inference within a controlled European environment, Mia Experts retains full control over its data, models, and algorithms.

Finally, the cloud infrastructure provides significant operational agility. The team can deploy updates quickly, iterate on AI models, and continuously improve application performance.

Accelerating Product Adoption

These technological choices have significantly strengthened Mia Experts’ positioning within the medical software ecosystem.

The cloud infrastructure makes the solution eligible for Ségur V2 standards, a key regulatory benchmark for healthcare software interoperability in France.

This strengthens credibility with physicians and facilitates integration into the national digital health ecosystem.

By maintaining full control over its AI pipeline — from hosting to model fine-tuning — Mia Experts can guarantee both data confidentiality and high-quality performance tailored to medical language.

What’s Next for Mia Experts

The next step is the progressive onboarding of the first users, with around 50 pre-registrations already secured before the official launch.

In the medium term, the startup aims to reach:

• 300 users within two years
• 500 users within three years

At the same time, Mia Experts plans to expand beyond surgical specialties with the launch of Mia Experts for General Practice, followed by extensions into additional medical disciplines.

The long-term vision is to build a modular medical platform adaptable to multiple specialties while sharing a unified technological foundation.

Advice for Other Startups

For startups building AI-driven products, the Mia Experts team highlights three key lessons.

First, anticipate your data strategy early. AI models are only as good as the data used to train them. Structuring and preparing datasets before accessing cloud resources can provide a major competitive advantage.

Second, do not underestimate regulatory complexity, especially in sectors like healthcare. Partnering with an experienced infrastructure manager can significantly accelerate deployment.

Finally, think of the cloud not only as hosting infrastructure but as a strategic platform for innovation and scalability.

Conclusion

The journey of Mia Experts shows that innovation in healthcare requires a careful balance between technological ambition, regulatory rigor, and practical usability.

By building on a sovereign and compliant cloud infrastructure from the outset, the startup has laid strong foundations for developing a medical platform that genuinely supports physicians.

The collaboration with OVHcloud has enabled Mia Experts to deploy a secure, scalable, and AI-ready infrastructure, ensuring full control over both health data and AI models.

For startups operating in highly regulated sectors, choosing the right cloud ecosystem can make all the difference — enabling innovation, accelerating growth, and building trust from day one.

Don’t let infrastructure costs limit your growth. We strongly urge other startups to join the OVHcloud Startup Program. Contact their team to build your own foundation for sustainable success.

If you’re a startup looking to transform your business, we encourage you to join the OVHcloud Startup Program or contact OVHcloud to discover how our solutions can support your journey!

This reference architecture demonstrates how to deploy a Large Language Model (LLM) inference system using vLLM on OVHcloud Managed Kubernetes Service (MKS). The solution leverages NVIDIA L40S GPUs to serve the Qwen3-VL-8B-Instruct multimodal model (vision + text) with OpenAI-compatible API endpoints.

This comprehensive guide shows you how to deploy, to scale automatically, and how to monitor vLLM-based LLM workloads on the OVHcloud infrastructure.

What are the key benefits?

• Cost-effectiveness: Leverage managed services to minimise operational overhead
• Real-time observability: Track Time-to-First-Token (TTFT), throughput, and resource utilisation
• Sovereign infrastructure: Keep all metrics and data within European datacentres
• Scalable by design: Automatically scale GPU inference replicas based on real workload demand

Context

Managed Kubernetes Service

OVHcloud MKS is a fully managed Kubernetes platform designed to help you deploy, operate, and scale containerised applications in production. It provides a secure and reliable Kubernetes environment without the operational overhead of managing the control plane.

How does this benefit you?

• Cost-efficient: Pay only for worker nodes and consumed resources, with no additional charge for the Kubernetes control plane
• Fully managed Kubernetes: Certified upstream Kubernetes with automated control plane management, provided upgrades and high availability
• Production-ready by design: Built-in integrations with OVHcloud Load Balancers, networking, and persistent storage
• Scalable and flexible: Scale workloads easily, node pools to match application demand
• Open and portable: Based on standard Kubernetes APIs, enable seamless integration with open-source ecosystems and avoid vendor lock-in

In the following guide, all services are deployed within the OVHcloud Public Cloud.

Architecture overview

This reference architecture demonstrates a basic deployment of vLLM for vision-language model inference on OVHcloud Managed Kubernetes Service, featuring:

• High-availability deployment with 2 GPU nodes (NVIDIA L40S)
• Optimised GPU utilisation with proper driver configuration
• Scalable infrastructure supporting vision-language models
• Comprehensive monitoring using Prometheus, Grafana, and DCGM
• Full observability for both application and hardware metrics

Data flow:

1. Inference request:
   • User → LoadBalancer → Gateway → NGINX Ingress → “Qwen3 VL” Service → vLLM Pod → GPU
   • Response follows reverse path with streaming support
2. Metrics collection:
   • vLLM Pods expose /metrics endpoint (port 8000)
   • DCGM Exporters expose GPU metrics (port 9400)
   • Prometheus scrapes both endpoints every 30 seconds
   • Grafana queries Prometheus for visualization
3. Load distribution
   • NGINX Ingress uses cookie-based session affinity
   • vLLM Service uses ClientIP session affinity
   • Anti-affinity ensures 1 pod per GPU node

Prerequisites

Before you begin, ensure you have:

• An OVHcloud Public Cloud account
• An OpenStack user with the Administrator role
• Hugging Face access – create a Hugging Face account and generate an access token
• kubectl already installed and helm installed (at least version 3.x)

🚀 Now you have all the ingredients, it’s time to deploy the recipe for Qwen/Qwen3-VL-8B-Instruct using vLLM and MKS!

Architecture guide: Native GPU deployment of vLLM on MKS with full stack observability

This reference architecture describes a Large Language Model deployment using vLLM inference server and Kubernetes, to enjoy the benefits of a service that’s both highly available and monitorable in real time.

Step 1 – Create MKS cluster and Node pools

From OVHcloud Control Panel, create a Kubernetes cluster using the MKS.

Navigate to: Public Cloud → Managed Kubernetes Service → Create a cluster

1. Configure cluster

Consider using the following configuration for the current use case:

• Name: vllm-deployment-l40s-qwen3-8b
• Location: 1-AZ Region – Gravelines (GRA11)
• Plan: Free (or Standard)
• Network: attach a Private network (e.g. 0000 - AI Private Network)
• Version: Latest stable (e.g. 1.34)

2. Create GPU Node pool

During the cluster creation, configure the vLLM Node pool for GPUs:

• Node pool name: vllm
• Flavor: L40S-90
• Number of nodes: 2
• Autoscaling: Disabled (OFF)

Why L40S-90?

• Cost-effective for single-model deployment (1 GPU per node)
• Sufficient RAM (90GB) for Qwen3-VL-8B model

You should see your cluster (e.g. vllm-deployment-l40s-qwen3-8b) in the list, along with the following information:

You can now set up the node pool dedicated to monitoring.

3. Create CPU Node pool

From your cluster, click on Add a node pool and configure it as follow:

• Node pool name: monitoring
• Flavor: B2-15
• Number of nodes: 1
• Autoscaling: Disabled (OFF)

✅ Note

Monitoring stack can run on GPU nodes if cost is a concern. Dedicated CPU node provides better isolation and resource management.

If the status is green with the OK label, you can proceed to the next step.

4. Configure Kubernetes access

Once your nodes have been provisioned, you can download the Kubeconfig file and configure kubectl with your MKS cluster.

# configure kubectl with your MKS cluster
export KUBECONFIG=/path/to/your/kubeconfig-xxxxxx.yml

# verify cluster connectivity
kubectl cluster-info
kubectl get nodes

Returning:

NAME                     STATUS   ROLES    AGE   VERSION
monitoring-node-xxxxxx   Ready    <none>   1d   v1.34.2
vllm-node-yyyyyy         Ready    <none>   1d   v1.34.2
vllm-node-zzzzzz         Ready    <none>   1d   v1.34.2

Before going further, add a label to the CPU node for monitoring workloads.

CPU_NODE=$(kubectl get nodes -o json | \
  jq -r '.items[] | select(.status.allocatable."nvidia.com/gpu" == null) | .metadata.name')
kubectl label node $CPU_NODE node-role=monitoring

Finally, check with the following command:

NAME                     GPU      ROLE
monitoring-node-xxxxxx   <none>   monitoring
vllm-node-yyyyyy         1        <none>
vllm-node-zzzzzz         1        <none>

Once both nodes are in Ready status, you can proceed to the next step.

Step 2 – Install GPU operator

To start, consider setting up the GPU operator.

✅ Note

This step is based on this OVHcloud documentation: Deploying a GPU application on OVHcloud Managed Kubernetes Service

1. Add NVIDIA helm repository and create namespace

Add NVIDIA helm repo:

helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm repo update

And create Namespace as follow.

kubectl create namespace gpu-operator

2. Install GPU operator with correct configuration

The GPU Operator must be configured with specific driver versions to ensure compatibility with vLLM containers.

However, the default installation uses recent drivers (580.x with CUDA 13.x) which are incompatible with vLLM containers (CUDA 12.x).

Solution: Force driver version 535.183.01 (CUDA 12.2).

helm install gpu-operator nvidia/gpu-operator \
  -n gpu-operator \
  --set driver.enabled=true \
  --set driver.version="535.183.01" \
  --set toolkit.enabled=true \
  --set operator.defaultRuntime=containerd \
  --set devicePlugin.enabled=true \
  --set dcgmExporter.enabled=true \
  --set dcgmExporter.image="dcgm-exporter" \
  --set dcgmExporter.version="3.1.7-3.1.4-ubuntu20.04" \
  --set gfd.enabled=true \
  --set migManager.enabled=false \
  --set nodeStatusExporter.enabled=true \
  --set validator.driver.enable=false \
  --set validator.toolkit.enable=false \
  --set validator.plugin.enable=false \
  --timeout 20m

✅ Note

Specifying the DCGM version may only be necessary if you encounter problems with the default image (e.g. ‘ImagePullBackOff’). If this is the case, add the following parameters:
--set dcgmExporter.repository="nvcr.io/nvidia/k8s"
--set dcgmExporter.image="dcgm-exporter"
--set dcgmExporter.version="3.1.7-3.1.4-ubuntu20.04"

kubectl get pods -n gpu-operator

Note that all pods should reach Running state in 5-10 minutes.

You can also check the GPU availability:

kubectl get nodes -o json | jq -r '.items[] | select(.status.allocatable."nvidia.com/gpu" != null) | "\(.metadata.name): \(.status.allocatable."nvidia.com/gpu") GPU(s)"'

Returning:

vllm-node-yyyyyy: 1 GPU(s)
vllm-node-zzzzzz: 1 GPU(s)

And you can test to run nvidia-smi:

DRIVER_POD=$(kubectl get pods -n gpu-operator -l app=nvidia-driver-daemonset -o name | head -1)
kubectl exec -n gpu-operator $DRIVER_POD -- nvidia-smi

If GPU tests are working properly, you can move on DCGM service configuration.

3. Configure DCGM service

Why is DCGM Exporter required?

DCGM (Data Centre GPU Manager) is NVIDIA’s official tool for monitoring GPUs in production. The goal is to be able to collect and display metrics from both GPU nodes.

The metrics provided are:

• DCGM_FI_DEV_GPU_UTIL – GPU utilisation (%)
• DCGM_FI_DEV_GPU_TEMP – GPU temperature (°C)
• DCGM_FI_DEV_FB_USED – VRAM used (MB)
• DCGM_FI_DEV_FB_FREE – Free VRAM (MB)
• DCGM_FI_DEV_POWER_USAGE – Power consumption (W)
• And 50+ other GPU metrics

Next, ensure DCGM service has the correct labels and port configuration:

kubectl patch svc nvidia-dcgm-exporter -n gpu-operator --type merge -p '{
  "metadata": {
    "labels": {
      "app": "nvidia-dcgm-exporter"
    }
  },
  "spec": {
    "ports": [
      {
        "name": "metrics",
        "port": 9400,
        "targetPort": 9400,
        "protocol": "TCP"
      }
    ]
  }
}'

Verify the endpoints (should show 2 IPs, one per GPU node).

kubectl get endpoints nvidia-dcgm-exporter -n gpu-operator

NAME                   ENDPOINTS                       AGE
nvidia-dcgm-exporter   x.x.x.x:9400,x.x.x.x:9400   17d

Step 3 – Deploy Qwen3 VL 8B with vLLM inference server

The deployment of the Qwen 3 VL 8B model on two L40S GPU nodes is carried out in several stages.

1. Create namespace and Hugging Face secret

Start by creating Namespace:

kubectl create namespace vllm

Next, you must retrieve your Hugging Face token and replace the HF_TOKEN value by your own:

export HF_TOKEN="hf_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

Create your secret as follow:

kubectl create secret generic huggingface-secret \
  --from-literal=token=$HF_TOKEN \
  --namespace=vllm

Verify you obtain the following output by launching:

kubectl get secret huggingface-secret -n vllm

NAME                 TYPE     DATA   AGE
huggingface-secret   Opaque   1      14d

2. Create vLLM deployment configuration

First, you can create vllm-deployment-2nodes.yaml file.

Deploy vLLM:

kubectl apply -f vllm-deployment-2nodes.yaml

You can monitor the deployment (it should take 8-10 minutes for model download and loading).

kubectl get pods -n vllm -o wide -w

Expected output after 10 minutes:

NAME               READY  STATUS   RESTARTS  AGE  IP       NODE  
qwen3-vl-xxxx-yyy  1/1    Running  0         1d   X.X.X.X  vllm-node-yyyyyy
qwen3-vl-xxxx-zzz  1/1    Running  0         1d   X.X.X.X  vllm-node-zzzzzz

You can also check the container logs:

kubectl logs -f -n vllm <pod-name>

You should find in the logs: “Uvicorn running on http://0.0.0.0:8000“

Is everything installed correctly? Then let’s move on to the next step.

3. Add service label

Ensure service has the correct label for ServiceMonitor discovery.

kubectl label svc qwen3-vl-service -n vllm app=qwen3-vl --overwrite

You can now verify by launching the following command.

kubectl get svc qwen3-vl-service -n vllm --show-labels | grep "app=qwen3-vl"

Returning:

qwen3-vl-service  ClusterIP  X.X.X.X  <none> 8000/TCP 1d  app=qwen3-vl

Step 4 – Install NGINX ingress controller

⚠️ Moving beyond Ingress

Follow this tutorial if you want to use Gateway instead of Ingress.

1. Add helm repository and configure Ingress

First of all, add helm repository:

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

Create configuration file with ingress-nginx-values.yaml.

Then, install NGINX Ingress:

helm install ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx \
  --create-namespace \
  -f ingress-nginx-values.yaml \
  --wait

Wait for LoadBalancer IP. The external IP assignment should take 1-2 minutes.

kubectl get svc -n ingress-nginx ingress-nginx-controller -w

Once <EXTERNAL-IP> is no longer , Ctrl+C and export it:

export EXTERNAL_IP=<EXTERNAL-IP>
echo "API URL: http://$EXTERNAL_IP"

2. Create vLLM Ingress resource

Next, create vLLM Ingress using vllm-ingress.yaml.

Apply it as follow:

kubectl apply -f vllm-ingress.yaml

You can now test different API calls to verify that your deployment is functional.

3. Test API

Firstly, check if the model is available:

curl http://$EXTERNAL_IP/v1/models | jq

{
  "object": "list",
  "data": [
    {
      "id": "qwen3-vl-8b",
      "object": "model",
      "created": 1772472143,
      "owned_by": "vllm",
      "root": "Qwen/Qwen3-VL-8B-Instruct",
      "parent": null,
      "max_model_len": 8192,
      "permission": [
        {
          "id": "modelperm-8fb35cdd3208b068",
          "object": "model_permission",
          "created": 1772472143,
          "allow_create_engine": false,
          "allow_sampling": true,
          "allow_logprobs": true,
          "allow_search_indices": false,
          "allow_view": true,
          "allow_fine_tuning": false,
          "organization": "*",
          "group": null,
          "is_blocking": false
        }
      ]
    }
  ]
}

Next, test inference using the following request:

curl http://$EXTERNAL_IP/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3-vl-8b",
    "messages": [{"role": "user", "content": "Count from 1 to 10."}],
    "max_tokens": 100
  }' | jq '.choices[0].message.content'

"1, 2, 3, 4, 5, 6, 7, 8, 9, 10"

Great! You’re almost there…

Step 5 – Install Prometheus stack

Now, set up the monitoring stack that provides complete observability for application-level (vLLM) and hardware-level (GPU) metrics:

1. Add helm repository and create namespace

Add Prometheus helm repo:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

Then, create the monitoring Namespace.

kubectl create namespace monitoring

2. Create Prometheus deployment configuration and installation

First, create prometheus.yaml file.

Install Prometheus stack:

helm install prometheus prometheus-community/kube-prometheus-stack \
  -n monitoring \
  -f prometheus.yaml \
  --timeout 10m \
  --wait

Now, monitor its installation and wait until the pods are ready:

kubectl get pods -n monitoring -w

If all pods are running successfully, you can proceed to the next step.

3. Check that the installation is operational

First access Grafana in background:

kubectl port-forward -n monitoring svc/prometheus-grafana 3000:80 &

Test Grafana health:

curl -s http://localhost:3000/api/health | jq

{
  "database": "ok",
  "version": "12.3.3",
  "commit": "2a14494b2d6ab60f860d8b27603d0ccb264336f6"
}

You can now access to Grafana locally via http://localhost:3000. You will have to use:

• Login: admin
• Password: Admin123!vLLM

Well done! You can now proceed to the configuration step.

Step 6 – Configure ServiceMonitors

The ServiceMonitors is used to tell Prometheus which endpoints to scrape for metrics.

1. Create vLLM ServiceMonitor

Retrieve the file from the GitHub repository: vllm-servicemonitor.yaml.

Next, apply and check that the ServiceMonitor vllm-metrics exists:

kubectl apply -f vllm-servicemonitor.yaml
kubectl get servicemonitor -n vllm

2. Create DCGM ServiceMonitor

First, create the dcgm-servicemonitor.yaml file.

Once again, apply and verify:

kubectl apply -f dcgm-servicemonitor.yaml
kubectl get servicemonitor -n gpu-operator

gpu-operator                  1d
nvidia-dcgm-exporter          1d
nvidia-node-status-exporter   1d

3. Configure Prometheus for Cross-Namespace discovery

Apply a patch to allow Prometheus to discover ServiceMonitors in all namespaces.

kubectl patch prometheus prometheus-kube-prometheus-prometheus -n monitoring --type merge -p '{
  "spec": {
    "serviceMonitorNamespaceSelector": {},
    "podMonitorNamespaceSelector": {}
  }
}'

Now you have to restart Prometheus.

1. Delete Prometheus pod to force configuration reload
2. Wait for Prometheus to restart

kubectl delete pod prometheus-prometheus-kube-prometheus-prometheus-0 -n monitoring

kubectl wait --for=condition=Ready \
  pod/prometheus-prometheus-kube-prometheus-prometheus-0 \
  -n monitoring \
  --timeout=180s

Wait about 2 minutes for discovery and finally, verify targets:

kubectl port-forward -n monitoring \
  prometheus-prometheus-kube-prometheus-prometheus-0 9090:9090 &

You can open in browser: http://localhost:9090/targets and search for:

• vllm
• dcgm

Note that the expected targets are:

• serviceMonitor/vllm/vllm-metrics/0 (2/2 UP)
• serviceMonitor/gpu-operator/nvidia-dcgm-exporter/0 (2/2 UP)

Step 7 – Create Grafana dashboards

In this final step, the goal is to create two Grafana dashboards to track both the software side with vLLM metrics and the hardware metrics that will monitor the GPU consumption and system.

1. vLLM application metrics

The dashboard provides insights into vLLM application performance, request handling, and resource utilization based on the following metrics:

This vLLM Grafana dashboard is composed of 23 panels:

The dashboard provides insights into LLM application performance, request handling, and resource utilisation based on the previous metrics.

Now create the dashboard using vllm-app-dashboard.json. Then, launch:

echo "Importing vLLM application dashboard..."
curl -X POST \
  'http://localhost:3000/api/dashboards/db' \
  -H 'Content-Type: application/json' \
  -u 'admin:Admin123!vLLM' \
  -d @vllm-app-dashboard.json | jq '.status, .url'

Next, you an access the vLLM dashboard and follow metrics in real time:

This dashboard is also essential to track hardware consumption for comprehensive monitoring.

2. GPU hardware metrics

Take advantage of the most useful DCGM metrics to check both the functioning and consumption of your hardware resources:

This hardware Grafana dashboard is composed of 13 panels with GPU hardware and system metrics. A detailed view is also available GPU util (%), temperature (°C), vRAM (GB) and power (Watt).

Please refer to hardware-dashboard.json by loading it as follows:

echo "Importing hardware dashboard..."
curl -X POST \
  'http://localhost:3000/api/dashboards/db' \
  -H 'Content-Type: application/json' \
  -u 'admin:Admin123!vLLM' \
  -d @hardware-dashboard.json | jq '.status, .url'

Finally, track resource consumption using this hardware dashboard:

Congratulations! Everything is working. You can now test your model and track the various metrics in real time.

Step 8 – LLM testing and performance tracking

Start by installing Python dependencies:

pip3 install openai tqdm

Replace the <EXTERNAL_IP> by the vLLM service external IP and launch the performance test thanks to the following Python code:

import time
import threading
import random
from statistics import mean
from openai import OpenAI
from tqdm import tqdm

APP_URL = "http://94.23.185.22/v1"
MODEL = "qwen3-vl-8b"

CONCURRENT_WORKERS = 500          # concurrency
REQUESTS_PER_WORKER = 10
MAX_TOKENS = 200                  # generation pressure

# some random prompts
SHORT_PROMPTS = [
    "Summarize the theory of relativity.",
    "Explain what a transformer model is.",
    "What is Kubernetes autoscaling?"
]

MEDIUM_PROMPTS = [
    "Explain how attention mechanisms work in transformer-based models, including self-attention and multi-head attention.",
    "Describe how vLLM manages KV cache and why it impacts inference performance."
]

LONG_PROMPTS = [
    "Write a very detailed technical explanation of how large language models perform inference, "
    "including tokenization, embedding lookup, transformer layers, attention computation, KV cache usage, "
    "GPU memory management, and how batching affects latency and throughput. Use examples.",
]

PROMPT_POOL = (
    SHORT_PROMPTS * 2 +
    MEDIUM_PROMPTS * 4 +
    LONG_PROMPTS * 6    # bias toward long prompts
)

# openai compliance
client = OpenAI(
    base_url=APP_URL,
    api_key="foo"
)

# basic metrics
latencies = []
errors = 0
lock = threading.Lock()

# worker
def worker(worker_id):
    global errors
    for _ in range(REQUESTS_PER_WORKER):
        prompt = random.choice(PROMPT_POOL)

        start = time.time()
        try:
            client.chat.completions.create(
                model=MODEL,
                messages=[{"role": "user", "content": prompt}],
                max_tokens=MAX_TOKENS,
                temperature=0.7,
            )
            elapsed = time.time() - start

            with lock:
                latencies.append(elapsed)

        except Exception as e:
            with lock:
                errors += 1

# run
threads = []
start_time = time.time()

print("\n-> STARTING PERFORMANCE TEST:")
print(f"Concurrency: {CONCURRENT_WORKERS}")
print(f"Total requests: {CONCURRENT_WORKERS * REQUESTS_PER_WORKER}")

for i in range(CONCURRENT_WORKERS):
    t = threading.Thread(target=worker, args=(i,))
    t.start()
    threads.append(t)

for t in threads:
    t.join()

total_time = time.time() - start_time

# results
print("\n-> BENCH RESULTS:")
print(f"Total requests sent: {len(latencies) + errors}")
print(f"Successful requests: {len(latencies)}")
print(f"Errors: {errors}")
print(f"Total wall time: {total_time:.2f}s")

if latencies:
    print(f"Avg latency: {mean(latencies):.2f}s")
    print(f"Min latency: {min(latencies):.2f}s")
    print(f"Max latency: {max(latencies):.2f}s")
    print(f"Throughput: {len(latencies)/total_time:.2f} req/s")

Returning:

-> STARTING PERFORMANCE TEST:
Concurrency: 500
Total requests: 5000

-> BENCH RESULTS:
Total requests sent: 5000
Successful requests: 5000
Errors: 0
Total wall time: 225.54s
Avg latency: 21.45s
Min latency: 6.06s
Max latency: 25.19s
Throughput: 22.17 req/s

Don’t forget to track GPU and vLLM metrics in your Grafana dashboards!

Conslusion

This reference architecture demonstrates a vLLM deployment on OVHcloud Managed Kubernetes Service (MKS) with comprehensive GPU monitoring. Benefits include:

• High Performance: GPU-accelerated inference with L40S
• Scalability: Kubernetes-native, horizontal scaling-ready
• Reliability: Health checks, auto-restart, monitoring
• API Compatibility: OpenAI-compatible endpoints
• Multimodality: Vision & text capabilities
• Full stack monitoring: Complete vLLM application and hardware dashboards

Going Further

Your current architecture is functional. However, if desired, it could be improved into a full production-ready solution.

Wish to take production hardening a step further?

Go further with the following enhancements:

1. Authentication & authorization
   • vLLM API authentication
   • Grafana authentication
   • Prometheus security
2. High availability & load balancing
   • Grafana high availability with multiple replicas and shared storage
   • Prometheus high availability
   • vLLM Horizontal Pod Autoscaling (HPA) based on custom metrics
3. Data persistence & backup
   • Prometheus long-term storage with persistent storage
   • Grafana Dashboard Backup
4. Observability enhancements
   • Distributed tracing by adding OpenTelemetry for request tracing
   • Alerting rules with production-ready alert rules

You can find the full code example in the GitHub repository.

In this article, we will explore how to perform OCR (Optical Character Recognition) on images using a vision-capable LLM, the OpenAI Python library, and OVHcloud AI Endpoints.

Introduction to OCR with Vision Models

Optical Character Recognition has been around for decades, but traditional OCR engines often struggle with complex layouts, handwritten text, or noisy images. Vision-capable Large Language Models bring a new approach: instead of relying on specialized OCR pipelines, you can simply send an image to a model that understands both visual and textual content.

In this example, we use the OpenAI Python library to create a simple OCR script powered by a vision model hosted on OVHcloud AI Endpoints.

The whole application is a single Python file:  no complex setup, just pip install openai and you’re ready to go.

Setting up the Environment Variables

Before running the script, you need to set the following environment variables:

export OVH_AI_ENDPOINTS_ACCESS_TOKEN="your-access-token"
export OVH_AI_ENDPOINTS_MODEL_URL="https://your-model-url"
export OVH_AI_ENDPOINTS_VLLM_MODEL="your-vision-model-name"

You can find how to create your access token, model URL, and model name in the AI Endpoints catalog. Make sure to choose a vision-capable model from the AI Endpoints catalog.

Installing Dependencies

The only dependency is the OpenAI Python library:

pip install openai

Define the System Prompt

The first step is to define a system prompt that describes what our OCR service does. This prompt tells the model how to behave:

SYSTEM_PROMPT = """You are an expert OCR engine.
Extract every piece of text visible in the provided image.
Preserve the original layout as faithfully as possible (line breaks, columns, tables).
Do NOT interpret, summarise, or translate the content.
Use markdown formatting to represent the layout (e.g. tables, lists).
If the image contains no text, reply with: "No text found."
"""

We tell it to behave as an expert OCR engine, to preserve the original layout, and to use markdown formatting for structured content like tables or lists.

Load the Image

Before sending the image to the model, we need to encode it as a base64 string. Here is a simple helper function that reads a local PNG file and returns a base64-encoded string:

import base64
from pathlib import Path

def load_image_as_base64(path: Path) -> str:
    """Load a local image and encode it as base64."""
    with open(path, "rb") as f:
        return base64.b64encode(f.read()).decode("utf-8")

The base64-encoded data is what gets sent to the vision model as part of the prompt.

Extract Text from the Image

The extract_text function sends the image to the vision model and returns the extracted text:

def extract_text(client: OpenAI, image_base64: str, model: str) -> str:
    """Extract text from an image using the vision model."""
    response = client.chat.completions.create(
        model=model,
        temperature=0.0,
        messages=[
            {"role": "system", "content": SYSTEM_PROMPT},
            {
                "role": "user",
                "content": [
                    {
                        "type": "image_url",
                        "image_url": {
                            "url": f"data:image/png;base64,{image_base64}"
                        }
                    }
                ]
            }
        ]
    )
    return response.choices[0].message.content

The image is passed as a data URL inside the image_url field, following the OpenAI Vision API format. The temperature is set to 0.0 because we want deterministic, faithful text extraction and not creative output.

Configure the Client

This example uses a vision-capable model hosted on OVHcloud AI Endpoints. Since AI Endpoints exposes an OpenAI-compatible API, we use the OpenAI client and just point it to the OVHcloud endpoint:

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.getenv("OVH_AI_ENDPOINTS_ACCESS_TOKEN"),
    base_url=os.getenv("OVH_AI_ENDPOINTS_MODEL_URL"),
)

model_name = os.getenv("OVH_AI_ENDPOINTS_VLLM_MODEL")

A few things to note:

• The API key, base URL, and model name are read from environment variables.
• The OpenAI library is compatible with any OpenAI compatible API, making it perfect for use with AI Endpoints.

Assemble and Run

With the client configured, extracting text from an image is straightforward:

image_base64 = load_image_as_base64(Path("./doc.png"))
result = extract_text(client, image_base64, model_name)
print(result)

And that’s it!

Here is the image used for this example:

And the result:

$ python ocr_demo.py
📄 Loading image: doc.png
🔍 Running OCR with Qwen2.5-VL-72B-Instruct via OVHcloud AI Endpoints...

📝 Extracted text 📝
Every month, the OVHcloud Developer Advocate team creates content, shares knowledge, and connects with the tech community. Here’s a look at what we did in March 2026. 🚀

🎙️ “Tranches de Tech” – Our monthly podcast

A new episode of our French-language podcast Tranches de Tech🥑 just dropped!

🎧 Episode 102: Tranches de Tech #26 – Architecte, c’est une bonne situation ça ?

This month we sat down with Alexandre Touret, Architect at Worldline to discuss the evolving role of software architects and the growing impact of AI on development practices. From Spotify’s claim that their devs no longer code, to agentic tools like OpenClaw and Claude Code reshaping workflows. We also cover ANSSI’s revised open-source policy, IBM tripling junior hires, and the critical responsibility of mentoring the next generation of developers in an AI-driven world.

📺 Live on Twitch

We streamed live on Twitch this month! Here’s what we covered:

🎥 Rémy Vandepoel discussed with Hugo Allabert and François Loiseau about our Public VCFaaS. Catch the replay on YouTube ▶️.

🎤 Conference Talks

The team hit the road (and the stage) at several conferences this month:

🇳🇱 KubeCon Amsterdam – Amsterdam, Netherlands 🇳🇱

Aurélie Vache gave a talk: The Ultimate Kubernetes Challenge: An Interactive Trivia Game

Conclusion

In this article, we have seen how to use a vision-capable LLM to perform OCR on images using the OpenAI Python library and OVHcloud AI Endpoints. The OpenAI library makes it very easy to send images to a vision model and extract text, and Python allows us to run the whole thing as a simple script.

You have a dedicated Discord channel (#ai-endpoints) on our Discord server (https://discord.gg/ovhcloud), see you there!

Since autumn 2025, the global memory market has been going through a major disruption. Although barely noticeable to end users, these developments are radically changing the cost of computer hardware and, as a direct result, the cost of the cloud.

This article will decipher this structural crisis, its real-life impacts, and the strategic choices that OVHcloud is implementing to mitigate its effects.

An industrial shift towards GPUs

Globally, the three major memory manufacturers have redirected a significant portion of their production capacity to meet the massive demand for GPUs, particularly for AI-related and high-bandwidth computing applications.

This reallocation took place without a corresponding reduction in the historical demand for RAM and storage, generating pressure on several market segments simultaneously.

The consequences of this were immediate and noticeable:

• pressure on supply, with reduced stock and extended lead times
• continuous rise in RAM and disk prices since September 2025
• long-term market instability, which is not expected to find a new balance until late 2026

A sustained inflation of memory components

Even after the market stabilises, prices are not expected to return to their historical levels before 2028, the amount of time needed for new production capacities to become truly operational.

This development profoundly disrupts the economic fundamentals of computer hardware, both for on-premises infrastructures and for the cloud. Depending on configurations, the prices related to RAM and storage could increase by 15% to 300% compared to 2025 prices, depending on the volumes of memory and disk capacity deployed.

This change of scale is both abrupt and unprecedented, with no recent equivalent in the global market.

A market under pressure, even with higher prices

Paradoxically, the rise in prices is not enough to secure the availability of components. Currently, to guarantee the delivery of their desired volume of RAM or disks, cloud providers need to order up to 12 months in advance, without being told the final price at the time of purchase.

In practice, prices are only communicated one to two months after delivery, depending on the changes in supply and demand during the quarter in question. This uncertainty places unprecedented pressure on industry players and cloud providers, simultaneously affecting production and distribution.

Towards a new global balance of demand

This situation will inevitably have repercussions on the volumes ordered. Some customers will find the prices too high and limit their investments, while others, lacking alternatives, will continue to place orders regardless.

This interplay of opposing forces should lead to a new global balance, but at a significantly higher price point. Current projections anticipate a 250% to 300% increase in the price of RAM by the end of 2026, compared to September 2025.

Our strategy to soften the blow

In light of this reality, OVHcloud has chosen not to automatically pass on the entire price increase of components to its customers.

For the cloud deployed between 2026 and 2028 (including Public Cloud, Private Cloud, and Bare Metal), the average price increase will be limited – between 9% and 11% – despite significantly higher RAM and disk costs.

To offset this gap, a moderate increase of 2% to 6% is planned for solutions deployed before 2025, depending on the age of the equipment, as well as a change in IPv4 pricing. The latter should not have a significant impact on our customers’ budgets, as the cost of IP addresses is a small share compared to other resources in a cloud project.

Our objective is clear: to maintain pricing consistency across the entire range from 2021 to 2028, and to prepare for a gradual return to normal in 2029.

Continuous investments and developing solutions

Beyond pricing adjustments, this period will be characterised by sustained investments in our solutions and in the customer experience.

Despite the strong pressure from rising component costs, we are continuing to develop our services to provide more value to our customers.

In practical terms, this will result in:

• a gradual strengthening of support mechanisms
• an increase in resources included in certain ranges
• a modernization of our computing and storage infrastructures

These initiatives demonstrate our commitment to not reduce this period to merely a consequence of cost increases, but to maintain a dynamic of improving our services, even in a constrained economic context.

Time frame and implementation procedures

Our clients have already received emails detailing the precise impacts on their services. The new prices will come into effect on 1 April 2026.

Until that date, it is possible to renew services at the current rates for a duration of up to 2 years. In all cases, the new prices will only apply at the end of the current contractual period.

A time of uncertainty and a strategic advantage

We are going through an exceptionally unpredictable period, where market visibility rarely lasts longer than one to two weeks. There remains hope that prices will stabilize on a long-term basis from 2026, so that we can avoid further unfavorable announcements.
In this tense context, having a global supply chain and two internal production facilities is a major strategic advantage. This allows us to continue receiving components and producing servers, while the memory shortage affects a large part of the market.

Our Prices

You will find below our new pricing:
– Public Cloud: Prices below are displayed on an hourly basis and with Linux OS. Please, find on our Prices web page our monthly-consumed virtual machine instances (b2, c2, r2) and Savings Plan options (b3, c3, r3) as well as prices with Windows licences.
– All our VPS, Floating IPs, and Additional IP pricing.
– Bare Metal: The displayed prices correspond to a 1-month commitment; additional discounts apply for 12- or 24-month prepayments. The prices for options are for new orders only. The renewal of options, which has been communicated by email to our customers, will be limited to +10% for disk options and +15% for RAM options.

For existing subscriptions renewed before April 1st, you can secure your current pricing for the full duration of the commitment you choose, effective from your renewal date.

Please note that the following product categories are not affected by our pricing evolution:
– Public Cloud – Compute : Cloud GPUs and Metal Instances
– Public Cloud – Container : Managed Kubernetes, Managed Registries & Managed Rancher
– Public Cloud – Network : Load Balancer, Gateway. Public and Private network traffic remains included.
– Public Cloud – Storage : Object Storage, Block Storage.
– Public Cloud – Analytics : Data Platform
– Public Cloud – AI & Machine Learning : AI Solutions (AI Notebook, AI Training, AI Deploy) and AI Endpoints
– Public Cloud – Quantum : Emulators & QPUs
– Bare Metal : Kimsufi et SoYouStart ranges
– Bare Metal : All storage (Veeam Enterprise plus, HYCU, Back-up Agent, NAS-HA, Cloud Disk Array)
– Private Cloud : All VMware offers, all storage offers (Veeam Enterprise plus, HYCU, Back-up Agent)

Un basculement industriel vers les GPU

À l’échelle mondiale, les trois grands fabricants de mémoire ont réorienté une part importante de leurs capacités de production pour répondre à la demande massive en GPU, en particulier pour les usages liés à l’IA et au calcul haute performance.

Cette réallocation s’est effectuée sans réduction équivalente de la demande historique en mémoire vive et en stockage, générant une pression simultanée sur plusieurs segments du marché.

Les conséquences sont immédiates et visibles :

• tension sur l’offre, avec des stocks réduits et des délais d’approvisionnement allongés ;
• hausse continue des prix de la RAM et des disques depuis septembre 2025 ;
• instabilité durable du marché, qui ne devrait retrouver un nouvel équilibre qu’à l’horizon fin 2026.

Une inflation durable des composants mémoire

Même après la stabilisation du marché, les prix ne devraient pas retrouver leurs niveaux historiques avant 2028, le temps nécessaire pour que de nouvelles capacités de production soient réellement opérationnelles.

Cette évolution bouleverse profondément les fondamentaux économiques du matériel informatique, tant pour les infrastructures on-premise que pour le cloud. Selon les configurations, l’impact tarifaire lié à la RAM et au stockage pourrait atteindre +15 % à +300 % par rapport aux prix de 2025, en fonction des volumes de mémoire et de capacité disque déployés.

Ce changement d’échelle est à la fois brutal et inédit, sans équivalent récent sur le marché mondial.

Un marché sous tension même à prix élevé

Paradoxalement, la hausse des prix ne suffit pas à sécuriser la disponibilité des composants. Aujourd’hui, pour garantir la livraison de volumes de RAM ou de disques, il est nécessaire pour les fournisseurs de cloud de passer commande jusqu’à 12 mois à l’avance, sans connaître le prix final au moment de l’achat.

En pratique, les tarifs ne sont communiqués qu’un à deux mois après la livraison, selon l’évolution de l’offre et de la demande sur le trimestre concerné. Cette incertitude exerce une pression inédite sur les acteurs industriels et les fournisseurs de cloud, affectant simultanément la production et la distribution.

Vers un nouvel équilibre mondial de la demande

Cette situation aura inévitablement des répercussions sur les volumes commandés. Certains clients jugeront les prix trop élevés et limiteront leurs investissements, tandis que d’autres, faute d’alternative, continueront à passer commande malgré tout.

Ce jeu de forces opposées devrait conduire à un nouvel équilibre mondial, mais à un niveau de prix nettement supérieur. Les projections actuelles anticipent une augmentation de la RAM de +250 % à +300 % à la fin 2026, par rapport à septembre 2025.

Notre stratégie pour amortir le choc

Face à cette réalité, OVHcloud a choisi de ne pas répercuter automatiquement l’intégralité de la hausse des composants sur ses clients.

Pour le cloud déployé entre 2026 et 2028 — incluant le Public Cloud, le Private Cloud et le Bare Metal — l’augmentation moyenne des prix sera limitée, entre +9 % et +11 %, malgré des coûts de RAM et de disques nettement plus élevés.

Pour compenser cet écart, un ajustement modéré est prévu sur les offres déployées avant 2025, de +2 % à +6 %, en fonction de l’ancienneté du matériel, ainsi qu’une évolution des tarifs des IPv4. Cette dernière ne devrait pas avoir d’impact significatif sur le budget de nos clients, le coût des adresses IP représentant une part limitée par rapport aux autres ressources d’un projet cloud.

Notre objectif est clair : préserver une cohérence tarifaire sur l’ensemble des gammes 2021-2028 et préparer un retour progressif à la normale en 2029.

Investissements continus et évolution des offres

Au-delà des ajustements tarifaires, cette période se caractérise par des investissements soutenus dans nos offres et dans l’expérience client.

Malgré la forte pression liée à l’augmentation des coûts des composants, nous continuons à faire évoluer nos services afin d’apporter davantage de valeur à nos clients.

Concrètement, cela se traduit par :

• un renforcement progressif des dispositifs de support ;
• une augmentation des ressources incluses dans certaines gammes ;
• une modernisation de nos infrastructures de calcul et de stockage.

Ces initiatives témoignent de notre volonté de ne pas réduire cette phase à une simple répercussion des hausses de coûts, mais de maintenir une dynamique d’amélioration de nos services, même dans un contexte économique contraint.

Calendrier et modalités d’application

Nos clients ont déjà reçu des emails détaillant les impacts précis sur leurs services. Les nouveaux tarifs seront appliqués à compter du 1^er avril 2026.

Jusqu’à cette date, il est possible de renouveler les services aux tarifs actuels pour une durée pouvant aller jusqu’à 2 ans. Dans tous les cas, les nouveaux prix ne s’appliqueront qu’à l’issue de la période d’engagement en cours.

Une période d’incertitude et un avantage stratégique

Nous traversons une phase exceptionnellement imprévisible, où la visibilité sur les marchés dépasse rarement une à deux semaines. L’espoir demeure que les prix se stabilisent durablement dès 2026, afin d’éviter de nouvelles annonces défavorables.

Dans ce contexte tendu, disposer d’une chaîne d’approvisionnement mondiale et de deux usines de production internes constitue un avantage stratégique majeur. Cela nous permet de continuer à recevoir des composants et à produire des serveurs, là où la pénurie de mémoire touche une grande partie du marché.

Nos tarifs

Vous trouverez ci-dessous nos nouveaux tarifs :
– Public Cloud : les prix ci-dessous sont affichés à l’heure et avec OS Linux. Vous trouverez sur notre page Tarifs les prix des instances de machines virtuelle consommées au mois (b2, c2, r2) ou en Savings Plan (b3, c3, r3) ainsi que les tarifs avec licences Windows.
– Tous nos tarifs VPS, Floating IPs & IP additionnelles.
– Bare Metal : les prix affichés correspondent à un engagement d’un mois ; des remises supplémentaires sont appliquées en cas de prépaiement sur 12 ou 24 mois. Les prix des options sont ceux des nouvelles commandes uniquement. Le renouvellement d’options qui a été communiqué par email à nos clients sera quant à lui limité à +10% sur les options de disques, +15% sur les options de RAM.

Pour toutes les souscriptions existantes renouvelées avant le 1er avril, vous pouvez conserver votre tarif actuel pendant toute la durée d’engagement choisie, à compter de votre date de renouvellement.

Veuillez noter que les catégories de produits suivantes ne sont pas concernées par l’évolution de nos tarifs :
– Public Cloud – Compute : Cloud GPUs et Metal Instances
– Public Cloud – Container : Managed Kubernetes, Managed Registries & Managed Rancher
– Public Cloud – Network : Load Balancer, Gateway. Le trafic réseau Public et Privé reste inclus.
– Public Cloud – Storage : Object Storage, Block Storage.
– Public Cloud – Analytics : Data Platform
– Public Cloud – AI & Machine Learning : AI Solutions (AI Notebook, AI Training, AI Deploy) et AI Endpoints
– Public Cloud – Quantum : Emulators & QPUs
– Bare Metal – stockage : Veeam Enterprise Plus, HYCU, Back-up Agent, NAS-HA, Cloud Disk Array
– Bare Metal : Gammes Kimsufi et SoYouStart
– Private Cloud : offres VMware et offres de stockage (Veeam Enterprise plus, HYCU, Back-up Agent)