从手机阅读到电子墨水

这位开发者习惯用手机浏览个人博客和技术文章，但长时间盯着屏幕容易让眼睛疲劳。他偶然发现了一款名为 X4 的 4.3 英寸电子墨水阅读器，它由中国厂商 Xteink 出品，没有触摸屏、没有背光，也不预装任何书店。听起来像是缺点，却恰好符合「只读内容、不被推送打扰」的需求。

更让他意外的是，社区为这款设备开发了名为 Crosspoint 的开源固件，安装过程只需要点三下。随后他买来一本无 DRM 保护的电子书测试，复制到 X4 后直接就能阅读，几乎不需要折腾。

feedpaper：把 RSS 转成每日报纸

真正让这个项目成型的是一个叫 feedpaper 的小工具，已托管在 GitHub 上，可以通过 Homebrew 安装。它的逻辑很直接：

• 从 Feedbin 的 API 抓取所有未读订阅
• 过滤掉不适合电子墨水阅读的内容（例如 YouTube 频道、依赖 JavaScript 的博客、纯链接简报）
• 把剩余文章打包成 ePub 格式
• 标记这些条目为已读，方便下次不再重复抓取

开发者表示，借助 AI 的帮助，整个脚本只花了「几分钟」就搭出雏形。早晨生成好 feedpaper，拷进 X4，带上阅读器出门喝咖啡，手机则可以留在家里。

为什么这件事值得关注

这个项目的关键不在于硬件本身，而在于它展示了一种把已有工具重新组合的工作流：RSS 聚合服务负责内容来源，开源固件负责硬件体验，AI 负责快速把想法变成脚本。对于希望减少屏幕时间、回归深度阅读的人来说，这比直接买一台功能繁杂的平板更轻量。

当然，这套方案也有门槛：需要 Feedbin 账号，需要 X4 或兼容 Crosspoint 的 ESP32C3 设备，目前也只支持 macOS。但它提供了一种思路——数字生活的简化，有时候不是换一台更贵的设备，而是把几个开源工具串起来。

来源：heyjonny.dev｜项目地址：https://github.com/jonashonecker/feedpaper

vLLM 由加州大学伯克利分校团队于 2023 年开源，采用 Apache 2.0 协议，目前已是开源大模型私有化部署事实上的主流选择，被大量云平台和推理服务商集成。它的核心思路，是把操作系统管内存的老办法搬到了 GPU 上。

把显存当成分页内存来管

传统推理框架给每个请求预留一整段连续显存，按最大可能长度分配。一个请求只生成了 100 个词，却按 4096 个词的规格占着位置，浪费极其可观。

vLLM 的做法是分页。KV 缓存（模型生成时缓存的键值向量，避免重复计算）被切成固定大小的块，默认每块存 16 个 token。每个请求维护一张块表，把逻辑上连续的缓存映射到物理上零散的显存页。单块占用的字节数按「2（键和值）× 块大小 × KV 注意力头数 × 头维度 × 数据类型字节数」计算，块池规模常常达到数十万块。

调度器的核心数据结构就是这个空闲块队列。每来一批新词，allocate_slots 先算需要几块——比如预填充阶段有 17 个新词，就是向上取整 17÷16 等于 2 块；池子不够时，引擎会抢占低优先级请求，把它们已占用的块归还池中。

预填充和解码，是两种完全不同的活

引擎面对的负载分两类：预填充是对整段提示词做一次前向计算，属于计算密集型；解码只处理最新一个词，但仍要把整个模型权重和缓存读一遍，属于显存带宽密集型。

老版本 V0 引擎一个步骤内只能二选一，新版 V1 调度器可以把两类请求混在同一步里跑。调度顺序上，已在运行队列中的解码请求优先，剩余的词预算再分给等待队列里的预填充请求。调度策略支持先来先服务和按优先级两种。

前向计算时，所有序列被拍平拼接成一条「超级序列」，靠位置索引和注意力掩码保证各自只看自己的内容。这样就不需要右侧补齐，也就天然支持连续批处理——完成一个请求立刻释放资源补进新请求，GPU 不必等最慢的那条跑完。

四个让长请求不拖后腿的设计

分块预填充：把超长提示词的预填充切成小段，避免一个长请求独占一个引擎步骤，把其他请求的延迟全部拉高。参数上表现为给 long_prefill_token_threshold 设一个正整数。

前缀缓存：多轮对话中系统提示词和历史消息是重复的，相同前缀的缓存块可以在请求之间共享，不必重算。

