犀牛派 X1 实战：使用 Ollama 部署 Qwen 1.8B，附 API 参数与性能实测

[2501_94462299]

 

本文记录在犀牛派 X1 上通过 Ollama 部署 qwen:1.8b 的完整过程，并使用 Ollama API 测试模型加载时间、输入速度、输出速度和 CPU 占用。文章最后还会分析中文提示词乱码、首轮加载时间和上下文长度带来的影响。

一、测试目标

犀牛派 X1 本身具备较强的边缘计算能力，除了使用 QNN、AidGen 等方案调用 NPU，也可以通过 Ollama 快速运行 GGUF 格式的大语言模型。

这次主要验证以下几个问题：

1. 犀牛派 X1 能否直接运行 Qwen 1.8B；
2. Ollama 部署和调用是否足够简单；
3. 模型实际的输入、输出速度如何；
4. temperature、top_p、num_ctx 等参数怎样设置；
5. 推理过程中使用的是 CPU、GPU 还是 NPU；
6. 中文提示词乱码时应该如何排查。

二、测试环境

本次测试环境如下：

项目	配置
开发板	犀牛派 X1
系统	Ubuntu 22.04 / AidLux Linux 环境
推理工具	Ollama
模型名称	qwen:1.8b
模型架构	Qwen2
参数规模	1.84B
模型格式	GGUF V3
量化方式	Q4_0
模型大小	约 1.04 GiB
测试上下文	4096 tokens
最大生成长度	128 tokens

从加载日志看，Ollama 实际加载的模型名称为 Qwen2-beta-1_8B-Chat，参数量约 1.84B。虽然 Ollama 中的标签是 qwen:1.8b，但做严谨测评时，建议同时记录模型摘要、量化类型和文件摘要，避免同名标签更新后无法复现结果。

可以使用以下命令查看模型信息：

ollama list
ollama show qwen:1.8b
ollama show --modelfile qwen:1.8b

三、下载并运行 Qwen 1.8B

直接执行：

ollama run qwen:1.8b

如果本地没有模型，Ollama 会自动拉取模型清单和权重文件。本次下载的主要模型层约为 1.1GB，下载完成后会校验 SHA256，并自动进入交互式对话界面。

 

 

在交互界面输入：

hello

模型可以正常返回英文回答，说明模型下载、解析和基础推理链路已经跑通。

如果 Ollama 服务没有启动，可以在另一个终端执行：

ollama serve

查看当前加载的模型：

ollama ps

四、模型加载日志分析

模型首次运行时，Ollama 会输出 GGUF 元数据、模型架构、量化方式、上下文长度以及内存缓冲区等信息。

 

从日志可以提取出几个有价值的数据：

architecture  = qwen2
model params  = 1.84 B
model size    = 1.04 GiB
model ftype   = Q4_0
n_ctx_train   = 32768
n_ctx         = 4096
CPU buffer    = 1062.67 MiB
KV cache      = 768.00 MiB
compute buffer= 300.75 MiB

模型训练时支持的上下文上限为 32768，但这次实际只分配了 4096。对于 1.8B 模型和边缘设备来说，这是一个更均衡的设置。

从日志估算，仅模型、KV Cache 和计算缓冲区就需要约：

1062.67 + 768.00 + 300.75 ≈ 2131.42 MiB

此外还需要 Ollama 进程、系统组件和其他临时缓冲区，因此实际可用内存不能只按 1.04GiB 的模型文件大小计算。

五、使用 Ollama API 测试性能

Ollama 默认监听：

http://127.0.0.1:11434

为了方便解析返回的 JSON，先安装 jq：

sudo apt install -y jq

使用下面的命令测试：

curl -s http://127.0.0.1:11434/api/generate \
  -d '{
    "model": "qwen:1.8b",
    "prompt": "请用100字解释什么是边缘计算。",
    "stream": false,
    "keep_alive": "10m",
    "options": {
      "temperature": 0.2,
      "top_p": 0.9,
      "top_k": 40,
      "repeat_penalty": 1.1,
      "seed": 42,
      "num_predict": 128,
      "num_ctx": 4096
    }
  }' | jq '{
    response,
    total_seconds: (.total_duration / 1000000000),
    load_seconds: (.load_duration / 1000000000),
    prompt_tokens: .prompt_eval_count,
    prompt_tokens_per_second:
      (.prompt_eval_count / (.prompt_eval_duration / 1000000000)),
    output_tokens: .eval_count,
    output_tokens_per_second:
      (.eval_count / (.eval_duration / 1000000000))
  }'

其中必须设置：

"stream": false

这样才能在一次完整响应中读取计数和耗时字段。

 

 

六、实测结果

本次得到的数据如下：

指标	实测结果
总耗时	22.669 秒
模型加载时间	2.274 秒
输入 Token 数	37
输入处理速度	9.325 token/s
输出 Token 数	128
输出生成速度	7.792 token/s

按照输出速度计算，128个输出 Token 的纯生成时间大约为：

128 ÷ 7.792 ≈ 16.43 秒

输入处理时间约为：

37 ÷ 9.325 ≈ 3.97 秒

加上约2.27秒模型加载时间，基本能与22.67秒的总耗时对应起来。

如果把模型提前预热并通过 keep_alive 保持在内存中，后续请求通常可以省去大部分加载时间。因此测试时最好把“冷启动”和“热启动”分开记录：

• 冷启动：包含模型加载，体现首次请求等待时间；
• 热启动：模型已经驻留内存，更适合评价持续服务能力。

