1. 问题背景
在本地部署大模型的过程中，我先完成了项目编译，并尝试启用 GPU 加速运行模型。
原本预期是在 Windows 环境下，通过已安装的 CUDA Toolkit 和显卡驱动直接调用 NVIDIA GPU 完成推理，但实际运行时并没有达到预期效果。
在部署和测试过程中，先后出现了以下几个问题：
- 程序无法正确识别 GPU；
- 程序虽然能够检测到显卡，但 GPU 加速无法稳定启用；
- 后续性能测试如果依赖手动操作，测试效率和结果一致性都较差。
因此，我对本地运行环境、CUDA 依赖和测试流程进行了逐步排查与处理。
2. GPU 无法正确识别的问题
2.1 问题现象
在模型完成编译后，程序运行时始终无法正常调用 GPU。
虽然系统中已经安装了 CUDA Toolkit，并且相关环境变量也已配置，但实际构建和运行阶段仍然提示找不到可用的 GPU 环境。
2.2 初步判断
起初，我认为问题可能出在 CUDA 本身，例如：
- CUDA Toolkit 安装不完整；
- 环境变量未生效；
- 显卡驱动版本异常；
- 编译工具链没有正确链接 CUDA 依赖。
因此，我先从这些基础项入手进行检查。
2.3 排查过程
为定位问题，我依次检查了以下内容：
- NVIDIA 显卡驱动是否正常；
- CUDA 工具链是否可用；
- 终端环境是否能够正确访问系统路径；
- 编译和运行时调用的系统目录是否一致。
在排查过程中，我发现问题并不在 CUDA 本身，而在当前使用的 Developer PowerShell 环境。
该终端与系统实际环境之间存在位数访问差异，导致在访问系统目录时发生了重定向。这样一来，程序虽然在终端中执行正常，但在调用与 NVIDIA 相关的系统组件时，并没有访问到正确的 64 位目录，因此无法完成 GPU 环境识别。
2.4 处理结果
确认问题来源后，我通过指定正确路径重新验证了显卡工具和相关依赖的可用性，最终定位并解决了"无法识别 GPU"的问题。
3. GPU 加速无法稳定启用的问题
3.1 问题现象
在解决了 GPU 无法识别的问题后，程序已经能够检测到显卡，编译过程也可以正常完成。
但是，在实际运行阶段，GPU 加速仍然无法稳定启用，最终出现了 GPU kernel 启动失败 的问题。
3.2 原因分析
继续排查后，我发现该问题主要与以下因素有关：
- CUDA 版本与显卡驱动之间的兼容性；
- 运行时依赖加载不完整；
- 本机环境下 CUDA 相关组件之间存在版本不匹配问题。
也就是说，程序虽然已经能够"看到"GPU，但在真正调用 CUDA 运行环境执行推理时，依赖链并不稳定，因此导致 GPU kernel 无法正常启动。
3.3 处理结果
在当前机器环境下，这一问题暂时没有完全解决。
最终，该模型只能先以 CPU 模式 运行，以保证后续功能验证和性能测试能够继续进行。
这一过程也说明：
能够识别显卡，并不等于能够稳定使用 GPU 完成推理。
4. 性能测试流程效率低的问题
4.1 问题现象
在模型可以基本运行之后，新的问题转向了测试流程本身。
由于后续需要进行多组性能测试，如果继续采用手动输入提示词、逐条记录输出结果的方式，会带来两个明显问题：
- 测试效率较低；
- 不同轮次之间难以保证输入格式和记录方式一致。
这会直接影响性能数据的可靠性，也不利于后续统计分析。
4.2 解决方法
为提高测试效率并保证测试过程统一，我编写了一个批量测试脚本 measure_latency.py。
该脚本的主要功能包括：
- 自动读取当前目录下的
input.txt文件； - 将文件中的每一行内容作为一组独立输入；
- 逐组提交给本地模型进行推理；
- 自动记录关键性能指标。
4.3 输出结果
脚本执行完成后，可以自动生成测试结果文件，并记录以下指标：
ttft_ms：首字延迟；tpot_ms：平均每个 token 的生成时间；e2e_ms：完整输出的端到端耗时。
通过这种方式，后续的多组测试可以在统一流程下完成，既提高了效率，也便于后续整理数据和撰写实验报告。
5. 过程总结
通过这次本地部署和测试，我对大模型运行环境的实际问题有了更具体的认识。
首先，编译成功并不代表运行环境已经完全正确 。
在 Windows 平台下，终端环境、系统目录访问方式、CUDA 版本、驱动依赖和运行时加载路径，都可能影响模型是否能够真正调用 GPU。
其次，在实际测试中，除了运行环境本身，测试流程是否规范 同样重要。
如果没有统一的输入和记录方式，即使模型能够运行，也难以得到可靠的性能数据。
因此，这次工作的收获不仅是完成了本地部署，更重要的是建立了一个相对规范的问题排查思路和性能测试流程，为后续继续优化部署环境和开展系统化实验打下了基础。