简介：本文面向企业内网的本地大模型部署，提供一套可复用的五维评测框架。文章解读vLLM推理参数的作用与取舍，给出GPU与模型文件的前置校验步骤，并说明工具调用的安全管控。读者可据此建立自己的性能基线，在吞吐、延迟和显存之间找到平衡点。
AI辅助编程在企业内网中的需求快速增长。很多团队希望把代码和核心数据留在内网，同时获得可用的代码补全、代码审查和测试用例生成能力。本地部署大模型可以满足这一目标，但从模型文件到稳定可用的API服务，中间涉及驱动、容器、推理引擎和模型参数等多个环节，每个环节都可能出问题。
本文的目标是给出评测方法，而不是判断某个产品“好不好”。文中以一套常见组合为例：可视化容器管理面板、vLLM推理引擎和一个27B参数级别的代码模型。读者可以把其中任一组件替换为自己选用的产品，沿用同样的评测维度与记录方法。文中不给出具体测试数值，所有结论都需要在自己的硬件和业务数据上重新验证。
本方案由三部分组成：
评测报告应至少记录以下版本信息，否则结果无法复现：
| 记录项 | 示例 | 实测值 |
|---|---|---|
| 宿主机操作系统 | Ubuntu 22.04 | 待填写 |
| GPU型号与数量 | 4张同型号数据中心GPU | 待填写 |
| NVIDIA驱动版本 | nvidia-smi输出 | 待填写 |
| CUDA版本 | nvidia-smi输出 | 待填写 |
| 容器运行时与GPU插件 | Docker与NVIDIA Container Toolkit | 待填写 |
| 面板版本 | 面板官方版本号 | 待填写 |
| vLLM版本 | vllm --version 输出 |
待填写 |
| 模型名称与版本 | 模型仓库中的完整标识 | 待填写 |
版本之间的兼容性以官方文档和发布说明为准。驱动版本过低时，容器内可能无法识别GPU或无法加载CUDA库。
本文设计了五个评测维度。每个维度给出建议的通过标准，读者可以按自己的业务要求调整阈值。
| 评测维度 | 关注指标 | 验证方法 | 建议通过标准 |
|---|---|---|---|
| 功能完整性 | 模型加载、模型列表接口、流式输出、工具调用解析 | 发送标准对话与工具调用请求，检查响应结构 | 所有用例返回格式正确，工具调用参数为合法JSON |
| 性能表现 | 首字延迟（TTFT）、输出吞吐（Tokens/s）、显存占用 | 按并发梯度压测，记录各指标分位数 | 业务目标并发下，P95延迟满足团队的交互要求 |
| 易用性 | 部署步骤数、配置项可视化程度、排障耗时 | 记录从环境准备到服务可调用的全部步骤与耗时 | 同一名运维人员可在约定时间内独立完成部署 |
| 兼容性 | GPU驱动、容器GPU透传、内网操作系统适配 | 校验驱动与CUDA版本，在容器内执行GPU查询 | 容器内能正常识别全部目标GPU |
| 可维护性 | 日志、监控、版本升级、配置变更成本 | 观察长期运行日志，模拟异常重启后的恢复 | 服务在重启后自动恢复，升级步骤有文档且可回滚 |
性能与功能测试之前，需要先确认环境一致。环境问题如果不先排除，后续的测试数据大多没有意义。
1. GPU驱动与容器GPU透传
在宿主机执行以下命令：
nvidia-smi
正常输出应包含GPU型号、驱动版本、CUDA版本以及每张卡的显存总量和当前占用。
再验证容器能否访问GPU。镜像的CUDA版本应与宿主机驱动兼容，下面的镜像标签仅作示例：
docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi
如果宿主机能看到GPU而容器内看不到，通常是NVIDIA Container Toolkit未安装或未配置。若容器内输出的GPU数量少于宿主机，需检查面板创建容器时的设备配置。
2. 模型文件完整性
模型文件从托管仓库下载到本地后，目录中应包含以下内容：
config.json：模型结构配置。tokenizer.json、tokenizer_config.json。model-00001-of-0000N.safetensors，以及对应的索引文件 model.safetensors.index.json。缺少任何一类文件，推理引擎都会加载失败。分片数量应与索引文件中记录的数量一致。下载完成后建议核对文件大小和校验和，避免因网络中断产生残缺文件。
在面板中部署时，vLLM的启动命令大致如下。参数名以所用版本的官方文档为准，不同版本之间可能改名或废弃。
vllm serve /models/your-27b-code-model \--served-model-name code-model \--port 8000 \--quantization fp8 \--gpu-memory-utilization 0.9 \--tensor-parallel-size 4 \--max-model-len 65536 \--enable-prefix-caching \--enable-auto-tool-choice \--tool-call-parser your-parser-name
下面逐个说明参数的作用和取舍。
模型路径与服务标识
--model（新版本中可直接作为位置参数传入）：本地模型目录。--served-model-name：客户端请求时使用的模型名。统一命名有利于后续切换模型而不改客户端配置。--port：HTTP服务端口。需要与面板的端口映射和反向代理配置保持一致。性能与资源调度
--quantization fp8：以FP8精度加载权重。按每个参数1字节估算，27B参数的权重约占27 GB显存，而BF16约需54 GB，因此量化能明显降低显存压力。FP8需要GPU硬件支持，并且会对输出质量产生影响，需要用自己的业务样本比较量化前后的结果。--gpu-memory-utilization 0.9：vLLM可使用单卡显存的比例，默认值为0.9。这个值越高，留给KV Cache的空间越大，但宿主机上其他服务（如监控、其他容器）的可用空间越小。若同一张卡上还运行其他进程，应适当调低。--tensor-parallel-size 4：将模型切分到4张卡上并行计算。该值必须能整除模型的注意力头数，并且通常要与可用GPU数量一致。张量并行会引入卡间通信，如果卡间互联带宽较低，吞吐提升可能很有限。--max-model-len 65536：单个请求允许的最大上下文长度（以token计）。KV Cache占用的显存随上下文长度近似线性增长，而注意力计算量随长度近似平方增长。设置前应先查阅模型的原生上下文上限，再根据显存容量估算可同时服务的并发数。示例中使用65536，实际取值应按业务需要确定，不宜直接设为模型支持的最大值。推理策略与功能增强
--enable-prefix-caching：缓存相同前缀的KV结果。编程助手常在每次请求中带入相同的系统提示词和项目背景，启用后，这部分计算可以复用，重复请求的首字延迟通常会下降。缓存命中情况需要通过压测对比来确认。--enable-auto-tool-choice 与 --tool-call-parser：开启自动工具调用，并指定与模型输出格式匹配的解析器。解析器名称必须与模型对应，选错时，模型输出的工具调用会被当作普通文本，导致功能失效。--enforce-eager：关闭CUDA Graph等编译优化，以减少启动时间并规避部分算子的编译问题，代价是吞吐通常有所下降。调试阶段可以启用，生产环境应以压测结果决定是否保留。工具调用的安全管控
工具调用让模型能够触发外部操作，因此它是风险最高的一项功能。解析器只负责把模型输出转为结构化数据，并不判断这些操作是否允许执行。建议在部署时同时满足以下要求：
1. 功能测试
在服务启动后，先确认模型列表接口可用：
curl http://localhost:8000/v1/models
然后分别发送普通对话请求、流式输出请求和工具调用请求。检查项包括：响应字段是否符合OpenAI兼容格式，流式输出是否连续且最终正常结束，工具调用的函数名和参数是否为合法JSON，并且与定义的参数类型一致。
2. 性能测试
性能测试需要统一口径，否则不同团队的数据无法比较。建议按以下定义记录指标：
nvidia-smi定时采样获取。压测的参数建议如下：
--max-model-len的一半）三组样本，样本应取自真实业务代码。3. 长稳测试
选取业务目标并发的60%至80%，持续运行数小时。期间观察以下现象：显存占用是否随时间持续上升，服务是否无故重启，失败率是否随时间升高，多卡之间的显存和计算负载是否保持均衡。
4. 结果记录模板
| 测试项 | 硬件与版本 | 并发数 | 输入长度 | TTFT（P50/P95） | 输出吞吐 | 显存峰值 | 失败率 | 测试时长 |
|---|---|---|---|---|---|---|---|---|
| 基线 | 待填写 | 1 | 短 | 待测 | 待测 | 待测 | 待测 | 待测 |
| 压力 | 待填写 | 8 | 中 | 待测 | 待测 | 待测 |