简介面向企业管理层与技术负责人的DeepSeek私有化部署方案资料聚焦降低AI落地门槛、拓展业务边界覆盖一体机硬件选型、成本优化与数据安全合规等关键问题。内容从DeepSeek V3/R1的性能与准确率提升出发梳理入门到专业级的英伟达GPU及国产信创机型配置给出AI智能知识库、文档翻译、ChatBI数据库查询、Office AI助手等开箱即用场景并强调私有化部署对数据安全、合规与定制化能力的价值适合正在评估大模型落地路径的企业决策者参考。资料为单份PDF文档共1个文件压缩包大小2.85MB已有92人学习。文档还包含不同型号的参数对比与选型指南可直接对照企业自身算力需求和预算选择合适的部署方案。1. DeepSeek应用一体机一份PDF方案背后的私有大模型落地路线DeepSeek应用一体机通俗讲就是把DeepSeek模型权重、推理引擎、API服务和常用应用预装到一台服务器上以整机形态交付给企业的私有化大模型方案。它解决的问题很直接企业手里有敏感数据不敢送到云端API又想要DeepSeek的生成与推理能力那就把模型搬到自己的机房或内网里对外只暴露一个OpenAI兼容接口内部业务系统通过这个接口使用模型能力。适合三类人看有GPU服务器但不知道从哪下手的甲方工程师做集成交付的乙方实施人员以及被“云端调用数据合规”卡住的项目负责人。这份方案通常以PDF形式在内部传阅但方案真正值钱的部分不是那张架构图而是从裸机到可用服务的完整落地路径。下文按选型、部署、接入、避坑、验收逐层拆开讲。2. 一体机的架构与算力选型显存、并发和模型规模的三角关系2.1 一体机的整体组成推理引擎、API网关与应用层各管哪一段拿到一份DeepSeek应用一体机方案先别急着看硬件配置单先看它的软件分层。常见做法是把整机拆成四层底层是GPU与系统环境往上走是推理引擎再往上是API服务层最顶层是落地的应用客户端。推理引擎承担模型加载、KV Cache管理和token生成常见选型是vLLM、SGLang或TensorRT-LLMAPI服务层把引擎包装成OpenAI兼容的HTTP接口应用层则五花八门有企业微信机器人、内部知识库问答、代码辅助工具以及跑在PC上的AI编程客户端。这四层里最容易“买错”的是推理引擎。很多一体机方案把模型权重下载下来就想跑结果用transformers的默认generate接口启动并发一上来GPU利用率上不去单卡4090跑32B模型慢到没法用。我的经验是只要做一体机推理引擎必须选vLLM这类带连续批处理continuous batching的框架它能把不同请求的prefill和decode阶段拼在一起算吞吐量能比朴素实现高一个数量级。API层则不需要自己造轮子vLLM自带OpenAI兼容服务省掉一层适配。应用层是交付时最容易返工的部分。一体机方案里写的“开箱即用”实际交付时往往要现场改一两天的对接代码因为客户的内部系统不认标准OpenAI协议或者需要在中间加一层权限校验。我一般会在方案里预留一个轻量API网关比如用FastAPI写一个转发层把vLLM的原始接口包一层加上API Key校验、调用审计和模型路由。这层不复杂但能让后续接入省很多事。2.2 算力估算多大数据量的模型配多少卡先算再买选硬件之前先做一个显存估算这个账算错了整机方案就废了。推理时显存消耗由三块组成模型权重、KV Cache、运行时激活值。模型权重很好估FP16精度下每10亿参数约占2GB显存7B模型约14GB32B模型约64GB70B模型约140GB。KV Cache是动态的它跟并发数和上下文长度成正比单条请求的KV Cache大小约等于 2K和V两份× 层数 × 注意力头维度 × 上下文长度 × 2字节。公式不用背记住一个经验值在32K上下文下为每路并发预留1~2GB显存比较稳妥。所以算显存有个口诀模型权重打底并发翻倍乘上下文再加成。举例一台双卡A10080GB的机器跑32B模型权重占64GB剩下96GB给KV Cache用按每路并发1.5GB算跑50路并发的32K上下文是够的。如果换成4卡409024GB单卡装不下32B全量权重就得做张量并行模型会切成4份占满96GB这时KV Cache只能挤剩下的空间并发能力大幅缩水。这就是为什么一体机方案里单卡4090往往只配7B或14B模型而不是硬上32B。显存这玩意儿最玄学的地方在于量化。AWQ或GPTQ量化到INT4权重直接减半32B模型用单张80G卡就能装下甚至勉强塞进48G卡。但量化会损失精度对代码生成任务影响较小对数学推理和长文本抽取影响明显。我的建议是如果客户业务以代码补全为主可以上INT4量化如果涉及数据分析、数学推理老老实实上全精度或FP8别在量化上省卡。2.3 模型规模选择7B、32B还是70B按业务容忍度来定模型规模的选择本质上是在算力成本和效果之间做取舍。7B级模型如DeepSeek-R1-Distill-Qwen-7B单卡就能跑响应快适合做简单的文本分类、关键词抽取、格式转换14B级模型需要一张24G以上的卡代码补全质量开始能用32B级是当前一体机的主流甜点区推理能力和代码能力相比7B有代差双卡配置成本也可控70B级以上要4卡A100/H100级别通常只有金融、政务这类对效果要求极高且预算充足的场景才上。判断该用哪个规模我一般问客户三个问题回答错了代价大不大单次请求能容忍多久并发量是几十还是几千如果回答错了只是内部知识库搜不到准确段落7B加RAG也能凑合如果是合同审核、代码仓库扫描直接上32B别浪费时间调小模型。并发这块要特别提醒很多乙方方案里写“支持100并发”指的是API层能接收100个请求真正卡脖子的是GPU的KV Cache和算力吞吐一体机的并发上限由显存和推理引擎共同决定不是靠改配置文件能突破的。3. 从裸机到可用服务DeepSeek本地部署的分步操作3.1 基础环境准备操作系统、驱动与Python推理栈拿到一台裸机服务器先从操作系统开始。Ubuntu 22.04是我在推理机上用得最多的系统CUDA驱动生态最省心如果是甲方指定的CentOS或麒麟系统确认内核版本和gcc版本后再装驱动不然容易在编译vLLM时踩坑。驱动版本建议CUDA 12.1以上用nvidia-smi确认显卡识别正常。然后是Python环境强烈建议用Miniconda隔离一个专门的推理环境不要让系统Python被污染。# 安装基础工具链 sudo apt update sudo apt install -y build-essential git curl # 安装 Miniconda wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh bash Miniconda3-latest-Linux-x86_64.sh -b -p /opt/miniconda3 source /opt/miniconda3/bin/activate # 创建推理专用环境 conda create -n vllm python3.10 -y conda activate vllm这里的核心逻辑是把推理依赖与系统隔离。Python 3.10不是越高越好而是要跟vLLM当前版本的兼容矩阵对齐3.10是目前兼容面最稳的选择。装完conda后顺手把pip升级到最新vLLM对pip版本有隐性要求老版本的pip在装torch时容易解析出冲突。接下来装PyTorch和vLLM。不要直接pip install vllm了事建议先装好与CUDA版本匹配的torch再装vLLM避免pip自动拉一个CPU版本的torch。# 安装与CUDA匹配的PyTorch这里以CUDA 12.1为例 pip install torch2.1.2 --index-url https://download.pytorch.org/whl/cu121 # 安装 vLLM pip install vllm # 验证安装 python -c import vllm; print(vllm.__version__)装完第一件事是跑一次python -c import vllm做冒烟验证。很多部署翻车都发生在这一步的静默阶段要么torch编译的是CPU版本要么CUDA运行时库没找到要么显卡驱动跟CUDA版本不匹配。vLLM在import时如果检测不到GPU会直接抛错这反而是好事能尽早暴露环境问题最怕的是import成功但跑起来莫名慢那就是GPU根本没被用上。3.2 用vLLM启动推理服务一条命令和它背后的参数模型权重准备好之后启动推理服务是整条链路里最关键的一步。新版vLLM推荐直接用vllm serve命令不需要手写Python入口。假设我把32B的DeepSeek模型权重放在/data/models/deepseek-r1-32b-instruct目录下启动命令长这样vllm serve /data/models/deepseek-r1-32b-instruct \ --served-model-name deepseek-r1 \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.85 \ --max-model-len 32768 \ --max-num-seqs 32 \ --host 0.0.0.0 \ --port 8000逐项说参数含义。--served-model-name是API对外暴露的模型名客户端请求里model字段填什么由它决定建议起一个业务友好的名称别把目录路径暴露出去。--tensor-parallel-size是张量并行卡数填2表示把模型切到两张卡上前提是两张卡之间走NVLink或PCIe高速互联否则通信开销会吃掉并行收益。--gpu-memory-utilization控制显存利用率上限0.85是保险值给CUDA上下文和碎片留出空间别填0.95以上实测高负载下容易炸OOM。--max-model-len是最长上下文直接影响KV Cache预留。设32768能满足绝大多数业务但如果知识库单段文本超过这个长度需要在知识库切块那里做控制。--max-num-seqs是同时参与批处理的最大序列数它不是并发上限而是排队上限超过这个数的请求会在引擎外部等待设置过小会导致吞吐上不去设置过大则KV Cache被打满。还有一个容易被忽略的参数--trust-remote-code。DeepSeek这类模型在加载tokenizer时往往需要执行远程代码不加上这个参数会直接报错很多新手在这里翻车。如果模型文件里有sentencepiece_model之类的自定义分词器务必加上vllm serve /data/models/deepseek-r1-32b-instruct \ --trust-remote-code \ --served-model-name deepseek-r1 \ --tensor-parallel-size 2启动日志里出现Uvicorn running on http://0.0.0.0:8000说明服务起来了。此时别急着接业务先确认模型是否完全加载日志中会有model weights loaded之类的字样没有加载成功但端口监听正常的假象偶尔会出现原因是加载失败后服务自动退出了8000端口被别的进程占用用ps aux | grep vllm核实一下最稳。3.3 验证OpenAI兼容接口curl确认服务真实可用服务起来后先别急着接业务系统用curl做一次最朴素的接口验证。两个接口必须测一个是/v1/models确认模型可见一个是/v1/chat/completions确认对话链路通。# 查看模型列表 curl http://127.0.0.1:8000/v1/models # 发起一次对话请求 curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer EMPTY \ -d { model: deepseek-r1, messages: [ {role: user, content: 用一句话解释什么是CORS} ], max_tokens: 256, temperature: 0.3 }注意Authorization头是必填的vLLM默认不校验内容但协议要求带上客户端SDK也会默认塞一个key。先填EMPTY占位后续如果要鉴权可以在启动命令里加--api-key设置真实密钥这时客户端必须传匹配的key才能访问。max_tokens建议显式设置不设的话部分客户端会用默认值可能跟一体机方案里约定的输出长度对不上。返回的JSON里关注两个字段choices[0].message.content是模型回答usage.total_tokens是本次消耗的token数。看到这两个字段正常返回说明推理链路已通。如果curl卡住不动多半是模型还在预热或者--max-model-len设得过大导致prefill阶段很慢如果返回400检查messages格式vLLM要求messages不能为空system/user/assistant的role字段必须合法。3.4 服务托管用systemd把推理服务变成开机自启现场交付的一体机不可能每次重启后都让人手动敲命令启动所以要把vLLM注册成systemd服务。这一步看着琐碎但决定了一体机是否“像一个正经产品”。写一个service文件放在/etc/systemd/system/deepseek-vllm.service[Unit] DescriptionDeepSeek vLLM Inference Service Afternetwork-online.target Wantsnetwork-online.target [Service] Typesimple Userinfer Groupinfer EnvironmentPATH/opt/miniconda3/envs/vllm/bin ExecStart/opt/miniconda3/envs/vllm/bin/vllm serve /data/models/deepseek-r1-32b-instruct --served-model-name deepseek-r1 --tensor-parallel-size 2 --gpu-memory-utilization 0.85 --max-model-len 32768 --max-num-seqs 32 --host 0.0.0.0 --port 8000 Restarton-failure RestartSec15 StartLimitBurst3 [Install] WantedBymulti-user.target几个关键点Userinfer要求系统里有一个名为infer的普通用户不要用root跑推理服务这是安全底线。Environment指定PATH是为了让systemd找到conda环境里的vllm可执行文件很多服务起不来的原因是PATH里没有conda的bin目录。Restarton-failure表示非正常退出时自动拉起StartLimitBurst3防止崩溃后无限重启刷屏。配置写好后执行sudo systemctl daemon-reload sudo systemctl enable deepseek-vllm sudo systemctl start deepseek-vllm systemctl status deepseek-vllm注意这里有个顺序问题第一次启用时如果模型还没完全加载完systemctl status可能显示active但curl仍在等待这是正常的看日志才是准确判断依据。查看日志用journalctl -u deepseek-vllm -f日志里出现Application startup complete才是真正就绪。我习惯在systemd服务里再加一个--api-key参数并把密钥写到单独的配置文件里这样客户端接错服务器时不会直接裸奔。4. 把一体机接进现有工具链API兼容层与典型接入方式4.1 兼容层设计为什么所有接入都统一走/v1/chat/completions一体机能不能快速被接受取决于客户现有系统接入有多容易。OpenAI兼容接口的最大好处是生态成熟几乎所有主流的AI编程工具、对话框架、Agent编排系统都原生支持/v1/chat/completions这意味着一体机部署好后客户端只需要改base_url和api_key两个配置就能切换过来。这是整个接入方案的地基不管内部推理引擎是什么对外一律暴露OpenAI兼容协议。实际交付时我还会在vLLM前面加一层极薄的转发服务它做三件事校验API Key、记录调用日志、做简单的模型名映射。vLLM自带的--api-key虽然能做校验但日志格式不适合审计模型名映射也做不了。我一般用FastAPI写十几行的转发层把请求原样转发给vLLM响应原样返回中间只夹一行业务日志。别在这层做复杂的重试和缓存逻辑转发层越薄越不容易出问题重试和超时控制在客户端侧做更合理。这一层也解决了“客户只想用自己内部的模型名”的痛点。比如客户内部文档里写的是modeldeepseek-r1-ent-v2而模型实际served_name是deepseek-r1在转发层做一次字段替换客户零感知切换。这类细节在一体机方案的POC阶段非常加分因为它意味着集成方不需要改任何代码。4.2 编程工具接入Codex CLI与VS Code插件直连内网一体机现在很多开发团队想把一体机接进Codex CLI或VS Code里的AI编程插件让写代码的同事直接用内网模型不走公网API。Codex CLI支持通过环境变量或配置文件指定自定义模型提供方以最新版CLI为例在~/.codex/config.toml里加一段model deepseek-r1 model_provider deepseek-local [model_providers.deepseek-local] name DeepSeek Local base_url http://192.168.10.20:8000/v1 env_key DEEPSEEK_LOCAL_KEY wire_api chat配置里base_url指向一体机的内网IP和端口wire_api填chat表示走Chat Completions协议。手工指定之后设置环境变量DEEPSEEK_LOCAL_KEY为任意非空字符串就可以开始对话式编程了。遇到Codex不认自定义provider的版本就用全局环境变量方式export OPENAI_API_KEYEMPTY export OPENAI_BASE_URLhttp://192.168.10.20:8000/v1 codex exec --model deepseek-r1 给这个项目补一个READMEVS Code里我推荐用Continue插件做演示接入。它的配置在.continue/config.json里用OpenAI兼容provider直连{ models: [ { title: DeepSeek Local 32B, provider: openai, model: deepseek-r1, apiBase: http://192.168.10.20:8000/v1, apiKey: EMPTY } ] }这类客户端接入最容易忽略的是上下文长度参数。默认情况下Continue会按照OpenAI官方模型128K上下文的最大长度来规划token把整仓库代码一次性塞进请求结果一体机的--max-model-len只有32K请求被拒或prefill极慢。解决办法是在config里把contextWindow字段显式调小到与一体机一致。这个配置漏掉的概率非常高我在好几个项目里都遇到过属于典型的接入后“慢半拍”根因。4.3 办公应用接入企业微信机器人调用本地DeepSeek办公场景里最常见的需求是给企业微信群接入一个AI机器人群成员机器人提问机器人调一体机模型回答再通过群机器人webhook发回来。先说结论这是我一小时就能从零跑通的链路但扣掉“系统提示词设计”和“报错处理”后一小时的预算会变成两小时。先在企业微信群里添加一个自定义机器人拿到webhook地址。然后写一个中转脚本负责接收用户消息、调用一体机、把结果发回群import json import requests # 企业微信机器人 Webhookkey 替换为实际值 WEBHOOK_URL https://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyreplace-me # 一体机 vLLM 服务地址 LLM_BASE http://192.168.10.20:8000/v1/chat/completions def chat(message: str) - str: resp requests.post( LLM_BASE, headers{Authorization: Bearer EMPTY}, json{ model: deepseek-r1, messages: [ {role: system, content: 你是企业内部AI助手回答要简洁、准确、口语化。}, {role: user, content: message}, ], temperature: 0.3, max_tokens: 1024, }, timeout120, ) resp.raise_for_status() return resp.json()[choices][0][message][content] def reply_to_group(text: str) - None: requests.post(WEBHOOK_URL, json{ msgtype: text, text: {content: text}, }) # 主入口收到群消息后调用 if __name__ __main__: user_question 请用三句话总结一下上季度的销售数据概况 answer chat(user_question) reply_to_group(answer)这段代码的逻辑不复杂先是chat函数把用户消息包成OpenAI格式发给一体机拿到content字段的回复然后reply_to_group把回复文本推到企业微信群。参数上注意timeout120很关键32B模型在低并发下生成1024个token可能需要二三十秒客户端超时设短了会误报失败。实际部署时不建议用轮询方式接收群消息企业微信机器人只支持主动推送不支持接收回调。要做双向对话常见做法是配置企业微信自建应用的接收消息URL或者在内部系统里做一个Web页面让用户输入问题。我一般用后者把上面的Python代码封装成一个Flask/FastAPI接口内部管理后台调它群里只做通知推送。这个区分很多交付文档没写清楚现场容易扯皮。4.4 tool calls需要即时结果的坑非流式响应与消息回传这个报错在Agent类工具接入时出现频率极高“messages tool calls need immediate results”。当模型在一次会话中决定调用多个工具时OpenAI协议要求所有tool调用结果必须在下一条消息里立即回传中间不能插入额外的user或assistant消息。很多自研Agent框架在拿到工具结果后会在消息序列里插入一段“我已收到结果”的assistant消息或者把两个工具的结果攒一起再发都会触发这个错误。具体到DeepSeek模型上这个问题还会因为模型本身的tool calling策略不同而被放大。DeepSeek官方API通过deepseek-chat模型支持function calling但在本地部署的vLLM服务上底层的R1模型不一定默认启用tool call解析。启动时需要显式开启自动tool call并指定解析器vllm serve /data/models/deepseek-r1-32b-instruct \ --enable-auto-tool-choice \ --tool-call-parser hermes--enable-auto-tool-choice让模型可以自主决定是否返回tool_calls字段--tool-call-parser指定用哪种格式解析。这里写hermes是因为DeepSeek的指令微调模型在工具调用格式上与Nous Hermes协议兼容这也是DeepSeek模型做function calling时一个比较省心的选型如果换成其他模型权重这个解析器要跟着变。没加这两个参数模型面对工具调用请求时会忽略tools字段直接回答一段文字客户端如果严格校验会报格式错误。客户端侧也有一个习惯要养成收到tool_calls后不要修改其中的message_id和tool_call_id按顺序逐条执行工具每个工具结果用role: tool的消息打包紧跟着原tool_call_id回传。一个常见的翻车姿势是框架为了“更人性化”把工具执行过程包装成普通assistant消息再发给模型这直接毁掉了协议语义。记住一旦进入tool调用消息序列就必须严格遵循“模型发出tool_call → 外部执行 → 立即回传tool result → 模型继续”的环中间任何多余消息都会让整个对话状态错乱。5. 部署与接入避坑5条高频故障的排查记录5.1 CUDA out of memory显存利用率不是越大越好现象并发一上来推理服务直接抛CUDA out of memory进程崩溃。查看nvidia-smi发现显存明明还有几个GB但服务就是申请不到。原因显存碎片化加上KV Cache预留不足。很多人在启动时把--gpu-memory-utilization设成0.98以为能榨干最后一点显存结果高并发下KV Cache扩容时找不到连续内存块直接OOM。解决把gpu-memory-utilization降到0.85留出约15%的余量同时把--max-num-seqs从40降到24让KV Cache的预留空间更充裕。改完后用长时间压测验证而不是只看启动是否成功。这类问题属于“显存玄学”的重灾区每次调参都记到变更记录里。5.2 并发一高就超时max-num-seqs与请求排队策略现象压测20路并发前10个请求正常后10个大量报TimeoutError模型本身没崩。原因vLLM的--max-num-seqs控制的是同时参与批处理的请求数超出的请求在入口排队客户端普遍只有30秒默认超时排队时间一长就误报失败。解决先看服务日志里的排队指标vllm serve启动后有一个/metrics端点里面能看到queue_size。如果排队始终有积压要么调大--max-num-seqs前提是显存够要么让客户端接受排队并调大超时。我一般推荐后者超时设到180秒同时在前端加一个“已排队请等待”的loading提示这比盲目加大max-num-seqs稳得多。5.3 客户端连不上内网一体机端口监听与主机防火墙现象在服务器上curl一切正常从办公电脑访问http://192.168.10.20:8000超时或拒绝连接。原因一体机的vLLM监听了127.0.0.1服务只在本机可见。我在3.2节特意强调--host 0.0.0.0但实际交付中总有环境把这参数丢了。解决先ss -tlnp | grep 8000看监听地址如果是127.0.0.1:8000改启动参数如果监听正常再查主机防火墙或云安全组是否放行8000端口。还有一类隐蔽原因一体机有多个网卡vLLM绑到了业务的网卡上办公网段恰好不通这时用route确认一下网段路由必要时把--host指定为业务网卡的IP。5.4 知识库导入乱码编码检测与文本切块现象把企业内部库里导出的文档切块后灌进知识库检索出来的片段全是乱码模型回答也跟着胡说。原因文档编码不是UTF-8常见的是GBK或GB18030编码的Word/文本文件。很多切块脚本默认按UTF-8读取遇到非UTF-8直接产生替换字符。解决切块前统一做编码检测用chardet识别再转成UTF-8保存。这一步应该写进知识库管道的预处理环节而不是靠人工检查。另一个连带问题是切块长度如果切块按固定512字符硬切句子被切断后语义不完整检索质量直线下降。用按段落或按语义边界的切块方式chunk_size设在300~500字之间overlap设50字左右效果比较稳。5.5 模型输出重复或空白采样参数与上下文长度现象模型回答里同一句话反复重复或者直接返回空内容。原因温度参数设得过高超过1.0加上max_tokens过小模型在生成后段陷入重复循环空白回答则多半是max_tokens设成0或系统提示词要求“只输出JSON”但模型被截断。解决温度调到0.3~0.7之间max_tokens不要小于256如果是JSON输出场景在系统提示词里明确字段约束并在客户端做JSON解析失败的重试。还有一个细节如果模型是R1这类推理模型默认会在回答前输出一段CoT推理内容客户端如果按普通文本截取可能拿到的是“思考过程”而不是“最终答案”。这类模型建议在请求里带上reasoning_content的处理逻辑或改用deepseek-r1-distill系列指令模型来规避。6. 让方案可交付验证规范、压测脚本与长期维护习惯6.1 交付前的三项验证接口兼容、并发压测与效果抽检一体机从“能跑”到“可交付”中间隔着验证这一步。我习惯按三层做先是接口兼容性测试把OpenAI官方SDK的base_url改成一体的地址跑一轮对话、流式输出、工具调用三个场景确认主流客户端能直连再做并发压测用脚本模拟20路并发记录成功率和平均响应时间这一步能提前暴露KV Cache配置问题最后做效果抽检拿客户真实的20~30条业务问题跑一遍人工判断回答质量是否达到可用线。压测脚本不用复杂并发线程加统计就够了import time import threading import requests BASE_URL http://127.0.0.1:8000/v1/chat/completions results [] def single_call(idx: int): t0 time.time() try: resp requests.post( BASE_URL, headers{Authorization: Bearer EMPTY}, json{ model: deepseek-r1, messages: [{role: user, content: 11?}], max_tokens: 64, }, timeout180, ) results.append((idx, resp.status_code, time.time() - t0)) except Exception as exc: results.append((idx, -1, time.time() - t0)) threads [threading.Thread(targetsingle_call, args(i,)) for i in range(20)] for t in threads: t.start() for t in threads: t.join() ok [r for r in results if r[1] 200] error [r for r in results if r[1] ! 200] print(f成功 {len(ok)}/{len(results)}) if ok: avg_cost sum(r[2] for r in ok) / len(ok) print(f平均响应 {avg_cost:.2f}s)压测的指标判断成功率不低于95%平均响应时间在模型可接受范围内。如果失败集中在某几个请求去看时间戳是否扎堆扎堆说明排队超时需要调max-num-seqs或客户端超时。6.2 维护期要盯的三个指标与日志轮转一体机交付后不是甩手不管维护期我最看重三个指标GPU利用率、请求平均时延、错误率。GPU利用率长期低于30%说明模型配置过大或并发不足考虑换小模型或合并服务平均时延突然翻倍先看是不是上下文长度被拉满再查是否有长文本请求占用错误率高于2%去翻vLLM日志找是OOM还是超时。日志管理上vLLM默认把日志打到标准输出systemd接管后会写进journald。建议配置按天轮转保留7~14天同时把vLLM的/metrics端点接入Prometheus这样客户随时能看曲线。模型权重的备份和一致性校验也是容易被忘掉的事。模型文件动辄几十GB传输过程中一个bit损坏就可能导致推理结果诡异。维护习惯是第一次部署完成后用sha256sum生成校验文件跟模型文件一起存档后续迁移或升级时先比对校验值确认一致再启动服务。最后一件事是我的个人习惯每次调参或变更都写一份变更记录哪怕只改了temperature一个值也记下来。因为一体机方案在客户现场跑半年后99%的问题都是“之前改过什么参数忘了”。把变更记录和压测结果放在一起找到根因的时间会从几小时缩短到几分钟。这算是这几年做推理服务交付攒下的最大心得希望帮到你。本文还有配套的精品资源点击获取
