让正文阅读与延伸浏览形成一条连续的信息链路
内容页聚焦阅读稳定性、元信息清晰度与下一步跳转意愿, 通过更集中化的文章主区域、可快速识别的内容辅助模块与轻量分享动作, 让阅读完成后的后续浏览更加自然。
内容页聚焦阅读稳定性、元信息清晰度与下一步跳转意愿, 通过更集中化的文章主区域、可快速识别的内容辅助模块与轻量分享动作, 让阅读完成后的后续浏览更加自然。
在阅读场景中减少视觉干扰,同时保留必要的跳转与推荐能力。
为了完成毕业设计,他想搞清楚一家小公司要在本地跑语言模型,到底需要什么样的硬件。他的办法很原始:下载一个模型,看着它崩溃或者慢得像爬,再换一个量化版本重来。后来他干脆把这个过程做成了工具,取名 Jaull。 Jaull 是一个带终端界面的开源 Python 工具。它会检测你的 CPU、内存、GPU 以及可用的后端,再问几个简单问题——你打算拿它做什么、最在意什么、需要哪些语言、是否商用——然后只用元数据在 Hugging Face 上检索。最终给出最多五个具体方案,每个方案都对应确切的文件、运行时、后端和 GPU 卸载配置,并附上它为什么排在这个位置。 估算和实测分开 Jaull 按组件估算内存:权重、KV 缓存、额外开销、余量,并把内存和显存当作两个池子分别计算,因此能告诉你先耗尽的是哪一个。想验证的话,可以在自己机器上运行、跑基准测试或给方案打分。每条结果都会连同文件的 SHA-256、机器信息和测试协议一起保存,只有与某个方案匹配的结果才能改变推荐顺序。一个 Q5_K_M 文件的基准成绩,说明不了旁边那个 Q6_K 的表现。 他在自己的 RTX 2060 上得到了一些数字: 1.2B 模型在指令遵循上大幅胜过 1.5B 模型 ,这本身就是不该按参数量排名的好理由。 他做错的地方 第一版卸载策略让大部分 GPU 闲置。在 Qwen2.5-7B 上只跑到 21.5 tok/s ,而把所有层都放到 GPU 上、只多占 133 MB 显存,就能到 59.4 。修正公式之后,同样的运行达到了 44.9 。 他还做过一个每秒 token 数预测器。一个简单版本给某个模型估了 170 tok/s,实测只有 18。他把预测功能从界面里删掉了,现在 Jaull 只在实测之后才显示速度。 有些数字根本测不了。在负责驱动显示器的 GeForce 上,Windows 不会按进程报告显存占用,Jaull 在那里会直接标注“不可比较”。 用法是克隆仓库、进入目录、同步依赖,然后直接运行。拿推荐不需要 llama.cpp,只有真正跑方案时才需要。他还没有在真实硬件上测试过 Intel(Vulkan)和 AMD 的支持,如果有人试了,他想知道工具为你的机器推荐了什么。按他自己的说法,Jaull 还不是一个完成品。 特别