引导解码：用语法约束的有限状态机限制采样范围，让输出严格符合指定格式。

投机解码与 PD 分离：前者用小模型先猜若干个词再由大模型批量验证，后者把预填充和解码拆到不同资源上执行。

启动时那几秒都在干什么

引擎构造阶段，工作进程会依次完成三件事：分配 CUDA 设备并按 gpu_memory_utilization（例如设为 0.8 即占用八成显存）核对余量、加载模型权重并切换到推理模式、初始化 KV 缓存。

最后一步会先跑一次空转前向计算，对显存拍个快照，据此反推能塞下多少个缓存块。除非显式指定 --enforce-eager，引擎还会针对若干预热批量大小捕获 CUDA Graph，把整串 GPU 操作录成一张有向无环图，后续直接回放，省下逐个启动内核的开销。

这些机制叠加起来，才是「同一张卡多扛几倍请求」的真正来源。对于正在做私有化部署、纠结要不要加卡的团队，先把引擎参数调明白，往往比直接采购更划算。

来源：Aleksa Gordić 技术博客《Inside vLLM: Anatomy of a High-Throughput LLM Inference System》、vLLM 开源项目

问题出在各家自己存自己的

wallfacer 的项目文档里，把这个痛点讲得很直白。

Claude Code 把每一次对话都存成 ~/.claude/projects/ 目录下一个没有标题的 JSONL 文件，用户当时所在的目录就是唯一的索引依据。Kiro CLI 的做法类似，所有会话平铺在 ~/.kiro/sessions/cli/ 一个文件夹里。Cursor CLI 则把每段对话埋进 ~/.cursor/chats/ 下面以哈希值命名的目录。Codex 又是另一套，按日期把运行记录归档在 ~/.codex/sessions/ 中。

几周下来，四款工具留下几十份彼此难以分辨的记录，而且没有任何办法把需要的那一份找出来。

wallfacer 的定位是把这些记录统一索引起来。项目文档中特别注明，索引过程是只读的，绝不改动各家智能体自己的文件；用户添加的标题、标签和项目分组，全部存放在 wallfacer 自己的本地 SQLite 数据库里，路径为 ~/.local/share/wallfacer/。删掉这个数据库，丢失的只是这层附加信息，对话本身不受影响。

一个程序，两副面孔

wallfacer 是单个二进制程序，但提供两种使用方式，区别只在于有没有跟子命令。

直接输入 wallfacer，进入的是全屏交互式会话浏览器；输入 wallfacer <子命令>，则是一次性执行的命令行模式，适合写进脚本。项目文档强调，这两者并非彼此独立的工具，也不存在切换的概念——它们读写的是同一份 SQLite 索引，在浏览器里打的标签，立刻就能被 wallfacer list --tag 检索到，反之亦然。浏览器能做的事，子命令同样能做。

浏览器模式下的操作是典型的终端界面风格：上下方向键或 j、k 移动；斜杠键触发模糊筛选，检索范围覆盖标题、项目、目录、标签和智能体名称；P、T、A 三个键分别循环切换项目、标签和智能体筛选条件，x 键一次性清空；回车键恢复会话，终端交给智能体接管，退出后自动返回浏览器；n 键新建会话，r、t、p 分别用于重命名、编辑标签和设置项目；d 键删除。当终端宽度低于约 100 列时，详情面板会自动让位，列表占满整个宽度。

命令行模式提供的子命令包括新建（new）、恢复（resume）、列表（list）、搜索（search）、查看详情（show）、重命名（rename）、标签增删（tag add/rm）、项目分组（project set/clear）、删除（rm）和重新扫描（sync）。其中 sync 会在每条命令执行前自动运行一次，无需手动触发。

引用某个会话时，既可以用编号前缀，比如 resume 5f2，也可以用完整标题，比如 resume "smoke test"。如果引用存在歧义，程序会列出所有候选项，而不是自行猜测。在 wallfacer 之外启动的会话会被自动识别，不需要任何导入步骤。

删除这件事，做得比较细

删除逻辑上，wallfacer 做了两层设计。rm 命令只是把会话移入自带的回收站，只有加上 --purge 参数才会永久删除。

更细的一处考虑在于多文件会话。Kiro CLI 一次会话会写出一份对话记录、一个元数据附属文件、提示词历史和一个临时目录；Cursor CLI 则把一段对话拆成两半，一部分在自己的目录下，另一部分归档到项目名下。wallfacer 在删除时会把这一整组文件一起处理，避免出现「已经删了，却还留在智能体自己的会话列表里」的情况。

