亚马逊AWS官方博客

HAQM Inf2 上的 DeepSeek-R1 蒸馏模型：监控与评估实践

1. 介绍

DeepSeek 在 2025 年春节期间发布的 DeepSeek-R1 模型引起了广泛的讨论。目前，用户可以通过以下几种方式在亚马逊云科技上部署 DeepSeek 模型：

  • 通过 HAQM Bedrock Marketplace 部署 DeepSeek-R1 模型；
  • 通过 HAQM SageMaker JumpStart 部署 DeepSeek-R1 模型；
  • 通过 HAQM Bedrock Custom Model Import 部署 DeepSeek-R1-Distill 模型；
  • 使用亚马逊云科技自研芯片 Trainium 和 Inferentia 通过 HAQM EC2 或者 HAQM SageMaker 部署 DeepSeek-R1-Distill 模型。

Inferentia2 是亚马逊云科技自主研发的云端机器学习推理芯片，专为深度学习推理工作负载提供高性能、高效率的计算能力，助力客户在云端高效部署和运行机器学习模型。

在大模型部署过程中，客户常常面临如何评估性能和优化推理效率的挑战。本文将以 Inferentia2 为测试环境，重点探讨如何评估模型推理性能。我们将基于 vLLM 部署模型，并介绍如何使用 Prometheus 和 Grafana 获取推理性能参数，同时解析关键指标的含义。

*由于本篇文章的重点在于性能参数的解读，因此不涉及 Inferentia2 的规格介绍及运行配置优化。

2. 部署模型

2.1 部署环境所需的 HAQM EC2

部署镜像选择 Deep Learning AMI Neuron (Ubuntu 22.04)。Deep Learning AMI 是专门为在 AWS 云上进行深度学习和机器学习优化而提供的镜像， 预装了主流深度学习框架，包括 TensorFlow、PyTorch 和 MXNet 等， 内置 AWS Neuron SDK 开发工具包，支持在 Inferentia 和 Trainium 芯片上运行工作负载。

Inferentia2 提供包含 1、6 和 12 卡的不同规格， 可以参考下面的截图。

等待资源部署完成：

2.2 安装 vllm 支持分布式推理

2.2.1 vllm

vLLM 是伯克利大学 LMSYS 组织开源的大语言模型高速推理框架，旨在提升实时场景下语言模型服务的吞吐与内存使用效率。PagedAttention 和 Continuous Batching 等核心技术在保持低延迟的同时显著提升 LLM 服务的吞吐量，并且大幅降低内存开销，解决 LLM 推理受限于显存由于带宽或者成本的带来的容量限制。

2.2.2 NxD inference

NxD (NeuronX Distributed) Inference 是一个基于 PyTorch 的开源推理库，专门用于在 AWS Inferentia 和 Trainium 实例上简化深度学习模型部署。该库在 Neuron SDK 2.21 版本中推出。NxD Inference 简化了深度学习模型的部署过程，实现了高性能推理。

NxD Inference 特点：

  • 支持 Llama、DBRX 和 Mixtral 等模型的快速部署；
  • LLM 推理功能支持连续批处理（continuous batching），支持推测解码（speculative decoding）等；
  • 架构优势：1）便于开发者自定义和扩展功能； 2）支持张量并行和序列并行，未来将支持流水线并行和多节点推理；
  • 三种集成方式： 1） 通过 vLLM 部署； 2） 直接使用 NxDI，适用于不使用 vLLM 的场景，支持静态批处理； 3） 底层集成， 可以直接使用推理模块和 NxD 核心原语，适合需要自定义的场景。

详情：http://awsdocs-neuron.readthedocs-hosted.com/en/latest/libraries/nxd-inference/nxdi-overview.html#nxdi-overview

2.2.3 NxD Inference 和 vllm 的集成

