尧图网页设计 
简介这是一份面向有Java基础、希望深入大模型部署领域的开发者的实战项目源码围绕如何用Java配合多GPU完成LLaMA2推理部署展开解决单卡算力不足与并行推理实现难的问题。压缩包共64个文件、约305KB以33个Java源文件为核心配合19个XML工程配置、Shell启动脚本、README说明、tokenizer词表文件等构成完整可运行的Maven工程。该资源已有1043人学习浏览。项目完整覆盖从模型加载、GPU分配、数据分发到并行计算与结果聚合的部署链路附有可执行的启动脚本和配置示例可帮助读者理解CUDA Java API或并行计算框架的使用方式快速搭建多GPU推理环境并复现运行效果是学习Java生态下LLaMA2落地部署的实用参考。1. 先解决一个麻烦Java 团队怎么把 LLaMA2 跑上自有 GPU一个 Java 后端团队要部署 LLM第一反应往往是不搭模型生态在 Python推理框架全是 PythonJava 过来像是给自己找麻烦。但这个资源包做的正是把这条链路走通——Java 负责对外接口和业务请求多 GPU 负责把 7B/13B 的权重放进去推理交给经过验证的加速层。说白了这是给想在企业内部做大模型私有化部署、但团队几乎全是 Java 技术栈的人一套可复现的工程样板环境怎么搭、量化怎么选、多卡怎么切、Java 怎么调每一步都落在脚本和代码上不是停留在概念。如果你正面临「老板让一个月内把 LLaMA2 上到现有 GPU 服务器」这种需求又不想推翻团队技术栈去重学 Python 服务端这套东西值得先花半小时拆开看一遍。下面按我复现时的顺序从选型到排障一步步讲清楚。2. 选型与架构为什么 Java 后端普遍走 Python 加速层 HTTP 这条路2.1 Java 侧没有官方运行时三条路线怎么权衡LLaMA2 官方没有给 Java 运行时这是绕不开的前提。我见过有人想用 JNI 直接调 C 推理引擎也有人试过在 Java 进程里嵌入 llama.cpp 的绑定最后都被拉回同一条路Python 加速层 Java HTTP 调用。原因很直白三者的对接成本和稳定性差一大截。路线对接成本并发能力多 GPU 支持适合场景Java 通过 JNI 直调 C 引擎高崩溃日志和内存管理全自理中需自研极少数定制场景进程内嵌入 Python 推理进程中两边内存互相影响中弱单卡快速验证Python 加速层 Java HTTP 调用低接口可视可测高好企业私有化部署第三条路线在工程上最稳Python 服务管住 GPU、显存和推理生命周期Java 服务通过 REST 接口发请求两边各自重启互不影响。这个资源包走的也是这个结构Java 端不是去写算子而是写一个对业务友好的 client 封装。提示如果只是单卡、单用户试玩llama.cpp 直接跑也够一旦涉及多用户并发和生产环境vLLM 这类带连续批处理的框架才是首选。2.2 多 GPU 切分原理张量并行和 KV Cache 的关系多 GPU 能放更大模型依赖的是张量并行Tensor Parallelism。原理一句话把 transformer 层里的 QKV 矩阵按列切成两份两张卡各持一半每张卡只算一半矩阵乘法算完再做 all-reduce 把结果合并。显存占用减半代价是卡间通信变多所以服务器里用 NVLink 或 PCIe 直连效果差别很大。除了权重还要算 KV Cache 的账。推理每生成一个 token都要把当前时刻的 K、V 向量存下来供后续 attention 使用这批缓存也占显存而且和上下文长度、并发数线性相关。这是我见过最多人漏算的部分权重算明白了加几路并发请求直接把卡撑爆。切分方式上vLLM 沿 transformer 层内部切权重称为张量并行llama.cpp 的做法偏朴素按层把不同 block 分到不同卡前几层在卡 0后几层在卡 1。两者都能跑但前者卡间通信更频繁显存利用率更高也是这个场景下我优先推荐的。2.3 资源包的结构与启动链路解压后先别急着跑把目录结构摸一遍。以这个资源包常见的布局来看核心是几个部分Python 推理服务入口、Java 客户端封装、启动与检测脚本、参数说明文档。模型权重一般不打包在里面体积太大下载地址会写进说明文件这是正常现象别以为资源缺东西。llama2-deploy/ ├── inference/ # Python 推理服务入口 ├── client/ # Java 客户端封装 ├── scripts/ # 启动与检测脚本 └── docs/ # 参数说明启动链路是先跑 Python 推理服务确认 GPU 两张卡都有负载再启动 Java 服务最后用压测脚本验证端到端延迟。这个顺序别反过来Java 先起了也没关系但排查时会分不清是接口问题还是模型没加载完。3. 环境与显存预算先算清楚再动手3.1 GPU 状态检查与驱动确认拿到服务器先确认 GPU 可见状态别信运维口头说的「有卡」。用下面两条命令核实nvidia-smi nvidia-smi --query-gpuindex,name,memory.total,memory.used,driver_version --formatcsv第一条看实时显存和进程占用第二条拿到精简的卡编号、型号与驱动版本。重点看驱动版本vLLM 对 CUDA 版本敏感驱动太老会让 torch 直接报 CUDA unavailable。常见版本对应关系是CUDA 11.8 需要驱动 520 系列以上CUDA 12.x 需要 525 以上具体以 PyTorch 官方支持矩阵为准驱动宁新勿旧。3.2 显存估算7B/13B 各精度能不能放进现有卡里动手前先算一笔账。权重显存约等于参数量乘以每个参数所占字节数FP16 是 2 字节INT8 是 1 字节INT4 约 0.5 字节。另外再加 KV Cache 和 CUDA context 的占用下面按 4096 上下文做了个估算表模型与精度权重显存KV Cache示例总显存参考LLaMA2-7B FP16约 14GB2-4GB约 18GBLLaMA2-7B INT8约 7GB2-4GB约 11GBLLaMA2-7B INT4/GPTQ约 4GB2-4GB约 8GBLLaMA2-13B FP16约 26GB4-6GB约 32GBLLaMA2-13B INT4/GPTQ约 6.5GB4-6GB约 12GB这表的意义在于一张 24GB 的卡跑 7B INT8 或 INT4 有余量13B FP16 一张卡放不下但两张 24GB 卡做张量并行刚好如果只有一张卡就得把 13B 降到 INT4 才能跑。我一般先把总显存算好再加 1-2GB 余量避免 CUDA context 和中间激活值把卡顶爆。生产环境并发一上来KV Cache 占用会成倍涨预算时最好按最大并发数再乘一次。3.3 Python 依赖与 Java 依赖清单Python 侧依赖集中在推理服务里requirements.txt 大致如下torch2.0.1 transformers4.31.0 vllm0.2.0 acceleratevLLM 版本别乱装最新先看资源包里锁的是哪个。不同版本的启动参数有差异比如旧版本用--tensor-parallel-size新版本也兼容但--max-model-len的默认值和行为在不同版本里略有不同踩过坑的人都知道升级框架是最耗时间的环节。Java 侧依赖少得多核心是 JSON 处理dependency groupIdcom.fasterxml.jackson.core/groupId artifactIdjackson-databind/artifactId version2.15.2/version /dependency如果用 JDK 11 自带的 HttpClient就不需要额外引 HTTP 库只加 Jackson 就够如果项目里本来就有 OkHttp 或 Spring Boot直接用现成的也行参数封装方式见下文。4. 部署实现多 GPU 启动参数从 vLLM 到 Java HTTP 调用4.1 启动 Python 推理服务tensor-parallel-size 与 CUDA_VISIBLE_DEVICES先明确一点资源包里的推理脚本大概率围绕 vLLM 封装因为 vLLM 对多 GPU 张量并行支持最成熟。模型文件建议提前准备好GPTQ 分片格式.safetensors和 vLLM 配合最顺。CUDA_VISIBLE_DEVICES0,1 python -m vllm.entrypoints.openai.api_server \ --model /data/models/llama2-13b-gptq \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.90 \ --max-model-len 4096 \ --host 0.0.0.0 \ --port 8000参数逐个说CUDA_VISIBLE_DEVICES0,1决定哪些卡可见两张卡做张量并行--tensor-parallel-size 2告诉框架把每层权重切成两份分到两张卡--gpu-memory-utilization 0.90限制每张卡最多用 90% 显存留一点给 CUDA context设为 1.0 容易在极端请求下 OOM--max-model-len 4096限制最大上下文长度设得越大 KV Cache 预留越多不是免费的。启动后进程会卡在前台加载权重看到Starting vLLM API server才算起来。如果资源包走的是 llama.cpp 路线启动命令就换一个风格CUDA_VISIBLE_DEVICES0,1 ./llama-server \ -m llama-2-13b-chat.Q4_K_M.gguf \ --n-gpu-layers 999 \ --split-mode layer \ --host 0.0.0.0 \ --port 8080llama.cpp 的 GGUF 单文件对新手友好但多卡是层切分卡间通信压力比张量并行小性能也相对弱一些。GGUF 走不了 vLLM两者选其一别混着用。4.2 Java 端调用封装HttpClient 流式与非流式Java 端封装调用我一般直接基于 JDK 11 的java.net.http.HttpClient少引一个依赖少一份维护。下面这段是核心方法非流式场景够了import java.net.URI; import java.net.http.HttpClient; import java.net.http.HttpRequest; import java.net.http.HttpResponse; import java.time.Duration; public class LlamaClient { private final HttpClient client; private final String endpoint; public LlamaClient(String endpoint) { this.endpoint endpoint; this.client HttpClient.newBuilder() .connectTimeout(Duration.ofSeconds(10)) // 连接超时设置短快速暴露网络问题 .build(); } public String chat(String prompt, int maxTokens) throws Exception { // 注意prompt 里的双引号必须先转义否则 JSON 解析直接失败 String escaped prompt.replace(\\, \\\\).replace(\, \\\); String body {prompt: %s, max_tokens: %d, temperature: 0.7} .formatted(escaped, maxTokens); HttpRequest request HttpRequest.newBuilder() .uri(URI.create(endpoint /v1/completions)) .timeout(Duration.ofSeconds(300)) // 生成慢读超时不能设太短 .header(Content-Type, application/json) .POST(HttpRequest.BodyPublishers.ofString(body)) .build(); HttpResponseString resp client.send(request, HttpResponse.BodyHandlers.ofString()); return resp.body(); } }逻辑说明先转义 prompt 中的反斜杠和双引号避免构造 JSON 时把结构改坏再拼装请求体注意 vLLM 的 OpenAI 兼容接口默认路径是/v1/completions读超时设 300 秒是因为长文本生成可能要几十秒太短会让 Java 侧先放弃。代码用了 Java 15 的文本块语法如果服务端是 JDK 8把body改成字符串拼接即可逻辑不变。Java 端拿到响应后用 Jackson 解析choices[0].text字段即可。需要流式输出时把 HTTP 请求改成BodyHandlers.ofLines()按行读 chunk但要注意 vLLM 返回的是 SSE 格式每行以data:开头解析时要跳过空行和[DONE]标记这块代码量会翻倍我先不展开。4.3 多 GPU 卡利用率确认服务起来后别急着调接口先确认两张卡真的都在干活。很多人在这一步翻车卡 0 快满载卡 1 纹丝不动。watch -n 1 nvidia-smiwatch每秒刷新一次显存和 GPU-Util。张量并行跑起来两张卡的显存占用应接近对称利用率也会交替起伏。如果只有卡 0 有显存占用回到第 4.1 节检查启动参数有没有传对如果是卡顺序不对用CUDA_VISIBLE_DEVICES1,0调换顺序再试。提示vLLM 启动时会先做 weight loading此时 GPU-Util 低是正常的等第一批请求进来才看得到真实负载。5. 排查与避坑五次部署记下的实际问题5.1 现象CUDA out of memory进程直接被杀启动后第一个请求就打爆显存日志里出现CUDA out of memory更狠的情况是进程直接被 kill连堆栈都看不到。原因显存预算只算了权重漏了 KV Cache、CUDA context 和中间激活。并发请求一进来KV Cache 占用直接翻倍余量瞬间耗尽。解决先调低--gpu-memory-utilization到 0.85 留出缓冲再缩小--max-model-len从 4096 降到 2048 实测一次还不行就换更粗的量化FP16 换 INT8INT8 换 INT4每降一档省一半权重显存。5.2 现象模型加载要十几分钟容器反复重启vLLM 打印Starting weight loading后卡了十几分钟甚至容器被健康检查判死反复重启。原因权重文件从 CPU 内存往显存搬运是单线程瓶颈机械盘或网络盘读大文件更慢某些镜像 CPU 核数给太少量化分片文件的加载时间成倍拉长。解决把模型文件放到本机 NVMe 盘上别放 NFS 网络盘容器 CPU limit 给到 8 核以上启动顺序调整为先加载模型再注册健康检查或者把健康检查首次延迟设到 5 分钟以上给足加载时间。5.3 现象Java 请求首次返回极慢第二次就正常第一次 Java 调用等了 40 秒第二次同样请求只要 1 秒用户反馈「接口不稳定」。原因vLLM 首次推理要跑 CUDA kernel 编译和显存分配这个预热过程只发生一次但会被监控系统记成超时故障。解决启动脚本里加一段预热请求服务起来后自动发一个短 prompt把首次推理的编译开销吃掉。常见做法是# 服务起来后先发一条短请求触发 kernel 编译和显存分配 curl -s -X POST http://127.0.0.1:8000/v1/completions \ -H Content-Type: application/json \ -d {prompt: 你好, max_tokens: 8} /dev/null echo 预热完成预热 token 数控制在 8 以内目的是触发链路不是真的生成内容。从那以后我把预热写进每次的部署脚本监控再没误报过。5.4 现象两张卡只有一张显存升高另一张始终为 0nvidia-smi显示卡 0 显存占用 20GB卡 1 一直是 0张量并行没生效。原因启动命令里漏传--tensor-parallel-size 2vLLM 默认只认一张卡或者CUDA_VISIBLE_DEVICES0,1写错了卡号实际只有一张卡可见。解决先执行nvidia-smi --query-gpuindex,name --formatcsv确认物理卡号再把--tensor-parallel-size和卡数对齐。改完参数重启后两张卡显存占用应基本对称。5.5 现象输出变成了乱码或重复的奇怪字符接口正常返回但生成内容夹杂大量无意义符号或同一句话循环很多遍。原因tokenizer 和模型权重版本不匹配。LLaMA2 不同版本有对应 tokenizer.model从网盘单独下载的拆分文件可能混用了 LLaMA 1 的 tokenizer词表对不上解码就乱。解决把 tokenizer 文件也放进模型目录别只放权重vLLM 启动时加上--tokenizer参数显式指定 tokenizer 路径避免自动探测到错的目录。检查版本时看 tokenizer.model 的 SHA256 是否和官方一致这是最省心的确认方式。6. 验证与调参压测脚本里看两个延迟指标部署完成、接口通了还差最后一步用数据确认这套东西能不能扛住真实请求。我习惯先用一个极简的循环压测脚本看两个指标——首 token 延迟和总生成时间这两个数字直接决定用户体感。# 连续发 30 次请求打印每次的首 token 延迟和总耗时 for i in $(seq 1 30); do curl -s -X POST http://127.0.0.1:8000/v1/completions \ -H Content-Type: application/json \ -d {prompt: 请用一句话介绍你自己, max_tokens: 128} \ -o /dev/null \ -w 第${i}次: 首token %{time_starttransfer}s, 总耗时 %{time_total}s\n done首 token 延迟看time_starttransfer代表从发请求到收到第一个字节的时间这个值越低用户感觉「模型开始回答了」就越快生成总耗时看time_total代表整个请求的生命周期。如果首 token 延迟高问题大概率在排队或 prefill 阶段如果首 token 快但 total 长说明生成速度是瓶颈需要调低上下文长度或升级显存带宽。调参时优先动这三个参数表格攒自实际部署参数作用常用值注意max_tokens最大生成长度64-512越大 KV Cache 占用越高temperature随机性0.2-0.8代码/事实类场景调低到 0.2top_p核采样范围0.8-0.95调低会让输出更保守还有一个常被忽略的习惯每次改完参数都要重新压测一轮别只凭体感判断。语言模型的输出带随机性三次单发请求的样本完全不可信最少跑 20 次看分布。从那以后我每次部署都强制走一遍「显存预算 → 预热 → 循环压测」这个流程Java 服务只管把延迟和错误率上报到监控模型侧的调参全部交给这套脚本翻车概率降了一大半。希望帮到你。本文还有配套的精品资源点击获取 Java团队如何将LLaMA2部署到自有GPU？多卡并行与显存优化实战
简介这是一份面向有Java基础、希望深入大模型部署领域的开发者的实战项目源码围绕如何用Java配合多GPU完成LLaMA2推理部署展开解决单卡算力不足与并行推理实现难的问题。压缩包共64个文件、约305KB以33个Java源文件为核心配合19个XML工程配置、Shell启动脚本、README说明、tokenizer词表文件等构成完整可运行的Maven工程。该资源已有1043人学习浏览。项目完整覆盖从模型加载、GPU分配、数据分发到并行计算与结果聚合的部署链路附有可执行的启动脚本和配置示例可帮助读者理解CUDA Java API或并行计算框架的使用方式快速搭建多GPU推理环境并复现运行效果是学习Java生态下LLaMA2落地部署的实用参考。1. 先解决一个麻烦Java 团队怎么把 LLaMA2 跑上自有 GPU一个 Java 后端团队要部署 LLM第一反应往往是不搭模型生态在 Python推理框架全是 PythonJava 过来像是给自己找麻烦。但这个资源包做的正是把这条链路走通——Java 负责对外接口和业务请求多 GPU 负责把 7B/13B 的权重放进去推理交给经过验证的加速层。说白了这是给想在企业内部做大模型私有化部署、但团队几乎全是 Java 技术栈的人一套可复现的工程样板环境怎么搭、量化怎么选、多卡怎么切、Java 怎么调每一步都落在脚本和代码上不是停留在概念。如果你正面临「老板让一个月内把 LLaMA2 上到现有 GPU 服务器」这种需求又不想推翻团队技术栈去重学 Python 服务端这套东西值得先花半小时拆开看一遍。下面按我复现时的顺序从选型到排障一步步讲清楚。2. 选型与架构为什么 Java 后端普遍走 Python 加速层 HTTP 这条路2.1 Java 侧没有官方运行时三条路线怎么权衡LLaMA2 官方没有给 Java 运行时这是绕不开的前提。我见过有人想用 JNI 直接调 C 推理引擎也有人试过在 Java 进程里嵌入 llama.cpp 的绑定最后都被拉回同一条路Python 加速层 Java HTTP 调用。原因很直白三者的对接成本和稳定性差一大截。路线对接成本并发能力多 GPU 支持适合场景Java 通过 JNI 直调 C 引擎高崩溃日志和内存管理全自理中需自研极少数定制场景进程内嵌入 Python 推理进程中两边内存互相影响中弱单卡快速验证Python 加速层 Java HTTP 调用低接口可视可测高好企业私有化部署第三条路线在工程上最稳Python 服务管住 GPU、显存和推理生命周期Java 服务通过 REST 接口发请求两边各自重启互不影响。这个资源包走的也是这个结构Java 端不是去写算子而是写一个对业务友好的 client 封装。提示如果只是单卡、单用户试玩llama.cpp 直接跑也够一旦涉及多用户并发和生产环境vLLM 这类带连续批处理的框架才是首选。2.2 多 GPU 切分原理张量并行和 KV Cache 的关系多 GPU 能放更大模型依赖的是张量并行Tensor Parallelism。原理一句话把 transformer 层里的 QKV 矩阵按列切成两份两张卡各持一半每张卡只算一半矩阵乘法算完再做 all-reduce 把结果合并。显存占用减半代价是卡间通信变多所以服务器里用 NVLink 或 PCIe 直连效果差别很大。除了权重还要算 KV Cache 的账。推理每生成一个 token都要把当前时刻的 K、V 向量存下来供后续 attention 使用这批缓存也占显存而且和上下文长度、并发数线性相关。这是我见过最多人漏算的部分权重算明白了加几路并发请求直接把卡撑爆。切分方式上vLLM 沿 transformer 层内部切权重称为张量并行llama.cpp 的做法偏朴素按层把不同 block 分到不同卡前几层在卡 0后几层在卡 1。两者都能跑但前者卡间通信更频繁显存利用率更高也是这个场景下我优先推荐的。2.3 资源包的结构与启动链路解压后先别急着跑把目录结构摸一遍。以这个资源包常见的布局来看核心是几个部分Python 推理服务入口、Java 客户端封装、启动与检测脚本、参数说明文档。模型权重一般不打包在里面体积太大下载地址会写进说明文件这是正常现象别以为资源缺东西。llama2-deploy/ ├── inference/ # Python 推理服务入口 ├── client/ # Java 客户端封装 ├── scripts/ # 启动与检测脚本 └── docs/ # 参数说明启动链路是先跑 Python 推理服务确认 GPU 两张卡都有负载再启动 Java 服务最后用压测脚本验证端到端延迟。这个顺序别反过来Java 先起了也没关系但排查时会分不清是接口问题还是模型没加载完。3. 环境与显存预算先算清楚再动手3.1 GPU 状态检查与驱动确认拿到服务器先确认 GPU 可见状态别信运维口头说的「有卡」。用下面两条命令核实nvidia-smi nvidia-smi --query-gpuindex,name,memory.total,memory.used,driver_version --formatcsv第一条看实时显存和进程占用第二条拿到精简的卡编号、型号与驱动版本。重点看驱动版本vLLM 对 CUDA 版本敏感驱动太老会让 torch 直接报 CUDA unavailable。常见版本对应关系是CUDA 11.8 需要驱动 520 系列以上CUDA 12.x 需要 525 以上具体以 PyTorch 官方支持矩阵为准驱动宁新勿旧。3.2 显存估算7B/13B 各精度能不能放进现有卡里动手前先算一笔账。权重显存约等于参数量乘以每个参数所占字节数FP16 是 2 字节INT8 是 1 字节INT4 约 0.5 字节。另外再加 KV Cache 和 CUDA context 的占用下面按 4096 上下文做了个估算表模型与精度权重显存KV Cache示例总显存参考LLaMA2-7B FP16约 14GB2-4GB约 18GBLLaMA2-7B INT8约 7GB2-4GB约 11GBLLaMA2-7B INT4/GPTQ约 4GB2-4GB约 8GBLLaMA2-13B FP16约 26GB4-6GB约 32GBLLaMA2-13B INT4/GPTQ约 6.5GB4-6GB约 12GB这表的意义在于一张 24GB 的卡跑 7B INT8 或 INT4 有余量13B FP16 一张卡放不下但两张 24GB 卡做张量并行刚好如果只有一张卡就得把 13B 降到 INT4 才能跑。我一般先把总显存算好再加 1-2GB 余量避免 CUDA context 和中间激活值把卡顶爆。生产环境并发一上来KV Cache 占用会成倍涨预算时最好按最大并发数再乘一次。3.3 Python 依赖与 Java 依赖清单Python 侧依赖集中在推理服务里requirements.txt 大致如下torch2.0.1 transformers4.31.0 vllm0.2.0 acceleratevLLM 版本别乱装最新先看资源包里锁的是哪个。不同版本的启动参数有差异比如旧版本用--tensor-parallel-size新版本也兼容但--max-model-len的默认值和行为在不同版本里略有不同踩过坑的人都知道升级框架是最耗时间的环节。Java 侧依赖少得多核心是 JSON 处理dependency groupIdcom.fasterxml.jackson.core/groupId artifactIdjackson-databind/artifactId version2.15.2/version /dependency如果用 JDK 11 自带的 HttpClient就不需要额外引 HTTP 库只加 Jackson 就够如果项目里本来就有 OkHttp 或 Spring Boot直接用现成的也行参数封装方式见下文。4. 部署实现多 GPU 启动参数从 vLLM 到 Java HTTP 调用4.1 启动 Python 推理服务tensor-parallel-size 与 CUDA_VISIBLE_DEVICES先明确一点资源包里的推理脚本大概率围绕 vLLM 封装因为 vLLM 对多 GPU 张量并行支持最成熟。模型文件建议提前准备好GPTQ 分片格式.safetensors和 vLLM 配合最顺。CUDA_VISIBLE_DEVICES0,1 python -m vllm.entrypoints.openai.api_server \ --model /data/models/llama2-13b-gptq \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.90 \ --max-model-len 4096 \ --host 0.0.0.0 \ --port 8000参数逐个说CUDA_VISIBLE_DEVICES0,1决定哪些卡可见两张卡做张量并行--tensor-parallel-size 2告诉框架把每层权重切成两份分到两张卡--gpu-memory-utilization 0.90限制每张卡最多用 90% 显存留一点给 CUDA context设为 1.0 容易在极端请求下 OOM--max-model-len 4096限制最大上下文长度设得越大 KV Cache 预留越多不是免费的。启动后进程会卡在前台加载权重看到Starting vLLM API server才算起来。如果资源包走的是 llama.cpp 路线启动命令就换一个风格CUDA_VISIBLE_DEVICES0,1 ./llama-server \ -m llama-2-13b-chat.Q4_K_M.gguf \ --n-gpu-layers 999 \ --split-mode layer \ --host 0.0.0.0 \ --port 8080llama.cpp 的 GGUF 单文件对新手友好但多卡是层切分卡间通信压力比张量并行小性能也相对弱一些。GGUF 走不了 vLLM两者选其一别混着用。4.2 Java 端调用封装HttpClient 流式与非流式Java 端封装调用我一般直接基于 JDK 11 的java.net.http.HttpClient少引一个依赖少一份维护。下面这段是核心方法非流式场景够了import java.net.URI; import java.net.http.HttpClient; import java.net.http.HttpRequest; import java.net.http.HttpResponse; import java.time.Duration; public class LlamaClient { private final HttpClient client; private final String endpoint; public LlamaClient(String endpoint) { this.endpoint endpoint; this.client HttpClient.newBuilder() .connectTimeout(Duration.ofSeconds(10)) // 连接超时设置短快速暴露网络问题 .build(); } public String chat(String prompt, int maxTokens) throws Exception { // 注意prompt 里的双引号必须先转义否则 JSON 解析直接失败 String escaped prompt.replace(\\, \\\\).replace(\, \\\); String body {prompt: %s, max_tokens: %d, temperature: 0.7} .formatted(escaped, maxTokens); HttpRequest request HttpRequest.newBuilder() .uri(URI.create(endpoint /v1/completions)) .timeout(Duration.ofSeconds(300)) // 生成慢读超时不能设太短 .header(Content-Type, application/json) .POST(HttpRequest.BodyPublishers.ofString(body)) .build(); HttpResponseString resp client.send(request, HttpResponse.BodyHandlers.ofString()); return resp.body(); } }逻辑说明先转义 prompt 中的反斜杠和双引号避免构造 JSON 时把结构改坏再拼装请求体注意 vLLM 的 OpenAI 兼容接口默认路径是/v1/completions读超时设 300 秒是因为长文本生成可能要几十秒太短会让 Java 侧先放弃。代码用了 Java 15 的文本块语法如果服务端是 JDK 8把body改成字符串拼接即可逻辑不变。Java 端拿到响应后用 Jackson 解析choices[0].text字段即可。需要流式输出时把 HTTP 请求改成BodyHandlers.ofLines()按行读 chunk但要注意 vLLM 返回的是 SSE 格式每行以data:开头解析时要跳过空行和[DONE]标记这块代码量会翻倍我先不展开。4.3 多 GPU 卡利用率确认服务起来后别急着调接口先确认两张卡真的都在干活。很多人在这一步翻车卡 0 快满载卡 1 纹丝不动。watch -n 1 nvidia-smiwatch每秒刷新一次显存和 GPU-Util。张量并行跑起来两张卡的显存占用应接近对称利用率也会交替起伏。如果只有卡 0 有显存占用回到第 4.1 节检查启动参数有没有传对如果是卡顺序不对用CUDA_VISIBLE_DEVICES1,0调换顺序再试。提示vLLM 启动时会先做 weight loading此时 GPU-Util 低是正常的等第一批请求进来才看得到真实负载。5. 排查与避坑五次部署记下的实际问题5.1 现象CUDA out of memory进程直接被杀启动后第一个请求就打爆显存日志里出现CUDA out of memory更狠的情况是进程直接被 kill连堆栈都看不到。原因显存预算只算了权重漏了 KV Cache、CUDA context 和中间激活。并发请求一进来KV Cache 占用直接翻倍余量瞬间耗尽。解决先调低--gpu-memory-utilization到 0.85 留出缓冲再缩小--max-model-len从 4096 降到 2048 实测一次还不行就换更粗的量化FP16 换 INT8INT8 换 INT4每降一档省一半权重显存。5.2 现象模型加载要十几分钟容器反复重启vLLM 打印Starting weight loading后卡了十几分钟甚至容器被健康检查判死反复重启。原因权重文件从 CPU 内存往显存搬运是单线程瓶颈机械盘或网络盘读大文件更慢某些镜像 CPU 核数给太少量化分片文件的加载时间成倍拉长。解决把模型文件放到本机 NVMe 盘上别放 NFS 网络盘容器 CPU limit 给到 8 核以上启动顺序调整为先加载模型再注册健康检查或者把健康检查首次延迟设到 5 分钟以上给足加载时间。5.3 现象Java 请求首次返回极慢第二次就正常第一次 Java 调用等了 40 秒第二次同样请求只要 1 秒用户反馈「接口不稳定」。原因vLLM 首次推理要跑 CUDA kernel 编译和显存分配这个预热过程只发生一次但会被监控系统记成超时故障。解决启动脚本里加一段预热请求服务起来后自动发一个短 prompt把首次推理的编译开销吃掉。常见做法是# 服务起来后先发一条短请求触发 kernel 编译和显存分配 curl -s -X POST http://127.0.0.1:8000/v1/completions \ -H Content-Type: application/json \ -d {prompt: 你好, max_tokens: 8} /dev/null echo 预热完成预热 token 数控制在 8 以内目的是触发链路不是真的生成内容。从那以后我把预热写进每次的部署脚本监控再没误报过。5.4 现象两张卡只有一张显存升高另一张始终为 0nvidia-smi显示卡 0 显存占用 20GB卡 1 一直是 0张量并行没生效。原因启动命令里漏传--tensor-parallel-size 2vLLM 默认只认一张卡或者CUDA_VISIBLE_DEVICES0,1写错了卡号实际只有一张卡可见。解决先执行nvidia-smi --query-gpuindex,name --formatcsv确认物理卡号再把--tensor-parallel-size和卡数对齐。改完参数重启后两张卡显存占用应基本对称。5.5 现象输出变成了乱码或重复的奇怪字符接口正常返回但生成内容夹杂大量无意义符号或同一句话循环很多遍。原因tokenizer 和模型权重版本不匹配。LLaMA2 不同版本有对应 tokenizer.model从网盘单独下载的拆分文件可能混用了 LLaMA 1 的 tokenizer词表对不上解码就乱。解决把 tokenizer 文件也放进模型目录别只放权重vLLM 启动时加上--tokenizer参数显式指定 tokenizer 路径避免自动探测到错的目录。检查版本时看 tokenizer.model 的 SHA256 是否和官方一致这是最省心的确认方式。6. 验证与调参压测脚本里看两个延迟指标部署完成、接口通了还差最后一步用数据确认这套东西能不能扛住真实请求。我习惯先用一个极简的循环压测脚本看两个指标——首 token 延迟和总生成时间这两个数字直接决定用户体感。# 连续发 30 次请求打印每次的首 token 延迟和总耗时 for i in $(seq 1 30); do curl -s -X POST http://127.0.0.1:8000/v1/completions \ -H Content-Type: application/json \ -d {prompt: 请用一句话介绍你自己, max_tokens: 128} \ -o /dev/null \ -w 第${i}次: 首token %{time_starttransfer}s, 总耗时 %{time_total}s\n done首 token 延迟看time_starttransfer代表从发请求到收到第一个字节的时间这个值越低用户感觉「模型开始回答了」就越快生成总耗时看time_total代表整个请求的生命周期。如果首 token 延迟高问题大概率在排队或 prefill 阶段如果首 token 快但 total 长说明生成速度是瓶颈需要调低上下文长度或升级显存带宽。调参时优先动这三个参数表格攒自实际部署参数作用常用值注意max_tokens最大生成长度64-512越大 KV Cache 占用越高temperature随机性0.2-0.8代码/事实类场景调低到 0.2top_p核采样范围0.8-0.95调低会让输出更保守还有一个常被忽略的习惯每次改完参数都要重新压测一轮别只凭体感判断。语言模型的输出带随机性三次单发请求的样本完全不可信最少跑 20 次看分布。从那以后我每次部署都强制走一遍「显存预算 → 预热 → 循环压测」这个流程Java 服务只管把延迟和错误率上报到监控模型侧的调参全部交给这套脚本翻车概率降了一大半。希望帮到你。本文还有配套的精品资源点击获取