索引采用增量同步，项目文档称，即使积累了数百个会话，速度依然能保持。

更新检查也考虑了管道场景

一个容易被忽略但设计得比较克制的细节是版本更新提示。浏览器每天向 GitHub 查询一次是否有新版本，如果有，只在页脚提示一次；子命令则直接复述这个缓存结果，且输出到标准错误流，因此不会污染 --json 的输出内容，也不会混进管道。整个查询过程不会阻塞任何操作，命令行侧读取的是缓存文件而非发起网络请求。设置环境变量 WALLFACER_NO_UPDATE_CHECK=1 可以彻底关闭这项功能。

安装与后续规划

安装方式有两种。在 macOS 或 Linux 上可通过 Homebrew 安装，也可以用 Go 直接安装，要求 Go 1.22 及以上版本。项目同时在发布页提供了预编译的可执行文件。项目文档提到，Homebrew 配置文件放在本仓库内而非单独的 tap 仓库，这也是安装时需要写全地址的原因，配置完成后升级命令照常使用。

路线图方面，目前已支持 Claude Code、Cursor CLI、Kiro CLI 和 Codex 四款智能体的适配器，opencode 的适配器在计划中。后续还打算加入默认智能体设置、基于 SQLite FTS5 的会话全文搜索、命令行侧的回收站恢复功能、把会话记录导出为 Markdown、统计功能（按项目或周统计会话数与磁盘占用），以及一个桌面客户端——侧边栏列会话、内嵌终端、支持多标签页，底层复用同一套 Go 代码。

项目采用 MIT 许可证，用 Go 语言编写，其他智能体可通过一个小型适配器接口接入。作者在文档中表示，欢迎贡献，尤其欢迎新的智能体适配器。截至本文整理时，该仓库在 GitHub 上有 14 个星标和 2 次复刻，提交次数为 34 次。

来源：GitHub / pradipta（wallfacer 项目页）、Hacker News

这里的关键词是「训练」，不是「运行」。前向传播、反向传播、权重更新，整个学习循环全部发生在芯片内部。

和以往的边缘 AI 项目差在哪

边缘 AI 并不新鲜。TinyML 在单片机上做推理已有多年，社区把安德烈·卡帕西（Andrej Karpathy）的极简项目 llama2.c 移植到 ESP32 上，跑起了约 26 万参数的 Transformer；最近还有项目在同样八美元的 ESP32-S3 上跑起了将近 2900 万参数的模型。

作者指出，这些工作都很出色，但它们有一个共同点——都是推理。模型诞生在别处，在显卡或数据中心上用数据训练好、量化，然后才被装进芯片里运行。用项目作者的比喻说，大脑是在外面煮熟了端上来的。

Qapla’ 想回答的是另一个问题：如果模型根本没法在外面诞生，会怎么样？

作者举了两个设想中的场景：一个螺栓固定在田间农机上的传感器，需要学习这一台机器的正常振动特征——它和世界上任何其他机器都不一样——从而在出故障前发现异常、安排检修；或者一块地里的传感器，学习这片土壤如何变干，它的土质、日照和排水情况，在作物受影响之前预测何时需要灌溉。这些场景里，数据在设备装上去之前根本不存在，没有人能预先训练它，芯片只能在原地独自学习。

为什么选了克林贡语

手头没有农机可供实验，作者就用唯一现成的对象来测试芯片的真实学习能力：语言。

在单片机里训练，规则和数据中心完全不同。ESP32-S3 只有几 MB 的 RAM/PSRAM，而不是几十 GB，这直接锁死了模型规模——量级是几十万参数而非几百万。这么小的模型能学会一门语言的结构（构词方式、音位组合规则、部分语法），但学不会整门语言的深层语义，所以任务必须裁到与模型相称。同时，小模型不需要海量文本，需要的是紧凑、干净、结构清晰，并且在版权上没有麻烦的语料。

三个约束叠加，问题就变得具体了：哪种语言同时满足这些条件？作者的答案是克林贡语。

这个选择工程考量多过极客趣味。克林贡语由语言学家马克·奥克兰（Marc Okrand）在 1984 年创造，是一门有系统音系、语法和形态的人造语言，采用不常见的宾语—动词—主语语序，构词后缀规则严格。也就是说，它有真实的结构可供学习，这正好能证明小模型是真的在学规律，而不是在死记噪声。同时它字母表很小，按字符处理只有约 30 个符号，模型可以做得足够小；社区还有一部开源许可的词典 boQwI’，语料不涉及版权风险。

