最新

大家好，分享一下我最新的替代方案，可以替代 Elasticsearch、CloudWatch 等，这些方案要么需要支付高昂的云服务费用，要么托管解决方案的成本更高。这虽然是一个已知的模式，但可能还不够普及：将日志写入 S3 作为持久化存储，使用 Parquet 格式，并用 DuckDB 进行快速查询。这已经成为我所有副项目摄取日志的主要方式，而且我再也不用担心丢失日志，而且存储可能还是免费的。<p>功能<p><pre><code> 格式无关 - 通过可配置的字段提取，适用于任何 JSON 日志格式 快速 - 每秒摄取 28K+ 条目 高效 - Parquet + Snappy (3.7 倍压缩) 快速查询 - 在 56K 条日志上，DuckDB 查询时间小于 50 毫秒 S3 兼容 - AWS S3、MinIO、DigitalOcean Spaces、R2 等 分区 - 类似 Hive 的按日期/级别分区（没有冗余的分区后缀） 自动刷新 - 可配置的自动刷新（默认：90 秒） 去重 - 可选的去重 </code></pre> 很乐意回答关于内部机制的任何问题

我曾经认为，在服务之间定义清晰的接口和契约，就足以维持模块化。我共享一个数据库，因为它看起来是最省事的做法。我错了。共享数据库或任何跨越到外部组件边界的资源，都会创建一个“焊接”接头，它无视任何接口定义。这会引发一连串的故障，随时可能发生。<p>许多工程师希望避免严格定义数据所有权带来的摩擦。他们寻求一个礼貌、中立的区域来避免冲突。我认为这种方法在智力上是不诚实的。通过避免执行真正模块化所需的冲突，你构建的系统注定会在模式发生变化的那一刻崩溃。<p>我不得不为此付出惨痛的代价。我现在对每个组件的数据层都强制执行严格的分离。这在前期更难，但它是构建能够扩展而不会因自身重量而崩溃的系统的唯一方法。如果你正在共享数据库，或者以任何方式让你的域数据跨越到外部模块的边界，那么你并没有构建一个模块化系统。你只是在推迟不可避免的崩溃。

我复现了 David Ng 的 RYS 方法（<a href="https:&#x2F;&#x2F;dnhkng.github.io&#x2F;posts&#x2F;rys&#x2F;" rel="nofollow">https:&#x2F;&#x2F;dnhkng.github.io&#x2F;posts&#x2F;rys&#x2F;</a>），并在消费级 AMD GPU（RX 7900 XT + RX 6950 XT）上进行了测试，结果出乎意料。<p>Transformer 似乎拥有离散的“推理电路”——由 3-4 层组成的连续区块，它们充当不可分割的认知单元。复制正确的区块，模型就会运行两次推理流程。无需更改权重，无需训练。模型只是思考得更久了。<p>在标准基准测试（lm-evaluation-harness，n=50）上的结果如下：<p>Devstral-24B，复制 12-14 层一次： - BBH 逻辑推理：0.22 → 0.76 - GSM8K（严格）：0.48 → 0.64 - MBPP（代码生成）：0.72 → 0.78 - 没有任何指标下降<p>Qwen2.5-Coder-32B，复制 7-9 层一次： - 推理探针：76% → 94%<p>奇怪的是：不同的复制模式可以从相同的权重中创建不同的认知“模式”。双流程提升数学能力。三流程提升情感推理能力。交错加倍（13,13,14,14,15,15,16）则创造了一个纯粹的数学专家。相同的模型，相同的 VRAM，不同的路由。<p>电路边界非常清晰——移动一层，效果就会消失或反转。较小的模型（24B）比大型模型（Ng 在 72B 中发现了 7 层）拥有更紧凑的电路（3 层）。<p>在代码库中提供了用于在任何 GGUF 模型中查找电路并应用任意层路由的工具。整个过程——扫描、发现、验证——只花了一个晚上。<p>欢迎提问。