作者质疑当前大型语言模型（LLM）日益增长的趋势，认为巨大的规模并非总是必要的。虽然大型模型适用于需要细致理解的复杂通用任务，如聊天机器人，但许多应用——例如SQL自动补全或结构化数据提取——范围有限，并不需要数十亿参数。 核心问题是*推理成本*。运行这些大型模型成本高昂，需要大量的计算能力和基础设施，最终每次用户交互都会增加成本。 作者预测将出现转向更小、更专业化的模型，这些模型针对特定任务进行训练。现有工具已经允许构建和部署这些“小而强大”的模型，甚至可以直接在网页浏览器中进行，为LLM应用提供更高效、更经济的未来——可能仅用1500万个参数就能实现所需的结果。
每日HackerNews RSS
## 为什么LLM如此庞大？ - Hacker News讨论总结
最近Hacker News上出现了一场关于大型语言模型（LLM）日益增长的规模以及这是否真的必要的讨论。许多评论员认为，对于许多任务，较小的模型——特别是那些使用文本补全而非聊天界面的模型——更有效且更具成本效益。他们指出，LLM本质上是自动补全工具，而聊天界面是建立在其之上的用户友好层。
几位用户强调了直接使用核心文本补全功能的优势，从而可以更好地进行提示工程并获得更好的结果。另一些人指出模型开发的快速步伐，对一个模型的微调可能很快就会因为新版本的发布而过时。
对话还涉及“人工智能军备竞赛”的更广泛影响，暗示模型尺寸的膨胀是由财务激励和对市场控制的渴望驱动的，而非真正的必要性。一种观点是，小型、专业的模型是未来，并且鉴于强大、便携设备的潜力，当前笔记本电脑的尺寸是不必要的大。
## 加密货币的赌场：永续期货解释 许多金融创新服务于实体经济，但加密货币常常创造仅存在于自身领域的系统。一个典型例子是**永续期货（perps）**——一种迷人且占据主导地位的加密货币交易形式（通常是现货交易量的6-8倍），类似于衍生品在传统市场中的作用。 本质上，加密货币交易所充当赌场，依靠吸引投注者，并且需要大量资金来保证支付。永续期货通过减少促进风险承担所需的资本来解决这个问题。它们允许交易者使用杠杆进行投机，并通过“资金费率”（赢家和输家之间的支付）频繁地结算收益和损失（每天多次）。 虽然永续期货起源于加密货币之外，但它们在加密货币领域找到了归宿，这得益于高杠杆（通常为20倍-100倍，而传统市场的限制为2倍-4倍）。这种杠杆会带来风险，通过**自动减杠杆（ADL）**来缓解——一种有争议的机制，交易所可以在极端市场波动期间减少获胜头寸以弥补损失。 这个系统并非完美无缺。它依赖于信任，并且交易所可能优先考虑自身利益（或附属公司的利益）而非个人交易者。由于现有解决方案和风险规避，它不太可能在传统金融领域被广泛采用，但理解永续期货是理解加密货币市场动态的关键。
弗兰克·盖里，1929年出生，是一位享誉全球的建筑师，以其开创性的解构主义风格而闻名。他摒弃了传统的对称性，拥抱非常规的形状和材料，创造出一种独特且不可预测的美学。 在南加州大学和哈佛大学学习后，他创立了自己的公司，并在毕尔巴鄂古根海姆博物馆的项目中获得国际赞誉。这促成了他在世界各地标志性建筑的委托，包括芝加哥的杰伊·普里茨克亭、巴黎的路易威登基金会和布拉格的“跳舞的房子”。 盖里的建筑以其雕塑般的形态而立刻被辨认出来——经常被描述为类似于折叠的玻璃或揉皱的纸袋——并且每个项目都独具原创性。1989年，他荣获普利兹克建筑奖，他的作品被赞誉为具有“高度精致……冒险的美学”，并被比作爵士乐的即兴精神。
## 弗兰克·盖里逝世
著名建筑师弗兰克·盖里，以其独特且常常具有挑战性的设计而闻名，已去世。一则黑客新闻的讨论强调了他的作品影响，从他早期非常规的圣莫尼卡住宅——被描述为永久“无人应答”和“令人困惑”——到像古根海姆博物馆毕尔巴鄂分馆和华特迪士尼音乐厅等标志性建筑。
评论员指出盖里在建筑设计中率先使用技术，以及他勇于突破界限，即使这意味着建造的建筑物将艺术表达置于实用考虑之上。许多人分享了他们与他的建筑的经历，包括麻省理工学院斯塔塔中心（因漏水和设计缺陷而闻名）和脸书门洛帕克园区（因屋顶花园受到赞扬，但因内部布局受到批评）。
虽然他因其雕塑般的形态和影响力而受到赞誉，但有些人质疑他作为设计师的实用性，质疑他对美学的关注是否有时会损害功能性。尽管如此，盖里作为一位开创性和有影响力的建筑师的遗产已被广泛认可。
## 药品定价差异：米博案例 一个鲜明的例子是米博，一种治疗干眼的药物。在欧洲可以非处方药购买，价格约为20美元（以EvoTears销售），而在美国，同样的药物作为处方药销售，价格高达800美元以上。有人成功地从欧洲药房在线购买到该药，价格为32美元，凸显了巨大的价格差异。 这并非个例；美国的处方药价格平均比其他发达国家高2.5倍。Bausch & Lomb 战略性地寻求FDA将其作为处方药批准——尽管在其他地方是OTC药物——以利用专利保护和最大化利润，米博2024年的销售额超过1.72亿美元。 批评人士认为这是价格欺诈，该公司此前在其前身Valeant时期也曾使用过这种策略。Bausch & Lomb 为其定价辩护，理由是获得FDA批准所需的广泛临床试验，但专家认为，该药物在欧洲已经确立的安全记录应该使其在美国获得OTC地位。 提出的解决方案包括要求FDA在批准药物作为处方药之前考虑国际OTC批准，并对米博等案例进行追溯审查，最终将患者的可及性置于公司利润之上。
## 潮汐的复杂科学
我们现代准确预测潮汐的能力依赖于几个世纪的科学进步。古希腊人最初确定月球的引力是潮汐的原因，后来牛顿和拉普拉斯对此进行了量化，但*计算*潮汐却非常复杂。拉普拉斯的方程虽然准确，但对于特定地点来说，手动求解过于困难。
这促使洛德·开尔文在1870年代发明了机械潮汐预测机——这些复杂的设备自动化了繁琐的计算。这些机器不仅考虑了月球的引力，还考虑了太阳的影响、地球的倾角，以及关键的海岸线形状和海洋深度。
潮汐不仅仅是跟随月球的隆起；它们是受陆地影响的波浪，创造出独特的模式，例如围绕岛屿的环形潮汐和潮汐变化最小的区域。预测潮汐需要理解众多天文组成部分的强度和时间，*以及*当地的地理因素。
这些机器一直沿用至1970年代，当时数字计算机终于超越了它们的能力。即使在今天，潮汐仍然是一种令人惊讶的复杂现象，持续的发现揭示了超出我们当前理解的更多复杂性。
## 潮汐：比你想象的更复杂
一篇[signoregalilei.com文章](https://signoregalilei.com/)引发的Hacker News讨论表明，潮汐远比通常认为的更为微妙。传统的“隆起”解释是一种误解；潮汐是由月球（以及太阳）对地球不同部位的不同引力作用驱动的，产生拖曳效应，而不是简单的提升。
讨论强调了陆地分布对潮汐强度的影响——一些海岸线经历显著变化，而另一些海岸线几乎没有变化。参与者们争论了离心力与引力的作用，共识倾向于认为不同的引力是主要驱动因素。 历史背景也被分享，包括开尔文勋爵19世纪的潮汐预测机器——现代机器学习的前身——以及查尔斯·达尔文之子乔治·达尔文的贡献。
除了核心物理学之外，评论者还注意到天气的影响以及当前预测模型的局限性，以及一些有趣但科学依据较少的理论，将潮汐与电磁现象联系起来。 这段对话强调了人们对这种自然现象的持久着迷以及不断探索以充分理解其复杂性的努力。
苏萨姆·帕尔展示了一种仅使用CSS的解决方案来解决经典的FizzBuzz问题，仅用四行CSS代码即可实现序列输出。该代码利用CSS计数器和`:nth-child()`选择器在列表(`<li>`)元素内生成序列。 具体来说，它为每个列表项递增计数器，除非该项能被5整除，否则显示计数器值，为3的倍数添加前缀“Fizz”，为5的倍数添加后缀“Buzz”。 作者承认该解决方案并非针对代码高尔夫优化，而是将其作为起点提供。提供了一个精简版的代码，去除了所有空格，长度为152个字符。帕尔邀请读者提交更短、更高效的解决方案。一个可运行的示例可在css-fizz-buzz.html找到。
## CSS FizzBuzz：代码高尔夫挑战
一则Hacker News讨论围绕着仅使用CSS实现经典的FizzBuzz问题。挑战的重点是最小化代码尺寸（“代码高尔夫”）。 多个解决方案被提出，利用CSS特性如`:nth-child()`、`::before`、`::after`和CSS计数器。
最初使用有序列表(`<ol>`)的尝试实现了较小的字符数（129），但存在视觉错位问题。为了改善外观所做的修正增加了代码尺寸。 其他方法使用了`<p>`标签和CSS变量，旨在进一步优化。
参与者争论了在字符计数中包含HTML大小的“公平性”，认为真正最小的解决方案需要JavaScript来生成必要的列表元素。 该讨论突出了使用CSS解决问题的创造性（尽管非常规）方法，以及代码简洁性和可读性/正确性之间的固有权衡。 解决方案的字符数从68到152不等，并且仍在不断尝试实现尽可能小的实现。
## REPL 的调试适配器协议：nluarepl & hprofdap 调试适配器协议 (DAP) 传统上用于调试，但令人惊讶的是，它非常适合构建 REPL（读取-求值-打印循环）。这种方法被用于创建诸如 **nluarepl**（Neovim 的 Lua REPL）和 **hprofdap**（用于检查 Java 堆转储）之类的工具。 DAP 的 `evaluate` 命令允许客户端发送表达式进行求值，并返回 `result` 以及可选的 `type`。重要的是，它包含一个 `variablesReference`，可以以 UI 中可导航的树的形式表示结构化数据。可以使用 `variables` 命令检索更多详细信息，从而可以深入检查数据结构，即使是嵌套或循环引用。DAP 还支持代码补全等功能。 虽然 DAP 包含断点处理等调试特定功能，但这些功能可以被绕过或为 REPL 使用而最小化实现——例如，nluarepl 使用日志点代替断点。使用 DAP 的主要动机是 **重用现有的调试 UI 元素**（例如 `nvim-dap` 中的元素），并避免重新发明 REPL 界面，从而将开发精力集中在核心求值逻辑上。这种方法提供了一种熟悉的用户体验，具有一致的键映射和行为。
软件自由保护协会 (SFC) 正在法庭上起诉 Vizio，原因是其 SmartCast 电视使用了 GPLv2 和 LGPLv2.1 许可的 Linux 和其他软件。SFC 指控 Vizio 通过未能提供相应的源代码而违反了这些许可协议，这是这些开源许可的关键要求。
加州法官已发布初步裁决，*支持* SFC 的主张，认为 Vizio 有义务向购买者（在本案中为 SFC）提供源代码。然而，该裁决并非最终，取决于最近听证会上的辩论。
此案凸显了法律先例的转变。早期，开源许可的可执行性存在不确定性，但法院越来越多地维护其条款。此前由软件自由法律中心对 Monsoon Multimedia、Xterasys 和 Verizon 等公司提起的成功诉讼铺平了道路。
最近被沃尔玛以 23 亿美元收购的 Vizio 拥有强大的辩护资源，这使得本案成为开源许可执行的重要考验。听证会的最终结果还有待观察。
CachyOS，一个以速度和优化为重点的社区驱动型Linux发行版，宣布获得了Framework（模块化笔记本电脑公司）的重大赞助。Framework将提供一台Framework Laptop 16用于开发，并每月捐赠250美元——约占CachyOS典型月度资金的10%。
此次合作尤其有价值，因为Framework展现了对支持Linux生态系统的承诺。这笔资金将有助于稳定CachyOS的基础设施，并为实现全职开发这一长期目标做出贡献，最终改善用户体验。Framework还已公开将CachyOS列为其2025年的赞助项目之一，展示了其对开源项目的更广泛支持。CachyOS社区对这两个组织都表达了热烈的支持。
## 框架赞助 CachyOS，引发讨论
框架（Framework），以其模块化笔记本电脑而闻名，正在以每月 250 美元的捐款和硬件赞助基于 Arch 的 Linux 发行版 CachyOS。此举引发了关于框架选择发行版的讨论，因为 Valve 的 SteamOS 也倾向于选择 Arch 而不是 Debian/Ubuntu。框架解释说，赞助是由用户数据驱动的，数据显示其客户群中更喜欢 Arch。
讨论迅速扩大到 Arch（灵活性、最小的基础操作系统、强大的上游兼容性）与 Debian（稳定性、可重复性）的优势。一些人认为 Arch 的滚动发布模式非常适合快速硬件更新，而另一些人则强调 Debian 的安全重点。
然而，此次赞助也因框架最近推广 Omarchy 项目而受到批评，该项目由一位持有极右翼观点的争议人物创建。虽然框架澄清他们并非直接赞助 Omarchy，但缺乏对社区担忧的强有力回应引发了关于该公司价值观的争论。尽管存在争议，许多用户对 CachyOS 在框架硬件上的性能感到兴奋，并提到了速度提升和积极的用户体验。
使用单调递增的序列值作为幂等性键可以简化消费者的消息处理。消费者无需存储所有已处理的键，只需跟踪*最新*键，丢弃任何键较低或相等的消息作为重复消息。这在使用像Kafka这样的分区源时尤其高效。 然而，为生产者生成这些键可能具有挑战性。单线程生产者可以轻松利用数据库序列或计数器。并发生产者会带来复杂性；确保单调性需要原子获取和发出键，以防止重复——通常会造成性能瓶颈。仅仅使用数据库序列是不够的；真正的原子性需要诸如Postgres建议锁之类的机制。 虽然对消费者有益，但实现单调递增的键需要仔细考虑生产者架构和潜在的性能权衡。Kafka分区偏移量自然地充当分区内消息的此类键。
## 幂等键用于精确一次处理：总结
Hacker News 的讨论集中在分布式系统中实现“精确一次”处理——确保操作仅发生一次，即使存在潜在的消息重试。一个关键的解决方案是使用 UUIDv5 键。这些基于输入生成唯一标识符，允许在数据库中检测重复项。如果收到具有相同幂等键的消息，可以忽略它或优雅地处理。
讨论了 SHA256 哈希等替代方案，UUIDv5 本质上是一种哈希盐+字符串的方法。然而，当处理涉及数据库事务*外部*的外部副作用时，会出现挑战——无法回滚这些副作用。
对话强调了真正实现“精确一次”的难度，并倾向于“最多一次”处理。人们对持久化工作流的复杂性以及最终一致性与强保证之间的需求表示担忧。一些人建议利用现有的解决方案，如基于 TCP 的序列化（尽管这在多个生产者/消费者的情况下会失效），或者专注于简化流程，以避免对复杂工作流的需求。最终，讨论强调了分布式系统的实际挑战以及确保数据一致性所涉及的权衡。