企业官网建设流程全解析

简介：面向企业管理层与技术负责人的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-LLM；API服务层把引擎包装成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模型约14GB，32B模型约64GB，70B模型约140GB。KV Cache是动态的，它跟并发数和上下文长度成正比：单条请求的KV Cache大小约等于 2（K和V两份）× 层数 × 注意力头维度 × 上下文长度 × 2字节。公式不用背，记住一个经验值：在32K上下文下，为每路并发预留1~2GB显存比较稳妥。

所以算显存有个口诀：模型权重打底，并发翻倍乘，上下文再加成。举例，一台双卡A100（80GB）的机器跑32B模型，权重占64GB，剩下96GB给KV Cache用，按每路并发1.5GB算，跑50路并发的32K上下文是够的。如果换成4卡4090（24GB），单卡装不下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 python=3.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 torch==2.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] Description=DeepSeek vLLM Inference Service After=network-online.target Wants=network-online.target [Service] Type=simple User=infer Group=infer Environment="PATH=/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 Restart=on-failure RestartSec=15 StartLimitBurst=3 [Install] WantedBy=multi-user.target

几个关键点：User=infer要求系统里有一个名为infer的普通用户，不要用root跑推理服务，这是安全底线。Environment指定PATH是为了让systemd找到conda环境里的vllm可执行文件，很多服务起不来的原因是PATH里没有conda的bin目录。Restart=on-failure表示非正常退出时自动拉起，StartLimitBurst=3防止崩溃后无限重启刷屏。

配置写好后执行：

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，响应原样返回，中间只夹一行业务日志。别在这层做复杂的重试和缓存逻辑，转发层越薄越不容易出问题；重试和超时控制在客户端侧做更合理。

这一层也解决了“客户只想用自己内部的模型名”的痛点。比如客户内部文档里写的是model=deepseek-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_KEY=EMPTY export OPENAI_BASE_URL=http://192.168.10.20:8000/v1 codex exec --model deepseek-r1 "给这个项目补一个README"

VS 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 # 企业微信机器人 Webhook，key 替换为实际值 WEBHOOK_URL = "https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=replace-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, }, timeout=120, ) 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把回复文本推到企业微信群。参数上注意timeout=120很关键，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": "1+1=?"}], "max_tokens": 64, }, timeout=180, ) results.append((idx, resp.status_code, time.time() - t0)) except Exception as exc: results.append((idx, -1, time.time() - t0)) threads = [threading.Thread(target=single_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%的问题都是“之前改过什么参数忘了”。把变更记录和压测结果放在一起，找到根因的时间会从几小时缩短到几分钟。这算是这几年做推理服务交付攒下的最大心得，希望帮到你。

本文还有配套的精品资源，点击获取