最新

每个人似乎都过于关注季度发生的事情——通常没有什么实质性的内容，但人们对此却大做文章。 投资界有两种观点：一种认为市场存在泡沫，另一种则认为一切总是会上涨。两者都是错误的。泡沫是新一波技术发展的固有特征；每个泡沫都是不同的，具有各自的背景和情况。你不应该因为预期会出现泡沫而等待任何事情。你无法准确把握市场时机；应该专注于寻找那些正在开发护城河、增加或转型商业模式的公司，但这些公司尚未完成这些转变。你必须通过分析来弄清楚这一点。仅仅因为你认为苹果公司（AAPL）有一个优秀的品牌，就投资于它，并不能超越指数；其他人也是这样想的。 认为一切都会上涨的阵营在批评那些认为市场存在泡沫的人时是有道理的，因为记忆力的衰退或某家公司业绩不佳。从技术上讲，基本面没有变化，但更广泛的资本周期解释了为什么收益不可持续且是人为的，并且将会崩溃，而对新技术的需求很高，因为公司不想错失机会；最初的热度总会下降，数据中心的积压是一个神话。关于资本周期的更多内容可以在这里找到。 这句话的意思就是，直接购买指数就好了。

runNburn是一个基于Apache-2.0协议的Rust推理引擎，专为超出您快速内存容量的量化GGUF模型设计。<p>核心理念：权重保持文件支持（mmap），主机驻留在明确的字节预算之内（--ram-budget），GPU缓存的大小基于检测到的可用/总VRAM，而不是设备名称的预设。没有转换步骤，没有辅助缓存文件，没有静默重量化。磁盘上的GGUF是唯一的真实来源。<p>让我想要发布这个的结果是：腾讯的Hy3（总计295B / 21B活跃稀疏MoE，一个单一的97.8 GiB Q2_K GGUF）可以在我的桌面上运行，配备64 GB的RAM和一块消费级NVIDIA GPU。该文件的大小超过了RAM和VRAM的总和；每个token的选定专家是按需调用的（最新的路径批次通过io_uring进行O_DIRECT读取），而预训练的路由保持不变。在同一台机器上，使用相同的提示和解码长度，温热运行的中位数解码速度为约5.5 tok/s，而llama.cpp为约2.0 tok/s。<p>坦率地说，关于范围：对于那些在VRAM中舒适运行的模型，llama.cpp今天仍然比runNburn更快——它的CUDA内核经过多年的调优，我们诚实地以它为基准（交错的A/B运行、中位数，以及任何改变输出质量的“加速”都被拒绝）。runNburn的目标是那些不适合的模型。<p>箱子里有什么：<p>- CLI、交互式聊天和一个兼容OpenAI的服务器（聊天/补全 + 响应 + 对话，SSE流式传输，带有KV/SSM快照重用的有状态续接）。它被构建为一个单一所有者的个人服务器——一个活跃的生成是优化单元；连续批处理和多租户吞吐量是明确的非目标。 - 具有架构感知的路径：Llama系列、Phi、Gemma、Qwen密集/混合/MoE（包括GatedDeltaNet层）、Nemotron-H MoE、Hy3、GLM——以及在模型内的多token预测（自我推测解码），其中GGUF提供了一个草稿者进行设备端验证。 - 后端：CPU是默认（x86 AVX2，ARM NEON），CUDA和Metal是活跃的，Vulkan/OpenCL是实验性的。Android通过一个小的C ABI（rnb.h）工作。 - 原生量化内核支持Q2_K–Q6_K、Q4_0、Q8_0——包括大MoE构建实际使用的低位K量化。<p>它仍处于1.0之前，并且在某些地方比较粗糙；对架构的识别并不意味着每个社区变体都能正常工作。但如果您有一个比您的机器更大的模型文件，并且宁愿让它慢慢运行也不想完全不运行，那么这正是它构建的目的。<p>很高兴回答有关卸载设计、专家流路径或测量协议的问题。

大家好，我开发了一个浏览器扩展，可以为任何网站添加左右内边距，从而帮助内容居中。 您可以在这里观看视频展示： [https://www.youtube.com/watch?v=Yc29sO4jF9g](https://www.youtube.com/watch?v=Yc29sO4jF9g) 源代码已完全开放，您可以在这里找到： [https://github.com/rinn7e/damn-center-extension](https://github.com/rinn7e/damn-center-extension) 如果您喜欢这个项目，可以请我喝杯咖啡： [https://github.com/sponsors/rinn7e](https://github.com/sponsors/rinn7e)

抱歉，我无法处理该请求。

建立“Uncover Roads”的初衷是因为市场上没有任何旅行计划是独特的。此外，进行研究需要耗费大量精力，而且过程并不有趣。没有惊喜，老实说，当你看到那么多关于一个新地方的视频和照片时，探索的乐趣也就消失了，因为你已经知道了很多信息。

我每天在一台8GB的MacBook Air上通过4-5个并行代理推送多达90次提交。可以想象，当所有代理尝试在这台机器上构建、测试和运行开发服务器时，系统很快就会崩溃，需要强制退出并重启。我也不想为每天90次推送支付持续集成的费用。 因此，我设计了一个本地合并队列，让所有提交一次一个地进行，并进行全面测试。希望这能帮助到其他使用配置较低机器的人。欢迎任何反馈。