大模型推理服务器在正式项目里通常被称为 LLM Inference Server核心任务是把已经训练好的大模型以服务的形式对外提供推理能力。训练阶段的目标是把模型“造”出来推理阶段的目标则是让这个模型在真实请求下稳定、高效地“跑”起来。实际部署时很多人下载一个开源模型在 Python 脚本里调用一次就算完成部署但真正的推理服务要复杂得多多个用户同时请求时不能逐个排队等显存要被动态复用输出是逐 token 生成的请求要有超时和错误处理服务挂掉后还要能自动恢复。这篇文章会从大模型推理服务器的基本原理讲起带你在本地把 vLLM 跑起来完成模型部署、接口验证、并发压测、参数调优再用 systemd、Nginx 和监控手段把它从“能跑”变成“能上线”。整个过程不需要超大显存的显卡以常见的 7B 到 14B 开源模型为例即可。学完之后你会清楚推理服务器内部做了什么、部署命令里的参数到底在控制什么、压测数据该怎么看、遇到显存不足或者并发超时该从哪里查起。1. 大模型推理服务器到底在解决什么问题1.1 从“单机调用模型”到“服务化推理”差距在哪里先看一段最常见的本地推理代码。很多人在笔记本或服务器上第一次跑大模型时写的是这样的逻辑from transformers import AutoModelForCausalLM, AutoTokenizer import torch model_name /data/models/Qwen2.5-7B-Instruct tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained( model_name, torch_dtypetorch.float16, device_mapauto ) prompt 介绍一下大模型推理服务器 inputs tokenizer(prompt, return_tensorspt).to(cuda) output model.generate(**inputs, max_new_tokens128) print(tokenizer.decode(output[0], skip_special_tokensTrue))这段代码能跑通但它只是“单机调用”不是“推理服务”。问题在于模型加载后占住显存但每次调用都阻塞等待生成完成第二个用户只能等第一个用户结束。没有请求队列、超时、鉴权和错误返回格式。每次生成过程中已经产生的 KV cache 没有被框架级复用并发能力几乎为零。进程一退出服务就没了也没有日志、监控和重启机制。大模型推理服务器做的事情就是把模型加载、token 生成、显存管理、动态批处理、并发调度、接口协议这些能力封装成可以长期运行的服务进程。客户端只需要发送一个 HTTP 请求就能拿到与大模型交互的结果。1.2 推理过程为什么不能只看“总耗时”大模型的文本生成是自回归过程。模型每次只生成一个 token然后把新 token 拼接进输入序列再继续预测下一个 token。因此一次完整推理的时间可以拆成两个阶段Prefill预填充阶段处理整个输入 prompt计算第一个输出 token。这个阶段计算量大但只发生一次。Decode解码阶段逐个生成后续 token。每个 token 生成都需要读取全部 KV cache所以这个阶段对显存带宽非常敏感。因为这个特性评价推理服务器性能时不能只用一个“总耗时”指标。常用指标如下指标全称含义关注原因TTFTTime To First Token从发送请求到收到第一个输出 token 的时间用户感知到的“响应速度”TPOTTime Per Output Token生成每个输出 token 的耗时决定输出流畅度TPSTokens Per Second每秒生成的 token 数模型本身和硬件的生成效率吞吐量Throughput单位时间内服务器能处理的请求数或 token 数决定服务器容量QPSQueries Per Second每秒完成的请求数对外服务能力在对话类场景中TTFT 影响用户第一感受TPOT 影响打字效果是否流畅。在离线批量生成场景中吞吐量则比单请求延迟更重要。需要注意的是吞吐量和高并发时单个请求的 TPOT 可能会变慢因为服务器通过动态批处理来提高整体利用率本质是用单请求延迟换整体吞吐。1.3 推理服务器内部做了哪些关键优化大模型推理服务器和普通 Web 服务最大的区别是它必须管理昂贵的显存和动态变化的 KV cache。主流推理框架会做以下几类优化Continuous Batching连续批处理普通批处理要等同一个批次的所有请求全部完成才释放资源。连续批处理允许每个请求完成后立刻释放显存并让新请求插入当前批次显著提升吞吐。PagedAttention分页注意力vLLM 采用类似操作系统分页内存的思路把 KV cache 分成固定大小的块避免显存碎片化也支持更长上下文。KV Cache 复用相同前缀的请求可以共享已经计算过的 KV cache对多轮对话和固定 system prompt 场景很有帮助。量化把权重从 FP16 降低到 INT8 或 INT4减少显存占用在部分场景也能提高吞吐但可能带来精度损失。Prefix Caching前缀缓存当多个请求使用相同前缀时框架可以直接复用前缀计算减少重复 Prefill。这些优化对用户是透明的但理解它们之后你才能解释为什么压测时并发提升单请求延迟会上升以及为什么显存充足并不意味着并发可以无限提高。2. 部署前先把硬件、驱动和依赖环境对齐2.1 显存估算怎么判断一张卡能不能跑某个模型部署大模型推理服务器的第一步不是装框架而是先搞清楚显存够不够。推理阶段显存主要由三部分组成模型权重。KV cache。框架运行时和 CUDA 上下文。模型权重可以通过公式粗略估算。常见做法是权重大小约等于参数量乘以每个参数字节数。FP16 是每个参数 2 字节INT8 是 1 字节INT4 约 0.5 字节。模型参数量FP16 权重估算INT8 权重估算常见部署卡型参考1B 到 3B2GB 到 6GB1GB 到 3GB消费级显卡即可7B 到 8B14GB 到 16GB7GB 到 8GB24GB 显存比较稳妥13B 到 14B26GB 到 28GB13GB 到 14GB40GB 或 48GB 显存32B 到 34B64GB 到 68GB32GB 到 34GB多卡或大显存服务器70B 及以上140GB 以上70GB 以上多卡集群KV cache 的大小取决于 max-model-len、并发请求数和每层的隐藏维度实际占用往往比想象中大。如果显存刚好卡在权重线附近建议先留出 10% 到 20% 余量或者直接选择量化模型。注意这里给出的是估算值具体占用量还要看模型结构、上下文长度和推理框架版本。部署前用nvidia-smi观察实际占用比浏览器里的“显存计算器”更可靠。2.2 驱动、CUDA、PyTorch 和推理框架的版本关系很多人把nvidia-smi顶部显示的 CUDA Version 当成当前环境已经安装的 CUDA这其实是一个常见误区。它表示当前 GPU 驱动最多支持到什么 CUDA 版本运行 PyTorch 时实际使用的是 PyTorch 自带的 CUDA 运行库。部署前先做一次基础检查nvidia-smi nvcc --version python --version pip --version如果没有安装 CUDA Toolkitnvcc可能不存在但 PyTorch 仍然可以从 PyPI 安装自带 CUDA 运行时的版本。推荐顺序是确认 GPU 驱动版本足够新。安装匹配的 PyTorch。安装推理框架例如 vLLM。在 Python 中检查 GPU 是否可用。import torch print(torch.__version__) print(torch.cuda.is_available()) print(torch.cuda.device_count()) print(torch.cuda.get_device_name(0))如果torch.cuda.is_available()返回 False优先检查驱动版本和 PyTorch 的 CUDA 版本是否兼容而不是马上重装系统。2.3 Python 虚拟环境和依赖安装的推荐顺序推理框架对依赖版本比较敏感尤其是 PyTorch、CUDA、transformers、tokenizers 之间经常存在版本匹配要求。强烈建议使用虚拟环境不要把推理环境装进系统 Python。mkdir -p /opt/llm-server cd /opt/llm-server python3 -m venv .venv source .venv/bin/activate pip install --upgrade pip pip install torch pip install vllm安装完成后先检查 vLLM 版本和 PyTorch 能否正常配合python -c import vllm; print(vllm.__version__) python -c import torch; print(torch.__version__, torch.cuda.is_available())这里有一个常见坑如果先安装 vLLM它可能会根据当前 PyTorch 版本决定是否重新编译或者报“版本不支持”。因此建议先装好 PyTorch再装 vLLM。如果 pip 解析依赖时出现冲突可以考虑使用虚拟环境重装而不是手动强制降级多个包。3. 用 vLLM 从零拉起一个可用的推理服务3.1 vLLM、Ollama、llama.cpp 怎么选当前生态里比较常见的推理框架有 vLLM、Ollama、llama.cpp、SGLang、TensorRT-LLM 等。它们的定位并不完全相同。框架特点适合场景不适合场景vLLM高吞吐、连续批处理、OpenAI 兼容接口生产环境服务化部署、并发请求边缘设备、CPU-only 环境Ollama一键启动、模型管理简单本地体验、个人开发机、快速试模型高并发生产服务、复杂定制llama.cpp纯 C/C 实现、支持 CPU边缘设备、Mac、嵌入式高吞吐 GPU 服务SGLang结构化生成、复杂调度需要结构化输出、长上下文生态不如 vLLM 广泛TensorRT-LLMNVIDIA 优化、低延迟固定模型结构的高性能生产改动频繁、想快速上手如果你想快速体验Ollama 最省事。如果你想理解推理服务并把它做成生产接口vLLM 是更合适的起点。本文以 vLLM 为例因为它的 OpenAI 兼容接口可以直接对接很多上层应用且压测和部署思路对其他框架同样适用。3.2 vLLM 启动命令最小可运行案例假设你已经把模型文件下载到本地目录例如/data/models/Qwen2.5-7B-Instruct。启动一个 OpenAI 兼容服务的最简命令如下CUDA_VISIBLE_DEVICES0 python -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen2.5-7B-Instruct \ --served-model-name qwen2.5-7b \ --max-model-len 8192 \ --gpu-memory-utilization 0.85 \ --tensor-parallel-size 1 \ --host 0.0.0.0 \ --port 8000各参数的含义--model本地模型目录路径也可以是 Hugging Face 上的模型 ID。生产环境建议使用本地路径避免启动时去外网下载。--served-model-name对外暴露的模型名称客户端请求中的model字段必须与它一致。--max-model-len模型最大上下文长度。它同时影响输入 token 和输出 token 的总和。--gpu-memory-utilization允许 vLLM 占用的显存比例。设置成 0.85 表示最多使用 85% 显存剩余留给 CUDA context。--tensor-parallel-size张量并行卡数。单卡时必须为 1。--host和--port监听地址和端口。启动后日志中会出现类似信息表示服务已经监听INFO: Started server process [12345] INFO: Waiting for model to be loaded on GPU... INFO: Model loading took 20.3 GB INFO: Uvicorn running on http://0.0.0.0:80003.3 用 OpenAI 兼容接口验证推理服务服务启动后先用 curl 发一个最简单的对话请求curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5-7b, messages: [ {role: user, content: 用一句话介绍大模型推理服务器} ], max_tokens: 128, temperature: 0.7 }正常返回的 JSON 结构大致如下{ id: chatcmpl-abc123, object: chat.completion, created: 1700000000, model: qwen2.5-7b, choices: [ { index: 0, message: { role: assistant, content: 大模型推理服务器是面向大模型推理场景的高性能服务系统。 }, finish_reason: stop } ], usage: { prompt_tokens: 20, completion_tokens: 24, total_tokens: 44 } }在 Python 里也可以用 OpenAI SDK 调用from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:8000/v1, api_keyEMPTY ) resp client.chat.completions.create( modelqwen2.5-7b, messages[{role: user, content: 大模型推理服务器和训练服务器有什么区别}], max_tokens256 ) print(resp.choices[0].message.content) print(resp.usage)这一步验证的不只是服务能启动而是确认请求解析、模型生成、响应格式、token 统计都能正常工作。3.4 关键启动参数的取舍参数常见默认值调大影响调小影响部署建议--max-model-len由模型配置决定KV cache 更大显存更紧张能处理更长文本长文本可能被截断根据业务最长输入输出总和设置--gpu-memory-utilization0.9 左右更多显存用于模型和 KV cache显存利用率低并发能力下降一般 0.85 到 0.95 之间--max-num-seqs由框架决定允许更多请求同时参与批处理吞吐更高并发稍高就会排队显存充足时可适当调大--tensor-parallel-size1多卡并行单请求显存压力降低单卡无法跑大模型单卡保持 1--dtypeauto使用更高精度输出更稳定使用低精度可减少显存显卡支持时优先 float16--quantization无无指定量化算法例如 awq、gptq显存不足时启用但需要量化模型需要特别说明的是--max-model-len不是“模型最大输入长度”而是“输入加上输出 token 的总和”。如果设置 8192用户输入占用了 7000 token输出最多只能再生成 1192 token。生产环境要结合业务实际请求长度仔细计算否则会出现奇怪的截断问题。4. 压测和调优把参数从“能跑”调到“稳定可用”4.1 压测前先看哪些指标启动服务只是第一步。真正要上线时必须知道这台服务器能承受多大并发、单请求延迟是多少、瓶颈在哪里。压测阶段需要关注五类数据请求成功率并发升高后有没有连接失败、超时、返回 500 或 503。QPS 和 TPS服务器每秒完成多少个请求、生成多少 token。TTFT 和 TPOT首 token 延迟和每个 token 的生成延迟。GPU 利用率和显存占用判断瓶颈在计算、带宽还是显存。请求排队长度vLLM 等框架会先把请求放入调度队列队列过长说明服务容量不够。实际部署中不能只看“GPU 利用率高”就认为服务器效率高。高利用率有时意味着请求在排队也可能是框架正在大量做 Prefill用户维度的 TTFT 已经非常高了。4.2 用 Python 脚本做最小并发压测下面是一个简单但足够验证并发能力的压测脚本。它用线程池同时发起多个请求记录每个请求的耗时和返回状态。import time import json import threading from concurrent.futures import ThreadPoolExecutor from urllib.request import Request, urlopen URL http://127.0.0.1:8000/v1/chat/completions MODEL qwen2.5-7b PROMPT 请写一段关于人工智能的简短介绍控制在五十字以内。 def send_once(): body json.dumps({ model: MODEL, messages: [{role: user, content: PROMPT}], max_tokens: 128, temperature: 0.7 }).encode(utf-8) req Request(URL, databody, headers{Content-Type: application/json}) start time.time() try: with urlopen(req, timeout120) as resp: data json.loads(resp.read().decode(utf-8)) usage data.get(usage, {}) elapsed time.time() - start return { ok: True, elapsed: elapsed, prompt_tokens: usage.get(prompt_tokens, 0), completion_tokens: usage.get(completion_tokens, 0), } except Exception as exc: return { ok: False, elapsed: time.time() - start, error: str(exc), } def run_concurrency(concurrency, total_requests40): results [] with ThreadPoolExecutor(max_workersconcurrency) as executor: futures [executor.submit(send_once) for _ in range(total_requests)] for f in futures: results.append(f.result()) ok [r for r in results if r[ok]] failed [r for r in results if not r[ok]] total_latency sum(r[elapsed] for r in ok) / len(ok) if ok else 0 total_tokens sum(r[completion_tokens] for r in ok) print(f并发数: {concurrency}, 总请求: {total_requests}) print(f成功: {len(ok)}, 失败: {len(failed)}) print(f平均耗时: {total_latency:.2f}s) print(f总生成 token: {total_tokens}) if ok: print(f平均生成速度: {total_tokens / sum(r[elapsed] for r in ok):.2f} token/s) if __name__ __main__: for c in [1, 4, 8, 16]: run_concurrency(c)运行脚本时建议从低并发开始逐步增加python benchmark.py不要一上来就开 100 并发。如果服务器显存不足或配置不当高并发可能直接触发 CUDA OOM导致服务进程崩溃而不仅仅是返回错误。4.3 根据压测结果调整参数压测数据出来后常见调整方向如下如果显存占用很高但并发一高就排队可以调大--max-num-seqs让更多请求进入同一个 batch。如果 TTFT 很高检查请求队列是否积压或者 KV cache 是否因为max-model-len设置过大而被浪费。如果 TPOT 较慢可以尝试量化模型或者选用更小的模型。如果并发稍高就报 503VLM 通常会在排队长时拒绝新请求需要调大队列容量、增加服务副本或者从入口做限流。每次修改参数后都应该重新用同样的压测脚本测试保证对比口径一致。4.4 压测阶段的高频坑错误做法max-model-len直接设成模型支持的最大值比如 32768导致 KV cache 占用极大后续并发一高就 OOM。正确做法是根据业务平均长度设置比如对话场景 4096 或 8192。错误做法压测脚本一上来就 100 并发结果服务进程崩溃误以为 vLLM 性能差。正确做法是 1、4、8、16 逐步加压找到服务的真实容量曲线。错误做法使用默认 float32 或用未量化的超大模型显存直接被打满。正确做法是使用 float16 或预量化模型先保证服务能稳定响应再考虑更高精度。错误做法只看“GPU 利用率 95%”就判定服务器已经满载忽略了用户请求的 TTFT 实际已经超过 10 秒。正确做法是同时看 GPU 指标和请求延迟指标二者需要结合分析。5. 从开发到生产服务化、权限和监控5.1 用 systemd 把推理服务变成常驻服务直接用python -m vllm.entrypoints.openai.api_server启动的进程在终端关闭、服务器重启或进程异常退出后就没了。生产环境建议用 systemd 托管。创建/etc/systemd/system/vllm-server.service[Unit] DescriptionvLLM Inference Server Afternetwork-online.target Wantsnetwork-online.target [Service] Userllm Groupllm WorkingDirectory/opt/llm-server EnvironmentCUDA_VISIBLE_DEVICES0 EnvironmentHF_HOME/data/huggingface ExecStart/opt/llm-server/.venv/bin/python -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen2.5-7B-Instruct \ --served-model-name qwen2.5-7b \ --max-model-len 8192 \ --gpu-memory-utilization 0.85 \ --tensor-parallel-size 1 \ --host 0.0.0.0 \ --port 8000 Restartalways RestartSec10 [Install] WantedBymulti-user.target启动和查看状态sudo systemctl daemon-reload sudo systemctl enable vllm-server sudo systemctl start vllm-server sudo systemctl status vllm-server journalctl -u vllm-server -f需要说明的是如果是初学者或者本地开发环境可以省掉这一步先保证功能和压测跑通。生产环境再补。5.2 增加 HTTP 网关、鉴权和限流vLLM 自带的服务默认没有鉴权监听在0.0.0.0时谁都能调用。生产环境至少要加一层 Nginx 转发和访问限制。一个最小 Nginx 配置示例server { listen 8001; location /v1/ { proxy_pass http://127.0.0.1:8000; proxy_http_version 1.1; proxy_set_header Host $host; proxy_read_timeout 300s; proxy_send_timeout 300s; } }在网关层可以根据业务情况增加 API Key 校验、IP 白名单、请求频率限制。大模型推理请求的耗时通常很长所以proxy_read_timeout不能设置太短否则稍微复杂一点的生成请求会被 Nginx 提前断开。注意学习阶段可以不做鉴权但不要把没有鉴权的服务直接暴露到公网。推理服务可能消耗大量 GPU 资源一旦被恶意刷请求费用和稳定性都会失控。5.3 监控GPU、请求队列和错误率上线后需要监控的核心指标包括GPU 利用率、显存占用、温度、功耗。服务的 QPS、TTFT、TPOT、平均生成 token 数。请求成功率、超时率、错误码分布。vLLM 的排队请求数。最直接的命令行检查方式nvidia-smi nvidia-smi dmon -s pucvmet -d 2nvidia-smi dmon可以持续输出 GPU 利用率和显存变化适合定位部署初期的压力状况。完整监控方案通常用 Prometheus 采集指标再用 Grafana 展示。vLLM 日志本身也会打印请求级延迟但生产环境更适合通过指标系统做聚合告警。6. 常见问题排查链路6.1 启动时报 CUDA out of memory现象启动 vLLM 或压测时日志中出现torch.OutOfMemoryError: CUDA out of memory.可能原因模型权重加上 KV cache 超过显存上限。gpu-memory-utilization设置过高没有给 CUDA context 留空间。其他进程占用了显存例如之前启动的推理服务没有退出。检查方式nvidia-smi ps -ef | grep vllm解决方式调低gpu-memory-utilization到 0.8 左右。调小max-model-len。杀掉旧进程或者使用CUDA_VISIBLE_DEVICES指定空闲卡。如果显存确实不够换量化模型或换更大显存显卡。6.2 首次请求特别慢后续变快现象服务刚启动第一次请求等了很久才返回后续请求恢复正常。可能原因模型权重还在加载或者 CUDA kernel 正在进行图编译。Prefill 阶段输入很长第一个 token 本来就慢。磁盘读取模型文件的速度较慢。检查方式看服务日志中模型加载耗时。用短 prompt 和长 prompt 对比 TTFT。解决方式服务启动后先发一个预热请求让 CUDA 图编译完成。把模型文件放在 SSD 上降低首次加载延迟。如果业务有固定 system prompt可以启用框架的前缀缓存。6.3 并发一高就 503 或超时现象并发从 8 提高到 16 后部分请求返回 503 或直接超时。可能原因vLLM 队列长度达到上限新请求被拒绝。KV cache 不足无法容纳更多并发请求。单请求生成时间过长超过了 Nginx 或客户端的超时时间。检查方式查看服务日志中的队列拒绝记录。观察压测时显存是否接近 100%。使用journalctl -u vllm-server -f实时查看请求处理情况。解决方式调大max-num-seqs或队列长度。调低max-model-len释放更多 KV cache。在网关层增加合理的超时和重试策略。如果业务并发持续增长需要增加服务副本或升级硬件。6.4 输出乱码、截断或结果不稳定现象同一问题多次请求结果时好时坏或者输出到一半就停止。可能原因max_tokens设置太小输出被截断。temperature设置过高随机性过大。模型量化后精度损失部分场景输出质量下降。请求的stop参数包含业务中不该停止的字符串。检查方式对比不同max_tokens和temperature下的输出。在量化模型和原始 FP16 模型之间做同一组输入对比。解决方式根据业务需求调整max_tokens。对事实型任务使用较低temperature比如 0.1 到 0.3。如果量化导致输出质量明显下降考虑换粗粒度量化或降低量化比例。6.5 一套可复用的排查清单问题现象优先检查常见原因处理建议启动报 OOMnvidia-smi、日志显存不够或参数过大调低显存利用率、减少 max-model-len、加卡首次请求慢服务日志、预热请求模型加载、CUDA 图编译预热一次后再接入流量并发高报 503服务日志、排队长度队列满或 KV cache 不足调大队列参数、限制请求长度、扩容输出被截断返回的 finish_reasonmax_tokens 太小调大 max_tokens 或调小输入长度结果不稳定采样参数、量化方式temperature 过高降低 temperature检查量化损失显存占用与预期不符vLLM 启动日志KV cache 被 max-model-len 放大按实际业务长度设置 max-model-len7. 环境区分、方案选型和后续学习路径7.1 学习环境、测试环境与生产环境差异同一个推理服务在不同阶段需要做的事情完全不一样。维度学习环境测试环境生产环境模型规模0.5B 到 7B 即可按业务选择7B 到 14B 常见按业务并发和效果要求选择部署方式前台进程运行systemd 或容器systemd、容器、多副本鉴权不需要简单 Key 即可必须做监控没有记录日志Prometheus、Grafana、告警压测可选必须做发布前和定期做回滚不需要保留旧版本需要灰度发布和回滚方案生产环境多做的工作主要是为了两个目标可观测和可恢复。即使模型效果一般只要日志、监控、限流和重启策略齐全系统也能稳定运行反过来如果模型效果很好但服务随时会崩同样无法交付。7.2 根据业务选择模型和推理框架不同业务对推理服务的要求差异很大实时对话助手关注 TTFT 和 TPOT需要低延迟优先考虑小模型、量化、前缀缓存。离线批量摘要关注吞吐量可以接受较高单请求延迟优先考虑大 batch、连续批处理。长文档问答关注长上下文支持需要较大max-model-len但并发能力会受限。边缘设备优先考虑 llama.cpp 和 GGUF 量化甚至可以跑 CPU。框架选型也不是越新越好。vLLM 生态成熟、接口规范是大多数场景的稳妥选择。如果对延迟有极致要求且模型结构固定可以研究 TensorRT-LLM。如果只需要个人电脑上快速跑模型Ollama 更合适。7.3 下一步扩展方向当你能独立完成“部署一个模型到 vLLM 并通过接口调用”之后可以从这几个方向继续深入学习模型量化原理理解 GPTQ、AWQ 和 GGUF 之间的区别并实测部署效果。学习 KV cache 和 Prefix Caching优化多轮对话场景。学习 Tensor Parallel 和 Pipeline Parallel尝试多卡部署更大的模型。学习分布式推理网关和调度例如用多套 vLLM 副本承接更高并发。学习评估体系用固定测试集对比不同模型、不同量化方式、不同采样参数的效果。给新手的练习路径是先用 7B 模型在单卡上完成部署再写压测脚本观察不同max-num-seqs和max-model-len对延迟和吞吐的影响最后加上 systemd 和 Nginx。这个过程不复杂但能让你真正理解推理服务器的资源模型。之后无论换成 SGLang、Ollama 还是 TensorRT-LLM都能很快迁移思路。