需要注意，本次 eval_count 正好等于 num_predict=128，说明回答很可能触及了最大输出限制。对回答完整性进行测试时，可以改成256或512。

七、资源占用情况

推理期间，系统监控中多个 CPU 核心负载明显上升，部分核心一度接近100%，CPU 总占用也达到较高水平。

结合模型日志中的 CPU buffer、CPU KV buffer 和 CPU compute buffer 可以判断，本次 Ollama 测试主要使用 CPU 推理。截图中没有观察到与推理负载相匹配的 NPU 使用变化。

这也是 Ollama 与 QNN/AidGen 部署路线的主要差别：

• Ollama：模型获取和API调用非常方便，适合快速验证、开发原型和兼容 OpenAI 风格的应用；
• QNN/AidGen：部署步骤更多，但可以针对高通 NPU 进行加速，更适合追求功耗和推理性能的端侧应用。

因此，7.79 token/s 应理解为本次 Ollama CPU 路线的实测结果，不能代表犀牛派 X1 NPU 的性能上限。

八、常用参数如何设置

参数	作用	建议测试范围
temperature	控制随机性，越高越发散	0、0.2、0.6、0.9
top_p	保留累计概率范围内的候选词	0.8～0.95
top_k	每一步保留概率最高的K个词	20～80
min_p	过滤相对概率过低的候选词	0～0.1
repeat_penalty	抑制重复内容	1.0～1.2
repeat_last_n	检查重复时回看的Token数量	64～256
seed	固定随机种子，便于重复实验	42
num_predict	最大输出Token数量	128～512
num_ctx	上下文窗口大小	2048、4096、8192

技术问答可以从下面这组配置开始：

{
  "temperature": 0.2,
  "top_p": 0.85,
  "top_k": 30,
  "repeat_penalty": 1.1,
  "seed": 42,
  "num_predict": 256,
  "num_ctx": 4096
}

创意写作可以适当提高随机性：

{
  "temperature": 0.9,
  "top_p": 0.95,
  "top_k": 80,
  "repeat_penalty": 1.05
}

做参数对比时不要同时修改所有参数。推荐顺序是：

1. 固定提示词、seed、上下文和输出长度；
2. 单独测试不同 temperature；
3. 再测试 top_p 与 top_k；
4. 最后测试不同 num_ctx 带来的内存和速度变化；
5. 每组至少运行3次，第一次作为预热，后两次计算平均值。

九、踩坑：中文提示词出现乱码

本次截图中，终端里的中文提示词已经出现乱码，而模型回答的内容变成了“100xOHP图像处理系统”，与“解释边缘计算”的原始问题无关。

因此应当把结果拆开看：

• Token速度、加载时间等性能数据仍然有效；
• 这一次的回答内容不能用于评价模型的中文理解质量。

先检查系统区域设置：

locale

建议确保至少包含：

LANG=zh_CN.UTF-8
LC_CTYPE=zh_CN.UTF-8

如果系统没有中文UTF-8区域，可以安装并生成：

sudo apt install -y locales
sudo locale-gen zh_CN.UTF-8

临时设置当前终端：

export LANG=zh_CN.UTF-8
export LC_ALL=zh_CN.UTF-8

更稳妥的方式是通过 UTF-8 编码的 Python 程序发送请求，避免远程桌面、剪贴板和终端共同参与字符转换：

python3 - <<'PY'
import json
import urllib.request

payload = {
    "model": "qwen:1.8b",
    "prompt": "请用100字解释什么是边缘计算。",
    "stream": False,
    "options": {
        "temperature": 0.2,
        "seed": 42,
        "num_predict": 128,
        "num_ctx": 4096,
    },
}

request = urllib.request.Request(
    "http://127.0.0.1:11434/api/generate",
    data=json.dumps(payload, ensure_ascii=False).encode("utf-8"),
    headers={"Content-Type": "application/json; charset=utf-8"},
)

with urllib.request.urlopen(request, timeout=300) as response:
    result = json.load(response)

print(result["response"])
PY

如果这段程序可以得到正常中文回答，而直接粘贴 curl 命令仍然乱码，问题就在终端或远程剪贴板，而不是模型本身。

十、进一步测试建议

后续可以围绕以下方向继续测评：

1. 对比 num_ctx=2048/4096/8192 时的内存占用；
2. 对比 Q4_0、Q4_K_M、Q5_K_M 等不同量化版本；
3. 连续运行10轮，观察温度、降频和速度波动；
4. 对比冷启动和模型常驻内存后的首字延迟；
5. 与同参数量的其他模型进行中文、代码和逻辑题测试；
6. 将 Ollama CPU 路线与 AidGen/QNN NPU 路线进行横向对比。

十一、总结

本次在犀牛派 X1 上成功通过 Ollama 部署并运行了 Qwen 1.8B Q4_0 模型。部署体验比较简单，模型下载完成后即可通过命令行或 HTTP API 调用。

在 num_ctx=4096、最大输出128 Token 的条件下，本次实测结果为：

• 输入处理速度约 9.33 token/s；
• 输出生成速度约 7.79 token/s；
• 冷启动总耗时约 22.67秒；
• 模型加载约2.27秒；
• 推理期间 CPU 负载较高。

如果目标是快速搭建本地聊天、验证接口或开发应用原型，Ollama 很方便；如果目标是充分利用犀牛派 X1 的高通 NPU，则应继续测试 QNN/AidGen 方案。

参考资料

• Ollama Generate API
• Ollama Modelfile 参数说明
• Ollama CLI 文档

---

推荐 CSDN 标签： 犀牛派X1、Ollama、Qwen、边缘计算、大模型部署、嵌入式AI