作者也把丑话说在前面：这不是口袋版 ChatGPT，它不聊天、不答题、不推理，学到的是语言的形状而不是意义；它产出的克林贡语在语义上并不完美；它不快，训练要花好几个小时，甚至好几天。

一颗芯片里的完整训练循环

在 ESP32-S3 内部完成的步骤包括：权重随机初始化、读取并切分语料、前向传播、交叉熵损失计算、反向传播（导数全部手写）、权重更新（带 0.9 动量的 SGD 加余弦学习率）、把检查点存入 LittleFS 闪存，以及用学到的权重生成文本。芯片之外要做的事：没有。

架构本身没有新意，是一个微型但完整的 Transformer：单个模块、单头因果注意力、权重绑定、ReLU 前馈网络和层归一化，按字符工作，词表约 31 个符号，上下文 32 个字符，总计约 319,000 个参数。

这里没有 PyTorch，也没有自动求导，前向传播的每一个导数都用 C 显式写出。为确认没写错，每个梯度都与前向传播的中心差分做了对比，最差相对误差为 1.07e-08，而阈值是 1e-4；内核还先用 ESP-IDF 构建并在 QEMU 的 xtensa 模拟环境中跑通，然后才烧进真实硅片。这两项检查都放在仓库的 tests/ 目录里，可以自行复现。

作者强调，真正的难点不是参数量，而是内存。31.9 万参数「只」占约 1.3 MB，但训练不只是放下权重：同一时刻内存里还要有等量大小的梯度副本、一份优化器动量、一份最优模型备份，加上反向传播需要的全部中间激活值，再加上语料本身——加起来是芯片 PSRAM 里的好几 MB。这就是推理与训练的本质差别，也是这个项目与其他边缘 AI 项目的分野。

跑出来的数字

全部训练在芯片内完成，供电靠一个手机充电器。参数约 319,000 个，词表 31 个字符，上下文 32 个字符，优化器为带动量（0.9）的 SGD 加余弦学习率，共 5000 步，耗时约两天，硬件是 ESP32-S3 N16R8 搭配一块 SH1106 OLED 屏。

损失下降过程如屏幕上所显示：第 1495 步批次损失 2.193、移动平均 2.137；第 2549 步为 1.982 与 2.035；第 4905 步为 1.996 与 1.871。作者提醒，真正该看的是移动平均——单个批次的损失取决于抽到哪些句子，波动很大，而平均值在稳步下降。芯片最终收在约 1.87。

模型吐出的文本长这样：

hIngan motlh puS ruq tuq DujDaq SISwI’ nge’vI’

>

vIn SuvwI’ yIvwI’ qarghtaHvIS SIchoH

不算完全通顺的克林贡语，但形态学值得一看：SuvwI’ 意为「战士」，由词根 Suv（战斗）加后缀 -wI’（做某事的人）构成，是一个构造正确的真实词汇；DujDaq 意为「在船上」，由 Duj（船）加处所后缀 -Daq 构成；qarghtaHvIS 带有复合后缀 -taHvIS（表示「当……时」，持续体加状语），位置分毫不差；hIngan 距离 tlhIngan——也就是「克林贡」这个词本身——只差两个字母。

其余一些词构造合规但并不存在。没有人给模型任何规则、语法标签或形态切分，喂进去的只是逐字符的原始文本，它从中捕捉到了足够的规律，把词根和后缀重组成站得住脚的形状。作者也坦承，仅凭两个样本无法判断其中多少是真正的泛化、多少是语料的统计回声，「一个用小语料训练的 31.9 万参数模型，预期就是二者兼有」。

想自己试的话

语料 corpus/klingon.txt 已随仓库提供，采用 Apache 2.0 许可，可用 corpus/build_corpus.py 重新生成，克隆下来就能跑。不过作者认为更有意思的实验不是重复他的，而是把这套东西对准自己的文本：用 tools/gen_header.py 把任意文本转成头文件，再用 PlatformIO 执行 pio run -t upload 烧录，然后用 pio device monitor 看着损失实时下降。

硬件需要一块带 PSRAM 的 ESP32-S3（型号 N16R8），一块通过 I2C 连接的 SH1106 OLED 屏（可选，但作者说少了它就少了一半乐趣）。芯片从随机权重开始训练，会定期保存训练损失移动平均最低的检查点；中途拔电，上次存档之后学到的东西就没了，跑完再拔，「大脑」还在。

需要提醒的是：这真的要花好几个小时，很多个小时，甚至好几天。用作者的话说，这不是 bug，而是重点所在——它慢，但它确实能跑通。

