资讯详情

深入了解 · 专业解读

私有大模型API部署：为什么租用GPU服务器是最优解

发布时间：2026/7/18 2:39:18
私有大模型API部署：为什么租用GPU服务器是最优解 1. 为什么非得在租用GPU服务器上跑私有大模型API——先破除三个典型幻觉“本地MacBook M3 Pro跑Qwen2.5-7B够不够用”“我有台闲置的i964G内存RTX4090主机是不是直接就能当生产API服务”“云厂商免费试用的A10实例部署完就能对外提供服务了吧”这三个问题我在过去两年里被问了至少187次。每次回答前我都得先泡杯浓茶——因为接下来要拆的不是技术而是认知地基。真实情况是租用GPU服务器不是“退而求其次”的妥协方案而是当前私有大模型API落地最理性、最可控、最具成本弹性的工程选择。它既不是“比本地强一点”也不是“比公有云API便宜一点”而是一套完整的技术决策闭环。先说第一个幻觉“本地MacBook能跑何必租服务器”M3 Pro的16GB统一内存跑Qwen2.5-7B量化版AWQ 4-bit确实能启动但实测吞吐量是0.8 token/s上下文撑死2K tokens。一旦接入一个带RAG的Web前端用户点击查询后等待32秒才返回首token——这不是AI服务这是行为艺术。更关键的是macOS对CUDA生态零支持所有vLLM、TGI、sglang等高性能推理引擎全失效你只能用llama.cpp这种CPU优先方案等于主动放弃GPU加速红利。第二个幻觉“我那台RTX4090主机就是现成的服务器。”硬件没错但系统层漏洞百出。我帮一位朋友诊断过他自建的4090集群Ubuntu 22.04 NVIDIA驱动535 CUDA 12.2表面一切正常但vLLM启动时反复报CUDA driver version is insufficient for CUDA runtime version。查了三天才发现他用apt install nvidia-driver-535装的驱动实际加载的是内核模块nvidia_uvm而vLLM依赖的CUDA Runtime需要nvidia-dkms包里的完整符号表。这种驱动/运行时版本错配在个人主机上几乎100%存在但在租用服务器上服务商已预置好经过验证的驱动栈组合比如Lambda Labs的Ubuntu 22.04镜像默认配CUDA 12.4 Driver 535.129.03省掉你至少17小时的环境踩坑。第三个幻觉最危险“云厂商免费A10实例拿来就用。”A10单卡24GB显存跑Llama3-8B-Instill没问题但注意它的PCIe带宽是x16 Gen464GB/s而同价位A100是x16 Gen464GB/s但显存带宽达2TB/s。当你用vLLM做PagedAttention时KV Cache频繁换页A10的显存带宽瓶颈会直接导致prefill阶段延迟飙升400%。我们实测过同样Llama3-8B-InstillA10上首token延迟1.8sA100上仅0.32s。免费资源的隐性成本是牺牲用户体验和业务响应SLA。所以租用GPU服务器的核心价值从来不是“有没有GPU”而是把GPU变成可预测、可计量、可回滚的基础设施单元。它让你跳过硬件采购周期、绕开驱动兼容地狱、规避电力与散热运维把全部精力聚焦在模型选型、API封装、流量治理这些真正创造业务价值的环节上。提示别被“租用”二字吓住。主流服务商如Vast.ai、RunPod、Lambda Labs的按小时计费模式实际成本可能低于你家宽带月费。以A100×1为例RunPod标价$0.39/h每天满负荷运行24小时≈$9.36而你买一张二手A100显卡加电源散热改造成本已超$800且无SLA保障。2. 租用GPU服务器的选型铁律三看一测拒绝参数幻觉选服务器不是比谁显存大、谁FP16算力高。我经手过32个私有大模型API项目失败的11个里10个栽在初始选型上。核心教训只有一条服务器不是模型的容器而是API服务的承重墙。承重墙要扛住什么并发请求、长上下文、流式响应、错误熔断——这些才是选型的刻度尺。2.1 看显存带宽决定你能不能撑住128K上下文很多人盯着显存容量VRAM看却忽略显存带宽Memory Bandwidth。这是致命误区。举个真实案例客户要用DeepSeek-V2-236B跑128K上下文租了两台A100 80GBSXM4结果API平均延迟从2.1s飙到18.7s。抓取GPU指标发现sm__inst_executedSM指令执行数没爆但dram__bytes_read显存读字节数持续98%打满。原因A100 80GB的显存带宽是2TB/s但128K上下文下KV Cache占显存约62GB每次prefill需从显存读取超400GB数据。2TB/s带宽理论最大吞吐250GB/s实际受PCIe拓扑限制有效带宽仅1.2TB/s——根本不够用。解决方案换H100 80GBSXM5显存带宽3.35TB/s且支持HBM3NVLink 4.0多卡间KV Cache同步延迟降低76%。但注意H100贵得多是否值得要看你的业务场景。如果只是内部知识库问答平均上下文8KA100完全够用如果要做法律合同全文比对动辄100K tokensH100是刚需。所以选型第一铁律根据目标模型的最大上下文长度反推所需最小显存带宽。计算公式如下所需最小带宽(GB/s) (KV_Cache_Size_GB × 2) ÷ (Prefill_Time_s × 0.8) // 其中0.8是实际带宽利用率系数2是读写双倍开销 // KV_Cache_Size_GB ≈ (Model_Params_Billion × 2 × Context_Length_Tokens) ÷ 10^9以Llama3-70B-Instill70B参数跑32K上下文为例KV_Cache_Size ≈ (70 × 2 × 32000) ÷ 10^9 4.48GB要求Prefill时间≤1.5s → 所需带宽 ≥ (4.48 × 2) ÷ (1.5 × 0.8) ≈ 7.47 GB/s→ A101.6TB/s绰绰有余连RTX40901TB/s都远超需求。2.2 看PCIe通道决定你能不能稳住100并发流式响应很多团队用vLLM部署后单卡QPS能到35但一上生产就崩。查日志全是CUDA out of memory奇怪的是nvidia-smi显示显存只用了65%。真相藏在PCIe带宽里。vLLM的PagedAttention机制要求每个请求的KV Cache页在GPU显存中连续存放。当并发请求数激增页表管理器BlockManager需高频访问GPU页表而页表本身存储在GPU显存中。此时CPU需通过PCIe总线向GPU发送大量小包内存访问指令。若PCIe带宽不足指令排队导致GPU计算单元空转显存虽未满但计算吞吐骤降。我们实测过同一台A100服务器PCIe配置不同带来的差异配置PCIe版本通道数实际可用带宽100并发流式QPS默认BIOSGen4x165.8GB/s28.3BIOS强制Gen5Gen5x1612.5GB/s41.7BIOS启用Resizable BARGen5x16 RBA14.2GB/s47.9看到没仅靠BIOS调优QPS提升近70%。而租用服务器的优势在于Lambda Labs和RunPod的A100实例默认开启Resizable BARVast.ai的H100实例甚至预装NVIDIA Base Command Platform自动优化PCIe拓扑。所以选型第二铁律必须确认服务商是否开放PCIe高级特性Resizable BAR、ASPM L1 Substates的BIOS控制权。没有这个再好的GPU也是跛脚马。2.3 看网络IO决定你API的P99延迟能不能压进500msAPI服务的P99延迟70%由网络IO决定而非模型推理。尤其当你的前端是Web应用用户通过HTTPS调用API时整个链路是浏览器 → CDN → 负载均衡 → API网关 → 模型服务 → 返回其中“API网关 → 模型服务”这跳如果走公网延迟波动极大。我们曾遇到某客户用AWS EC2部署模型服务在us-east-1API网关在ap-southeast-1跨区域调用P99延迟高达1.2s。解决方案租用服务器时必须选择与你API网关同地域、同可用区AZ的实例。更进一步如果网关用Kong或Traefik可配置hostNetwork: true让API网关Pod直接使用宿主机网络消除Service Mesh的额外跳转。但最关键的隐藏项是服务器是否提供10Gbps以上内网带宽很多低价实例标称“高网络性能”实际是共享带宽。RunPod的Enterprise Plan明确承诺“Guaranteed 10Gbps Private Network”而Vast.ai的“High Network”标签仅表示“优先调度”无SLA。我们压测过同为A100实例RunPod的10Gbps内网在1000并发下P99延迟稳定在320msVast.ai同配置实例P99跳变至680ms。2.4 一测用真实负载压测拒绝“Hello World”式验证所有参数都是纸面数据。最终决策必须基于真实压测。我的标准测试流程分三步Step 1冷启耗时测试# 启动vLLM服务后立即curl -X POST time curl -s http://localhost:8000/v1/completions \ -H Content-Type: application/json \ -d {model:qwen2.5-7b,prompt:Hello,max_tokens:1}合格线A100 ≤ 8.5sH100 ≤ 5.2s。超时说明镜像或启动脚本有缺陷。Step 2流式响应稳定性测试用wrk模拟100并发持续5分钟wrk -t12 -c100 -d300s \ --scriptstream-test.lua \ --latency http://your-server-ip:8000/v1/chat/completionsstream-test.lua需解析SSE流统计首token延迟TTFT和每token延迟TPOT。合格线TTFT P95 ≤ 1.2sTPOT P95 ≤ 80ms。Step 3错误熔断压力测试故意发送超长prompt131072 tokens观察服务是否OOM崩溃或优雅返回context_length_exceeded。崩溃即淘汰。注意压测必须在租用后、部署前完成。我见过太多团队跳过这步上线后才发现A10实例在128并发下第97个请求开始出现Connection reset by peer——根源是实例的TCP连接队列溢出需调大net.core.somaxconn但很多服务商不开放sysctl权限。3. 部署栈的黄金组合为什么vLLM FastAPI Docker是当前最优解市面上部署方案五花八门Ollama主打易用TGI强调企业级sglang专注函数调用但真正在生产环境扛住日均50万请求的90%用的是vLLM FastAPI Docker组合。这不是跟风而是三年实战淬炼出的平衡点。3.1 vLLM为何胜出PagedAttention不是营销话术是实打实的显存榨取术很多人以为vLLM快是因为用了CUDA Graph错了。CUDA Graph只加速kernel launch真正革命性的是PagedAttention——它把GPU显存当成操作系统的虚拟内存来管理。传统Attention如HuggingFace Transformers中每个请求的KV Cache必须在显存中连续分配。假设Llama3-8B单请求KV Cache需1.2GB10个并发就要12GB连续显存。但GPU显存碎片化严重实际可能有15GB空闲却因无法凑出12GB连续块而OOM。PagedAttention怎么做它把KV Cache切成固定大小的页Page每页2KB分散存入显存任意位置用页表Page Table记录映射关系。就像Linux的页表管理物理内存vLLM的页表管理GPU显存。这样10个请求只需10×2KB20KB页表空间显存利用率从45%提升至89%。我们实测对比A100 80GB方案最大并发数显存占用率P95 TTFTTransformers FlashAttention-21478%1.42svLLM默认配置3289%0.87svLLM启用CUDA Graph PagedAttention4192%0.63s看到没并发能力翻了近3倍而显存占用只增3%。这就是PagedAttention的威力——它让GPU显存从“刚性容器”变成“弹性池子”。但vLLM不是万能的。它对模型格式有强约束必须是HuggingFace格式且需支持apply_rotary_pos_emb等底层算子。DeepSeek-V2官方权重就因RoPE实现差异需手动patchmodeling_deepseek.py才能加载。这点必须提前验证。3.2 FastAPI为何不可替代异步IO不是锦上添花是API服务的生命线有人问“既然vLLM自带HTTP Server为啥还要套FastAPI”答案vLLM的Server是单线程阻塞式而FastAPI是异步非阻塞式。区别在哪想象一个场景用户A发来长文本摘要请求耗时8s用户B同时发来简单问答耗时0.3s。vLLM原生Server会把B的请求排在A后面B要等8.3sFastAPI则用async/awaitB的请求在A处理间隙被快速响应。FastAPI的异步能力来自Starlette底层ASGI框架和UvicornASGI服务器。它能把HTTP请求解析、JSON序列化、日志记录这些I/O密集型操作交给事件循环并发处理而把模型推理这种CPU/GPU密集型任务交给vLLM的专用进程池。我们的部署架构图[Client] ↓ HTTPS [Cloudflare CDN] ↓ (缓存静态资源透传API) [Load Balancer] ↓ (Round Robin到多台API服务器) [FastAPI Gateway] ←→ [vLLM Worker Pool] ↑ ↑ Async I/O GPU Compute (Uvicorn) (vLLM Engine)关键设计点FastAPI不碰模型只做三件事请求校验检查model参数是否在白名单[qwen2.5-7b, deepseek-v2-236b]非法请求直接400返回不进vLLM流式代理将客户端SSE请求转换为vLLM的/v1/chat/completions流式调用再把vLLM的data: {...}逐行转发给客户端熔断监控用tenacity库实现指数退避重试当vLLM返回503时自动降级到备用模型如本地Ollama的Phi-3-mini。这套组合让我们在单台A100服务器上稳定支撑200并发P99延迟400ms。而纯vLLM Server在150并发时就开始丢包。3.3 Docker为何是必选项不是为了“上云”而是为了“可重现”反对Docker的人常说“Docker有性能损耗裸机部署更快。”这话对但错在前提——私有大模型API的核心诉求不是极致性能而是可重现、可审计、可回滚。没有Docker你会陷入“环境沼泽”开发机用Ubuntu 22.04 CUDA 12.2生产服务器是CentOS 7 CUDA 11.8vLLM编译报错运维同事升级了NVIDIA驱动vLLM突然报libcudart.so.12: cannot open shared object file安全团队要求禁用root用户但vLLM启动脚本硬编码了sudo。Docker如何破局镜像即契约Dockerfile明确定义了OS、CUDA、Python、vLLM版本docker build生成的镜像是环境的唯一真相运行时隔离--gpus all --shm-size2g参数确保GPU和共享内存资源独占避免与其他进程争抢一键回滚docker pull your-registry/model-api:v1.2.3docker stop docker run5秒切回旧版本。我们的标准Dockerfile关键段FROM nvcr.io/nvidia/pytorch:23.10-py3 # 使用NVIDIA官方PyTorch镜像预装CUDA 12.2 cuDNN 8.9省去90%编译时间 RUN pip install --no-cache-dir vllm0.4.2 \ pip install --no-cache-dir fastapi0.111.0 uvicorn0.29.0 COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt # 关键设置GPU内存限制防止单请求OOM拖垮整机 ENV VLLM_MAX_NUM_SEQS256 ENV VLLM_MAX_MODEL_LEN32768 CMD [uvicorn, main:app, --host, 0.0.0.0:8000, --port, 8000, --workers, 1]注意不要用--gpus device0这种指定设备号的方式。租用服务器的GPU设备号可能动态变化如重启后从/dev/nvidia0变成/dev/nvidia1应始终用--gpus all让NVIDIA Container Toolkit自动映射。4. 从零部署全流程手把手带你跑通第一个私有大模型API现在我们把前面所有原则落地为可执行步骤。以下流程已在Lambda Labs、RunPod、Vast.ai三大平台实测通过耗时控制在22分钟内含压测。4.1 准备工作三件套缺一不可第一件SSH密钥对租用服务器时必须上传SSH公钥id_rsa.pub。别用密码登录——既不安全又无法自动化。生成命令ssh-keygen -t rsa -b 4096 -C your_emailexample.com -f ~/.ssh/gpu-server-key # 将~/.ssh/gpu-server-key.pub内容粘贴到服务商控制台第二件模型权重下载脚本别在服务器上用git lfs clone——太慢且易中断。用huggingface-hub工具pip install huggingface-hub huggingface-cli download --resume-download \ Qwen/Qwen2.5-7B-Instruct \ --local-dir ./models/qwen2.5-7b \ --revision main--resume-download支持断点续传--revision指定分支避免master分支更新导致模型不一致。第三件基础环境检查清单登录服务器后立即执行# 1. 检查GPU识别 nvidia-smi -L # 应输出GPU 0: ... (UUID: GPU-xxxx) # 2. 检查CUDA驱动兼容性 nvidia-smi | grep CUDA Version # 如12.4 nvcc --version # 如12.2 —— 驱动版本≥CUDA Runtime版本才正常 # 3. 检查PCIe带宽关键 lspci -vv -s $(lspci | grep NVIDIA | head -1 | awk {print $1}) | grep LnkSta: | head -1 # 输出应为Speed 16GT/s, Width x16若为Speed 8GT/s则需进BIOS调优4.2 构建部署镜像Dockerfile的魔鬼细节创建项目目录mkdir -p model-api/{models,src,docker} cd model-apidocker/Dockerfile内容已针对租用服务器优化# 使用NVIDIA官方镜像避免CUDA版本冲突 FROM nvcr.io/nvidia/pytorch:23.10-py3 # 设置时区避免日志时间错乱 ENV TZAsia/Shanghai RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime echo $TZ /etc/timezone # 安装系统依赖解决常见缺失库 RUN apt-get update apt-get install -y \ libglib2.0-0 \ libsm6 \ libxext6 \ libxrender-dev \ rm -rf /var/lib/apt/lists/* # 创建非root用户安全刚需 RUN useradd -m -u 1001 -g root -s /bin/bash modeluser USER modeluser WORKDIR /home/modeluser # 复制模型权重注意生产环境应挂载卷此处为演示 COPY models/ ./models/ # 安装Python依赖 COPY src/requirements.txt . RUN pip install --no-cache-dir -r requirements.txt # 复制应用代码 COPY src/ ./src/ # 暴露端口 EXPOSE 8000 # 启动命令关键--host 0.0.0.0绑定所有接口 CMD [uvicorn, src.main:app, --host, 0.0.0.0:8000, --port, 8000, --workers, 1, --log-level, info]src/requirements.txtvllm0.4.2 fastapi0.111.0 uvicorn0.29.0 pydantic2.7.1 python-multipart0.0.9src/main.py核心逻辑精简版from fastapi import FastAPI, HTTPException, Request, BackgroundTasks from vllm import AsyncLLMEngine from vllm.engine.arg_utils import AsyncEngineArgs from vllm.sampling_params import SamplingParams import asyncio app FastAPI(titlePrivate LLM API) # 初始化vLLM引擎注意必须在全局作用域避免重复初始化 engine_args AsyncEngineArgs( model./models/qwen2.5-7b, tensor_parallel_size1, gpu_memory_utilization0.9, max_model_len32768, enforce_eagerFalse, # 生产环境设为True避免CUDA Graph编译抖动 ) engine AsyncLLMEngine.from_engine_args(engine_args) app.post(/v1/chat/completions) async def chat_completions(request: Request): try: body await request.json() # 校验model参数 if body.get(model) ! qwen2.5-7b: raise HTTPException(400, Unsupported model) # 构建SamplingParams sampling_params SamplingParams( temperaturebody.get(temperature, 0.7), top_pbody.get(top_p, 0.9), max_tokensbody.get(max_tokens, 1024), streambody.get(stream, False) ) # 异步调用vLLM results_generator engine.generate( body[messages][0][content], # 简化只取首消息 sampling_params, request_idfreq-{int(asyncio.time())} ) # 流式响应 async def generate(): async for request_output in results_generator: yield fdata: {json.dumps(request_output.dict())}\n\n return StreamingResponse(generate(), media_typetext/event-stream) except Exception as e: raise HTTPException(500, str(e))4.3 一键部署Shell脚本封装所有脏活创建deploy.sh实现“一行命令全程无人值守”#!/bin/bash # deploy.sh - 私有大模型API一键部署脚本 SERVER_IPyour-server-ip MODEL_NAMEqwen2.5-7b IMAGE_NAMEprivate-llm-api echo 【步骤1】上传代码到服务器... scp -i ~/.ssh/gpu-server-key -r ./model-api/* modeluser${SERVER_IP}:/home/modeluser/model-api/ echo 【步骤2】远程构建Docker镜像... ssh -i ~/.ssh/gpu-server-key modeluser${SERVER_IP} EOF cd ~/model-api docker build -t ${IMAGE_NAME} -f docker/Dockerfile . EOF echo 【步骤3】启动容器自动重启挂载模型卷... ssh -i ~/.ssh/gpu-server-key modeluser${SERVER_IP} EOF docker run -d \ --name llm-api \ --gpus all \ --shm-size2g \ --network host \ --restart unless-stopped \ -v /home/modeluser/model-api/models:/home/modeluser/models \ -p 8000:8000 \ private-llm-api EOF echo 【步骤4】验证服务状态... sleep 5 curl -s http://${SERVER_IP}:8000/docs | head -20 | grep Swagger UI echo ✅ API服务启动成功 || echo ❌ 启动失败请检查日志 echo 【步骤5】查看实时日志... ssh -i ~/.ssh/gpu-server-key modeluser${SERVER_IP} docker logs -f llm-api赋予执行权限并运行chmod x deploy.sh ./deploy.sh4.4 上线前必做四层健康检查服务起来不等于能用。必须通过四层检查第一层API连通性curl -X POST http://your-server-ip:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5-7b, messages: [{role: user, content: 你好}], stream: false } | jq .choices[0].message.content # 应返回你好很高兴见到你。第二层流式响应完整性用浏览器访问http://your-server-ip:8000/docs在Swagger UI中测试/v1/chat/completions勾选streamtrue观察是否逐字返回SSE格式。第三层错误处理健壮性故意发超长promptcurl -X POST http://your-server-ip:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5-7b, messages: [{role: user, content: $(printf x%.0s {1..131073})}], stream: false } # 应返回400错误且message包含context_length_exceeded第四层资源占用合理性ssh modeluseryour-server-ip nvidia-smi --query-gpuutilization.gpu,memory.used --formatcsv,noheader,nounits # 正常值GPU-Util 70%Memory-Usage 90%经验之谈如果nvidia-smi显示GPU-Util长期30%说明vLLM没跑起来检查Docker日志是否有ImportError: libcudart.so.12如果Memory-Usage95%说明gpu_memory_utilization参数设太高需调低至0.85。5. 生产就绪的七把锁没有这七步你的API就是纸糊的部署成功只是起点。真正的挑战在上线后——流量突增、模型异常、安全攻击、成本失控。以下是我在32个项目中总结出的“生产就绪七把锁”缺一不可。5.1 锁1API网关层限流——防止单用户吃光所有GPUvLLM本身不提供限流必须在API网关层实现。我们用Kong开源版配置# kong.yaml services: - name: llm-service url: http://127.0.0.1:8000 routes: - name: llm-route paths: [/v1/] plugins: - name: rate-limiting config: minute: 60 # 每分钟最多60次 policy: local identifier: header key: X-User-ID # 从请求头提取用户标识关键点identifier: headerkey: X-User-ID让限流基于业务用户ID而非IP避免CDN导致所有用户共用一个IP。若没Kong用Nginx也能实现limit_req_zone $http_x_user_id zonellm_limit:10m rate1r/s; server { location /v1/ { limit_req zonellm_limit burst5 nodelay; proxy_pass http://127.0.0.1:8000; } }5.2 锁2模型加载预热——消灭首请求的“惊群效应”新模型首次加载时vLLM需编译CUDA Graph首请求延迟可能达15s。解决方案启动后自动预热。 在src/main.py中添加app.on_event(startup) async def startup_event(): 服务启动时预热模型 print(Warming up model...) sampling_params SamplingParams( temperature0.1, top_p0.95, max_tokens16, prompt_logprobs1 ) # 发送10个预热请求 for i in range(10): await engine.generate(warmup, sampling_params, request_idfwarmup-{i}) print(Model warmed up!)5.3 锁3日志结构化——让错误可追溯非“大海捞针”默认vLLM日志是纯文本难以分析。改用JSON日志import logging import json from pythonjsonlogger import jsonlogger class CustomJsonFormatter(jsonlogger.JsonFormatter): def add_fields(self, log_record, record, message_dict): super().add_fields(log_record, record, message_dict) log_record[timestamp] datetime.utcnow().isoformat() log_record[level] record.levelname # 在main.py中配置 logger logging.getLogger() logHandler logging.StreamHandler() formatter CustomJsonFormatter() logHandler.setFormatter(formatter) logger.addHandler(logHandler) logger.setLevel(logging.INFO)日志样例{timestamp: 2024-06-15T08:23:41.123Z, level: INFO, request_id: req-1718439821, model: qwen2.5-7b, input_tokens: 24, output_tokens: 156, ttft_ms: 842, tpot_ms: 67}5.4 锁4Prometheus监控——GPU不是黑箱是透明仪表盘用Prometheus抓取vLLM指标需启用--enable-prometheus# 启动vLLM时加参数 CMD [python, -m, vllm.entrypoints.api_server, \ --host, 0.0.0.0:8000, \ --port, 8000, \ --enable-prometheus, \ --prometheus-host, 0.0.0.0, \ --prometheus-port, 8001]Prometheus配置scrape_configs: - job_name: vllm static_configs

相关新闻