oh-my-pi 本地小型模型实验指南tinyModel / memoryModel / autoThinkingModel 的工程化落地【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pi本文是 oh-my-pi 项目中「嵌入式本地小型模型local tiny-model」实验的完整工程记录。它覆盖会话标题生成providers.tinyModel、Mnemopi 记忆提取与整合providers.memoryModel、以及auto思考级别难度分类器providers.autoThinkingModel复用记忆模型注册表三条可选的本地推理路径包括运行时环境结论、设备与量化策略、实测基准、最终胜出的提示词配方与已发布的模型清单。读完本文你将掌握如何在 oh-my-pi 中配置、下载并运行本地 tiny 模型理解其单 worker 常驻架构与各模型取舍并能直接复现标题生成与记忆提取的调优结论。三条路径默认值均为online即存量用户不会产生任何下载或端侧推理开销只有显式选择本地模型后才开始下载权重。在线路径下优先使用配置的tiny角色未配置时回退到任务专属的在线模型。运行时与环境关键结论技术栈huggingface/transformerstransformers.jsv4 运行在 Bun 之上。在 Bun 中该库加载的是原生onnxruntime-node后端而非 WASM 构建。非 FHS 发行版NixOS 及一切 loader 路径上缺少libstdc.so.6的主机按需加载的onnxruntime-node/sherpa-onnx-node/sharp插件是预编译二进制它们dlopenlibstdc.so.6与libgcc_s.so.1且自带各自的DT_RUNPATHomp 可执行文件自身的 RPATH 无法解析它们。需要设置OMP_NATIVE_LIBRARY_PATH指向存放这些库的冒号分隔目录omp 只会把它追加到推理 worker 子进程的LD_LIBRARY_PATH中绝不会传给 shell/eval/daemon 子进程。Nix 包nix/package.nix默认设置该变量。单 worker 常驻模型每模型一个进程无守护、闲时自退每个本地模型由机器上恰好一个 worker 进程服务该进程拥有 socket~/.omp/run/tiny/model-backend.sockWindows 上是命名管道socket 名与日志路径的推导见 title-protocol.ts第一个需要该模型的 omp 进程会detached 方式拉起 worker日志写在 socket 旁即*.sock.log其他所有 omp 进程只做连接。这样模型在整台机器上只常驻一份而不是每个实例一份。没有任何守护进程监管它worker 在 15 分钟无请求后自行退出OMP_TINY_WORKER_IDLE_MS可覆盖该窗口用于测试代码默认值TINY_WORKER_IDLE_MS 15 * 60 * 1000退出时 unlink 自己的 socket之后任意 omp 进程的下一次请求会重新拉起一个新 worker。并发拉起存在竞争多个进程同时 spawn 时通过.bind.lock文件锁仲裁输家发现 socket 已存活便自行退出其父进程接管赢家。ping返回 launch tag格式为omp 版本|onnx|device|dtype或mlx|mlx-lm 版本|脚本 crc因此当 omp 升级或providers.tinyModelDevice/Dtype改变后客户端会发现 tag 不匹配通知旧 worker 关闭并重新拉起见 title-client.ts 的探活与替换逻辑。两个并发实例若使用冲突的设备配置会不断互相替换对方的 worker所以请约定统一的设备设置。协议是消息级的load、带 messages/prefill/stop/max tokens 的chat提示词构建与标题抽取都在客户端完成因此 ONNX worker 与 MLX worker 两种实现可以互换请求类型定义见 title-protocol.ts。设备策略默认纯 CPU加速失败回退一次本地 tiny 模型默认仅 CPU 推理若显式指定的加速 provider 无法初始化则在 CPU 上重试一次设备回退链实现在 worker.ts 的#loadPipelineWithDeviceFallback中用providers.tinyModelDevice设置持久化选择 providerdefault保持 CPU或用PI_TINY_DEVICE环境变量按次覆盖环境变量优先于设置合并逻辑见 title-client.ts 的tinyWorkerEnvOverlay。可接受值cpu、gpu、mlx/metal、webgpu、auto、cuda、dml、coreml、wasm、webnn、webnn-gpu、webnn-cpu、webnn-npu校验实现见 device.ts非法值会抛错而不是静默降级。coreml保持 opt-in需通过PI_TINY_DEVICEcoreml显式开启不在默认值中因为缓存的 decoder-LLM ONNX 在会话初始化时可能加载失败。WebGPU/Metal 目前只适用于单进程 eval 测试环境生产 worker 会把 Darwin 上的gpu/webgpu/auto请求强制回退到 CPU因为 ONNX Runtime/Bun 目前在 WebGPU 推理后的 worker teardown 阶段会硬崩溃DARWIN_WEBGPU_UNSAFE_ORDER常量即此回退链见 device.ts。只有在显式退出 CPU 默认值时才应使用providers.tinyModelDevice或PI_TINY_DEVICE。MLX 后端Apple silicon直接换掉整个 workerPI_TINY_DEVICEmlx或metal不是切换 ONNX provider而是换用另一个 worker 实现每个模型由mlx-server.py服务它运行在 omp 首次使用时通过uv否则python3 -m venv要求 Python ≥ 3.10安装的、锁定版本的mlx-lmvenv 中位置在~/.omp/agent/cache/tiny-mlx-runtime/。该 worker下载模型的预量化 4-bit MLX 导出注册表中的mlxRepo到~/.omp/agent/cache/tiny-models/mlx/带逐字节进度用mlx_lm.load加载与 ONNX worker 说完全相同的协议因此标题、记忆补全和auto思考分类器都无需改动即可工作整个 Python 进程是唯一涉及的进程忽略PI_TINY_DTYPEMLX 仓库本身就是预量化 4-bit。若 venv 引导失败无 Python、安装错误、非 Apple 主机omp 会记录警告并在该进程剩余生命周期内回退到 ONNX CPU worker。MLX 仅在 darwin/arm64 上可用tinyMlxSupported见 device.ts。实测数据M4 Max冷启动 venv 安装 LFM2.5-230M 下载 加载共 15.7s第二个 omp 实例挂到已运行 worker 上远小于 1s预热后标题生成 15–60msQwen3-1.7B在 onnxruntime-node 上被阻塞下载 984MB回答一次记忆提取约 200ms。量化精度q4 是甜点q4 更小、加载更快、推理也更快q8/int8 在 CPU 上加载更慢且推理更慢。所有已发布的模型默认q4持久化用providers.tinyModelDtype设置覆盖default保持 q4例如用fp16换取更高保真度或按次用PI_TINY_DTYPE环境变量优先。可接受值auto、fp32、fp16、q8、int8、uint8、q4、bnb4、q4f16、q2、q2f16、q1、q1f16无法识别的值会在 worker 启动时大声报错失败见 dtype.ts 的normalizeTinyModelDtype绝不静默加载错误精度。加载耗时修正重要早期「q4 ≥1B 模型加载要几分钟」的结论是测量伪影——由约 5 个多 GB 的 HuggingFace 下载并行进行导致 I/O 饱和。干净、隔离的热加载全部在 3 秒以内模型q4 热加载TinyLlama-1.1B~0.5sLlama-3.2-1BgraphOptall~2.8sLlama-3.2-1BgraphOptdisabled~0.5sLFM2-1.2B~0.36sQwen2.5-1.5B~1.5sQwen3-1.7B~1.6sgemma-3-1b~1.1s结论1B–1.7B 模型在 CPU 上完全可用。session_options.graphOptimizationLevel权衡加载与推理速度disabled 加载最快、推理略慢all 默认。首次运行从 HF Hub 下载权重到缓存目录q4 权重约 150MB–1.1GB视模型而定后续热加载为亚秒级到 ~3s。推理是异步的、对后台友好适合记忆任务标题生成则是半交互式。任务一会话标题生成providers.tinyModel任务把第一条用户消息转成 3–7 个词的标题。子 1B 的 tiny 模型足够胜任。获胜配方纯 system prompt无 few-shot。在 assistant 回合prefilltitle并在/title处stop然后取第一行。贪心解码do_sample:falsechat template 中enable_thinking:false。这些参数直接对应客户端构造的请求title-client.ts 与 worker.tsTITLE_PREFILL title、TITLE_CLOSE /title、TITLE_MAX_NEW_TOKENS 20worker 侧do_sample: false且渲染聊天模板时enableThinking: false。实验教训few-shot 示例会污染子 0.6B 模型的标题使模型照抄示例中的主题。共享提示词对嵌入式模型关闭示例对能力足够的在线模型保留。最小的模型会把大小写指令当成输出。normalizeGeneratedTitle 在生成后统一大小写因此提示词里省略了这条规则。Token 偏置bad_words_ids在此确认为无效操作——prefill 已经控制了开头。替换基准30 条近期首会话提示词q4 CPU无示例模型缓存热加载均值 / p953–7 词命中观察到的取舍LFM2.5-230M214MB93 / 194ms21/28语义平衡最好偶发通用标题Falcon-H1-Tiny-90M147MB117 / 174ms17/29最小复杂输入保真度较低LFM2.5-350M292MB166 / 266ms4/30极度简洁常退化为一个词已发布的本地选项lfm2.5-230m、lfm2.5-350m、falcon-h1-90m。默认设置online。omp tiny-models默认下载lfm2.5-230m常量DEFAULT_TINY_TITLE_LOCAL_MODEL_KEY见 models.ts。注册表还给出了每个模型的来源仓库、dtype 与用途注释models.tsLFM2.5-230M 是「推荐本地模型约 214MB 缓存当前紧凑标题模型中平衡最好」Falcon-H1-Tiny-90M 是「最小选项约 147MB适合对下载体积最敏感的设备」LFM2.5-350M「偏好紧凑标签而非描述性标题」。任务二Mnemopi 记忆providers.memoryModelMnemopi 运行两类小型 LLM 任务提取Extraction——从单条消息中抽取持久、结构化的条目。整合Consolidation——把一列记忆总结成 1–3 句忠于原意的句子。这两类任务需要比标题更大的模型1B–1.7B。我们测试了 LFM2-1.2B、Qwen2.5-1.5B、Qwen3-1.7B 和 gemma-3-1bq4、CPU由四个并行 agent 各跑 27–31 组实验。提取环节的发现标准的 5 类别 JSON 提示词在小型模型上会以两种方式失效全空示例{facts:[],...}被逐字照抄→ 提取出 0 条事实。能力较强的模型会在数组里输出JSON 对象Mnemopi 的String(item)会把它们强制转成字面量字符串[object Object]。稳健的修复是每行一条的输出格式由 Mnemopi 解析器的行回退消费或扁平的 JSON 字符串数组。另外所有模型都会过度提取纯闲聊显式的「闲聊 → NONE」示例是最佳缓解手段。与标题任务相反的技术取向在 1B 规模few-shot 成为主导质量杠杆例如 Qwen2.5-1.5B 提取 F1 从 1-shot 的 0.52 提升到 3-shot 的 0.83gemma 的 recall 在 2-shot 下从 0.65 提升到 0.92。Prefill 会伤害提取——它在闲聊上强行输出产生误报。System-split把指令放进 system 角色对拥有 system 角色的模型有帮助。贪心 带温度采样两个任务都如此。Token 偏置同样是无效操作。逐模型结论16 条 fixture 集的直接对比Qwen3-1.7B— 提取最自律闲聊时返回空、无埋没事实泄漏、保留语言、输出干净的扁平 JSON。弱点粒度较粗漏掉了一次多轮值更新。Qwen2.5-1.5B— 提取粒度最佳原子级事实抓住了值更新零闲聊泄漏。弱点整合最弱run-on 长句、不去重且有一次退化的埋没事实输出。gemma-3-1b— 整合最佳去重有效、忠于原意、单条记忆干净。弱点泄漏闲聊、把德语翻译走了。LFM2-1.2B— 稳健且加载最快。弱点Label: value噪声、闲聊 埋没泄漏、单条记忆总结偏水。推荐与当前可用性实验更青睐Qwen3-1.7B的提取精度但已发布的 ONNX 导出目前无法在onnxruntime-node下运行其 RotaryEmbedding cache 更新不受支持。运行时会在加载模型之前就拒绝该选择而不是在推理中途失败——注册表中的onnxUnsupportedReason字段即此原因models.tsworker 在pipeline()入口处即拦截worker.ts。在可运行的选项中注册表把lfm2-1.2b标记为推荐的本地记忆模型DEFAULT_MEMORY_LOCAL_MODEL_KEY见 models.ts。gemma-3-1b偏向整合质量qwen2.5-1.5b偏向细粒度提取。已配置的本地选项llama3.2:3b、qwen3-1.7b如前述当前禁用、gemma-3-1b、qwen2.5-1.5b、lfm2-1.2b。默认设置online。实验暴露的已知 Mnemopi 解析器缺陷String(item)会把对象数组项变成[object Object]。行回退会丢弃10 字符的条目因此Name: Can这类正确的短事实会被丢弃。配置实战从设置项到命令行三个设置项的定义三者在 settings-schema.ts 中均有完整定义providers.tinyModelproviders 标签页 → Tiny Model 组会话标题模型。默认online优先/models中的 TINY 角色否则smol可选三个本地模型。providers.tinyModelDevice本地 tiny 模型标题 记忆的推理后端——一个 ONNX execution provider或mlx在 Apple silicon 上经 mlx-lm 跑 MLX 权重。默认default纯 CPU ONNX。PI_TINY_DEVICE环境变量覆盖它。providers.tinyModelDtype本地 tiny 模型的 ONNX 量化/精度。默认default各模型自带 dtype即 q4精度越低越快越高越忠于原意。MLX 后端忽略此设置其仓库是预量化 4-bit。PI_TINY_DTYPE环境变量覆盖它。记忆与思考分类模型providers.memoryModelmemory 标签页 → General 组条件mnemopiActiveMnemopi 的提取 整合 LLM。默认onlineTINY 角色否则 smol/远程。providers.autoThinkingModelauto思考级别的难度分类器。默认在线 smol 路径本地选项完全复用记忆模型注册表——因为共享 worker 的complete()只接受记忆类本地 key且 1B 记忆模型对编码难度分类的可靠性远高于子 1B 标题模型见 models.ts。CLI 命令omp tiny-models命令提供download与list两个动作tiny-models.ts# 列出全部本地 tiny 模型带推荐标注与描述 omp tiny-models list # 默认下载 lfm2.5-230m omp tiny-models download # 下载指定模型 omp tiny-models download lfm2.5-350m # 预取全部可用模型all 会跳过当前后端拒绝的模型保证批量下载保持绿色 omp tiny-models download all # JSON 输出便于脚本化 omp tiny-models list --jsondownload all的跳过逻辑在 tiny-models-cli.ts非 MLX 后端下会过滤掉带onnxUnsupportedReason的模型即当前的qwen3-1.7b。下载过程带进度条逐字节、显示百分比与文件名错误信息会提炼出可行动的线索如PI_TINY_、CUDA、cuDNN、onnxruntime-node相关行。下载的模型可用prewarm提前建立 worker 连接title-client.ts避免首次生成时在提交热路径上付出探活/拉起延迟。环境变量优先级完整的优先级链条是环境变量 持久化设置 内置默认。PI_TINY_DEVICE/PI_TINY_DTYPE存在时直接覆盖设置设置中的default哨兵值会被映射为「不传」让 worker 使用内置 CPU 默认映射逻辑见 device.ts 与 dtype.ts。集成要点providers.tinyModel、providers.memoryModel、providers.autoThinkingModel默认都是online因此现有用户没有下载或端侧推理开销除非主动选择本地。本地推理运行在worker中不在主线程模型磁盘缓存首次使用下载。记忆的本地路径应用了改进后的配方行格式 闲聊防护的提取提示词、加固的整合提示词作为Mnemopi 提示词覆盖在线路径完全不变。providers.autoThinkingModel使用与providers.memoryModel相同的已发布本地选项。给维护者与进阶用户的速查想让本地标题模型跑在 Apple silicon GPU 上PI_TINY_DEVICEmlxM4 Max 实测预热后标题 15–60ms。想用 Qwen3-1.7B 做记忆提取目前只能走 MLX 后端ONNX 导出被 RotaryEmbedding cache 阻塞在 ONNX 路径上它会在加载前被明确拒绝。追求整合质量选gemma-3-1b追求细粒度提取选qwen2.5-1.5b默认推荐与最快加载选lfm2-1.2b。排查 worker 问题读 socket 旁的*.sock.logworker 异常退出时客户端会把日志尾部拼进错误信息TINY_WORKER_CLOSED见 title-client.ts。测试与 CI 可覆盖的验证面ONNX worker 启动 带 tag 的 ping 握手有专门的冒烟测试入口smokeTestTinyTitleWorkertitle-client.ts选用lfm2.5-230m验证完整启动链路。【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 oh-my-pi 本地小型模型实验指南：tinyModel / memoryModel / autoThinkingModel 的工程化落地
oh-my-pi 本地小型模型实验指南tinyModel / memoryModel / autoThinkingModel 的工程化落地【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pi本文是 oh-my-pi 项目中「嵌入式本地小型模型local tiny-model」实验的完整工程记录。它覆盖会话标题生成providers.tinyModel、Mnemopi 记忆提取与整合providers.memoryModel、以及auto思考级别难度分类器providers.autoThinkingModel复用记忆模型注册表三条可选的本地推理路径包括运行时环境结论、设备与量化策略、实测基准、最终胜出的提示词配方与已发布的模型清单。读完本文你将掌握如何在 oh-my-pi 中配置、下载并运行本地 tiny 模型理解其单 worker 常驻架构与各模型取舍并能直接复现标题生成与记忆提取的调优结论。三条路径默认值均为online即存量用户不会产生任何下载或端侧推理开销只有显式选择本地模型后才开始下载权重。在线路径下优先使用配置的tiny角色未配置时回退到任务专属的在线模型。运行时与环境关键结论技术栈huggingface/transformerstransformers.jsv4 运行在 Bun 之上。在 Bun 中该库加载的是原生onnxruntime-node后端而非 WASM 构建。非 FHS 发行版NixOS 及一切 loader 路径上缺少libstdc.so.6的主机按需加载的onnxruntime-node/sherpa-onnx-node/sharp插件是预编译二进制它们dlopenlibstdc.so.6与libgcc_s.so.1且自带各自的DT_RUNPATHomp 可执行文件自身的 RPATH 无法解析它们。需要设置OMP_NATIVE_LIBRARY_PATH指向存放这些库的冒号分隔目录omp 只会把它追加到推理 worker 子进程的LD_LIBRARY_PATH中绝不会传给 shell/eval/daemon 子进程。Nix 包nix/package.nix默认设置该变量。单 worker 常驻模型每模型一个进程无守护、闲时自退每个本地模型由机器上恰好一个 worker 进程服务该进程拥有 socket~/.omp/run/tiny/model-backend.sockWindows 上是命名管道socket 名与日志路径的推导见 title-protocol.ts第一个需要该模型的 omp 进程会detached 方式拉起 worker日志写在 socket 旁即*.sock.log其他所有 omp 进程只做连接。这样模型在整台机器上只常驻一份而不是每个实例一份。没有任何守护进程监管它worker 在 15 分钟无请求后自行退出OMP_TINY_WORKER_IDLE_MS可覆盖该窗口用于测试代码默认值TINY_WORKER_IDLE_MS 15 * 60 * 1000退出时 unlink 自己的 socket之后任意 omp 进程的下一次请求会重新拉起一个新 worker。并发拉起存在竞争多个进程同时 spawn 时通过.bind.lock文件锁仲裁输家发现 socket 已存活便自行退出其父进程接管赢家。ping返回 launch tag格式为omp 版本|onnx|device|dtype或mlx|mlx-lm 版本|脚本 crc因此当 omp 升级或providers.tinyModelDevice/Dtype改变后客户端会发现 tag 不匹配通知旧 worker 关闭并重新拉起见 title-client.ts 的探活与替换逻辑。两个并发实例若使用冲突的设备配置会不断互相替换对方的 worker所以请约定统一的设备设置。协议是消息级的load、带 messages/prefill/stop/max tokens 的chat提示词构建与标题抽取都在客户端完成因此 ONNX worker 与 MLX worker 两种实现可以互换请求类型定义见 title-protocol.ts。设备策略默认纯 CPU加速失败回退一次本地 tiny 模型默认仅 CPU 推理若显式指定的加速 provider 无法初始化则在 CPU 上重试一次设备回退链实现在 worker.ts 的#loadPipelineWithDeviceFallback中用providers.tinyModelDevice设置持久化选择 providerdefault保持 CPU或用PI_TINY_DEVICE环境变量按次覆盖环境变量优先于设置合并逻辑见 title-client.ts 的tinyWorkerEnvOverlay。可接受值cpu、gpu、mlx/metal、webgpu、auto、cuda、dml、coreml、wasm、webnn、webnn-gpu、webnn-cpu、webnn-npu校验实现见 device.ts非法值会抛错而不是静默降级。coreml保持 opt-in需通过PI_TINY_DEVICEcoreml显式开启不在默认值中因为缓存的 decoder-LLM ONNX 在会话初始化时可能加载失败。WebGPU/Metal 目前只适用于单进程 eval 测试环境生产 worker 会把 Darwin 上的gpu/webgpu/auto请求强制回退到 CPU因为 ONNX Runtime/Bun 目前在 WebGPU 推理后的 worker teardown 阶段会硬崩溃DARWIN_WEBGPU_UNSAFE_ORDER常量即此回退链见 device.ts。只有在显式退出 CPU 默认值时才应使用providers.tinyModelDevice或PI_TINY_DEVICE。MLX 后端Apple silicon直接换掉整个 workerPI_TINY_DEVICEmlx或metal不是切换 ONNX provider而是换用另一个 worker 实现每个模型由mlx-server.py服务它运行在 omp 首次使用时通过uv否则python3 -m venv要求 Python ≥ 3.10安装的、锁定版本的mlx-lmvenv 中位置在~/.omp/agent/cache/tiny-mlx-runtime/。该 worker下载模型的预量化 4-bit MLX 导出注册表中的mlxRepo到~/.omp/agent/cache/tiny-models/mlx/带逐字节进度用mlx_lm.load加载与 ONNX worker 说完全相同的协议因此标题、记忆补全和auto思考分类器都无需改动即可工作整个 Python 进程是唯一涉及的进程忽略PI_TINY_DTYPEMLX 仓库本身就是预量化 4-bit。若 venv 引导失败无 Python、安装错误、非 Apple 主机omp 会记录警告并在该进程剩余生命周期内回退到 ONNX CPU worker。MLX 仅在 darwin/arm64 上可用tinyMlxSupported见 device.ts。实测数据M4 Max冷启动 venv 安装 LFM2.5-230M 下载 加载共 15.7s第二个 omp 实例挂到已运行 worker 上远小于 1s预热后标题生成 15–60msQwen3-1.7B在 onnxruntime-node 上被阻塞下载 984MB回答一次记忆提取约 200ms。量化精度q4 是甜点q4 更小、加载更快、推理也更快q8/int8 在 CPU 上加载更慢且推理更慢。所有已发布的模型默认q4持久化用providers.tinyModelDtype设置覆盖default保持 q4例如用fp16换取更高保真度或按次用PI_TINY_DTYPE环境变量优先。可接受值auto、fp32、fp16、q8、int8、uint8、q4、bnb4、q4f16、q2、q2f16、q1、q1f16无法识别的值会在 worker 启动时大声报错失败见 dtype.ts 的normalizeTinyModelDtype绝不静默加载错误精度。加载耗时修正重要早期「q4 ≥1B 模型加载要几分钟」的结论是测量伪影——由约 5 个多 GB 的 HuggingFace 下载并行进行导致 I/O 饱和。干净、隔离的热加载全部在 3 秒以内模型q4 热加载TinyLlama-1.1B~0.5sLlama-3.2-1BgraphOptall~2.8sLlama-3.2-1BgraphOptdisabled~0.5sLFM2-1.2B~0.36sQwen2.5-1.5B~1.5sQwen3-1.7B~1.6sgemma-3-1b~1.1s结论1B–1.7B 模型在 CPU 上完全可用。session_options.graphOptimizationLevel权衡加载与推理速度disabled 加载最快、推理略慢all 默认。首次运行从 HF Hub 下载权重到缓存目录q4 权重约 150MB–1.1GB视模型而定后续热加载为亚秒级到 ~3s。推理是异步的、对后台友好适合记忆任务标题生成则是半交互式。任务一会话标题生成providers.tinyModel任务把第一条用户消息转成 3–7 个词的标题。子 1B 的 tiny 模型足够胜任。获胜配方纯 system prompt无 few-shot。在 assistant 回合prefilltitle并在/title处stop然后取第一行。贪心解码do_sample:falsechat template 中enable_thinking:false。这些参数直接对应客户端构造的请求title-client.ts 与 worker.tsTITLE_PREFILL title、TITLE_CLOSE /title、TITLE_MAX_NEW_TOKENS 20worker 侧do_sample: false且渲染聊天模板时enableThinking: false。实验教训few-shot 示例会污染子 0.6B 模型的标题使模型照抄示例中的主题。共享提示词对嵌入式模型关闭示例对能力足够的在线模型保留。最小的模型会把大小写指令当成输出。normalizeGeneratedTitle 在生成后统一大小写因此提示词里省略了这条规则。Token 偏置bad_words_ids在此确认为无效操作——prefill 已经控制了开头。替换基准30 条近期首会话提示词q4 CPU无示例模型缓存热加载均值 / p953–7 词命中观察到的取舍LFM2.5-230M214MB93 / 194ms21/28语义平衡最好偶发通用标题Falcon-H1-Tiny-90M147MB117 / 174ms17/29最小复杂输入保真度较低LFM2.5-350M292MB166 / 266ms4/30极度简洁常退化为一个词已发布的本地选项lfm2.5-230m、lfm2.5-350m、falcon-h1-90m。默认设置online。omp tiny-models默认下载lfm2.5-230m常量DEFAULT_TINY_TITLE_LOCAL_MODEL_KEY见 models.ts。注册表还给出了每个模型的来源仓库、dtype 与用途注释models.tsLFM2.5-230M 是「推荐本地模型约 214MB 缓存当前紧凑标题模型中平衡最好」Falcon-H1-Tiny-90M 是「最小选项约 147MB适合对下载体积最敏感的设备」LFM2.5-350M「偏好紧凑标签而非描述性标题」。任务二Mnemopi 记忆providers.memoryModelMnemopi 运行两类小型 LLM 任务提取Extraction——从单条消息中抽取持久、结构化的条目。整合Consolidation——把一列记忆总结成 1–3 句忠于原意的句子。这两类任务需要比标题更大的模型1B–1.7B。我们测试了 LFM2-1.2B、Qwen2.5-1.5B、Qwen3-1.7B 和 gemma-3-1bq4、CPU由四个并行 agent 各跑 27–31 组实验。提取环节的发现标准的 5 类别 JSON 提示词在小型模型上会以两种方式失效全空示例{facts:[],...}被逐字照抄→ 提取出 0 条事实。能力较强的模型会在数组里输出JSON 对象Mnemopi 的String(item)会把它们强制转成字面量字符串[object Object]。稳健的修复是每行一条的输出格式由 Mnemopi 解析器的行回退消费或扁平的 JSON 字符串数组。另外所有模型都会过度提取纯闲聊显式的「闲聊 → NONE」示例是最佳缓解手段。与标题任务相反的技术取向在 1B 规模few-shot 成为主导质量杠杆例如 Qwen2.5-1.5B 提取 F1 从 1-shot 的 0.52 提升到 3-shot 的 0.83gemma 的 recall 在 2-shot 下从 0.65 提升到 0.92。Prefill 会伤害提取——它在闲聊上强行输出产生误报。System-split把指令放进 system 角色对拥有 system 角色的模型有帮助。贪心 带温度采样两个任务都如此。Token 偏置同样是无效操作。逐模型结论16 条 fixture 集的直接对比Qwen3-1.7B— 提取最自律闲聊时返回空、无埋没事实泄漏、保留语言、输出干净的扁平 JSON。弱点粒度较粗漏掉了一次多轮值更新。Qwen2.5-1.5B— 提取粒度最佳原子级事实抓住了值更新零闲聊泄漏。弱点整合最弱run-on 长句、不去重且有一次退化的埋没事实输出。gemma-3-1b— 整合最佳去重有效、忠于原意、单条记忆干净。弱点泄漏闲聊、把德语翻译走了。LFM2-1.2B— 稳健且加载最快。弱点Label: value噪声、闲聊 埋没泄漏、单条记忆总结偏水。推荐与当前可用性实验更青睐Qwen3-1.7B的提取精度但已发布的 ONNX 导出目前无法在onnxruntime-node下运行其 RotaryEmbedding cache 更新不受支持。运行时会在加载模型之前就拒绝该选择而不是在推理中途失败——注册表中的onnxUnsupportedReason字段即此原因models.tsworker 在pipeline()入口处即拦截worker.ts。在可运行的选项中注册表把lfm2-1.2b标记为推荐的本地记忆模型DEFAULT_MEMORY_LOCAL_MODEL_KEY见 models.ts。gemma-3-1b偏向整合质量qwen2.5-1.5b偏向细粒度提取。已配置的本地选项llama3.2:3b、qwen3-1.7b如前述当前禁用、gemma-3-1b、qwen2.5-1.5b、lfm2-1.2b。默认设置online。实验暴露的已知 Mnemopi 解析器缺陷String(item)会把对象数组项变成[object Object]。行回退会丢弃10 字符的条目因此Name: Can这类正确的短事实会被丢弃。配置实战从设置项到命令行三个设置项的定义三者在 settings-schema.ts 中均有完整定义providers.tinyModelproviders 标签页 → Tiny Model 组会话标题模型。默认online优先/models中的 TINY 角色否则smol可选三个本地模型。providers.tinyModelDevice本地 tiny 模型标题 记忆的推理后端——一个 ONNX execution provider或mlx在 Apple silicon 上经 mlx-lm 跑 MLX 权重。默认default纯 CPU ONNX。PI_TINY_DEVICE环境变量覆盖它。providers.tinyModelDtype本地 tiny 模型的 ONNX 量化/精度。默认default各模型自带 dtype即 q4精度越低越快越高越忠于原意。MLX 后端忽略此设置其仓库是预量化 4-bit。PI_TINY_DTYPE环境变量覆盖它。记忆与思考分类模型providers.memoryModelmemory 标签页 → General 组条件mnemopiActiveMnemopi 的提取 整合 LLM。默认onlineTINY 角色否则 smol/远程。providers.autoThinkingModelauto思考级别的难度分类器。默认在线 smol 路径本地选项完全复用记忆模型注册表——因为共享 worker 的complete()只接受记忆类本地 key且 1B 记忆模型对编码难度分类的可靠性远高于子 1B 标题模型见 models.ts。CLI 命令omp tiny-models命令提供download与list两个动作tiny-models.ts# 列出全部本地 tiny 模型带推荐标注与描述 omp tiny-models list # 默认下载 lfm2.5-230m omp tiny-models download # 下载指定模型 omp tiny-models download lfm2.5-350m # 预取全部可用模型all 会跳过当前后端拒绝的模型保证批量下载保持绿色 omp tiny-models download all # JSON 输出便于脚本化 omp tiny-models list --jsondownload all的跳过逻辑在 tiny-models-cli.ts非 MLX 后端下会过滤掉带onnxUnsupportedReason的模型即当前的qwen3-1.7b。下载过程带进度条逐字节、显示百分比与文件名错误信息会提炼出可行动的线索如PI_TINY_、CUDA、cuDNN、onnxruntime-node相关行。下载的模型可用prewarm提前建立 worker 连接title-client.ts避免首次生成时在提交热路径上付出探活/拉起延迟。环境变量优先级完整的优先级链条是环境变量 持久化设置 内置默认。PI_TINY_DEVICE/PI_TINY_DTYPE存在时直接覆盖设置设置中的default哨兵值会被映射为「不传」让 worker 使用内置 CPU 默认映射逻辑见 device.ts 与 dtype.ts。集成要点providers.tinyModel、providers.memoryModel、providers.autoThinkingModel默认都是online因此现有用户没有下载或端侧推理开销除非主动选择本地。本地推理运行在worker中不在主线程模型磁盘缓存首次使用下载。记忆的本地路径应用了改进后的配方行格式 闲聊防护的提取提示词、加固的整合提示词作为Mnemopi 提示词覆盖在线路径完全不变。providers.autoThinkingModel使用与providers.memoryModel相同的已发布本地选项。给维护者与进阶用户的速查想让本地标题模型跑在 Apple silicon GPU 上PI_TINY_DEVICEmlxM4 Max 实测预热后标题 15–60ms。想用 Qwen3-1.7B 做记忆提取目前只能走 MLX 后端ONNX 导出被 RotaryEmbedding cache 阻塞在 ONNX 路径上它会在加载前被明确拒绝。追求整合质量选gemma-3-1b追求细粒度提取选qwen2.5-1.5b默认推荐与最快加载选lfm2-1.2b。排查 worker 问题读 socket 旁的*.sock.logworker 异常退出时客户端会把日志尾部拼进错误信息TINY_WORKER_CLOSED见 title-client.ts。测试与 CI 可覆盖的验证面ONNX worker 启动 带 tag 的 ping 握手有专门的冒烟测试入口smokeTestTinyTitleWorkertitle-client.ts选用lfm2.5-230m验证完整启动链路。【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考