LLM on Zesean 的博客

聆行 VoxDrive — 分布式车载智能座舱（RK3588 + Jetson Orin 双板）

Fri, 04 Sep 2026 23:50:00 +0800

项目概述

聆行 VoxDrive 是一套跑在真实硬件上的双 SoC 分布式车载智能座舱：

RK3588（LubanCat-4）= 媒体 + 端侧语音节点：摄像头采集 → MPP 硬件编码 → MP4 循环存储 / RTMP 推流，NPU 跑行人/车辆检测做事件锁录；流式 ASR（fp16 三模型 NPU 分载）与 TTS 合成（SummerTTS）也都落在这块板；
Jetson Orin Nano = 中心 AI 节点：LLM / RAG / 意图路由 / 画面问答 / Qt 数字座舱，全离线、不上云；
两板以太网互联：视频走 RTMP，控制与事件走 ZeroMQ。语音可以控制录像、查状态、抓拍，还能直接问"画面里有什么"（VLM 看行车画面作答）；
麦克风与音箱是接在 RK 上的同一 USB 设备：说话本板识别、跨板查询、应答本板播报，播报期自动静音防"自己听到自己"（回灌）。

设计原则：数据密集走专用加速器（RK 的 VPU/RGA/NPU），模型密集走中心算力（Jetson 的 GPU）；实时敏感、算力可承担的小模型（ASR/TTS）下沉边缘，大模型（LLM/VLM）留中心。

双板实物

左上 Jetson Orin Nano（带散热扇），右侧 RK3588 LubanCat-4，两板经路由器以太网互联；左下 7 寸 DSI 触摸屏接 RK，正在运行座舱 UI 的桌面会话；麦克风/音箱 USB 组合设备接 RK 侧：

系统架构

