为什么你的小模型推理变慢了？SmolLM-Instruct_rai_1.8.0_medusa_1.0_npu 性能调优 10 个技巧

• 大模型
• 基础模型

小模型推理明明应该飞快，为什么跑起来却越来越慢？SmolLM-Instruct_rai_1.8.0_medusa_1.0_npu 是一个面向 NPU 加速的 1.8B 级小语言模型推理版本，内建 Medusa 推测解码头，本文提供 10 个可落地的性能调优技巧，帮你快速定位瓶颈、显著提升 tokens/s。

先搞懂模型命名：它为什么天生更快？

在调优之前，先读懂SmolLM-Instruct_rai_1.8.0_medusa_1.0_npu这个名字里的三个关键信息：

• SmolLM-Instruct：Hugging Face 出品的轻量级指令微调模型，参数量小、推理成本低，非常适合边缘与端侧部署；
• medusa_1.0：模型接入了 Medusa 推测解码头，能并行预测后续多个 token，再一次性验证，减少自回归解码步数——这是它区别于普通小模型的核心卖点；
• ra_1.8.0 / npu：表示 1.8.0 版本导出，且针对 NPU（神经网络处理器）做了适配。

模型仓库当前以 README.md 为核心说明文件，权重文件通过 Git LFS 托管，可用 SDK 或 Git 两种方式拉取（见 README.md）：

git clone https://gitcode.com/hf_mirrors/amd/SmolLM-Instruct_rai_1.8.0_medusa_1.0_npu

⚠️ 注意：如果只下载了骨架文件而没有拉到完整权重，加载阶段的反复重试与回退加载会直接表现为"推理莫名其妙变慢"。

技巧 1：用对 NPU 运行时，别拿 CPU 模拟器跑分

模型名带npu后缀，意味着最优路径是跑在 NPU 运行时上。常见的第一坑是：框架检测到 NPU 驱动版本不匹配，静默回退到 CPU 仿真路径，速度直接掉一个数量级。

做法：启动时打印实际设备信息，确认模型真的落在 NPU 上；驱动、运行时库与框架三者版本要成套匹配。

技巧 2：开启 Medusa 推测解码，白捡 2~3 倍吞吐

这是该模型最值钱的特性。Medusa 头并行起草 K 个候选 token，主模型一次前向即可验证，等效于"一步生成多个 token"。

做法：确认推理配置中投机解码处于开启状态，并按硬件调整draft tokens（草稿 token 数，一般 2~5）。如果配置里被默认关闭了，等于白白浪费了这个模型的核心优势。

技巧 3：控制 max_new_tokens，别为"可能的长输出"预留

很多部署会把max_new_tokens拉满以支持长回答。但对 1.8B 小模型而言，长输出意味着：

• KV Cache 持续膨胀，逐步逼近显存上限；
• 触发内存分配与扩容，产生隐性停顿。

做法：按业务真实输出上限设置，例如摘要类任务 256、对话类 512，够用即可。

技巧 4：Batch size 不是越大越快

小模型单次计算量小，吞吐主要受显存带宽限制。盲目加大 batch 会导致 KV Cache 占满、批处理间出现同步等待，反而更慢。

做法：从 1 开始逐步翻倍压测（1 → 2 → 4 → 8…），记录每组 tokens/s，取拐点前一组作为工作点。

技巧 5：压缩 KV Cache，掐灭长上下文的隐形杀手

当输入上下文拉长时，KV Cache 往往先于计算成为瓶颈，这是"跑短文本很快、跑长文档就卡"的典型原因。

做法：

• 启用推理框架的分页 KV 管理（PagedAttention 类机制）；
• 对 KV Cache 使用 int8/int4 量化存储；
• 对超长输入先做截断或分段摘要，再送入模型。

技巧 6：量化部署，再省一半显存

1.8B 全精度权重本身不大，但量化后显存占用、带宽压力同步下降，在小模型上收益尤其明显。

做法：优先尝试 int8（W8A8）或 int4（AWQ 类）量化版本；量化前后各跑一次同一组 prompt，用困惑度/评测集分数确认质量可接受。

技巧 7：固定输入、做好预热，消除首请求抖动

冷启动阶段，模型加载、算子编译、内存池首次分配都会计入延迟，让第一个请求慢好几倍。

做法：服务启动后先用固定 prompt 跑一轮预热（warmup），再开放流量；压测报告里把"首请求延迟"与"稳态延迟"分开统计，避免被平均数误导。

技巧 8：关掉冗余日志，用流式输出

推理服务里最常见的两个"隐形税"：

• DEBUG 级日志 + 每 token 打点，高频 I/O 会拖慢生成循环；
• 非流式模式攒完整回复才返回，感知延迟被放大数倍。

做法：生产环境日志级别调到 INFO/WARN，客户端启用流式输出，让首 token 延迟（TTFT）真实反映性能。

技巧 9：线程与并发配置与核数对齐

NPU 场景下，主机侧的预处理（分词、填充、张量搬运）仍跑在 CPU 上。线程数超过物理核数会造成频繁上下文切换。

做法：CPU 预处理线程数 ≈ 物理核数，推理并发数按"技巧 4"的压测拐点设定，两者分开调，不要混为一谈。

技巧 10：建立基线，用 profiling 数据说话

调优最忌讳"凭感觉改参数"。建议固定一套评测 prompt（覆盖短/中/长上下文各若干条），记录三项指标：

每次只改一个变量，对比前后数据；有条件时用框架自带的 profiler 看 NPU 算子耗时占比，确认瓶颈究竟在计算、带宽还是搬运。

总结：小模型调优的正确姿势 ⚡️

回到开头的问题——小模型推理变慢，绝大多数情况不是模型本身慢，而是：没落在 NPU 上、Medusa 推测解码没开、KV Cache 与 batch 配置不合理。按上面 10 个技巧逐项排查（先看设备与解码配置，再调批大小与内存，最后用基线数据验证），通常能把 tokens/s 拉回应有水平。

模型资料与下载方式详见 README.md，权重文件的获取入口位于其中的"模型文件"页面。

• 大模型
• 基础模型