项目代码采用 Apache 2.0 许可开源。作者表示，接下来真正有意思的部分，是把这套引擎推到极限，去处理一门有真实使用者、语料远大于克林贡语的真实小语种。

来源：GitHub / Qapla’ 项目主页（经 Hacker News）

它叫 Soup，最近登上 Hacker News 首页，标题很直白：在 4GB 笔记本显卡上微调 80 亿参数模型。项目采用 Apache-2.0 开源协议，目前在 GitHub 上有 147 颗星、23 个分支，累计 605 次提交。

一个配置文件，一条命令

Soup 想解决的是老问题。项目自述里写道，即便是有经验的团队，也要把 30% 到 50% 的时间花在跟基础设施较劲上，而不是改进模型。它的做法是把整套流程压成一个配置文件加一条命令：安装 `pip install “soup-cli[train]”`，然后 `soup init –template chat` 生成配置、`soup train` 开跑。批大小、显卡识别、量化全部自动处理，不需要远程登录服务器，也不需要云端资源。

真正让它能在 4GB 显卡上跑起来的是「层流式加载」：冻结的基座模型不常驻显存，而是按解码层逐层喂给显卡，配合 4bit NF4 量化把模型体积压到约四分之一，80 亿参数模型就能塞进 4GB 显卡。

新版本把偏好训练也拉了进来

最新的 v0.72.4 版本把这套机制扩展到了偏好对齐训练——也就是让模型学会「这个回答比那个好」的调优阶段。以往层流式加载只支持监督微调，现在直接偏好优化（DPO）以及 ORPO、SimPO、KTO 三种方法也能跑。

其中 DPO 需要一个参考模型做对照，常规做法要再加载一份权重、内存直接翻倍，那样省显存的意义就没了。Soup 的处理是复用同一份流式基座、把适配器关掉，等于一份权重、一条数据流。在 RTX 3050 4GB 显卡上实测，流式 DPO 的显存峰值是监督微调峰值的 0.914 倍；而强行加载真正的第二份模型，同样测试下多吃 730MB，正好是一份权重的大小。

难得的是把代价也写清楚了

这个项目最值得留意的地方，不是省显存，而是它把账算给你看。文档明确写出：参考模型省的是内存不是时间，DPO 每步读取层栈的次数是监督微调的 1.52 倍；GRPO 和 PPO 两种强化学习方法被有意排除在外，因为生成阶段每输出一个词都要重读所有层，流式加载省不出来。作者还标注训练结果与非流式版本逐位一致（差异为 0），并说明整个项目是在一台 4GB 笔记本上开发维护的，因此多显卡、更大模型和苹果芯片的支持都还没验证，相关功能都挂着明确的前置条件说明。该特性目前仍标注为测试版。

官方给出的显存对照是：8GB 约能带 70 亿参数、16GB 约 140 亿、24GB 约 340 亿、48GB 约 700 亿。项目内置 100 多个现成配方，覆盖通义千问、Llama 3、Gemma 3、Mistral、DeepSeek R1/V3、Phi-4 等模型，模板涵盖对话、代码、工具调用、推理、视觉、长上下文等场景。

我的判断是，这类工具的价值在于把「能不能跑」变成「值不值得跑」。手上这块小显卡，你打算拿它微调点什么？

来源：GitHub / Soup 项目页，Hacker News

他做的开源工具叫 claude-real-video，采用 MIT 许可、完全在本地运行。核心结论是：抽帧不该按秒数均匀采样。定时采样会同时犯两个错——把一堆几乎一样的人头特写塞满预算，又恰好跳过真正发生事情的那一秒。

他的做法是让阈值自己浮动：先算出每一帧的画面变化分数，再跟滚动平均值比，高动态素材自动抬高门槛，安静素材自动降低，不用人调参。去重则拆成三条通道——全局通道用 16×16 的色彩指纹判断整体变化；动作通道改用 32×32 网格，只要少数格子剧烈变化就保留，专治”画面里的人只占半个百分点”这类小主体；第三条通道精度提到 192×192，专门抓字幕更换、白板上多出一行字这种局部微变。有意思的是，第二条通道不是测出来的，是一位用户跑了 2181 段真实视频之后反馈出来的。

说白了，视频理解眼下卡的不是模型看不懂，而是给它看什么。这跟写提示词是同一件事：信息密度比信息总量重要。

如果你在做视频相关的自动化，不妨先检查一下自己的抽帧逻辑，是不是还停在”每秒一帧”。

来源：leoaido.com（作者黄志弘）