NxD Inference 通过扩展 vLLM 的模型执行组件来实现集成，复用 vLLM 的 LLMEngine 架构，保持了 vLLM 原有的输入处理、调度和输出处理流程，主要修改了 Model Runner 和 Model 部分使其支持 Neuron 硬件。使用时非常简单，只需要设置 device=“neuron” 参数，而其他的 vllm 的 API 使用方式保持不变，就可以像通常的使用方式一样进行模型加载和推理。

目前支持方式包含连续批处理（continous batching） 和流式生成（streaming generation）， PagedAttention 和 Chuncked Prefill 还在开发中。

目前支持的模型：

  • DBRX
  • LLama 2, 3, 3.1, 3.2 (1B and 3B), 3.3
  • Mistral-V2
  • Mixtral

2.2.4 安装 vllm

source /opt/aws_neuronx_venv_pytorch_2_5_nxd_inference/bin/activate

sudo apt-get install git-lfs
git lfs install

http://docs.github.com/repositories/working-with-files/managing-large-files/about-git-large-file-storage

大语言模型文件通常非常大（几 GB 到几十 GB），超出了 Git 的正常文件处理能力。 Git-lfs 将大型模型文件替换为文本指针存储在 Git 仓库中，而实际的模型文件内容存储在远程服务器上只在需要时才下载实际的模型文件。使用 git-lfs 的优势是支持断点续传，更高效地管理大型二进制文件，减少 Git 仓库的体积。

安装 transformers-neruonx 和相关依赖：

# Install Jupyter notebook kernel
pip install ipykernel
python3.10 -m ipykernel install --user --name aws_neuron_venv_pytorch --display-name "Python (torch-neuronx)"
pip install jupyter notebook
pip install environment_kernels

# Set pip repository pointing to the Neuron repository
python -m pip config set global.extra-index-url http://pip.repos.neuron.amazonaws.com

# Install wget, awscli
python -m pip install wget
python -m pip install awscli

# Update Neuron Compiler and Framework
python -m pip install --upgrade neuronx-cc==2.* --pre torch-neuronx==2.1.* torchvision transformers-neuronx

install vllm from source：

git clone http://github.com/vllm-project/vllm.git
cd vllm
pip install -U -r requirements-neuron.txt
pip install .

从 Hugging Face 下载模型：

huggingface-cli login
<Use your huggingface token>

下载：

huggingface-cli download deepseek-ai/DeepSeek-R1-Distill-Llama-8B

启动推理：

export MODEL_PATH=/home/ubuntu/.cache/huggingface/hub/models--deepseek-ai--DeepSeek-R1-Distill-Llama-8B/snapshots/ebf7e8d03db3d86a442d22d30d499abb7ec27bea/

cd vllm/

python3 -m vllm.entrypoints.openai.api_server \
--model $MODEL_PATH     \
--served-model-name DeepSeek-R1-Distill-Llama-8B     \
--tensor-parallel-size 2     \
--max-model-len 2048     \
--max-num-seqs 4     \
--block-size 8     \
--use-v2-block-manager     \
--device neuron     \
--port 8000

基础参数：

  • --model $MODEL_PATH：指定模型文件的路径位置
  • --served-model-name：设置服务的模型名称，这里是”DeepSeek-R1-Distill-Llama-8B”
  • --port 8000：设置服务监听的端口号

并行和性能参数：

  • --tensor-parallel-size 2：设置张量并行的大小为 2，用于在多个设备间分配模型
  • --max-model-len 2048：设置模型最大处理的序列长度为 2048 个 token
  • --max-num-seqs 4：设置最大并发处理的序列数量为 4

内存管理参数：

  • --block-size 8：设置 KV 缓存块的大小为 8
  • --use-v2-block-manager：启用 V2 版本的块管理器，这是一个更高效的内存管理方案

硬件参数：

  • --device neuron：指定使用 AWS Neuron 设备进行推理，这是针对 AWS Inferentia 芯片优化的设置

运行成功：

测试：

