1. 项目概述为什么要在本地跑 DeepSeek而不是只用网页版“How to Run DeepSeek Locally: A Step-by-Step Guide”这个标题一出来我就知道很多人点进来不是为了学命令行而是想搞清楚一件事我到底值不值得花两小时装一遍还是直接去官网对话更省事我自己前后试过三轮——第一次在2024年3月用DeepSeek-V2-7B跑在RTX 3090上卡在量化环节第二次换Ollamallama.cpp组合结果中文token切分错乱问“杭州西湖有几个桥”它硬是数出17个实际官方数据是15座第三次才真正稳下来用的是vLLMAWQ量化本地API服务模式。现在每天早上通勤路上我用手机连家里的局域网API端口写周报初稿响应延迟稳定在1.8秒内比网页版还快300ms。这不是玄学是本地部署带来的确定性数据不出设备、响应不看服务器排队、模型可自由微调、上下文长度能拉到128K、还能和你已有的Python脚本/Notion插件/自动化工作流无缝咬合。它适合三类人需要处理敏感业务文档的法务或财务人员比如合同条款比对、想把大模型嵌入自有产品的开发者比如给内部知识库加问答模块、以及像我这样对“AI黑箱”有执念的技术型用户——我要知道每个token是怎么算出来的不是只看它吐出什么。关键词里“DeepSeek”“Locally”“Step-by-step”三个词已经划清了边界不讲云服务、不讲API调用、不讲模型训练就聚焦在“我的笔记本/台式机上从零开始让DeepSeek真正跑起来”这件事本身。2. 整体设计思路与方案选型逻辑2.1 为什么放弃Ollama和LM Studio最终锁定vLLMAWQ组合刚接触本地大模型时我也被Ollama的ollama run deepseek-coder:6.7b这种一行命令迷住过。但实测两周后我把它从主力方案里划掉了。根本原因在于Ollama封装太深像一个黑盒咖啡机——你放豆子、按按钮、接杯子但不知道水温多少、萃取压力几Bar、粉碗有没有压平。比如DeepSeek-MoE-16B这种稀疏激活模型Ollama默认用GGUF格式加载而GGUF对MoE结构的支持直到2024年7月才在v0.4.0版本中初步补全之前版本会强制把所有专家都加载进显存导致RTX 4090都爆显存。我拿nvidia-smi盯着看发现显存占用曲线像心电图一样剧烈抖动这就是专家路由没走对的典型症状。LM Studio更麻烦——它本质是个图形界面壳子底层调用llama.cpp。问题出在tokenizer上DeepSeek系列用的是自研的DeepSeekTokenizer而llama.cpp默认用LlamaTokenizer两者对中文标点的切分逻辑差了一代。举个真实例子输入“请分析《民法典》第1024条”Ollama和LM Studio都会把书名号《》切成两个独立token导致模型误判为“分析民法典第1024条”漏掉法律名称的权威性标识而原生DeepSeekTokenizer会把《民法典》识别为一个完整语义单元。这个细节差异在法律文书解析场景里可能直接导致条款引用错误。最后选定vLLMAWQ是经过三轮压测后的理性选择。vLLM的核心优势是PagedAttention内存管理机制——它把KV缓存像操作系统管理物理内存一样分页显存利用率比HuggingFace Transformers高37%。我用deepseek-v2-7b做对比测试同样batch_size4、max_seq_len8192Transformers占显存14.2GBvLLM只占8.9GB。多出来的5.3GB刚好够我把LoRA微调权重也常驻显存实现“边推理边轻量更新”。AWQ量化则解决了精度与速度的平衡点相比INT4 GGUFAWQ在保留关键权重通道精度的前提下把模型体积压缩到原版的28%且推理速度提升2.1倍。更重要的是AWQ支持per-channel量化对DeepSeek-V2里那些动态稀疏的MoE专家层特别友好——它不会粗暴地把整个专家矩阵压成INT4而是对每个专家的权重通道单独计算量化参数保住了路由决策的准确性。提示如果你的GPU显存≤12GB比如RTX 3060 12G别硬刚vLLM。老老实实用llama.cppQwen2 tokenizer patch虽然要手动改几行C代码但至少能跑通。我附录里会给出这个降级方案的具体patch文件路径。2.2 为什么坚持用Linux环境Windows用户真不能做吗看到标题里“Step-by-Step”很多Windows用户会下意识想“我能不能用WSL2”答案是可以但必须当真Linux用不能当Windows子系统用。我见过太多人把WSL2当成“Windows里开个终端”结果卡在CUDA驱动上——Windows主机装了NVIDIA驱动WSL2里又装一遍驱动两个驱动抢显卡控制权nvidia-smi在WSL2里直接报“NVIDIA-SMI has failed because it couldn’t communicate with the NVIDIA driver”。正确的做法是把WSL2当作一台独立Linux服务器来配置。具体操作有三步第一卸载Windows端所有NVIDIA驱动只留WSL2专用驱动通过Microsoft Store安装“NVIDIA CUDA on WSL”第二WSL2发行版必须选Ubuntu 22.04 LTS别用24.04vLLM 0.6.3对glibc 2.39兼容性有问题第三CUDA Toolkit必须用12.1版本不是最新12.4因为vLLM编译时硬依赖cuBLAS 12.1.2.212。我试过用conda装CUDA结果vLLM编译时找不到libcublas.so.12折腾六小时才发现是conda环境里的CUDA版本和WSL2驱动不匹配。至于纯Windows原生环境理论上可行但成本太高。你需要手动编译vLLM的Windows wheel包而它的C扩展依赖Ninja构建系统Ninja在Windows上默认用MSVC编译器但vLLM的CUDA核函数是用nvcc写的MSVC根本不认识.cu文件。有人用WSL2交叉编译再拷回Windows但生成的wheel包在Windows上运行时又会报DLL load failed: The specified module could not be found——因为缺少cudnn_ops_infer64_8.dll等动态链接库而这些库在Windows CUDA安装包里是分散存放的路径还带版本号。所以我的建议很直白如果你主要用Windows就买块二手RTX 3090配Linux主机总成本比折腾Windows本地部署省20小时时间。这20小时够你把DeepSeek微调成专属法律助手了。2.3 为什么跳过Docker选择原生Python环境部署Docker镜像看着方便docker run -p 8000:8000 --gpus all deepseek:v2一行搞定。但实际用起来全是坑。最致命的是GPU显存隔离失效Docker容器默认用--gpus all会把整张卡的显存都挂进去而vLLM启动时会申请全部可用显存。如果同时跑两个容器第二个容器直接OOM。我试过用--gpus device0 --shm-size2g限制但vLLM的PagedAttention机制需要共享内存做KV缓存页交换2GB根本不够batch_size超过2就报OSError: unable to open shared memory object。更隐蔽的问题是模型路径权限。Docker容器里默认用户是root但DeepSeek的HuggingFace模型文件夹比如~/.cache/huggingface/hub/models--deepseek-ai--deepseek-v2/snapshots/xxx在宿主机上是普通用户权限。容器里root用户去读这个路径会遇到Permission denied——因为Linux的user namespace映射没配对。有人用--user $(id -u):$(id -g)解决但这样又导致容器里无法写日志vLLM的监控指标全丢。所以我坚持用原生Python环境核心就一条所有路径、权限、环境变量都在同一个用户空间里可控。pip install vllm0.6.3装完vllm-entrypoint命令直接调用显存占用、日志输出、模型加载路径全在htop和nvidia-smi里看得明明白白。调试时加个--debug参数vLLM会把每个attention layer的计算耗时打出来哪一层慢一目了然。这种透明度是Docker永远给不了的。3. 核心细节解析与实操要点3.1 硬件门槛的真实测算显存、内存、存储怎么算才不翻车很多人看到“RTX 4090推荐”就下单结果装完发现连模型都加载不了。显存不是简单看标称值得拆解成三块算模型权重显存 KV缓存显存 系统开销显存。先算模型权重。DeepSeek-V2-7B用AWQ量化后是3.8GB但这是FP16精度下的理论值。实际加载时vLLM会把权重转成FP16再送进CUDA核所以显存占用是3.8GB × 1.5 ≈ 5.7GB因为FP16权重FP32优化器状态临时缓冲区。这还没算KV缓存——它和序列长度、batch_size强相关。公式是KV缓存显存 2 × batch_size × seq_len × hidden_size × sizeof(dtype)。以DeepSeek-V2-7B为例hidden_size4096dtype用FP162字节batch_size4seq_len8192算出来是2×4×8192×4096×2÷1024³≈2.0GB。再加上系统开销CUDA驱动、vLLM框架本身约1.5GB总显存需求是5.72.01.59.2GB。所以RTX 309024GB完全够但RTX 4060 Ti16GB就悬了——它只剩6.8GB余量一旦batch_size提到8或者seq_len拉到128K立马OOM。内存RAM容易被忽略。模型权重文件本身要从磁盘加载到内存AWQ格式的3.8GB模型加载时内存峰值会冲到6GB因为解压校验格式转换。更关键的是vLLM启动时会预分配一块共享内存做页表管理大小是max_num_seqs × max_model_len × 16KB。如果设max_num_seqs256最大并发请求数max_model_len128K这块共享内存就要256×128000×16÷1024³≈500MB。所以16GB内存是底线32GB才舒服。存储空间陷阱最多。HuggingFace Hub默认把模型缓存到~/.cache/huggingface/hub/DeepSeek-V2-7B原始模型FP16有13GBAWQ量化版3.8GB但Hub会同时存多个snapshot。我清理过一次缓存发现光models--deepseek-ai--deepseek-v2这个目录就占了42GB——因为每次git lfs pull都会拉新commit旧版本不自动删。解决方案是在~/.huggingface/hf_home里建个软链接指向SSD分区然后定期执行huggingface-cli scan-cache --delete。注意别信网上说的“用--quantization awq参数自动量化”。vLLM的awq参数只是加载已量化的模型不是现场量化。你得先用autoawq库把HF格式模型转成AWQ格式这个过程本身要16GB显存而且必须用NVIDIA GPUAMD显卡不行。我附录里会给出完整的量化脚本含显存监控提示。3.2 模型获取与验证绕过HuggingFace限速的实操技巧DeepSeek官方模型放在HuggingFace Hub但国内直连经常卡在99%。我试过七种方法有效的是这三种第一用hf-mirror.com镜像站。不是简单改URL而是改~/.huggingface/transformers/config.json里的mirror_url字段填https://hf-mirror.com。但要注意镜像站同步有延迟DeepSeek-V2-16B的最新snapshot2024-07-15镜像站要晚36小时才更新。所以关键步骤是先git clone https://huggingface.co/deepseek-ai/deepseek-v2到本地再进目录git lfs pull -I model*.safetensors指定只拉模型文件跳过README.md等小文件速度从1MB/s提到12MB/s。第二用huggingface-hub库的离线模式。先在能联网的机器上运行from huggingface_hub import snapshot_download snapshot_download(repo_iddeepseek-ai/deepseek-v2, local_dir/path/to/model, revisionmain)生成一个完整快照打包成tar.gz传到目标机器。解压后用vllm加载时指定--model /path/to/model它会自动识别safetensors格式。第三最狠的——直接下载safetensors文件。打开HF模型页右键“Model card”里的safetensors链接复制URL用wget --headerAuthorization: Bearer YOUR_TOKEN URL下载。Token在HF官网Settings里生成注意勾选read权限。这个方法能绕过git lfs的协议层实测下载速度稳定在25MB/s。验证模型完整性不能只看文件大小。我写了个校验脚本from safetensors.torch import load_file import hashlib tensors load_file(/path/to/model/model.safetensors) # 计算所有权重tensor的SHA256 hashes [hashlib.sha256(t.cpu().numpy().tobytes()).hexdigest() for t in tensors.values()] print(Model hash:, hashlib.sha256(.join(hashes).encode()).hexdigest())官方发布的V2-7B模型hash是a1b2c3...我附录里会列全和你算出来的比对一致才算真正下全了。3.3 vLLM服务启动的关键参数详解每个flag背后都是血泪教训vLLM启动命令看着简单但每个参数都是踩坑后定的。我用vllm-entrypoint --model /path/to/model --tensor-parallel-size 1 --pipeline-parallel-size 1 --dtype half --quantization awq --max-model-len 128000 --gpu-memory-utilization 0.9 --enforce-eager这条命令拆解如下--tensor-parallel-size 1别信网上教程说“设成GPU数量”。DeepSeek-V2是单GPU优化模型强行设2会让vLLM把模型权重切片但V2的MoE层路由逻辑是全局的切片后路由表对不上生成结果全乱。我试过设2问“杭州天气”它回答“杭州市位于美国加利福尼亚州”。--dtype half必须显式指定。vLLM默认用auto会根据GPU型号选dtypeA100选bfloat16RTX 4090选half。但DeepSeek-V2的tokenizer对bfloat16支持不全会导致中文分词偏移。强制half所有GPU统一行为。--quantization awq这里有个大坑——AWQ量化模型必须用--quantization awq不能用--load-format awq。后者是旧版参数vLLM 0.6.3里已废弃用了会报unrecognized arguments但错误信息不提示是参数名错了只说error: unrecognized arguments: --load-format让人查半天配置文件。--max-model-len 128000这是DeepSeek-V2的原生上下文长度但别直接设这么大。vLLM的PagedAttention页大小是256 tokens128000要分500页页表管理开销大。我实测设64000性能损失不到3%但显存占用降了18%。真正需要长上下文时用--enable-chunked-prefill参数它允许分块prefill动态申请页比硬设128K更稳。--gpu-memory-utilization 0.9关键中的关键。vLLM默认用0.9但这是按显存总量算的。RTX 4090标称24GB实际可用23.7GB0.9就是21.3GB。如果模型权重KV缓存系统开销超了它不会报错而是静默降级到CPU offload响应时间从1秒变成45秒。我加了--verbose参数启动时看日志里有没有Using GPU memory utilization: 0.9这行有才是真生效。--enforce-eager强制用eager模式禁用CUDA Graph。Graph模式在batch_size稳定时快15%但DeepSeek-V2的MoE层激活是动态的Graph会把第一次的专家激活模式固化后续请求如果激活不同专家就出错。关掉它每次请求都重新编译kernel慢一点但绝对稳。4. 实操过程与核心环节实现4.1 从零开始的完整部署流程每一步的命令、预期输出与失败信号我们以Ubuntu 22.04 RTX 4090为基准环境走一遍真实部署。全程不用sudo所有操作在普通用户下完成。第一步环境初始化# 创建干净的conda环境别用venvvLLM编译依赖conda的gcc conda create -n deepseek python3.10 conda activate deepseek # 升级pip到24.0以上否则安装vLLM时会报setuptools版本冲突 pip install --upgrade pip # 安装CUDA Toolkit 12.1必须 wget https://developer.download.nvidia.com/compute/cuda/12.1.1/local_installers/cuda_12.1.1_530.30.02_linux.run sudo sh cuda_12.1.1_530.30.02_linux.run --silent --toolkit --override # 验证CUDA nvcc --version # 应输出 release 12.1, V12.1.105预期输出nvcc: NVIDIA (R) Cuda compiler driver, version 12.1.105。失败信号command not found说明PATH没加要echo export PATH/usr/local/cuda-12.1/bin:$PATH ~/.bashrc。第二步安装vLLM# 安装依赖 pip install ninja # 编译安装vLLM关键必须源码编译pip install vllm会装错CUDA版本 git clone https://github.com/vllm-project/vllm.git cd vllm git checkout v0.6.3 # 设置CUDA路径 export CUDA_HOME/usr/local/cuda-12.1 # 开始编译这步要12分钟别中断 pip install -e . --no-build-isolation预期输出最后几行是Successfully installed vllm-0.6.3。失败信号nvcc fatal : Unsupported gpu architecture compute_86说明CUDA版本不对重装12.1。第三步获取并验证模型# 创建模型目录 mkdir -p ~/models/deepseek-v2-7b-awq # 用hf-mirror下载假设已配置好镜像 huggingface-cli download --resume-download --local-dir ~/models/deepseek-v2-7b-awq deepseek-ai/deepseek-v2 --revision main # 验证完整性运行我前面给的校验脚本 python verify_model.py ~/models/deepseek-v2-7b-awq预期输出脚本打印的hash和官方一致。失败信号OSError: Unable to load weights from pytorch checkpoint说明safetensors文件损坏删掉重下。第四步启动vLLM服务# 启动命令注意路径和参数 vllm-entrypoint \ --model ~/models/deepseek-v2-7b-awq \ --tensor-parallel-size 1 \ --dtype half \ --quantization awq \ --max-model-len 64000 \ --gpu-memory-utilization 0.9 \ --enforce-eager \ --host 0.0.0.0 \ --port 8000 \ --api-key your-secret-key预期输出启动日志末尾出现INFO 07-15 10:23:45 api_server.py:123] Started server process然后nvidia-smi显示显存占用21.3GB。失败信号RuntimeError: CUDA out of memory说明--gpu-memory-utilization设太高降到0.85重试。第五步API测试curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer your-secret-key \ -d { model: deepseek-v2-7b, messages: [{role: user, content: 你好}], temperature: 0.7 }预期输出返回JSONchoices[0].message.content是“你好我是DeepSeek-V2很高兴为你服务。”。失败信号curl: (7) Failed to connect to localhost port 8000说明服务没起来看日志里有没有OSError: [Errno 98] Address already in use有就lsof -i :8000杀掉进程。4.2 构建生产级API服务反向代理、认证、监控三件套跑通API只是第一步真要当生产工具用得加三层防护第一层Nginx反向代理直接暴露8000端口不安全。用Nginx做反向代理既能加HTTPS又能限流。配置文件/etc/nginx/sites-available/deepseek-apiupstream deepseek_backend { server 127.0.0.1:8000; } server { listen 443 ssl; server_name ai.yourdomain.com; ssl_certificate /path/to/fullchain.pem; ssl_certificate_key /path/to/privkey.pem; location /v1/ { proxy_pass http://deepseek_backend/v1/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # 限流每个IP每分钟最多30次请求 limit_req zonedeepseek_api burst30 nodelay; } }关键点limit_req必须配合limit_req_zone $binary_remote_addr zonedeepseek_api:10m rate0.5r/s在http块里定义否则不生效。第二层API密钥认证增强vLLM自带--api-key但只是HTTP Header校验没审计日志。我在Nginx里加了日志记录log_format deepseek_log $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_authorization; access_log /var/log/nginx/deepseek_api.log deepseek_log;这样每次调用都会记IP、时间、请求内容、密钥前缀$http_authorization只记Bearer后前10位出了问题能快速溯源。第三层Prometheus监控vLLM暴露/metrics端点但默认只开/v1/metrics。要让它输出GPU显存、请求延迟等指标启动时加--disable-log-stats false然后用Prometheus抓取。我的prometheus.ymlscrape_configs: - job_name: vllm static_configs: - targets: [localhost:8000] metrics_path: /v1/metricsGrafana面板里我重点关注三个指标vllm:gpu_cache_usage_ratio显存使用率超90%要告警、vllm:request_latency_secondsP95延迟超5秒告警、vllm:num_requests_running并发请求数持续超20说明要扩容。实操心得别在vLLM服务里加--disable-log-stats false就以为万事大吉。vLLM的metrics是pull模式Prometheus每15秒拉一次如果vLLM进程重启metrics会重置导致Grafana图表断崖下跌。解决方案是在Prometheus里加rate(vllm:request_latency_seconds_count[1h])用速率代替绝对值避免重启干扰。4.3 与现有工作流集成Python脚本、VS Code插件、Notion双向同步本地部署的价值不在单点对话而在融入你的数字生活。我做了三件事Python脚本集成写了个deepseek_client.py封装成类import requests class DeepSeekClient: def __init__(self, base_urlhttp://localhost:8000/v1, api_keyyour-key): self.base_url base_url self.headers {Authorization: fBearer {api_key}} def chat(self, messages, temperature0.7): payload {model: deepseek-v2-7b, messages: messages, temperature: temperature} resp requests.post(f{self.base_url}/chat/completions, jsonpayload, headersself.headers) return resp.json()[choices][0][message][content] # 使用示例 client DeepSeekClient() result client.chat([{role: user, content: 把这段SQL转成自然语言描述SELECT * FROM users WHERE age 18}]) print(result) # 输出查询所有年龄大于18岁的用户信息这个脚本我塞进公司内部的ETL pipeline每天凌晨2点自动跑把数据库变更日志喂给DeepSeek生成中文版数据字典发到钉钉群。VS Code插件用CodeLLDB调试时我想实时看变量含义。装了“CodeLLDB”插件再在launch.json里加{ name: Debug with DeepSeek, type: lldb, request: launch, preLaunchTask: deepseek-analyze, env: {DEEPSEEK_URL: http://localhost:8000/v1} }preLaunchTask调用一个shell脚本把当前文件路径和光标位置传给DeepSeek生成调试建议直接显示在VS Code终端里。Notion双向同步用Notion API Python定时任务。我建了个Notion数据库字段有“问题”、“DeepSeek回答”、“人工修正”。脚本每天扫新增行把“问题”发给本地DeepSeek把回答写回“DeepSeek回答”字段。如果人工改了“人工修正”脚本检测到变化就用这个修正结果微调模型用QLoRA增量训练10分钟。这样Notion既是知识库又是持续学习的数据源。5. 常见问题与排查技巧实录5.1 显存爆炸的五种场景与对应解法显存问题占我所有故障的73%。整理成速查表场景现象根本原因解法场景1启动即OOMCUDA out of memory在vLLM加载模型时抛出--gpu-memory-utilization设太高或模型路径错误导致加载原始FP16模型用nvidia-smi看初始显存如果5GB说明加载了FP16检查--model路径是否指向AWQ目录不是HF原始目录场景2首请求OOM第一个API请求时显存瞬间飙到100%服务崩溃KV缓存预分配过大--max-model-len设太高改--max-model-len 32768加--enable-chunked-prefill场景3高并发OOM并发10个请求时OOM单请求正常--max-num-seqs默认256太大每个seq的KV缓存叠加设--max-num-seqs 64用--max-num-batched-tokens 4096控制总token数场景4长文本OOM输入10万字文本时OOM输入文本过长prefill阶段显存爆炸前端加文本长度校验超32K字符截断或用--enable-prefix-caching复用前缀场景5微调后OOMLoRA微调后加载模型OOMLoRA权重和base模型权重都占显存用--lora-modules参数只加载需要的LoRA模块不用的unload独家技巧用vLLM_DEBUG1环境变量启动vLLM会在日志里打印每层KV缓存的显存占用。比如看到blocks: 512, block_size: 16, total_blocks: 8192就知道当前用了8192个KV缓存块每个块16 tokens总容量131072 tokens。如果total_blocks远超--max-num-seqs × --block-size说明有缓存泄漏要重启服务。5.2 中文乱码与分词错误的根因定位中文问题八成出在tokenizer。DeepSeek用的是基于SentencePiece的DeepSeekTokenizer但vLLM默认用HuggingFace的AutoTokenizer两者对中文标点的处理不同。诊断步骤第一步确认tokenizer类型# 进入模型目录 cd ~/models/deepseek-v2-7b-awq # 查看tokenizer_config.json cat tokenizer_config.json | grep tokenizer_class如果输出tokenizer_class: DeepSeekTokenizer说明是原生tokenizer如果是AutoTokenizer说明被替换了。第二步测试分词# 用vLLM自带的tokenizer工具 python -m vllm.entrypoints.openai.api_server --model . --host 0.0.0.0 --port 8000 --api-key test --disable-log-stats # 然后调用tokenize API curl http://localhost:8000/v1/tokenize \ -H Content-Type: application/json \ -H Authorization: Bearer test \ -d {model: deepseek-v2-7b, prompt: 《民法典》第1024条}正确输出应是[123, 456, 789, ...]其中《民法典》对应一个token ID。如果输出[123, 456, 789, 101, 102, 103]101/102/103是《》和民法典分开的ID说明tokenizer没对齐。解法强制vLLM用原生tokenizer。在启动命令里加--tokenizer deepseek-ai/deepseek-v2指向HF上的tokenizer repovLLM会自动下载并匹配。5.3 API响应延迟高的系统级排查链响应慢不能只怪模型。我建立了一个四层排查链Layer 1网络层用curl -w curl-format.txt -o /dev/null -s http://localhost:8000/v1/chat/completionscurl-format.txt里定义time_namelookup、time_connect等字段。如果time_connect 100ms说明DNS或TCP连接慢要检查/etc/resolv.conf的DNS服务器。Layer 2vLLM服务层看vLLM日志里的prefill_time和decode_time。Prefill时间长2s说明输入文本太长或--max-model-len设小了触发多次prefillDecode时间长500ms/token说明GPU算力不足或batch_size设太大。Layer 3CUDA驱动层运行nvidia-smi dmon -s u -d 1看smStreaming Multiprocessor利用率。如果长期60%说明GPU没吃饱可能是PCIe带宽瓶颈——RTX 4090要插在x16 PCIe 5.