大家好，分享我最近找到的替代方案，适用于 Elasticsearch、CloudWatch 等那些需要高额云费用或管理解决方案成本更高的服务。这是一种已知的模式，但可能不够广为人知：将日志写入 S3 作为持久存储，使用 Parquet 格式并通过 DuckDB 快速查询。这已经成为我所有副项目中处理日志的主要方式，我再也不用担心丢失日志，并且可能还可以免费存储。
<p>功能<p>
<pre><code> 格式无关 - 通过可配置字段提取，支持任何 JSON 日志格式
快速 - 每秒处理 28K+ 条目
高效 - 使用 Parquet + Snappy（压缩比 3.7x）
快速查询 - DuckDB 在 56K 日志上查询时间小于 50ms
兼容 S3 - 支持 AWS S3、MinIO、DigitalOcean Spaces、R2 等
分区 - 按日期/级别进行 Hive 风格的分区（无冗余的部分后缀）
自动刷新 - 可配置的自动刷新（默认：90秒）
去重 - 可选去重
</code></pre>
欢迎随时询问有关内部实现的问题。
返回首页
最新
我曾经认为，定义清晰的接口和服务之间的契约就足以维持模块化。我共享数据库，因为这似乎是最简单的选择。我错了。共享数据库或任何跨越外部组件边界的资源，会形成一种“焊接”连接，违背了任何接口定义。这会造成潜在的故障级联，随时可能发生。
许多工程师希望避免严格定义数据所有权所带来的摩擦。他们寻求一个礼貌的中立区域，以避免冲突。我认为这种做法在智识上是不诚实的。通过避免为了强制执行真正的模块化而必须进行的对抗，你构建的系统注定会在架构变化的那一刻崩溃。
我不得不通过艰难的方式学习到这一点。现在，我在每个组件的数据层强制严格分离。虽然这在前期更困难，但这是构建能够扩展而不至于在自身重压下崩溃的系统的唯一方法。如果你在共享数据库，或者以任何方式让你的领域数据跨越到外部模块，你就不是在构建一个模块化系统，而是在推迟不可避免的崩溃。
我在消费级AMD GPU（RX 7900 XT + RX 6950 XT）上复现了David Ng的RYS方法（[链接](https://dnhkng.github.io/posts/rys/)），并发现了一些意想不到的结果。
变压器似乎具有离散的“推理电路”——由3到4层连续组成的块，作为不可分割的认知单元。复制正确的块后，模型的推理流程会运行两次。权重没有变化，没有训练，模型只是思考得更久。
在标准基准测试（lm-evaluation-harness，n=50）上的结果如下：
Devstral-24B，层12-14复制一次：
- BBH逻辑推理：0.22 → 0.76
- GSM8K（严格）：0.48 → 0.64
- MBPP（代码生成）：0.72 → 0.78
- 没有任何下降
Qwen2.5-Coder-32B，层7-9复制一次：
- 推理探测：76% → 94%
奇怪的是，不同的复制模式会从相同的权重中产生不同的认知“模式”。双重通过提升了数学能力，三重通过提升了情感推理。交错复制（13,13,14,14,15,15,16）则创造了一个纯数学专家。相同的模型，相同的显存，不同的路由。
电路边界非常清晰——移动一层，效果就会消失或反转。较小的模型（24B）比较大的模型（Ng在72B中发现7层）具有更紧凑的电路（3层）。
在这个代码库中，有工具可以在任何GGUF模型中找到电路并应用任意层路由。整个过程——扫描、发现、验证——只花了一个晚上。
欢迎提问。
对于一个以人工智能/机器学习为主要产品的初创公司，你会选择 .com 还是 .ai 域名？