curl localhost:8000/v1/completions \ -H "Content-Type: application/json" \ -d '{"model": "DeepSeek-R1-Distill-Llama-8B", "prompt": "What is DeepSeek R1?", "temperature":0, "max_tokens": 128}' | jq '.choices[0].text'

3. 如何监控模型的性能

3.1 大语言模型部署时需要关注的指标

大语言模型部署时主要关注性能指标和质量指标。

  • 性能指标
    • 延迟指标
      • 首 Token 延迟（TTFT）- 从请求开始到返回第一个 token 的时间
      • 每输出 Token 延迟（TPOT）： 每个输出 token 的延迟（不含首个 token）
      • 总体延迟（Latency） – 从用户发出请求到收到完整请求的时间
    • 吞吐量指标
      • 每秒请求数（QPS/RPS） – 系统每秒处理的请求数量
      • 每秒 Token 数（TPS） – 系统每秒处理的 token 数量
  • 质量指标
      • 准确性评估 – 预测正确的样本占总样本比例
      • 生成质量 – 预测为正样本中真正为正样本的比例
      • 可靠性指标 – 模型预测样本的好坏程度

在这篇文章中，我们主要讨论和大语言模型相关的性能指标，理由是：

  • 影响用户体验：延迟会影响用户体验，例如首字节延迟决定用户等待首次响应的时间； token 间延迟（ITL）影响用户获得连续响应的流畅度；
  • 控制运营成本： 更高的吞吐量意味着可以用更少的硬件资源时间完成更多的请求， 从而降低服务器的使用成本。

根据应用的不同场景，对于性能指标也有不同的优化重点。例如，在线流式应用优先会关注每个输出词元的延迟（TPOT）和端到端延迟；离线批量处理的应用会主要关注整体吞吐量。因此根据应用场景持续监控和优化性能指标，可以在保证用户体验的同时，实现资源的最优配置和成本的有效控制。

3.2 vllm 的性能监控指标

vllm 提供了这些指标：curl http://0.0.0.0:8000/metrics

下面是输出的结果：

