Ling-3.0-tiny 是个非常有趣的模型。它可以在 NVIDIA Orin Nano Super 8GB 上运行，支持 128K 上下文并采用 IQ4_NL 量化技术。

我一直在我这台8GB内存的小玩具——英伟达Orin Nano Super 8GB上寻找合适的模型。这个小设备今年早些时候售价249美元（现在已不是这个价），且空闲时功耗极低。它是个有趣的设备，适合作为智能体的运行平台。虽然它可能无法胜任有意义的编程工作，但处理简单任务应该游刃有余。当GitHub上出现对llama.cpp的支持后，我让Hermes为我配置并运行了一些基础测试。结果相当令人鼓舞。以下是我的Hermes运行的总结。 ===============以下为AI生成内容=================== # Ling-3.0-tiny在249美元8GB Orin Nano Super上完整128K上下文运行——IQ4_NL量化，33 tok/s，基于llama.cpp主分支 **简而言之：** 我成功在NVIDIA Jetson Orin Nano Super 8GB上运行了inclusionAI的Ling-3.0-tiny（总参数7.9B，约1.4B活跃参数MoE），采用**IQ4_NL量化格式，并支持完整原生131,072个token的上下文窗口**。短上下文解码速度约33 tok/s（比你的阅读速度还快），提示词评估速度为220-760 tok/s，整个模型仅占用7.4 GiB统一内存（交换空间约200 MB）。模型+KV缓存+CUDA卸载，全部运行在一块249美元的开发板上。 ## 硬件配置 - **Jetson Orin Nano Super开发套件** —— [英伟达官方产品页](https://www.nvidia.com/en-us/autonomous-machines/embedded-systems/jetson-orin/nano-super-developer-kit) - **发售价为249美元**（现价已上涨；SparkFun目前标价399美元）。配备8 GB统一LPDDR5内存，67 TOPS算力，搭载JetPack R39.2 / CUDA 13.2。 ## 模型与量化格式 - **原始模型：** [inclusionAI/Ling-3.0-tiny](https://huggingface.co/inclusionAI/Ling-3.0-tiny) —— 混合KDA+MLA推理型MoE架构，128个专家，每个token激活8个路由专家+1个共享专家 - **GGUF仓库：** [bartowski/Ling-3.0-tiny-GGUF](https://huggingface.co/bartowski/Ling-3.0-tiny-GGUF) - **使用文件：** [`Ling-3.0-tiny-IQ4_NL.gguf`](https://huggingface.co/bartowski/Ling-3.0-tiny-GGUF/blob/main/Ling-3.0-tiny-IQ4_NL.gguf) —— 4.40 GB，IQ4_NL量化（4.5 bpw），经imatrix校准 - **为何选择IQ4_NL：** 其大小为4.30 GiB，是当前能在8GB设备上完整支持131K KV缓存窗口的最大≥4位量化版本。Q5/Q6格式仅能支持约64K；而IQ4_NL能完整支持全窗口。 ## 引擎要求——这点很重要 官方量化器默认发布版本**无法加载此模型**。Ling-3.0-tiny采用的是**BailingMoE V3架构**，该架构需通过以下方式才能在llama.cpp中实现支持： - **PR [#26608 — 支持BailingMoE3架构](https://github.com/ggml-org/llama.cpp/pull/26608)**（已合并至主分支，2026年8月17日，新增架构支持与投机解码MTP功能） - **代码分支：`ggml-org/llama.cpp`主分支**，需使用合并后的最新代码——请直接克隆仓库，不要使用发行包 - 在设备上基于CUDA 13.2编译，针对sm_87架构（编译参数：`-DGGML_CUDA=on -DCMAKE_CUDA_ARCHITECTURES=87`），全部24层均通过GPU加速运行 **运行命令：** ```bash llama-server -m Ling-3.0-tiny-IQ4_NL.gguf -c 131072 \ --cache-type-k q8_0 --cache-type-v q8_0 \ -ngl 99 -fa on -b 512 -ub 256 --jinja -t 6 \ --temp 1.0 --top-p 0.95 --top-k 20 ``` ## 运行速度（设备实测） | 测试项目 | 结果 | |---------|------| | 提示词评估（2-8K长度） | 450-760 t/s | | 提示词评估（完整125K预填充） | 220-264 t/s | | 解码（短上下文） | 33 t/s | | 解码（96-128K深度上下文） | 15-17 t/s | | 首token生成时间（512 token） | ~1秒 | 128K上下文时内存占用：**7.2/7.4 GiB**，约200 MB交换空间。混合架构设计保持了KV缓存的高效性——仅6个MLA层承载与上下文成比例的缓存，而18个KDA层维持固定大小的循环状态，这正是实现完整窗口支持的关键。 ## 128K上下文下的连贯性如何？ 整体表现良好。我进行了标准的“大海捞针”测试：在完整上下文中嵌入**128个唯一密钥**，每个密钥在温度0下单独查询： - **96K上下文：92%检索率**（118/128）——前32K部分达到100% - **128K上下文：88%检索率**（113/128）——最后32K区域出现明显性能下降（67%） - 严格全字符串匹配率较低（约30-40%），因为模型常仅输出密钥的后缀片段——属于生成特性而非检索失误 - 深层上下文失败模式包括：数字混淆（如密钥105的查询结果变为015的密钥）以及少量臆造内容 **总结：多数查询通过，虽非完美的128K体验**——但在96K时性能陡降现象完全消失，对于249美元的开发板而言，其性价比确实令人印象深刻。 ## 结论 值得投入更多研究。混合KDA/MLA架构 + IQ4_NL量化 + llama.cpp主分支为边缘部署提供了极具吸引力的方案：智能推理MoE模型、原生128K窗口、稳定的15-33 tok/s生成速度，全部运行在8GB统一内存中。期待更多开发者探索96-128K注意力衰减现象——以及#26608中的投机解码支持是否能在设备端带来提升。 是否有其他用户在受限硬件上运行Ling-3.0-tiny？您使用的是什么量化版本和配置？