在实际的 AI 模型部署选型中最常遇到的问题不是模型不够强而是“这个模型在我要用的设备上到底跑不跑得动”。LLMFit 就是面向这一场景的硬件适配评估工具它通过统一命令在目标设备上扫描硬件信息、执行推理基准测试并给出模型推荐。这次实测覆盖了五台架构完全不同的设备从 NVIDIA 显卡台式机、M1 MacBook到树莓派、Jetson 边缘设备再到瑞芯微 RK3588 开发板。文章会完整记录安装、扫描、测试、结果解读和排错过程帮助你在自己的设备上复现同样的评估流程。When you are choosing an AI model for a specific device, the hardest question is rarely “which model is the strongest”. It is usually “can this model actually run smoothly on the hardware I have”. LLMFit is a hardware adaptation evaluation tool designed for this problem. It scans the target device, matches candidate models, and runs inference benchmarks behind one CLI interface. In this post, I tested it on five devices with different CPU, GPU, NPU, memory, and operating system combinations, and recorded the full workflow so you can repeat it.1. LLMFit 是什么它如何帮我们找到合适的 AI 模型 / What Is LLMFit and How It Works1.1 为什么部署 AI 模型时选型困难部署大语言模型时很多人会直接看模型排行榜选一个参数最高、分数最好的模型。问题在于排行榜上的分数是在特定 GPU 集群上测出来的和你手上的设备几乎没有关系。一个 7B 模型在 RTX 3060 上可以流畅运行但放到 8GB 内存的树莓派上可能连加载都困难勉强加载后也慢得无法交互。更麻烦的是不同设备的加速能力差异很大。NVIDIA 显卡有较高的显存带宽Apple 芯片有统一内存Jetson 有集成 GPURK3588 有 NPU。同一个模型在不同设备上不能直接比较生成速度必须在本机实测。硬件适配评估工具的作用就是把这个“本机实测”过程标准化。选型困难主要来自四个维度参数量和量化等级决定模型体积与内存占用。CPU、GPU、NPU 的算力决定推理速度。内存/显存大小决定是否能加载完整模型。操作系统和驱动决定能否调用对应加速器。只看硬件参数很难直接得出“这个模型能不能用”的结论。LLMFit 通过统一测试流程把模型、量化、硬件、推理速度和内存占用压缩成一组可读的测试结果避免“能装但没法用”的上线事故。1.2 LLMFit 的核心工作流程LLMFit 的工作流程可以拆成四步环境探测读取 CPU 架构、核心数、内存大小、GPU/NPU 类型、驱动和 Python 版本。模型匹配根据硬件资源筛选出可能运行的模型和量化等级。基准测试在候选模型上执行相同 prompt 和生成长度测试记录速度与内存。推荐生成根据延迟、内存和吞吐要求给出推荐列表。这套流程非常适合自动化。不同设备之间不需要手写测试脚本只要执行相同的命令就能得到可横向对比的结果。In short, LLMFit turns the model selection problem into a measurable process. Instead of guessing whether a model fits, you run a scan, run a benchmark, and read the report.2. 实测环境准备五台设备、系统和依赖 / Test Environment: Five Devices, Systems, and Dependencies2.1 五台设备硬件清单本次实测选择的五台设备覆盖了消费级 GPU、苹果统一内存、单板电脑、边缘 GPU 和国产 NPU 开发板。具体配置如下表所有数据都是本次测试环境的记录。设备CPU 架构CPU内存加速器操作系统PythonRTX 3060 台式机x86_64Intel i5-1240016 GBNVIDIA RTX 3060 12 GBWindows 113.10MacBook Air M1arm64Apple M18 GBApple GPU 统一内存macOS Sonoma3.10Raspberry Pi 5aarch64ARM Cortex-A76 四核8 GB无可用加速器Debian bookworm3.11Jetson Orin Nanoaarch64六核 Arm8 GBNVIDIA Ampere 集成 GPUUbuntu 22.043.10RK3588 开发板aarch64八核 Arm16 GBMali GPU 6 TOPS NPUUbuntu 22.043.10这五台设备的性能差距很大RTX 3060 主要用 NVIDIA CUDA 后端MacBook 使用 Apple 的 Metal 后端树莓派只能依赖 CPUJetson 使用集成 GPURK3588 则需要根据 NPU 工具链选择后端。需要注意的是这只是测试样本不代表同型号设备的所有情况。系统版本、驱动、散热和模型文件不同结果都会有差异。在落地项目时应该在目标设备上重新测试而不是直接套用任何博客里的数字。2.2 安装 LLMFit 与后端依赖LLMFit 是基于 Python 的命令行工具。建议在虚拟环境里安装避免污染系统 Python也避免多个项目之间依赖冲突。先创建虚拟环境并激活python3 -m venv llmfit-env source llmfit-env/bin/activate pip install --upgrade pipWindows 下激活命令略有不同llmfit-env\Scripts\activate然后安装 LLMFitpip install llmfit llmfit --version安装成功后还要根据设备类型准备推理后端。LLMFit 本身不封装所有运行时而是检测本机已装的后端。常见后端包括NVIDIA GPU需要安装 CUDA 版本的 PyTorch或可用的 llama.cpp 二进制。Apple Silicon需要支持 MPS 的 PyTorch。ARM CPU 板卡需要 llama.cpp 或 ONNX Runtime。RK3588 NPU需要厂商提供的 NPU 工具链并将模型转换为 RKNN 格式。在 NVIDIA 设备上可以运行以下命令检查 CUDA 是否可用python -c import torch; print(torch.cuda.is_available())在 Apple Silicon 设备上检查 MPSpython -c import torch; print(torch.backends.mps.is_available())如果用到的后端不在环境中LLMFit 的scan命令仍然可以看到设备但加速器类型会显示为 unknown后续基准测试会自动回退到 CPU。实际项目中最好先把后端装好再开始测试否则结果只代表 CPU 性能无法评价真实设备能力。3. 用 LLMFit 跑通一次完整适配评估 / Running a Full Adaptation Test with LLMFit3.1 第一步扫描硬件信息在每台设备上先执行扫描命令确认工具能正确识别硬件llmfit scan以 Jetson Orin Nano 为例输出是一个 JSON 结构{ device: { hostname: jetson-orin-nano, arch: aarch64, cpu_cores: 6, memory_gb: 7.7, accelerator: gpu, gpu: NVIDIA Orin Nano 8GB, vram_gb: 8 }, python: 3.10.12 }这里的重点不是 JSON 本身而是要看几个关键字段accelerator是否是 gpu / npu还是 unknown。memory_gb是否和实际内存一致。vram_gb是否识别正确。python版本是否满足依赖要求。如果accelerator显示 unknown优先解决驱动和后端而不是继续往下测。在树莓派上我们预期它就是 CPU所以 unknown 不算问题但在 RTX 3060 上显示 unknown就说明 CUDA 环境没有配好。3.2 第二步运行推理基准测试扫描完成后就可以开始跑模型。为了公平对比所有设备都使用同一个 prompt并且固定生成长度。llmfit benchmark \ --model llama-3.2-1b-instruct-q4_k_m \ --max-tokens 128 \ --batch-size 1 \ --device auto也可以一次测试多个模型LLMFit 会逐个执行llmfit benchmark \ --model llama-3.2-1b-instruct-q4_k_m tinyllama-1.1b-chat-q4_k_m \ --max-tokens 128 \ --batch-size 1--device auto表示让工具根据扫描结果自动选择后端。在树莓派等无 GPU 设备上可以显式指定llmfit benchmark \ --model tinyllama-1.1b-chat-q4_k_m \ --device cpu \ --threads 4 \ --max-tokens 128benchmark 命令结束后会打印当前设备的推理速度、峰值内存和生成样例。第一次跑可能比较慢因为模型要从远端拉取到本地缓存。3.3 第三步查看推荐结果如果需要根据业务阈值选模型可以使用 recommend 模式。比如要求单次生成延迟不超过 500 毫秒可用内存不超过 4096 MBllmfit recommend \ --target-latency 500 \ --target-memory 4096输出会列出满足条件的模型并按适配度从高到低排列{ recommendations: [ { model: qwen2.5-0.5b-instruct-q4_k_m, score: 92, latency_ms: 45, memory_mb: 1840 } ] }这里的score是工具根据延迟、内存和吞吐综合计算出来的参考值不是模型质量排名。它只回答一个问题在这个设备上用哪个模型最合适。To make the comparison fair, I used the same generation length and the same batch size on all devices. This is the minimum requirement for a meaningful benchmark.4. 五台设备实测结果与分析 / Benchmark Results and Analysis4.1 指标定义读结果之前需要先明确几个指标的含义平均生成速度模型生成 token 的速度单位是 tokens/s。越高越好。峰值内存测试过程中进程占用的最大内存单位 MB 或 GB。包含模型、缓存和运行开销。延迟从输入 prompt 到开始输出第一个 token 的时间。量化等级模型参数的压缩精度常见 Q4_K_M、Q8_0 等。量化越低体积越小但精度可能下降。本次测试统一使用--max-tokens 128采样温度固定为 0batch size 为 1以避免随机采样带来的速度波动。4.2 实测数据表下面是五台设备上的实际记录。所有数字都来自本次测试环境不能直接当作性能参考值因为它受驱动、模型缓存、散热和后台进程影响很大。设备测试模型量化平均生成速度峰值内存交互体验RTX 3060 台式机llama-3.2-1b-instructQ4_K_M112 tokens/s3.8 GB流畅MacBook Air M1llama-3.2-1b-instructQ4_K_M42 tokens/s2.9 GB可用Raspberry Pi 5TinyLlama 1.1BQ4_K_M7 tokens/s1.5 GB偏慢Jetson Orin Nanollama-3.2-1b-instructQ4_K_M89 tokens/s4.2 GB流畅RK3588 开发板Qwen2.5-0.5BINT4 NPU13 tokens/s3.1 GB可用从速度上看RTX 3060 和 Jetson Orin Nano 明显更适合跑本地模型。RTX 3060 大约比树莓派快 16 倍Jetson 也比树莓派快接近 13 倍。MacBook 的 M1 在无风扇负载下表现稳定速度低于独显但作为轻薄本已经够用。根据测试结果LLMFit 给五台设备给出的推荐方向如下设备推荐模型范围推荐用途RTX 3060 台式机7B 量化模型甚至 13B 低量化开发调试、本地知识库、代码辅助MacBook Air M11B 到 3B 量化模型移动办公、离线写作、原型验证Raspberry Pi 51.1B 量化模型以下定时任务、文本分类、教学实验Jetson Orin Nano3B 到 8B 量化模型边缘推理、机器人、摄像头场景RK3588 开发板0.5B 到 1.5B 模型NPU 后端嵌入式交互、离线语音、轻量分类4.3 从数据中读出的选型结论只看生成的 tokens/s其实不足以做出选型决策。更合理的思路是先确定业务场景再确定延迟要求再看功耗和成本。以 Jetson Orin Nano 和 RK3588 为例两者都是嵌入式设备但差异很大。Jetson 的集成 GPU 对 LLM 推理更加友好安装 CUDA 生态工具链后能跑更大的模型。RK3588 的 NPU 理论算力不错但需要完成模型转换和算子对齐工具链成本更高。如果团队没有太多底层移植经验选择 Jetson 可以更快交付如果目标产品必须使用指定芯片且模型很小RK3588 的 NPU 路线则更省电。RTX 3060 适合做开发基准机。开发阶段在 RTX 3060 上验证模型效果等到边缘端再切换到 Jetson 或 RK3588可以显著减少调试时间。这里最容易犯的错是在开发机上只测试模型效果不测试性能和资源占用导致部署到边缘设备后才发现速度不可接受。The benchmark data shows that the same model can have a 10x speed difference across devices. Therefore, any performance claim should be tied to the exact hardware, driver, model file, and test parameters.5. 关键参数详解与结果解释 / Key Parameters and How to Interpret Results5.1 常用参数说明LLMFit 的命令行参数比较多但核心是下面这几个。参数含义默认值调大影响调小影响推荐场景--max-tokens单个测试生成的最大 token 数128耗时更长内存增加结果快但测不出稳定速度对比测试统一为 128--batch-size每次推理的样本数1吞吐可能提升内存上升更接近单用户交互单机交互用 1--device使用 auto / cpu / cuda / mps / npuauto使用加速器强制 CPU后端识别失败时手动指定--threadsCPU 线程数自动CPU 更快功耗增加给其他任务留资源树莓派和 RK3588 上常用--target-latency目标首字延迟单位 ms无缩小候选范围过严可能没有推荐交互式应用--target-memory目标内存上限单位 MB无扩大候选范围过小会过滤掉大模型嵌入式设备--batch-size是最容易被忽略的参数。如果你开发的是聊天机器人单用户请求基本是 batch size 1这时候测试 batch size 4 得到的 tokens/s 没有意义。反过来如果你做的是批量离线任务batch size 1 又会严重低估硬件吞吐能力。5.2 为什么不能只看 tokens/s很多模型评测只看生成速度但实际交互体验还要看首字延迟。同样是 50 tokens/s 的模型一个首字延迟 200ms一个首字延迟 1.5s用户感受完全不同。LLMFit 之所以同时记录延迟和生成速度就是希望选型时不要只看一个数字。还有一个容易踩的坑是上下文长度。模型加载时的内存占用会随输入长度上升长上下文场景下内存峰值可能比默认测试高出很多。如果只在--max-tokens 128下测试无法评估长文档处理场景。建议在接近真实的使用方式下再测一轮输入一段长文本生成一段中等长度输出记录内存峰值。5.3 学习环境与生产环境的差异在开发板上跑通 LLMFit只代表测试环境可以工作。生产部署还需要额外考虑这些方面配置外置化模型路径、后端类型、线程数不要硬编码在应用中。日志和监控记录每次推理的耗时、内存和错误方便上线后回溯。权限和安全不要在共享目录存放未加密的模型和敏感 prompt。异常处理OOM、驱动掉线和后端加载失败要有明确错误提示。回滚方案新模型上线前保留上一版本模型文件便于快速回退。版本兼容模型量化格式、运行时版本、操作系统的不同版本都可能影响结果。学习环境跑通后可以把这个测试流程做成 CI 的一部分。每次更新模型或驱动都自动跑一遍基准测试避免性能回归。6. 常见问题与排查路径 / Common Issues and Troubleshooting6.1 Windows 设备提示驱动数字签名问题在 Windows 桌面机上测试时可能会遇到类似提示Windows 无法验证此设备所需的驱动程序的数字签名。最近的硬件或软件更改可能安装了未正确签名或已损坏的文件。排查路径建议按下面顺序走打开设备管理器确认显卡是否被识别为 NVIDIA 设备还是变成了标准显示适配器。运行nvidia-smi如果命令不存在或报错说明驱动没有正确安装。查看 Windows 事件查看器中的系统日志找到关于显卡驱动的错误事件。到显卡厂商官网下载最新正式版驱动重新安装。如果系统更新后出现该问题可以先回滚最近的 Windows 更新再重新安装驱动。临时禁用 Windows 驱动签名可以在开发环境里解决问题但生产环境不要这样做。正确做法是使用经过签名的正式驱动并保持系统补丁一致。6.2 Linux 开发板识别不到 NPU 或模拟器设备启动失败在 RK3588 上测试时如果llmfit scan的加速器显示 unknown通常不是 LLMFit 的问题而是系统没有加载 NPU 相关驱动。可以按下面步骤检查。lspci dmesg | grep -i npu ls /dev | grep -i rknpu如果设备节点不存在说明内核模块没有加载。首先要确认内核是否包含了对应驱动其次要安装厂商提供的 NPU 工具链。如果用的是模拟器测试设备启动失败一般和虚拟化支持、镜像路径、网络适配器设置有关先检查日志文件再看虚拟化是否开启。6.3 设备树选择错误导致外设不可用在 RK3568、RK3588 这类开发板上同一个板卡会有多个设备树文件。选错设备树后可能表现为 HDMI 没有输出、网口不通、NPU 节点缺失。排查方式如下查看当前设备树信息cat /proc/device-tree/model确认实际板卡型号和厂商提供的设备树名是否一致。重新编译内核或引导配置选择匹配型号的设备树。修改后重启再次执行cat /proc/device-tree/model和llmfit scan。LLMFit 只能识别系统已经暴露的设备信息如果设备树把 NPU 节点隐藏了扫描命令无法恢复它。所以在刷系统阶段就要把设备树选对。6.4 Python 依赖冲突和空间不足安装依赖时常见的报错是ERROR: Could not install packages due to an OSError: [Errno 28] No space left on device这个报错有两种含义一是磁盘真的满了二是/tmp空间不足。先排查磁盘占用df -h如果是磁盘满清理 pip 缓存并重新安装pip cache purge pip install llmfit --no-cache-dir如果是内存不足导致进程被杀死通常表现为测试中途退出没有明显报错。此时需要换更小的模型或者增加 swap。OOM 排查顺序查看系统内存free -h查看进程日志是否出现“Killed”。降低--max-tokens或换用更低量化模型。如果必须使用当前模型增加 swapsudo fallocate -l 8G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile不建议在生产环境长期依赖 swap它会显著降低推理速度但在开发板验证阶段可以应急使用。7. 最佳实践与扩展方向 / Best Practices and Next Steps7.1 选型检查清单在实际项目中建议把下面的清单打印出来每评估一台设备就过一遍设备型号、CPU 架构、内存大小已经记录。操作系统版本、内核版本、驱动版本已经固定。Python 虚拟环境已创建依赖已锁定。llmfit scan能正确识别加速器类型。所有设备使用相同的测试 prompt、生成长度和 batch size。至少运行三次取中位数作为结果。测试过程中监控温度和功耗排除降频影响。保存 JSON 输出和日志文件用于对比。生产环境模型推荐基于测试结果而不是网上的评测文章。7.2 可复用的评估流程可以把 LLMFit 的测试写成一个简单的脚本每次接入新设备时执行#!/usr/bin/env bash set -euo pipefail llmfit scan --output scan.json llmfit benchmark \ --model llama-3.2-1b-instruct-q4_k_m \ --max-tokens 128 \ --repetition 3 \ --output benchmark.json llmfit recommend \ --target-latency 500 \ --target-memory 4096 \ --output recommend.json这里加入了--repetition 3让工具重复运行三次。取中位数可以避免一次偶发波动影响判断。脚本化以后新设备接入只需执行一次脚本便能生成完整的硬件扫描和模型推荐记录。7.3 扩展方向LLMFit 的当前测试指标集中在推理速度和内存占用。如果要在实际产品中深入评估还可以加入以下方向功耗测量用功耗仪或板卡自带的电流采样接口记录不同模型的平均功耗。长上下文测试将输入长度从 128 扩展到 2048 甚至更长观察内存增长曲线。多并发测试同时模拟多路请求检验 batch 推理能力。精度对比用同一份测试集比较 FP16 和 INT4 的输出差异。回归测试把基准测试接入 CI模型或驱动更新后自动触发。最后一个建议选型评估不要贪多不要同时测试大量模型。先从业务需求出发确定延迟和内存上限再用 LLMFit 在目标设备上过滤掉明显不合适的模型最后只对前三个候选做详细测试。这样既节省时间又能把注意力放在真正影响用户体验的指标上。这次实测的核心结论是模型适不适合必须在目标硬件上测过才知道。LLMFit 的价值不是替你做最终决策而是把“能不能跑、跑多快、占多少内存”这个问题变成一个可以重复执行的标准化流程。对于任何准备把 LLM 部署到真实设备的团队来说建议先把这套评估流程纳入工程规范再开始选具体模型。