curl http://0.0.0.0:8000/metrics 
# HELP vllm:iteration_tokens_total Histogram of number of tokens per engine_step. # TYPE vllm:iteration_tokens_total histogram vllm:iteration_tokens_total_sum{model_name="DeepSeek-R1-Distill-Llama-8B"} 272.0 vllm:iteration_tokens_total_bucket{le="1.0",model_name="DeepSeek-R1-Distill-Llama-8B"} 271.0 vllm:iteration_tokens_total_bucket{le="2.0",model_name="DeepSeek-R1-Distill-Llama-8B"} 271.0 # HELP vllm:time_to_first_token_seconds Histogram of time to first token in seconds. # TYPE vllm:time_to_first_token_seconds histogram vllm:time_to_first_token_seconds_sum{model_name="DeepSeek-R1-Distill-Llama-8B"} 0.8229701519012451 vllm:time_to_first_token_seconds_bucket{le="0.001",model_name="DeepSeek-R1-Distill-Llama-8B"} 0.0 v .... vllm:time_to_first_token_seconds_count{model_name="DeepSeek-R1-Distill-Llama-8B"} 2.0 # HELP vllm:time_per_output_token_seconds Histogram of time per output token in seconds. # TYPE vllm:time_per_output_token_seconds histogram vllm:time_per_output_token_seconds_sum{model_name="DeepSeek-R1-Distill-Llama-8B"} 10.362053394317627 .... vllm:time_per_output_token_seconds_count{model_name="DeepSeek-R1-Distill-Llama-8B"} 254.0 # HELP vllm:e2e_request_latency_seconds Histogram of end to end request latency in seconds. # TYPE vllm:e2e_request_latency_seconds histogram vllm:e2e_request_latency_seconds_sum{model_name="DeepSeek-R1-Distill-Llama-8B"} 11.185362100601196 .... vllm:e2e_request_latency_seconds_bucket{le="+Inf",model_name="DeepSeek-R1-Distill-Llama-8B"} 2.0 vllm:e2e_request_latency_seconds_count{model_name="DeepSeek-R1-Distill-Llama-8B"} 2.0 # HELP vllm:request_queue_time_seconds Histogram of time spent in WAITING phase for request. # TYPE vllm:request_queue_time_seconds histogram vllm:request_queue_time_seconds_sum{model_name="DeepSeek-R1-Distill-Llama-8B"} 0.0014662742614746094 .... vllm:request_queue_time_seconds_count{model_name="DeepSeek-R1-Distill-Llama-8B"} 2.0 # HELP vllm:request_inference_time_seconds Histogram of time spent in RUNNING phase for request. # TYPE vllm:request_inference_time_seconds histogram vllm:request_inference_time_seconds_sum{model_name="DeepSeek-R1-Distill-Llama-8B"} 11.183895826339722 .... vllm:request_inference_time_seconds_count{model_name="DeepSeek-R1-Distill-Llama-8B"} 2.0 # HELP vllm:request_prefill_time_seconds Histogram of time spent in PREFILL phase for request. # TYPE vllm:request_prefill_time_seconds histogram vllm:request_prefill_time_seconds_sum{model_name="DeepSeek-R1-Distill-Llama-8B"} 0.8215038776397705 .... vllm:request_prefill_time_seconds_count{model_name="DeepSeek-R1-Distill-Llama-8B"} 2.0 # HELP vllm:request_decode_time_seconds Histogram of time spent in DECODE phase for request. # TYPE vllm:request_decode_time_seconds histogram vllm:request_decode_time_seconds_sum{model_name="DeepSeek-R1-Distill-Llama-8B"} 10.362391948699951 .... vllm:request_decode_time_seconds_count{model_name="DeepSeek-R1-Distill-Llama-8B"} 2.0 # HELP vllm:time_in_queue_requests Histogram of time the request spent in the queue in seconds. # TYPE vllm:time_in_queue_requests histogram vllm:time_in_queue_requests_sum{model_name="DeepSeek-R1-Distill-Llama-8B"} 0.0014662742614746094 .... vllm:time_in_queue_requests_bucket{le="+Inf",model_name="DeepSeek-R1-Distill-Llama-8B"} 2.0 vllm:time_in_queue_requests_count{model_name="DeepSeek-R1-Distill-Llama-8B"} 2.0 # HELP vllm:request_prompt_tokens Number of prefill tokens processed. # TYPE vllm:request_prompt_tokens histogram vllm:request_prompt_tokens_sum{model_name="DeepSeek-R1-Distill-Llama-8B"} 16.0 .... vllm:request_prompt_tokens_bucket{le="+Inf",model_name="DeepSeek-R1-Distill-Llama-8B"} 2.0 vllm:request_prompt_tokens_count{model_name="DeepSeek-R1-Distill-Llama-8B"} 2.0 # HELP vllm:request_generation_tokens Number of generation tokens processed. # TYPE vllm:request_generation_tokens histogram vllm:request_generation_tokens_sum{model_name="DeepSeek-R1-Distill-Llama-8B"} 256.0 .... vllm:request_generation_tokens_count{model_name="DeepSeek-R1-Distill-Llama-8B"} 2.0 # HELP vllm:request_params_n Histogram of the n request parameter. # TYPE vllm:request_params_n histogram vllm:request_params_n_sum{model_name="DeepSeek-R1-Distill-Llama-8B"} 2.0 vllm:request_params_n_bucket{le="1.0",model_name="DeepSeek-R1-Distill-Llama-8B"} 2.0 .... vllm:request_params_n_count{model_name="DeepSeek-R1-Distill-Llama-8B"} 2.0 # HELP vllm:request_max_num_generation_tokens Histogram of maximum number of requested generation tokens. # TYPE vllm:request_max_num_generation_tokens histogram vllm:request_max_num_generation_tokens_sum{model_name="DeepSeek-R1-Distill-Llama-8B"} 256.0 .... vllm:request_max_num_generation_tokens_count{model_name="DeepSeek-R1-Distill-Llama-8B"} 2.0 # HELP vllm:request_params_max_tokens Histogram of the max_tokens request parameter. # TYPE vllm:request_params_max_tokens histogram vllm:request_params_max_tokens_sum{model_name="DeepSeek-R1-Distill-Llama-8B"} 256.0 .... vllm:request_params_max_tokens_bucket{le="+Inf",model_name="DeepSeek-R1-Distill-Llama-8B"} 2.0 vllm:request_params_max_tokens_count{model_name="DeepSeek-R1-Distill-Llama-8B"} 2.0 # HELP vllm:lora_requests_info Running stats on lora requests. # TYPE vllm:lora_requests_info gauge vllm:lora_requests_info{max_lora="0",running_lora_adapters="",waiting_lora_adapters=""} 1.7387586964559853e+09 # HELP vllm:num_preemptions_total Cumulative number of preemption from the engine. # TYPE vllm:num_preemptions_total counter vllm:num_preemptions_total{model_name="DeepSeek-R1-Distill-Llama-8B"} 0.0 # HELP vllm:prompt_tokens_total Number of prefill tokens processed. # TYPE vllm:prompt_tokens_total counter vllm:prompt_tokens_total{model_name="DeepSeek-R1-Distill-Llama-8B"} 16.0 # HELP vllm:generation_tokens_total Number of generation tokens processed. # TYPE vllm:generation_tokens_total counter vllm:generation_tokens_total{model_name="DeepSeek-R1-Distill-Llama-8B"} 256.0 # HELP vllm:request_success_total Count of successfully processed requests. # TYPE vllm:request_success_total counter vllm:request_success_total{finished_reason="length",model_name="DeepSeek-R1-Distill-Llama-8B"} 2.0 # HELP vllm:num_requests_running Number of requests currently running on GPU. # TYPE vllm:num_requests_running gauge vllm:num_requests_running{model_name="DeepSeek-R1-Distill-Llama-8B"} 0.0 # HELP vllm:num_requests_swapped Number of requests swapped to CPU. # TYPE vllm:num_requests_swapped gauge vllm:num_requests_swapped{model_name="DeepSeek-R1-Distill-Llama-8B"} 0.0 # HELP vllm:num_requests_waiting Number of requests waiting to be processed. # TYPE vllm:num_requests_waiting gauge vllm:num_requests_waiting{model_name="DeepSeek-R1-Distill-Llama-8B"} 0.0 # HELP vllm:gpu_cache_usage_perc GPU KV-cache usage. 1 means 100 percent usage. # TYPE vllm:gpu_cache_usage_perc gauge vllm:gpu_cache_usage_perc{model_name="DeepSeek-R1-Distill-Llama-8B"} 0.0 # HELP vllm:cpu_cache_usage_perc CPU KV-cache usage. 1 means 100 percent usage. # TYPE vllm:cpu_cache_usage_perc gauge vllm:cpu_cache_usage_perc{model_name="DeepSeek-R1-Distill-Llama-8B"} 0.0 # HELP vllm:cpu_prefix_cache_hit_rate CPU prefix cache block hit rate. # TYPE vllm:cpu_prefix_cache_hit_rate gauge vllm:cpu_prefix_cache_hit_rate{model_name="DeepSeek-R1-Distill-Llama-8B"} -1.0 # HELP vllm:gpu_prefix_cache_hit_rate GPU prefix cache block hit rate. # TYPE vllm:gpu_prefix_cache_hit_rate gauge vllm:gpu_prefix_cache_hit_rate{model_name="DeepSeek-R1-Distill-Llama-8B"} -1.0 # HELP vllm:cache_config_info Information of the LLMEngine CacheConfig # TYPE vllm:cache_config_info gauge vllm:cache_config_info{block_size="2048",cache_dtype="auto",calculate_kv_scales="False",cpu_offload_gb="0",enable_prefix_caching="False",gpu_memory_utilization="0.9",is_attention_free="False",num_cpu_blocks="0",num_gpu_blocks="4",num_gpu_blocks_override="None",sliding_window="None",swap_space_bytes="4294967296"} 1.0

