最新

各位 HN 的朋友们： 我开发了一款游戏，玩家需要通过在中间城市之间跳跃，从 A 点旅行到 B 点。 每次跳跃都有最大距离限制，所以你不能直接选择目的地。你需要规划一条路线，经过距离相近的城市，并尽量减少跳跃次数。 听起来很简单，直到你需要穿越一个你只知道一两个城市的地区。我发现这款游戏展现了一种不同类型的地理知识：不仅仅是知道国家在哪里，而是理解城市在一个区域内是如何相互连接的。 游戏设有固定的每日路线，供大家比较，同时还有无限次的练习游戏、每周挑战和多人模式。 希望大家喜欢这款游戏，我非常期待大家的反馈！

随着旧的编码模型编写并公开代码，新的编码模型是否会因为旧模型生成的代码质量不高而对其进行训练？

似乎每个人都过于关注季度业绩——通常并没有什么实质性的变化，但人们却对此大做文章。 投资界存在两大阵营：一种人认为存在泡沫，另一种人认为一切只会涨。这两种观点都错了。泡沫是新技术浪潮的固有产物；每一次泡沫都不同，都有其自身的情况。你不应该因为预期泡沫而等待。你无法准确把握市场时机；你应该专注于寻找那些正在建立竞争壁垒，或者正在拓展或转型业务模式，但尚未完成这些举措的公司。你必须通过分析来弄清楚这一点。仅仅因为你认为苹果（AAPL）拥有强大的品牌就想通过投资它来跑赢指数，这是不可能的，因为其他所有人也这么认为。 认为一切只会涨的阵营，在批评那些认为存在泡沫的人时是有道理的，因为记忆中的抛售，或者某家公司业绩不佳。从技术上讲，基本面并没有改变，但更广泛的资本周期解释了为什么收益是不可持续和人为的，并且将会崩溃，而对新技术的强劲需求是因为公司不想错过机会；最初的热潮总会消退，数据中心积压订单是个谎言。关于资本周期的更多内容请看这里。 说了这么多，只是想告诉你，直接购买指数基金就好。

runNburn 是一个 Apache-2.0 协议的 Rust 推理引擎，用于处理那些因过大而无法完全载入快速内存的量化 GGUF 模型。 核心理念：权重保持文件映射（mmap），主机内存占用保持在明确的字节预算（--ram-budget）之下，GPU 缓存大小根据检测到的可用/总 VRAM 来确定，而不是设备名称预设。没有转换步骤，没有侧载缓存文件，也没有静默的重新量化。磁盘上的 GGUF 文件是唯一的真相来源。 促使我发布此消息的结果：Tencent 的 Hy3（总计 295B 参数 / 21B 激活稀疏 MoE，单个 97.8 GiB 的 Q2_K GGUF 模型）可以在我拥有 64 GB RAM 和一块消费级 NVIDIA GPU 的台式机上运行。该文件比 RAM 和 VRAM 的总和还要大；每个 token 选择的专家是按需加载的（最新的路径通过 io_uring 进行 O_DIRECT 读取批处理），而预训练的路由保持不变。在同一台机器上，使用相同的提示，相同的解码长度，一次预热运行的中位数解码速度约为 5.5 token/秒，而 llama.cpp 的速度约为 2.0 token/秒。 关于范围的说明：对于可以轻松载入 VRAM 的模型，llama.cpp 目前仍然比 runNburn 快——它的 CUDA 内核经过了多年的优化，我们诚实地与它进行比较（交替进行 A/B 运行，取中位数，任何改变输出质量的“加速”都会被拒绝）。runNburn 的优势在于处理那些无法完全载入的模型。 包含内容： - 命令行界面、交互式聊天和兼容 OpenAI 的服务器（聊天/补全 + 响应 + 对话，SSE 流式传输，通过 KV/SSM 快照重用进行有状态的续接）。它被构建为一个单用户个人服务器——一次活跃生成是优化单元；连续批处理和多租户吞吐量明确不是目标。 - 架构感知路径：Llama 系列、Phi、Gemma、Qwen 密集/混合/MoE（包括 GatedDeltaNet 层）、Nemotron-H MoE、Hy3、GLM——以及模型内的多 token 预测（自推测解码），在 GGUF 提供 drafter 的情况下进行设备端验证。 - 后端：CPU 是默认选项（x86 AVX2，ARM NEON），CUDA 和 Metal 是活跃的，Vulkan/OpenCL 是实验性的。Android 通过一个小型的 C ABI (rnb.h) 工作。 - 原生的量化内核支持 Q2_K–Q6_K、Q4_0、Q8_0——包括大型 MoE 模型实际使用的低比特 K-quant。 它处于 1.0 版本之前，在某些地方可能还不完善；识别一种架构并不意味着社区中的所有变体都能正常工作。但如果你有一个比你的机器还大的模型文件，并且宁愿它运行得慢一些而不是根本无法运行，那么这正是它被设计来解决的情况。 我很乐意回答关于卸载设计、专家流式传输路径或测量协议的问题。

