第一次稳定出字时，终端显示 3.2 token/s。
这个速度谈不上流畅，但模型总算在 RISC-V 开发板上跑起来了。接着生成到 200 token 左右，KV Cache 开始挤占 L3 缓存；芯片温度冲到 85℃后，主频又从 2.2GHz 降到 1.2GHz。没有 H100 兜底，7B 模型能启动只是开头，还得保证它不会在 30 秒内因过热降频。
《科创板日报》2025 年 7 月 18 日的报道提到，RISC-V 向高性能应用拓展已经具备初步基础。EET-China 的 2026 年产业观察则给出一组预测：RISC-V 设备出货量将达到 360 亿颗，年复合增长率为 31.7%。这些数字落到开发板上，最终还是三个读数：首字延迟、持续生成速度和温度。
以下结果均来自同一套玄铁 C950-AI 配置，不能直接外推到其他 RISC-V 芯片。
先把板卡和测试口径钉住
本次使用的是 玄铁 C950-AI 开发套件，硬件配置如下：
- 处理器：16 核 RISC-V，支持 RVV 1.0 向量扩展和 Zvk 扩展；
- 内存：32GB LPDDR5，速率 6400 MT/s；
- 加速单元：专用矩阵乘法单元；
- 散热：主动风冷加铜质散热片。
Q4_K_M 量化后的模型文件约 3.8GB，但部署时仍要给 KV Cache、运行时和中间张量留空间。本次按 6—8GB 做内存预算，最终两个框架的峰值占用分别为 5.8GB 和 6.2GB。
在 2024 年以前的旧版开发板上，常见问题是向量指令版本和算子实现无法对齐，程序可以运行，计算却回落到通用路径。C950 的矩阵乘法单元直接影响了后面的 MNN 测试结果，这也是不同板卡难以照搬数据的原因。
默认编译器能编过，性能未必能看
环境采用以下组合：
- 内核：Linux Kernel 6.12+；
- 工具链：基于 LLVM 18 的定制编译器；
- 编译参数：
-march=rv64gcv； - 运行时：Python 3.12、PyTorch 2.5 RISC-V Backend；
- 算子编译：HHB（High-performance Heterogeneous Backend）。
HHB 负责把高层算子映射到 C950 的向量单元，减少中间指令转换。这里最容易漏掉的是内存对齐：输入 Tensor 如果没有按 64 字节对齐，RVV 指令会频繁进入异常或慢速路径。本次测试中，推理速度因此下降超过 40%。
所以，框架对比之前先检查 Tensor 地址和内存分配器。否则后面的量化、线程数调整很可能都在补一个底层对齐问题。
先把7B权重压到3.8GB
FP16 版本的 Llama-3.2 7B 会迅速撞上内存带宽瓶颈。INT8 和 INT4 都做了尝试，最终使用 GGUF 格式的 INT4 量化。
处理顺序并不复杂：先把原始 FP16 权重转换为 GGUF，再调用 llama.cpp 的 quantize 工具，量化格式选择 Q4_K_M。转换后的文件约 3.8GB，内存占用降低约 70%，本次校验中的困惑度变化不明显。
C950 没有硬件 FP8 加速，因此 FP8 在这块板上拿不到明显优势。这个结论只适用于当前硬件，不能当成 INT4 和 FP8 的通用比较。
量化完成后，又对非关键 Attention Head 做了 10% 的稀疏化剪枝。收益约为 5%，同时减轻了长文本生成时的 KV Cache 压力。幅度不算大，主收益仍然来自 INT4 量化。
llama.cpp先通路，MNN再压性能
两个框架使用同一块板卡和同一个量化模型，生成长度固定为 512 tokens。
| 指标 | llama.cpp（RVV 优化版） | MNN（C950 专用后端） | 测试观察 |
|---|---|---|---|
| 首字延迟 | 1.8s | 1.1s | MNN 的算子融合更激进 |
| 生成速度 | 3.1 t/s | 4.4 t/s | MNN 更充分地调用矩阵单元 |
| 平均功耗 | 12W | 10.5W | 单位计算的执行时间更短 |
| 内存峰值 | 6.2GB | 5.8GB | MNN 的内存池占用更低 |
开头提到的 3.2 token/s 来自初次跑通。切换到 C950 专用后端并完成算子调整后，MNN 才达到 4.4 token/s。
如果目标是尽快验证一个新模型，llama.cpp 更省事；模型和硬件已经固定，再投入时间做专用后端，MNN 的速度、首字延迟和功耗更占优势。
200 token后掉速，先查KV Cache
长文本测试中，生成约 200 token 后速度明显下降。排查发现，KV Cache 逐渐填满 C950 的 L3 缓存，后续访问频繁落到 DRAM，形成“内存墙”。
处理方式有两步：
- 引入 PagedAttention，对 KV Cache 做分页管理；
- 把最大上下文长度限制为 2048。
调整后，长文本阶段的生成速度能够维持在 3 t/s 以上。代价也很直接：上下文上限被固定在 2048。对端侧设备来说，稳定速度和更长上下文无法同时拉满，需要按场景取舍。
85℃之后，峰值速度就没有参考价值了
持续运行时，向量单元的高负载会形成局部热点。芯片温度升到 85℃后触发降频，主频从 2.2GHz 掉到 1.2GHz，生成速度随之下滑。
这次采用了两项处理：一是在非关键的 Token 生成阶段降低向量单元激活频率，实施动态算子调度；二是增加外置 12V 风扇强制散热。调整后，温度稳定在 68℃左右。
需要说明，68℃包含外置风扇的效果，不能算裸板成绩。只展示 4.4 t/s 的瞬时峰值，却不交代散热条件，对部署没有多少参考价值。
留下的是一条能复现的链路
这次跑通 7B 模型，实际使用的组合可以压缩成一条链路：
RVV 1.0 与 Zvk 硬件 → LLVM 18 定制工具链 → Q4_K_M INT4 量化 → MNN 专用后端或 llama.cpp → PagedAttention 与 2048 上下文 → 主动散热。
当前 3—4 t/s 的持续速度还不足以支撑流畅的实时对话。放到工业质检、离线 Agent 调度等对延迟不敏感的任务里，10.5—12W 的平均功耗和 5.8—6.2GB 的内存峰值，已经提供了可以继续评估的部署起点。至于能否替代昂贵 GPU，需要按模型、上下文长度和散热条件单独核算。
投资界对“RISC-V 商用落地加速营伙伴计划”的报道提到，入选的 PoC 和 Demo 将获得 10 个月集中式资源支持，目标是改造成可商用方案。这也点出了端侧部署最费时间的部分：终端出字只是演示，稳定速度、内存占用和温度才决定能不能交付。