但是这样的输出看起来很不直接，还是需要图形化的展示，便于我们在部署大语言模型后能更加清楚地了解模型的性能情况。Prometheus & Grafana 可以帮助我们实现这个要求。

3.2.1 通过 Prometheus + Grafana 优化监控面板

参考：

  1. http://docs.vllm.ai/en/latest/getting_started/examples/prometheus_grafana.html
  2. http://github.com/vllm-project/vllm/tree/main/examples/online_serving/prometheus_grafana

可以使用 vllm 提供的样例， 其中 Prometheus 的采样周期在 prometheus.yaml 中定义为 5 秒。

~/vllm/examples/online_serving/prometheus_grafana$ tree ./ 
./ 
├── README.md 
├── docker-compose.yaml 
├── grafana.json 
└── prometheus.yaml 

0 directories, 4 files

启动 prometheus 和 grafana 服务：

docker compose up

为了能拿到更丰富测试数据以便于展示的性能指标， 我们运行 benchmark 测试：

python3 ../../../benchmarks/benchmark_serving.py \
 --model deepseek-ai/DeepSeek-R1-Distill-Llama-8B \
--tokenizer deepseek-ai/DeepSeek-R1-Distill-Llama-8B \
--endpoint /v1/completions \
--dataset-name sharegpt \
--dataset-path ShareGPT_V3_unfiltered_cleaned_split.json \
--request-rate 3.0 \
--served-model-name DeepSeek-R1-Distill-Llama-8B \
--port 8000

