14MB vs 8MBNeedle 2 到 Needle 3一次升级卷掉了近一半体积【免费下载链接】needleAutomation foundation model for tiny devices: 2-bit, 8-29 MB, tool calls, ASR, structured extraction and embeddings on phones, wearables, smart homes, robots, cars and microcontrollers.项目地址: https://gitcode.com/GitHub_Trending/needle20/needle端侧 AI 的竞争逻辑很简单谁能把模型塞进更小的 Flash、用更少的内存跑起来谁就能上手机、手表、路由器、树莓派。Cactus Compute 的 Needle 系列在这个方向上一路压缩——Needle 2 用单文件 14MB 装下 4500 万参数、以 28MB 内存跑通工具调用已经算得上极致轻量而新一代 Needle 3 直接把最小可部署档压到约 8MB体积几乎砍半参数规模却不降反升。这篇拆解我们从体积、内存、延迟、架构四个维度逐项对比两代模型再钻进仓库源码看看这近一半的体积到底砍在了哪里、换回了什么最后给还在用 Needle 2 的存量部署一个明确的迁移判断。四维对比同样面向端侧两代模型差在哪先把两代模型的核心参数摆在一起信息全部来自仓库源码与官方文档没有一处猜测数字。维度Needle 2Needle 3参数量45M4500 万满配 20 层 121M最小 2 层 rung 约 29M单文件体积14MB.cact8–29MB.cact最浅档约 8MB满配约 29MB权重量化W4A84-bit 权重 8-bit 激活2-bit Cactus Quants约 2.125 bits/weight运行内存约 28MB更浅 rung 进一步下探适配 180MB 的低内存设备端侧延迟结构化 JSON 直接生成无自由文本CPU 端单次工具调用 320ms 级引擎C 单核引擎版本 2.0.4C 引擎升级至 3.2.0API 兼容扩展能力面工具调用、置信度门控工具调用 结构化抽取 文本嵌入 语音Whistle 共用容器几个容易被误读的点值得先说透8MB不是参数规模而是最小部署档的体积。大纲里常见的45M→8M 参数说法是不准确的——Needle 3 的参数并没有缩水满配 20 层是 121M 参数比 Needle 2 的 45M 还多近三倍。体积之所以不增反减靠的是两件事2-bit 极低比特量化以及架构层面的算术瘦身后文细说。体积对比要放在同一档位上。Needle 2 只有一个档位14MB、45M 参数。Needle 3 则是梯级ladder设计从 2 层到 20 层每一档深度都是一个可部署模型体积在 8MB 到 29MB 之间浮动。与 Needle 2 直接对标的是它的最浅档——约 8MB、29M 参数正好是近一半的由来。延迟与内存数字来自社区实测口径。仓库源码本身不写死这些指标它们由目标硬件决定但社区对 Cactus Needle 3 的部署报告给出了一致的画像CPU 端单次调用 320ms、峰值内存 180MB足以支撑树莓派、二手笔记本这类设备。Needle 2 时代的28MB 内存稳定运行记录在 Needle 3 的更浅 rung 上只会更低。砍掉的是什么换来的是什么这一节是全文的核心那近一半体积不是白砍的也不是无痛的。砍掉的是权重精度不是能力Needle 2 的量化是 W4A8权重 4-bit、激活 8-bit配合预转置矩阵与层优先布局专为 GEMV/GEMM 计算流设计。到 Needle 3权重直接压到 2-bit——.cact格式说明里写得很清楚这是每权重 2.125 bits的 Cactus Quants先做 Hadamard 旋转再用 Lloyd-Max 单位球码本量化每组权重存一份 L2 范数用于反量化。导出端也能验证这一点needle/model/export.py 中同时实现了 2/3/4-bit 码本的打包而仓库的微调对比表明确写着本地 LoRA 导出是 4-bit、平台训练才是与发布模型一致的 2-bit 后训练量化见 README.md 的 Customisation 章节。2-bit 换来的不止是体积读取 8MB 权重所需的 Flash 带宽、mmap 后的内存驻留、首次加载耗时全部同步下降——这正是近一半体积的真正价值所在。换回来的是四样新东西第一梯级可裁剪架构。Needle 3 是 Laddered Simple Attention Network训练时让 2 到 20 层每一个深度都成为可部署模型。实现上needle/model/architecture.py 里的ladder_order与ladder_layer_indices按二分法从两端向中间逐层嵌套选取子网络保证任意深度的 rung 都是空间上均匀覆盖的稳定子集needle build --layers N一行命令就能导出任意档位。这意味着同一套权重可以按设备能力裁剪——手机用 8 层MCU 用 2 层产品线共享一套训练资产。第二算术瘦身。满配 121M 参数里大头在 engram——一种用 n-gram 哈希做键、gather 读取的记忆表源码里engram_indices用 FNV 风格素数哈希把 token 序列映射到 18432 个槽位。engram 的读写不走稠密矩阵乘所以121M 模型做的其实是 50M 模型的算术量README 原话。换到 FFN 位置的是 Monarch Hadamard MLP——三个 Kronecker 结构 Walsh 因子矩阵加对角缩放把稠密 FFN 替换成近乎免参数的变换HadamardMLP类。注意力侧则从 v2 的经典 MHA 升级为 GQA 因果卷积 taps 滑动窗口 全局层的混合KV 缓存进一步缩水。第三多模态能力面。Needle 2 只会做工具调用。Needle 3 增加了EmbeddingHeadneedle/model/architecture.py 中的probe_pool机制把隐藏层池化成向量Python 侧暴露为needle_embed同一模型同时输出文本嵌入端侧检索、匹配、路由不再需要第二套模型Whistle 语音模型与 Needle 3 共享.cact容器和同一套引擎语音进、工具调用出一次调用完成。第四更强的行为约束。v2 时代的结构化 JSON 输出依赖训练约束v3 则是从你的 schema 编译字节级语法约束每一个 token——输出保证可解析、参数保证有证据支撑。配合校准过的置信度头run()会对没有依据的字段直接拒答而非猜答案见 needle/init.py 的 grounding 逻辑。代价是存在的通用对话能力被主动放弃README 第一段就把话挑明we trade general chat capacity to beat models 10x its size on mobile tool calls——用通用闲聊能力换工具调用精度。Needle 3 面对非工具类请求会返回空列表而非自由文本response 里type为respond时只有工具结果不生成一句多余的话。如果你的场景是陪聊型助手两代 Needle 都不合适如果你的场景是听懂指令、执行动作这个取舍反而是优势。基准测试也印证了取舍的回报——六项基准上8–29MB 的 Needle 3 在移动工具调用上压过 10 倍体量的模型抽取任务也能对标 2–3 倍大小的模型升级建议现有 Needle 2 用户该不该迁移结论先行该迁移但不要一刀切迁移。分三种情况看1. 新项目、新设备直接上 Needle 3。原因很硬——Needle 2 的三大不可变更部分都是工程痛点置信度头不参与训练、微调后校准失效SentencePiece 分词器硬编码进.cact非英语场景 token 膨胀约 1.7 倍.cact权重与 C 引擎版本强绑定。这三条每一条都在阻碍非英语部署、置信度门控和引擎迭代。Needle 3 的字节级语法约束、校准头随模型训练、平台微调全模型训练把这几个坑全部填平了。2. 存量 Needle 2 部署零成本保留按需迁移。仓库专门为兼容留了后门needle.Needle(tools[...], generation2)可以继续跑现有部署README 原话keeps running Needle 2 for existing deploymentsneedle download --generation 2、needle fetch --generation 2也能继续拉取 v2 引擎与权重。CLI 里--generation 2|3的选择项就是为两代共存设计的。如果你的产品已经稳定跑在 14MB 档、没有体积压力不必为了追新而重构。3. 要迁移时两条路都通。一条是平替needle build --layers 8 --out tuned.cact把 8 层 rung 导出成与你现有 14MB 相近体量的部署文件工具定义、Prompt 格式、JSON 响应契约基本沿用接入成本主要在一次 schema 校验与回归测试。另一条是极致压缩2 层 rung 的 8MB 档适合从 MCU 到智能家居网关的更低端设备代价是精度需要你用微调拉回——README 的微调数据给出了量化回报在 DroidCall 上微调每个梯级子网络提升 18–36 个点从 4 层起微调后的子网络即可反超 DeepSeek V4 Flash起点仅 29M 参数一个必须提醒的兼容性坑Needle 2 的 checkpoint 与当前包不兼容。load_checkpoint在检测到 v2 checkpoint 时会直接报错并提示Use cactus-needle 2.x见 needle/model/run.py。也就是说v2 的 LoRA 适配器与训练产物不能在新包里复用真要迁移微调资产要么在 2.x 环境下导出为.cact后由 v3 引擎加载.cact带格式 tag_weight_generation会自动识别要么干脆用 v3 的梯级结构重新微调。此外本地微调导出的 v3 文件不携带校准置信度头confidence会返回None——需要置信度门控的产品应走平台微调路径保留该头。最后说一句大实话14MB 到 8MB 的近一半本质不是参数瘦身而是量化精度与架构效率的联动红利。Needle 3 用 2-bit 权重 engram/Hadamard 算术瘦身把更小和更强同时做到了而它敢于在 121M 参数上谈 8MB 部署靠的是梯级架构让一个模型、任意档位成为可能。对端侧开发者来说值得记住的未必是 14 与 8 这两个数字而是这条链路精度砍到 2-bit架构换成免参数变换能力面扩到嵌入与语音部署档位按需裁剪——这套组合拳才是端侧 AI 模型卷体积的正确姿势。【免费下载链接】needleAutomation foundation model for tiny devices: 2-bit, 8-29 MB, tool calls, ASR, structured extraction and embeddings on phones, wearables, smart homes, robots, cars and microcontrollers.项目地址: https://gitcode.com/GitHub_Trending/needle20/needle创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/10 14:43:50 · 阅读 1.2k 14MB vs 8MB：Needle 2 到 Needle 3，一次升级卷掉了近一半体积
14MB vs 8MBNeedle 2 到 Needle 3一次升级卷掉了近一半体积【免费下载链接】needleAutomation foundation model for tiny devices: 2-bit, 8-29 MB, tool calls, ASR, structured extraction and embeddings on phones, wearables, smart homes, robots, cars and microcontrollers.项目地址: https://gitcode.com/GitHub_Trending/needle20/needle端侧 AI 的竞争逻辑很简单谁能把模型塞进更小的 Flash、用更少的内存跑起来谁就能上手机、手表、路由器、树莓派。Cactus Compute 的 Needle 系列在这个方向上一路压缩——Needle 2 用单文件 14MB 装下 4500 万参数、以 28MB 内存跑通工具调用已经算得上极致轻量而新一代 Needle 3 直接把最小可部署档压到约 8MB体积几乎砍半参数规模却不降反升。这篇拆解我们从体积、内存、延迟、架构四个维度逐项对比两代模型再钻进仓库源码看看这近一半的体积到底砍在了哪里、换回了什么最后给还在用 Needle 2 的存量部署一个明确的迁移判断。四维对比同样面向端侧两代模型差在哪先把两代模型的核心参数摆在一起信息全部来自仓库源码与官方文档没有一处猜测数字。维度Needle 2Needle 3参数量45M4500 万满配 20 层 121M最小 2 层 rung 约 29M单文件体积14MB.cact8–29MB.cact最浅档约 8MB满配约 29MB权重量化W4A84-bit 权重 8-bit 激活2-bit Cactus Quants约 2.125 bits/weight运行内存约 28MB更浅 rung 进一步下探适配 180MB 的低内存设备端侧延迟结构化 JSON 直接生成无自由文本CPU 端单次工具调用 320ms 级引擎C 单核引擎版本 2.0.4C 引擎升级至 3.2.0API 兼容扩展能力面工具调用、置信度门控工具调用 结构化抽取 文本嵌入 语音Whistle 共用容器几个容易被误读的点值得先说透8MB不是参数规模而是最小部署档的体积。大纲里常见的45M→8M 参数说法是不准确的——Needle 3 的参数并没有缩水满配 20 层是 121M 参数比 Needle 2 的 45M 还多近三倍。体积之所以不增反减靠的是两件事2-bit 极低比特量化以及架构层面的算术瘦身后文细说。体积对比要放在同一档位上。Needle 2 只有一个档位14MB、45M 参数。Needle 3 则是梯级ladder设计从 2 层到 20 层每一档深度都是一个可部署模型体积在 8MB 到 29MB 之间浮动。与 Needle 2 直接对标的是它的最浅档——约 8MB、29M 参数正好是近一半的由来。延迟与内存数字来自社区实测口径。仓库源码本身不写死这些指标它们由目标硬件决定但社区对 Cactus Needle 3 的部署报告给出了一致的画像CPU 端单次调用 320ms、峰值内存 180MB足以支撑树莓派、二手笔记本这类设备。Needle 2 时代的28MB 内存稳定运行记录在 Needle 3 的更浅 rung 上只会更低。砍掉的是什么换来的是什么这一节是全文的核心那近一半体积不是白砍的也不是无痛的。砍掉的是权重精度不是能力Needle 2 的量化是 W4A8权重 4-bit、激活 8-bit配合预转置矩阵与层优先布局专为 GEMV/GEMM 计算流设计。到 Needle 3权重直接压到 2-bit——.cact格式说明里写得很清楚这是每权重 2.125 bits的 Cactus Quants先做 Hadamard 旋转再用 Lloyd-Max 单位球码本量化每组权重存一份 L2 范数用于反量化。导出端也能验证这一点needle/model/export.py 中同时实现了 2/3/4-bit 码本的打包而仓库的微调对比表明确写着本地 LoRA 导出是 4-bit、平台训练才是与发布模型一致的 2-bit 后训练量化见 README.md 的 Customisation 章节。2-bit 换来的不止是体积读取 8MB 权重所需的 Flash 带宽、mmap 后的内存驻留、首次加载耗时全部同步下降——这正是近一半体积的真正价值所在。换回来的是四样新东西第一梯级可裁剪架构。Needle 3 是 Laddered Simple Attention Network训练时让 2 到 20 层每一个深度都成为可部署模型。实现上needle/model/architecture.py 里的ladder_order与ladder_layer_indices按二分法从两端向中间逐层嵌套选取子网络保证任意深度的 rung 都是空间上均匀覆盖的稳定子集needle build --layers N一行命令就能导出任意档位。这意味着同一套权重可以按设备能力裁剪——手机用 8 层MCU 用 2 层产品线共享一套训练资产。第二算术瘦身。满配 121M 参数里大头在 engram——一种用 n-gram 哈希做键、gather 读取的记忆表源码里engram_indices用 FNV 风格素数哈希把 token 序列映射到 18432 个槽位。engram 的读写不走稠密矩阵乘所以121M 模型做的其实是 50M 模型的算术量README 原话。换到 FFN 位置的是 Monarch Hadamard MLP——三个 Kronecker 结构 Walsh 因子矩阵加对角缩放把稠密 FFN 替换成近乎免参数的变换HadamardMLP类。注意力侧则从 v2 的经典 MHA 升级为 GQA 因果卷积 taps 滑动窗口 全局层的混合KV 缓存进一步缩水。第三多模态能力面。Needle 2 只会做工具调用。Needle 3 增加了EmbeddingHeadneedle/model/architecture.py 中的probe_pool机制把隐藏层池化成向量Python 侧暴露为needle_embed同一模型同时输出文本嵌入端侧检索、匹配、路由不再需要第二套模型Whistle 语音模型与 Needle 3 共享.cact容器和同一套引擎语音进、工具调用出一次调用完成。第四更强的行为约束。v2 时代的结构化 JSON 输出依赖训练约束v3 则是从你的 schema 编译字节级语法约束每一个 token——输出保证可解析、参数保证有证据支撑。配合校准过的置信度头run()会对没有依据的字段直接拒答而非猜答案见 needle/init.py 的 grounding 逻辑。代价是存在的通用对话能力被主动放弃README 第一段就把话挑明we trade general chat capacity to beat models 10x its size on mobile tool calls——用通用闲聊能力换工具调用精度。Needle 3 面对非工具类请求会返回空列表而非自由文本response 里type为respond时只有工具结果不生成一句多余的话。如果你的场景是陪聊型助手两代 Needle 都不合适如果你的场景是听懂指令、执行动作这个取舍反而是优势。基准测试也印证了取舍的回报——六项基准上8–29MB 的 Needle 3 在移动工具调用上压过 10 倍体量的模型抽取任务也能对标 2–3 倍大小的模型升级建议现有 Needle 2 用户该不该迁移结论先行该迁移但不要一刀切迁移。分三种情况看1. 新项目、新设备直接上 Needle 3。原因很硬——Needle 2 的三大不可变更部分都是工程痛点置信度头不参与训练、微调后校准失效SentencePiece 分词器硬编码进.cact非英语场景 token 膨胀约 1.7 倍.cact权重与 C 引擎版本强绑定。这三条每一条都在阻碍非英语部署、置信度门控和引擎迭代。Needle 3 的字节级语法约束、校准头随模型训练、平台微调全模型训练把这几个坑全部填平了。2. 存量 Needle 2 部署零成本保留按需迁移。仓库专门为兼容留了后门needle.Needle(tools[...], generation2)可以继续跑现有部署README 原话keeps running Needle 2 for existing deploymentsneedle download --generation 2、needle fetch --generation 2也能继续拉取 v2 引擎与权重。CLI 里--generation 2|3的选择项就是为两代共存设计的。如果你的产品已经稳定跑在 14MB 档、没有体积压力不必为了追新而重构。3. 要迁移时两条路都通。一条是平替needle build --layers 8 --out tuned.cact把 8 层 rung 导出成与你现有 14MB 相近体量的部署文件工具定义、Prompt 格式、JSON 响应契约基本沿用接入成本主要在一次 schema 校验与回归测试。另一条是极致压缩2 层 rung 的 8MB 档适合从 MCU 到智能家居网关的更低端设备代价是精度需要你用微调拉回——README 的微调数据给出了量化回报在 DroidCall 上微调每个梯级子网络提升 18–36 个点从 4 层起微调后的子网络即可反超 DeepSeek V4 Flash起点仅 29M 参数一个必须提醒的兼容性坑Needle 2 的 checkpoint 与当前包不兼容。load_checkpoint在检测到 v2 checkpoint 时会直接报错并提示Use cactus-needle 2.x见 needle/model/run.py。也就是说v2 的 LoRA 适配器与训练产物不能在新包里复用真要迁移微调资产要么在 2.x 环境下导出为.cact后由 v3 引擎加载.cact带格式 tag_weight_generation会自动识别要么干脆用 v3 的梯级结构重新微调。此外本地微调导出的 v3 文件不携带校准置信度头confidence会返回None——需要置信度门控的产品应走平台微调路径保留该头。最后说一句大实话14MB 到 8MB 的近一半本质不是参数瘦身而是量化精度与架构效率的联动红利。Needle 3 用 2-bit 权重 engram/Hadamard 算术瘦身把更小和更强同时做到了而它敢于在 121M 参数上谈 8MB 部署靠的是梯级架构让一个模型、任意档位成为可能。对端侧开发者来说值得记住的未必是 14 与 8 这两个数字而是这条链路精度砍到 2-bit架构换成免参数变换能力面扩到嵌入与语音部署档位按需裁剪——这套组合拳才是端侧 AI 模型卷体积的正确姿势。【免费下载链接】needleAutomation foundation model for tiny devices: 2-bit, 8-29 MB, tool calls, ASR, structured extraction and embeddings on phones, wearables, smart homes, robots, cars and microcontrollers.项目地址: https://gitcode.com/GitHub_Trending/needle20/needle创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考