技能介绍

解决什么问题

RDK S100/S100P/S600 想把 HuggingFace 上的 LLM/VLM 跑起来时，问题不只是“有没有模型”，而是量化编译链路是否可复现：march 是否匹配板子、校准数据是否代表真实分布、Vision/Text 两条分支如何分别编译、量化后输出和浮点输出差多少、最终板端包里到底该放哪些文件。这个技能负责主机侧 PTQ 流水线，把这些问题收敛到可检查的产物和报告里。

技能如何工作

核心能力是把 config.json + model.safetensors + tokenizer 这类 HuggingFace checkpoint 转成 OE-LLM 的 .hbm，并管理校准、编译、验证、打包：

确认目标板与 march：nash-e 对应 S100，nash-m 对应 S100P，nash-p 对应 S600；这是最容易固化到下游产物的配置。
环境与依赖：Ubuntu 22.04 / x86_64，建议 128 GB 内存（Text decode 编译峰值约 100 GB RSS）、≥300 GB 空闲磁盘；OE-LLM SDK 1.0.0 的安装顺序不能乱，因为它 pin 了 PyTorch 依赖。
校准数据：Vision 用 50 张真实多样图像（例如 COCO val2017），不要用纯色块；Text 用 100–200 条多语言、多长度、多主题 prompt，按 OE-LLM JSON 布局准备。
编译分支：纯 LLM 跳过 Vision；Vision 编译前必须解除栈限制，compile_hbo 是单线程 CPU 工作，16 层 ViT 单核约 110 min。Text decode 编译可加 --enable-swap、--memlimit-gb 防 OOM；tok_embeddings.bin 会作为外部 embedding 表导出。
量化验证：用导出的 BC 对比量化与浮点输出，健康 PTQ 每条分支余弦通常在 0.95–0.99；低于 0.90 先怀疑校准集不具代表性，而不是调编译 flag。
打包产物：生成 Vision/Text 的 .hbm、Text 侧的 tok_embeddings.bin、deploy_bundle/ 布局和 SHA256SUMS，并输出模型、march、chunk/cache、余弦、校准数量、包大小的报告。

适用边界与注意点

它只做主机侧编译与打包，不做板端 hbdk4_runtime 推理接线，也不验证端到端 token 输出。march 必须由用户确认，没有运行时校验；Vision 假设 ViT 形状 encoder，Conformer 等音频分支不在范围。--enable-swap 会写 64 GB swap 并调用 sudo swapon，只在自己拥有的主机上跑。高余弦也不保证最终文本正确，板端效果仍需板侧技能在真机上验证。