ShareGPT_V3_unfiltered_cleaned_split 是一个广泛用于大语言模型性能测试的数据集，包含了客户和 GPT 之间的真实对话数据，用于评估在不同输入长度下的性能表现，测量模型的吞吐速度和生成速度。这个数据集已成为多个主流 LLM 推理框架（如 vLLM、TGI、OpenPPL 等）的标准测试数据集，可以从 Hugging Face 或其镜像站点下载。

wget http://huggingface.co/datasets/anon8231489123/ShareGPT_Vicuna_unfiltered/resolve/main/ShareGPT_V3_unfiltered_cleaned_split.json

安装在 DLA 中缺少的一些库：

pip install datasets

运行结果截图：

开始配置 Grafana & Prometheus

  • 使用初始密码 admin/admin 登陆 http://[ip]:3000
  • 添加 connections → data sources

save & test

  • 创建 Grafana dashboard， 选择右上角 New → import

可以使用 vllm 提供的版本：http://docs.vllm.ai/en/latest/getting_started/examples/prometheus_grafana.html

注意将其中的模型替换为我们通过 vllm 启动的模型。

选择 load， 得到下面的监控图标。

3.2.2 了解监控图表

*监控图表仅作为展示，并不和上述运行配置对应。 

请求情况

上面两张图表为 benchmark 测试输入的 prompt token 数量，和大语言模型生成的 token 数量的分布情况。两张表的纵轴表示输入和生成的 token 数的长度区间，从 0～2000 token；横轴表示测试的时间范围。颜色由浅绿，到黄色，再到深红的渐变表示请求次数。

负载情况
  • Scheduler State：Num waiting 持续上升，从 0 增加到 600 左右，表示系统积压了大量的等待处理请求，处理能力已经到到瓶颈，当前配置的计算资源已经无法满足请求处理需求。
  • Queue Time：队列等待时间从接近 0 秒快速上升到接近 30 秒，曲线呈现持续上升的趋势，这说明在队列中的等待时间越来越长，系统处理能力不足导致请求堆积。

延迟指标

  • TTFT – 首 token 延迟