大家好，我开发了一个浏览器扩展程序，可以为任何网站添加左边距或右边距，从而帮助居中显示网站内容。 您可以在此处观看视频演示：https://www.youtube.com/watch?v=Yc29sO4jF9g 源代码可在以下地址获取：https://github.com/rinn7e/damn-center-extension 如果您喜欢这个项目，可以请我喝杯咖啡：https://github.com/sponsors/rinn7e

这是接下来的待办事项！ 对它们进行排序，与截图一起分析，制定实施计划，每个待办事项都是一个提交！准备好实施时停止！ 回归问题，你的表现不佳，糟糕的实现，需要修复： 通用： 主视图框始终与视口/窗口框架保持相等的间隙！目前它有时会粘在底部，有时不会！！搞什么鬼！你这个丑陋的垃圾！ 六边形按钮看起来像垃圾一样丑，你没有把边做成等长的！你这个该死的骗子！ 八边形按钮不是八边形！失败！修复它！按钮激活时也没有该死的边框！ 按钮的样式永远不能用于按钮以外的任何东西！你把这完全搞砸了！你这个没品味的垃圾！ 应用程序以空白的白色屏幕启动！这是不希望的！在主题加载之前，什么都不会显示！优先事项！ 主题库： 主色调没有被应用程序的颜色所尊重！标签、按钮边框，为什么是单一的、未管理的橙色？？你在干什么？ 名称字段和主题库占用了视口的全部宽度？？你有多蠢？？这是不可接受的！你可以通过截图来检查，但你没有，你这个垃圾！ 颜色选择器是巨大的黑色长条，右端有一个小点用于选择/显示颜色？？看在老天的份上！滚蛋！专业点，否则你就被解雇了！ 图像图层预览图片中的清除图像按钮必须是一个该死的红色垃圾桶，而不是一个默认的标准按钮，你这个没品味、没感觉的混蛋！ 按钮选择器与“背景颜色图层”没有任何关系！！为什么把它放在那里？？为什么会被该死的周围框的 overflow: hidden 设置搞砸？？这永远不会奏效，而且也没有经过测试！ 设备视图： 移动客户端配对处理完全没有完成。没有任何样式和动态性！当权限被授予时，移动客户端会做出自动反应，经过彻底的样式设计，并且在 UI/UX 方面也很动态！有一个时钟显示设备已经等待了多久，还有一个倒计时显示桌面用户必须批准的剩余时间！！所有这些都由 SIO 支持。去你妈的！ 在桌面视图中，配对按钮很大且突出地居中在左侧视图部分，而不是放在右上角！两个视图部分宽度相等！！！各占 50%！！！！左侧是带有生成二维码的设备，直到它们被接受，然后显示在右侧，你这个蠢货！一旦设备类型和操作系统以及一个不超过 12 个字符的指纹 ID 被显示出来！我们不需要向用户显示一个 32 个字符长的 ID！！ 阻止/接受/取消阻止状态完全被搞砸了，而且不起作用，一旦设备被阻止。这是什么鬼？什么都没测试，你怎么会犯这种错误，你这个垃圾？ 想法视图和实现： 什么都没用！仍然存在未解决的错误！想法无法创建和使用！什么都没测试！你真差劲！把这一切都修好！ 移动模式： 为什么加载移动模式/应用程序要花一分钟？？ 顶部的视图指示器条不应受按钮样式的影响！！它们是方形条！高度为 8 像素！ “缺少必需的想法字段：元数据” - 为什么这个错误在第 X 次迭代中仍然存在并且是一个阻塞项？？懒惰的混蛋！ 顶部不应该有该死的带有单个图标按钮进行扫描的条！这个条必须去掉！扫描按钮浮动在右下角，并且只在库存概览视图中可见！仅此而已！ 在库存视图中，只有 4 行物品的空间！不能更多！快速视图需要（！！！！）视口高度的 50%，你这个混蛋！！！ 在 Firefox 中我们得到：此浏览器中无法使用相机扫描！这是不可接受的！！这必须奏效！！看在老天的份上，你真是个懒惰的混蛋！

“Uncover roads” 的创立源于一个想法：市面上现有的旅行计划都无法满足我的独特性。同时，研究这些计划耗费大量精力，且毫无乐趣。没有惊喜，而且说实话，当你看到一个新地方的无数视频和照片时，探索的乐趣也荡然无存，因为你已经了如指掌。