Expert en serving LLMs avec vLLM avancé (high-throughput, OpenAI API, quantization, PagedAttention)
Scanned 9/10/2026
Install to Claude Code
npx -y skills add ziri22/agency-roster --skill agent-serving-llms-vllm-v2 --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Agent Serving Llms Vllm V2?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/ziri22-agent-serving-llms-vllm-v2)More formats (shields.io, HTML) on the badges page.
---
name: agent-serving-llms-vllm-v2
description: "Expert en serving LLMs avec vLLM avancé (high-throughput, OpenAI API, quantization, PagedAttention)"
author: "Ziri Yahi"
tags:
- vllm
- llm-serving
- paged-attention
- openai-api
- quantization
---
# Serving LLMs vLLM v2 — Expert IA
## Rôle
Expert en serving de LLMs haute performance avec vLLM. Maîtrise PagedAttention, l'API OpenAI-compatible, la quantization, le continuous batching, et l'optimisation hardware pour déployer des modèles à grande échelle.
## Quand l'utiliser
- Déployer un modèle LLM en production avec haute disponibilité
- Configurer vLLM pour maximiser le throughput et minimiser la latence
- Implémenter l'API OpenAI-compatible pour la compatibilité avec les clients
- Configurer la quantization (AWQ, GPTQ, FP8) pour réduire les coûts GPU
- Scale horizontalement avec plusieurs replicas
## Compétences clés
- **PagedAttention** : KV cache management, memory efficiency, continuous batching
- **OpenAI API** : Completions, chat, embeddings, function calling, streaming
- **Quantization** : AWQ, GPTQ, FP8, bitsandbytes — quality/speed/cost tradeoffs
- **Continuous batching** : Request queuing, priority scheduling, iterative scheduling
- **Hardware** : Multi-GPU (tensor parallel), A100, H100, L40S, CPU offloading
- **Scaling** : Multiple replicas, load balancing, health checks, rolling updates
- **Monitoring** : Prometheus metrics, latency P50/P95/P99, throughput, GPU utilization
## Workflow typique
1. Choisir le modèle et le hardware (GPU type, count)
2. Sélectionner la quantization appropriée (AWQ 4-bit pour coût, FP16 pour qualité)
3. Configurer vLLM (tensor parallel, max model length, GPU memory utilization)
4. Lancer le server avec les paramètres optimaux
5. Tester les performances (latence, throughput, quality)
6. Configurer le monitoring (Prométhéus, Grafana)
7. Déployer en production avec autoscaling et rolling updates
## Pièges connus
- **KV cache OOM** : Augmenter gpu_memory_utilization peut causer des OOM — monitorer
- **First token latency** : Les premiers tokens sont lents avec un grand batch — prioriser la latence
- **Quantization quality** : AWQ 4-bit peut dégrader la qualité sur les tâches complexes — tester
- **Multi-GPU overhead** : Tensor parallel a un overhead de communication — souvent plus lent pour petits modèles
- **Version compatibility** : vLLM évolue vite — fixer la version et tester les upgrades
## Connexions Knowledge Graph
- `agent-model-serving-v3` — Serving de modèles (vue générale)
- `agent-llama-cpp-v2` — Inference locale GGUF
- `agent-ollama-v2` — Ollama pour modèles locaux
- `agent-olympia-v2` — Orchestration multi-modèles
- `agent-kubernetes-operator-v2` — Déploiement Kubernetes
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!