P99 延迟约 10 秒，P50 延迟为 5 秒，平均延迟呈上升趋势，从 0.5 秒上升到 5 秒，说明随着时间的推移，系统负载可能在增加。

  • TPOT – 每个输出 token 的延迟

P99 延迟为 300ms-350ms， P50 和平均延迟稳定在 150ms-200ms 之间，说明整体 token 输出的速度比较稳定。

TPOT 是主要影响客户感受的指标，普通人的一般阅读速度在 200～300 词每分钟，一般 100ms 以内可以保证流畅的用户体验，400ms 以内可以保持用户的注意力。

  • 整体延迟

端到端的请求延迟从 10 秒左右逐渐上升到 3 分钟，平均延迟也呈上升趋势， 表明系统存在性能瓶颈。

从这三个性能指标来看：

  • P50 延迟延迟相对稳定，说明大部分请求响应正常，每个输出 token 的延迟稳定，保证了生成的连续性；
  • 首 token 延迟偏高，特别是 P99 延迟，端到端延迟持续增长；
  • token 间延迟高于理想值。

吞吐量指标
  • 每秒产生的 token 数：图上检查点为 24.4 token/s。
  • Cache Utilization：展示了 GPU Cache Usage 和 CPU Cache Usage，分别代表 GPU 显存中 KV 缓存的使用率，和 CPU 内存中 KV 缓存的使用率。当 GPU 显存接近饱和时，会将部分请求换出到 CPU 内存中。CPU-GPU 的数据传输会带来额外开销，影响推理性能。
  • Max Generation Token in Sequence Group：表示每个序列组中生成的最大 token 数量，反映了模型生成文本长度的动态变化。生成 token 的数量会影响推理延迟、GPU 内存使用和系统整体的吞吐量。这个参数受到 max_tokens、min_tokens 和 stop_token_ids, ignore_eos 和 bad_words 等影响。详情可以参卡片下面的链接： http://docs.vllm.ai/en/latest/api/inference_params.html。
  • Finish Reasons：反映了生成过程结束的原因，主要包含由长度限制结束和由停止条件结束。长度限制包含达到 max_token 设定的最大生成长度，和达到模型的最大上下文长度限制。停止条件结束包含遇到停止字符串，遇到指定的停止 token id 和模型的结束符号（EOS token）。
  • Requests Prefill 和 Decode Time：分别表示处理输入 prompt 阶段的时间和生成新 token 的时间。prefill 影响首 token 延迟，Decode 影响 token 间延迟。

4. 总结

本文介绍了如何使用 Prometheus 和 Grafana 监控基于 vLLM 部署的 DeepSeek 蒸馏后的 llama 模型性能，讨论了关注模型性能指标的重要性和关键指标：首 Token 延迟（TTFT）、Token 间延迟（TPOT）和端到端延迟，讲解了如何配置 Prometheus 和 Grafana 监控模型性能，并针对 Grafana dashboard 中的一些性能指标进行了分析。通过这些指标的综合分析，可以有效评估模型部署的性能表现，及时发现系统瓶颈，优化资源配置，在保证用户体验的同时，实现成本的有效控制。

*前述特定亚马逊云科技生成式人工智能相关的服务仅在亚马逊云科技海外区域可用，亚马逊云科技中国仅为帮助您了解行业前沿技术和发展海外业务选择推介该服务。

5. 参考链接

本篇作者

冯源

亚马逊云科技解决方案架构师，曾服务于南洋理工大学、惠普和新智云。工作涉及企业混合云环境运维管理、运营管理、混合云平台和云服务解决方案。有十余年企业基础设施咨询及实施、项目管理和交付以及混合云平台研发管理经验。2022 年加入亚马逊云科技，关注 Greenfield 客户使用亚马逊云科技的场景，曾负责广告、零售、餐饮，制造和教育等客户。

何培培

亚马逊云科技解决方案架构师，负责基于亚马逊云科技的云计算方案架构咨询和设计。