flowchart LR
 subgraph RK ["RK3588 · 媒体节点 + 语音推理节点"]
 CAM["IMX415
MIPI CSI"] --> ISP["rkisp
NV12 1080p"]
 ISP --> ENC["MPP H.264 硬编
VBR · 零 CPU 软编"]
 ENC --> MP4["MP4 分段循环存储
水位覆盖 · 事件锁录"]
 ENC --> RTMP["RTMP 推流
断流自动重连"]
 NPU["RKNPU
YOLOv5s INT8"] -->|"行人/车辆检测"| MP4
 SVC["recorder_service
REP :6700 / PUB :6701"]
 MP4 --- SVC
 RTMP --- SVC
 MIC["USB 组合设备
麦克风+音箱"] --- VS
 VS["voice_service
NPU×3 流式解码"] -->|"识别文本"| ROUTER
 TN["tts_node
SummerTTS 多核
本板播报"] -.->|"合成请求"| TTS
 end
 subgraph JS ["Jetson Orin · 中心算力节点"]
 MM["mediamtx
RTMP/RTSP/HLS"] --> UI["Qt 数字座舱
预览 · 状态 · 告警"]
 VLMQ["画面问答"] -.->|"vlm 直通"| VLM["vlm_service
Qwen2-VL-2B"]
 VLM -.->|"抓帧 :6700"| SVC
 ROUTER["意图路由"] --> LLM["LLM
Qwen2.5-1.5B"]
 ROUTER --> RAG["RAG
真实车主手册"]
 ROUTER --> TB["Tool Bus"]
 TB --> TTS["TTS 网关
REQ :6720"]
 LLM --> TB
 end
 RTMP -->|"视频流"| MM
 TB <-->|"REQ :6700
状态/抓拍/开关 (RTT 2ms)"| SVC
 SVC -->|"PUB :6701
水位/断流/检测事件"| UI

两个平面刻意分开：视频大流量不进控制面，控制面单条消息只有几百字节——跨板工具往返实测 0.73-2ms。语音链同理：音频采集、识别、合成、播报都在 RK 本板，跨板只传识别文本与应答文本两条轻量通道。

真机实拍（RK3588 7 寸触摸屏，真屏拍摄）

行车记录页：左侧 mediamtx 拉流的实时预览（断流自动重连），右侧状态卡轮询 RK（帧率/段数/磁盘水位环）+ 实时事件日志，底部按钮经 tool_bus 直控真设备；语音气泡「你：打开行车记录」是刚说完一句语音导航后 UI 的回显：

主页磁贴：录像状态横条（30.0fps / 138 段 / 5.8GB 可用）与四张磁贴的数据全部来自跨板实时链路，无一张静态图：

行车记录仪原始画质参考（IMX415 直出 1080p 快照，RK 端 NV12→JPEG、跨板抓拍约 0.15s）：

车控页 + 语音上屏（Jetson 侧实例同款界面）：问"现在录着吗"走真实链路（识别 → 路由 → 跨板查询 → LLM 组织 → TTS），底栏字幕是用户原话、气泡是基于真实工具应答生成的播报：

行车记录视频链路（RK3588）

flowchart LR
 A["IMX415
RAW Bayer"] -->|MIPI CSI-2| B["rkcif → rkisp
3A/格式"]
 B -->|NV12| C["V4L2 用户态
mmap 4 缓冲 + DMA-BUF"]
 C --> D["MPP H.264
NV12 直入 · VBR"]
 D --> E["Mp4SegmentSink
I 帧边界滚动分段"]
 D --> F["RtmpSink
flv + extradata"]
 C -.每 30 帧.-> G["最新帧槽"]
 G --> H["RGA → RKNN
YOLOv5s INT8 · NPU"]
 H -->|"命中行人/车辆"| E

几个值得说的实现细节：

NV12 同制式直入 MPP：ISP 出的 NV12 不做格式转换直接编码（全链路 CPU ~2.8%），RGA 只用于检测前处理的缩放；
MP4 分段的坑：movenc 不代转 Annex-B，需逐 NAL 转 AVCC 并手工组装 avcC；NAL 边界 off-by-one 的症状是"时长正常但解码全错"——验收判据用逐段全量解码而非 duration；
事件锁录：检测线程经"最新帧槽"旁路挂接（忙时覆盖、不反压主管线），命中即给当前段加 LOCK_ 前缀，循环覆盖天然豁免，另有配额防锁段吃满磁盘；
rkisp 残留态：boot 残留下 S_FMT 原样传回会得到行距矛盾的布局（SEGV/无帧），修复=清零强制重算 + 读回几何校验。

端侧语音闭环（推理与音频 I/O 都在 RK，LLM 留 Jetson）

语音链的形态一句话：音频不出板，跨板只传文本。麦克风/音箱（同一 USB 设备）接 RK——voice_service 进程内采集 16k PCM → kaldi-native-fbank 特征（与 sherpa C++ 前端逐位一致）→ zipformer 三模型 fp16 NPU 三核分载流式解码 → 识别文本 REQ 回 Jetson 意图路由 → 应答文本回到 RK 的 tts_node（SummerTTS 多核合成）→ 本板播报。

防回灌：麦克风和音箱是同一块硬件，播报期做事件驱动静音，解除须等 play_end 后麦克风连续 1s 真实静音（+超时兜底）；
ASR 选 fp16 而非 int8：INT8 全套量化精度分析实测不满足流式精度（状态累积崩溃），fp16 零量化损失且 RTF 0.3 以内；TTS 评估 matcha RKNN 路线后放弃（声码器输出 STFT 谱需宿主 ISTFT，NPU 图不适用），改用 SummerTTS 引擎源码上板编译——真麦声学自环实测识别逐字正确、无循环。

Jetson 侧保留三个关键架构决策：

真设备域确定性直通。1.5B 小模型在 7 个工具间选择实测不可靠（“关闭预览"被选成关车窗、“还剩多少存储"选成编数），改为关键词命中即直达跨板工具、LLM 只把真实结果组织成播报——控制类链路降到 0.43s。
语义双路路由。规则通路兜底 + 语义通路（离线意图中心余弦，阈值留出探针校准）：关键词全 miss 的改述问句直接走 RAG 快路径，9.4s → 1.2s；语义通路故障自动退化为规则单路。
推理位置按实时性分层。ASR/TTS 下沉边缘 NPU/CPU，LLM/RAG 留中心——判据是"实时敏感 × 算力可承担”，不是无脑把模型搬到一块板。

RAG 语料是真实车主手册（官网 PDF → 三级过滤 → 577 块向量库，板上构建），召回阈值 0.48 由"手册内改述句 vs 手册外噪声"的相似度实测分界定出。

座舱 UI 双端部署（RK 触摸屏）

同一套 dashboard 代码不改一行，配置切换跑在两种形态：

Jetson 桌面与 RK 7 寸 DSI 触摸屏（1024×600，Goodix 触摸）各跑一个实例，双端同时在线、订阅同一套 ZMQ 数据源——UI 是纯客户端，换屏只是多一个实例，服务端拓扑零变化；
小屏自适应：可用几何过小时自动最大化 + X 级缩放 1.5625× 到 1600×938 逻辑设计尺寸（Qt 自带 QT_SCALE_FACTOR 在本板组合上首帧后冻结，实测弃用）；
真机闭环已验证：说"打开行车记录”→ RK 触摸屏切页并自动拉起 RTSP 预览，画面色彩正确、跨屏数据实时。

实测数据

所有数字可复述测量方法，无估算值：

指标	实测值
采集（IMX415 → NV12 1080p）	30.0fps，max 帧间距 33ms（驱动时间戳，120 帧）
MPP H.264 硬编	延迟 avg 4.8 / max 8.5ms，全链路 CPU ~2.8%（单核）
跨板拉流（RK→Jetson mediamtx）	1080p30 全量解码零错误（30.2s），静态场景 VBR 下探 0.71Mbps
跨板控制面（ZMQ REQ）	RTT 2ms（路由器组网）；直连组网复测 avg 0.73ms（0.64-0.83，n=20）；抓拍 143ms（含 JPEG 编码 + 183KB base64 跨板）
RKNN 事件锁录检测	推理 25.3ms ewma（NPU core0），检测线程挂接下录像 30fps 无损；连续 1.5h+ 录像 ewma 26.2ms / 5154 次
语音闭环全程（文本入口→播报结束）	3.55-5.47s（LLM 组织 0.86-1.07s 为大头，跨板工具仅 2-10ms）；修复回灌级联后干净口径：router 应答 1.49-4.14s，→播报结束 7.0-17.9s（=答复文本+合成+实时音频时长，随答复长度自洽）
ASR 推理（RK NPU fp16 三模型分核）	RTF 0.26-0.30（10.1s 中英混复测 0.296），线上流式转写与 Jetson ORT fp32 贪心逐字一致；前端特征与 sherpa C++ 逐位一致（对拍 maxabs=0）
TTS 合成（RK SummerTTS 多核 CPU）	RTF 0.22-0.27（7 字句 0.63s、28 字句 1.47s），合成 PCM 回传播放时长精确吻合
VLM 画面问答（Qwen2-VL-2B，按需换出 llm）	应答与画面实测一致；周期=快照 0.35s+推理 4.7s+恢复 14.9s（冷启动 ~25-30s）；GPU 铁律=共存 OOM/须 evict 页缓存/ctx 2048+图降采样 960×540
真麦声学闭环（USB 组合设备）	播命令→空气→麦克风→NPU 识别逐字正确→真数据应答→本板播报+防回灌静音→无循环
LLM	Qwen2.5-1.5B Q4_K_M，22.8 token/s（首测）；第三轮复测 20.5-21.0 token/s（llama.cpp 纯生成口径 ×3，全栈在线）
长稳	16min 双板联跑 fps 稳定 30.00、29417 帧零异常；故障注入 5s 精确超时自愈；第三轮复测时已连续录像 1.5h+（154k 帧） 30.001fps、RTMP 零写错误
回归验证	2026-09-06 第二轮全量验证全绿：RK 5/5 + Jetson selftest 8/8 + 回归 4/4×2 + E2E 抽查（RTSP 90 帧零错误/色度中性、HLS、跨板语音查询含真实值 rtt 1.6-2.2s、跨板抓拍 123ms）；同日傍晚第三轮性能复测（跨板 RTT/LLM/RAG 208-280ms/ASR/TTS/E2E 全栈在线全项重测）

五个实战排障叙事

比数字更有意思的是踩坑（每条都有一手证据链）：

RKNN「流式状态发散」— 症状像量化精度，根因是内存布局。zipformer 转 RKNN 后流式解码首块全对、之后结构性错乱（值集不变、位置全乱），INT8/fp16 同症状——直觉会怪量化或图编译。真因是 RKNN 对 4D 图输入的布局约定：缓存张量必须按 transpose(0,2,3,1) 预转置喂入。定位：探针模型 chunk 级逐张量对账 → 周期标记指纹排除数值精度 → 4D 直通 tiny 图暴力解出唯一转置；修复后转写与 fp32 逐字一致。教训：多输入非图像模型上 NPU，先做直通等价自测。
ZMQ linger 默认无限：对端进程死亡时，客户端析构带着未投递消息永久阻塞，工具总线整体楔死。没有 gdb 条件，靠 /proc/<pid>/wchan + 残留 context 线程定位；修复 linger=0 + EINTR 重试后，故障注入 5s 精确超时、恢复即自愈。
1.5B 选错工具：LLM 自由选工具实测不可靠（关预览→关车窗），改成"关键词直通执行 + LLM 仅组织结果"——把确定性还给代码，把语言能力留给模型。
rkisp 残留态：S_FMT 原样传回残留行距，驱动照收但布局自相矛盾，症状是段错误 + 无帧。教训：不信任驱动的"照单全收"，写入前清零重算、读回后几何校验。
防回灌静音窗口被"事件语义差"击穿：E2E 对账发现播报结束时间异常，排查见扬声器播的回答被自家麦克风识别、级联出新查询。根因是跨板事件语义差：Jetson 的 play_end 是"合成+写入完成"（12s 音频 2.9s 就发出），而播报在 RK 实时进行——静音在"写完"后 0.6s 就解除，长答复播到一半麦克风听到自己的声音。修复=静音期顺带能量观测，解除改为 play_end 后麦克风连续 1s 真实静音；同场景对比级联 3 次 → 0 次。教训：跨板系统的"同名词事件"未必同语义，端到端对账日志是最好的透视镜。

与站内其他项目的关系

车载 AI 语音助手（Jetson）：本项目的 Jetson 侧前身，七服务架构与音频链路由它收编重构而来；
X 射线焊缝检测下位机：另一条嵌入式线（STM32 + FreeRTOS）。

车载 AI 语音助手（Jetson Orin Nano）

Tue, 01 Sep 2026 14:00:00 +0800

项目概述

基于 NVIDIA Jetson Orin Nano 的端侧车辆 AI 语音助手：说话→听懂→思考→执行→回答全链路在车端本地完成，不依赖云端。集成 ASR-TTS 语音交互、意图路由、RAG 车辆知识库、LLM/Tool 调用与 QT 数字座舱界面，实现车辆知识问答、车控工具调用与 GUI 展示。

各服务模块采用 ZeroMQ 轻量级通信框架，实现松耦合的分布式多服务架构。

系统架构

系统拆分为 ASR、Intent Router、RAG、LLM、Tool Bus、TTS、QT UI 七个模块，模块间通过 ZMQ 的 REQ/REP + PUB/SUB 组合，实现请求应答、状态广播、状态同步三种通信模式。

以一句「帮我把空调调到 24 度」为例的完整链路：

flowchart LR
 MIC["麦克风"] --> VAD["VAD / 关键词唤醒"]
 VAD --> ASR["ASR 语音识别
sherpa-onnx zipformer"]
 ASR --> IR["意图路由
语义分类 + 规则分类"]
 IR -->|"车控意图"| LLM["LLM
Qwen2.5-3B Q4_K_M"]
 IR -->|"知识问答"| RAG["RAG 检索
车辆手册向量库"]
 RAG --> LLM
 LLM -->|"tool_call JSON"| TOOL["Tool Bus
车控工具执行"]
 LLM -->|"respond JSON"| TTS["TTS 播报
SummerTTS"]
 TOOL -->|"状态同步"| UI["QT 座舱 UI"]
 TTS --> OUT["扬声器"]

关键技术点

AI 语音交互：ASR 使用 sherpa-onnx 部署 zipformer 模型，TTS 基于 SummerTTS；设计了 ASR 与 TTS 的同步机制，避免 TTS 播放期间语音回灌误识别；构建 VAD 与关键词唤醒
意图路由：语义分类 + 规则分类双通路融合的意图识别，编排 5 类服务调用，按意图选择 RAG 检索、LLM 调用、直接语音回复或 Tool 调用的组合
RAG 车辆知识库：基于 sentence-transformers 将车辆手册向量化，余弦相似度 + Top-K 检索，端侧全离线完成知识问答
LLM 部署与 Tool 调用：llama.cpp 部署 Qwen2.5-3B 的 GGUF Q4_K_M 量化模型；通过 prompt 强约束让模型只输出两类 JSON——respond 交给 TTS 播放，tool_call 驱动车控工具执行
QT 车载座舱 GUI：数字座舱界面，实时展示空调、车窗、天窗、摄像头与传感器等车辆状态

核心 API 与接口设计

服务端口与通信原语

服务	端口	协议
Intent Router	:6666	ZMQ REQ/REP
RAG Service	:6667	ZMQ REQ/REP
LLM Service	:6668	ZMQ REQ/REP
Tool Bus	:6669	ZMQ REQ/REP
状态广播	:6670 / :6671	ZMQ PUB/SUB
TTS Server	:7777	音频流
llama-server（GGUF 推理后端）	:8080	HTTP

C++ 侧封装了 ZmqServer / ZmqClient（REQ/REP 请求应答）与 ZmqPub / ZmqSub（状态广播）两组通用组件，各服务只依赖消息契约、不依赖彼此实现。

意图路由：五分类多分支

Router 对每句输入做语义分类 + 规则分类双通路融合，输出五类意图并按类型路由到不同服务链：

意图	链路	典型时延
EMERGENCY（紧急事项）	RAG → TTS	~0.5s
FACTUAL（手册事实问答）	RAG → TTS	~0.5s
EXPLICIT_CMD（明确车控指令）	Tool Bus → TTS	~0.5s
COMPLEX（复杂查询）	RAG → LLM → TTS	秒级
CREATIVE（闲聊/生成）	LLM → TTS	秒级
LLM + Tool 闭环	LLM ↔ Tool → LLM → TTS	秒级

LLM 双模式 JSON 契约

通过 Prompt 强约束 LLM 只输出两类 JSON，这是「语音语义 → 车辆动作」的核心契约：

1
2
3
4
5
6
7


{"action": "respond", "content": "好的，已为您将空调调到 24 度"}

{"action": "tool_call",
 "tool": "ac",
 "tool_action": "set_temperature",
 "params": {"value": 24},
 "reason": "用户要求把空调调到 24 度"}

respond → 直接送 TTS 播报
tool_call → Tool Bus 侧做参数归一化与校验（例如从口语化文本中提取「24 度」的数值），执行后通过 PUB 通道把车辆状态同步给 QT 座舱，并把执行结果回灌 LLM 生成自然语言回复
无法归一化的输出会降级为 respond 兜底，保证任何情况下用户都能得到语音反馈

RAG 检索接口

车辆手册切片后经 sentence-transformers 编码为 768 维向量入库；查询时同模型编码 query → 余弦相似度 Top-K 检索 → 命中文档拼接进 LLM 上下文，全部在端侧离线完成。

项目状态

全链路已在 Jetson Orin Nano 上跑通，端侧离线完成语音到车控的闭环。

端侧大模型在线/离线部署（Agent）——机器人项目迁移实战（三）

Sat, 15 Aug 2026 14:00:00 +0800

在 Jetson Orin Nano 上部署大语言模型（LLM）是实现端侧大模型 Agent 的第一步，也是最核心的工程挑战。由于 Jetson 采用的是统一内存架构（Unified Memory Architecture），CPU 和 GPU 共享物理内存（4GB 或 8GB），这与传统 PC 的“内存+独立显存”有很大不同。在 Orin Nano 上，我们必须精细控制内存预算，防止系统因 OOM（Out of Memory）而崩溃。

针对子任务 3.1（离线版 - LLM 推理），从瑞芯微 RK 平台迁移到 NVIDIA Jetson 平台，我们需要将原有的 RKNN 链路彻底重构为 NVIDIA 生态的加速链路。

子任务 3.1 拆解：端侧 LLM 部署实施方案

✅️微任务 3.1.1：Jetson 硬件环境准备与 Swap 空间配置

目标：解决 Orin Nano 在模型编译或高负载时内存不足的问题。
具体步骤：

1.确认 JetPack 版本（推荐使用 JetPack 6.x，自带 CUDA 12.x 和更现代的 Linux 内核）。

1
2


#jtop查看板卡信息
jtop

2.必须配置虚拟内存（Swap）：Orin Nano 即使是 8GB 版本，在编译模型或运行 4B 模型时也极易耗尽物理内存。建议通过 NVMe SSD 划分 16GB 的 Swap 空间。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


#查看内存和SWAP
free -h
#查看磁盘
lsblk
#创建swap
sudo fallocate -l 16G /swapfile
#设置权限
sudo chmod 600 /swapfile
#验证
ls -lh /swapfile
#格式化swap
sudo mkswap /swapfile
#启用swap
sudo swapon /swapfile
#插看swap
swapon --show & free -h
#开机自动挂载
sudo nano /etc/fstab
#末尾加入/swapfile none swap sw 0 0
#优化swap策略
cat /proc/sys/vm/swappiness
>60
sudo sysctl vm.swappiness=10
#永久生效
sudo nano /etc/sysctl.conf
#末尾加入vm.swappiness=10

3.开启最高性能模式：

1
2


sudo nvpmodel -m 0
sudo jetson_clock

锁住 CPU/GPU 频率，确保推理时延迟最低

✅️微任务 3.1.2：推理引擎技术选型（llama.cpp vs TensorRT-LLM）

目标：根据开发周期和性能需求选择最佳引擎。
方案对比与选择：
- 方案 A：llama.cpp（推荐优先部署）：对 Jetson 适配极佳，编译简单，内存开销极小。通过开启 GGML_CUDA=1，可以将计算完全卸载到 Orin Nano 的 Ampere GPU 上。支持 GGUF 格式，量化极其方便。
- 方案 B：TensorRT-LLM（极致性能追求）：NVIDIA 官方的王牌，吞吐量最高。但由于 TensorRT-LLM 的编译依赖较重，在 8GB 的 Orin Nano 上直接编译模型 Engine 极易 OOM，通常需要在 PC 端（带有 NVIDIA 独立显卡的 Ubuntu 主机）进行交叉编译，生成 Engine 后再拷贝到 Jetson 上运行。
实施建议：第一阶段使用 llama.cpp + CUDA 快速打通链路；第二阶段追求极限低时延时，在 PC 端配置 Docker 交叉编译 TensorRT-LLM 的 Engine。

方案A具体步骤：

1.确认环境

1
2


uname -m#为aarch64
dpkg -l | grep nvidia-jetpack#JetPack 5.1+ 或 6.x、CUDA 已安装

2.安装依赖

1
2
3
4
5
6
7
8


sudo apt update

sudo apt install -y \
 git \
 cmake \
 build-essential \
 python3 \
 python3-pip

3.获取 llama.cpp

1
2


git clone https://github.com/ggml-org/llama.cpp#网慢可以转gitee
cd llama.cpp

4.jetson cuda编译

1
2
3
4
5


cmake -B build -G Ninja \
 -DCMAKE_BUILD_TYPE=Release \
 -DGGML_CUDA=ON \
 -DCMAKE_CUDA_ARCHITECTURES=87 \
 -DLLAMA_CURL=ON

参数	意义
GGML_CUDA=ON	启用 CUDA backend
87	Orin Nano Ampere 架构
Ninja	加速编译
LLAMA_CURL	支持 hf 模型下载

5.编译

1

cmake --build build -j$(nproc)

6.验证

1

./build/bin/llama-cli -h

7.部署测试

下载 https://huggingface.co/bartowski/Qwen2.5-3B-Instruct-GGUF

放入/home/nvidia/Downloads/llama.cpp/models

1
2
3
4
5


./build/bin/llama-cli \
 -m ./models/Qwen2.5-3B-Instruct-Q4_K_M.gguf \
 -ngl 999 \
 -p "你好，请用一句话介绍ROS2" \
 -n 64

✅️微任务 3.1.3：Qwen2.5 模型量化与格式转换

目标：将 Hugging Face 发布的原始 Qwen3.5 模型权重转换为 GGUF 格式，并完成不同量化策略（Q8_0、Q6_K、Q5_K_M、Q4_K_M）的压缩与性能测试，实现 Jetson Orin Nano 端侧部署（原始 Qwen 模型通常以 Transformers 格式发布）
量化策略
- 原始模型一般FP16
- Q8_0：8-bit量化
- Q6_K：6-bit量化K-Quant， llama.cpp 后来提出的新量化算法
- Q5_K_M：5-bit量化、K-Quant算法、Medium（重要层保留更多精度）
- Q4_K_M：4-bit量化、K-Quant、Medium
格式大小

FP16 8GB

Q8_0 4.3GB

Q6_K 3.3GB

Q5_K_M 2.9GB

Q4_K_M 2.3GB

格式	大小
FP16	8GB
Q8_0	4.3GB
Q6_K	3.3GB
Q5_K_M	2.9GB
Q4_K_M	2.3GB

量化工具需要先理解模型结构

GGUF 是 llama.cpp 的统一模型格式
HuggingFace模型(safetensors) –> 转换成GGUF(F16) -> GGUF量化 - > Q4_K_M / Q5_K_M

原始模型

Qwen3-4B/
├── config.json
├── tokenizer.json
├── model.safetensors
├── model-00001-of-00002.safetensors
└── model-00002-of-00002.safetensors
#model.safetensors神经网络权重矩阵

GGUF是llama.cpp专用模型容器

具体步骤（以 llama.cpp 路线为例）：

Qwen2.5-1.5B-Instruct (HF格式)

 ↓ convert_hf_to_gguf.py

qwen2.5-1.5b-f16.gguf

 ↓ llama-quantize

qwen2.5-1.5b-q4_k_m.gguf

1.hf获取国产模型慢，在魔塔社区下代替Qwen2.5-1.5B-Instruct

1
2
3
4
5


# 1. 安装魔搭下载工具（使用清华源瞬间装完）
pip install modelscope -i https://pypi.tuna.tsinghua.edu.cn/simple

# 2. 一键满速下载到指定目录（告别网络报错）
modelscope download --model qwen/Qwen2.5-1.5B-Instruct --local_dir ./Qwen2.5-1.5B-Instruct

模型位置：

2.使用 llama.cpp 的 convert_hf_to_gguf.py 脚本将模型转化为gguf格式

convert_hf_to_gguf.py 依赖 transformers 库，因此在使用前先配个miniconda

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


wget https://mirrors.tuna.tsinghua.edu.cn/anaconda/miniconda/Miniconda3-latest-Linux-aarch64.sh
bash Miniconda3-latest-Linux-aarch64.sh
source ~/.bashrc
conda --version
conda config --add channels https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main/
conda config --add channels https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/free/
conda config --add channels https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud/conda-forge/
conda config --set show_channel_urls yes
conda tos accept --override-channels --channel https://repo.anaconda.com/pkgs/main
conda tos accept --override-channels --channel https://repo.anaconda.com/pkgs/r

创建进入

1
2


conda create -n llama_cpp_env python=3.10 -y
conda activate llama_cpp_env

安装transformers 和torch

然后转换

1
2
3
4
5
6


cd ~/Downloads/llama.cpp

python convert_hf_to_gguf.py \
 /home/nvidia/Desktop/Qwen2.5-1.5B-Instruct \
 --outfile qwen2.5-1.5b-f16.gguf \
 --outtype f16

3.模型量化：执行 ./llama-quantize。

Orin Nano 4GB 版：必须选择 INT4 量化（如 Q4_K_M），且只能运行 1.8B 模型。
Orin Nano 8GB 版：推荐选择 INT4 量化运行 4B 模型，或者选择 INT8 量化（如 Q8_0）运行 1.8B 模型（具备更好的指令遵循能力）。

1
2
3
4


./build/bin/llama-quantize \
 qwen2.5-1.5b-f16.gguf \
 qwen2.5-1.5b-q4_k_m.gguf \
 Q4_K_M

✅️微任务 3.1.4：Qwen2.5-0.5B-Instruct Lora微调

目标：实现Qwen2.5-0.5B-Instruct微调测试。

方案选择：

Orin Nano 4GB 版：必须选择 INT4 量化（如 Q4_K_M），且只能运行 1.8B 模型。
Orin Nano 8GB 版：推荐选择 INT4 量化运行 4B 模型，或者选择 INT8 量化（如 Q8_0）运行 1.8B 模型（具备更好的指令遵循能力）。

实验环境：魔塔实例，8核32gb，显存24g

方案1：魔塔微调神器 ms-swift

1.安装工具

1
2
3


pip install ms-swift -U
pip install modelscope -U
python -c "from modelscope import snapshot_download; snapshot_download('Qwen/Qwen2.5-0.5B-Instruct', local_dir='.')"

2.创建微调数据集

1
2
3
4
5
6


cd /mnt/workspace
cat << 'EOF' > cat_data.jsonl
{"messages": [{"role": "user", "content": "你是谁？"}, {"role": "assistant", "content": "喵喵喵！本大爷是专属猫咪助手，有小鱼干才回答你！"}]}
{"messages": [{"role": "user", "content": "今天天气怎么样？"}, {"role": "assistant", "content": "喵~ 太阳很大，适合本猫在窗台上睡觉！"}]}
{"messages": [{"role": "user", "content": "帮我写一段Python代码。"}, {"role": "assistant", "content": "打工人自己写！喵！好吧，给你个 print('Meow')。"}]}
EOF

3.开始lora微调

1
2
3
4
5
6
7
8


swift sft \
 --model ./models \
 --model_type qwen2 \
 --template qwen2_5 \
 --dataset cat_data.jsonl \
 --num_train_epochs 1 \
 --max_steps 40 \
 --output_dir ./output

4.合并lora权重

1
2
3
4
5
6


cd /mnt/workspace

swift export \
 --model ./models \
 --adapters ./output/v1-20260615-211104/checkpoint-40 \
 --merge_lora true

5.使用 llama.cpp 转换为 GGUF

1
2
3
4
5
6
7
8
9


cd /mnt/workspace
git clone https://github.com/ggerganov/llama.cpp.git
cd llama.cpp
pip install -r requirements.txt

cd /mnt/workspace/llama.cpp
python convert_hf_to_gguf.py /mnt/workspace/output/v1-20260615-211104/checkpoint-40-merged \
 --outfile /mnt/workspace/my_cat_qwen.gguf \
 --outtype q8_0

微任务 3.1.4：流式推理接口开发（C++ / Python）

目标：实现全流式（Streaming）文本输出，降低首字时延（First-token Latency）。
具体步骤：
1. 编写推理控制客户端，调用 llama.cpp 的 API 或使用 llama-cpp-python（确保编译时使能了 CUDA）。
2. 配置关键推理参数：
  - n_ctx（上下文窗口）：机器人局部交互通常不需要太长上下文，建议设为 512 或 1024，以节省大量 KV Cache 占用的显存。
  - n_gpu_layers：设置为 -1，代表将所有模型层（Layers）全部加载到 GPU 显存中，避免 CPU-GPU 之间的数据拷贝时延。

微任务 3.1.5：ROS2 节点封装与端侧通信集成

目标：将大模型推理能力接入机器人系统，供 Agent 决策模块调用。
具体步骤：
1. 创建一个 ROS2 Lifecycle 节点（如 llm_inference_node）。
2. 输入端：订阅 ASR 模块发布的语音识别文本话题（Topic）。
3. 输出端：使用 ROS2 的 Action 机制（而不是普通的 Service 或 Topic）。因为大模型生成是流式的、耗时的，Action 机制允许节点在生成过程中持续回传（Feedback）流式文本，供 TTS 模块实现边接收边朗读（全流式响应），从而大幅降低整个 Agent 链路的感知延迟。