统一内存架构的迷你主机因优先考虑“容量”而非原始速度，已成为运行大型语言模型（LLM）的热门选择。与传统台式机因显存受限而存在性能上限不同，这些系统在 CPU、GPU 和 NPU 之间共享同一内存池。这使得相对平价的迷你主机能够加载庞大的模型（如 700 亿参数模型），而这些模型在过去通常需要昂贵的高端工作站显卡才能运行。 然而，这种容量优势是以性能大幅下降为代价的。LLM 的文本生成速度主要受限于内存带宽；由于迷你主机的带宽远低于独立显卡，其生成文本的速度就像“慢速阅读者”一样。此外，计算密集型的“预填充”阶段（读取长提示词）也是迷你主机中较弱的集成显卡难以应付的环节。 归根结底，这些机器不是追求速度的利器，而是解决容量问题的工具。它们非常适合那些需要运行大型、高内存占用模型，且模型无法在标准显卡上加载的用户。对于较小的模型或需要高速交互的任务，独立显卡依然是更好的选择。请根据模型规模而非营销参数来选择硬件。
每日HackerNews RSS
Hacker News 最新 | 过往 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
统一内存详解：为什么迷你电脑能运行 70B 模型而大型 GPU 却不行 (vettedconsumer.com)
8 分，ermantrout 发布于 3 小时前 | 隐藏 | 过往 | 收藏 | 1 条评论 | 帮助
LoganDark 5 分钟前 [–]
不过，其实也没法运行得那么好。我的“迷你电脑”是一台配备 128GB 统一内存的 M4 Max，但在推理方面，内存带宽依然严重不足（尽管它比任何非统一架构的消费级产品都要好得多！）。回复
准则 | 常见问题 | 列表 | API | 安全 | 法律 | 加入 YC | 联系
搜索：
Hacker News | 最新 | 过往 | 评论 | 提问 | 展示 | 招聘 | 提交 | 登录
古钱币：斯巴达钱币是怎样的？ (coinweek.com)
5 分 | thunderbong 发布于 2 小时前 | 隐藏 | 过往 | 收藏 | 1 条评论 | 帮助
quuxplusone 18 分钟前 [–]
维基词典：
> 普鲁塔克在《吕山德传》第 17 章中告诉我们，在早期，钉子（ὀβελοί (obeloí)）被用作货币，六枚钉子为一把（δραχμή (drakhmḗ)），后来这个名字变成了 ὀβολós (obolós)。
不过，在（传说中的）斯巴达版本里，货币更加笨重，且刻意降低其实用价值。你不希望人们因为钱币本身的用途而觊觎它——仅仅因为它的交易价值就足以让人贪婪了！因此，斯巴达的铁币（据称）是用醋淬火处理的，以破坏其内在价值。
https://en.wikipedia.org/wiki/Pelanor
不过，这个传说不太可能符合古代的实际情况。
回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 加入 YC | 联系
搜索：
在社交媒体往往充满敌意的部落主义氛围中，Robin Berjon 提出了一种技术桥梁，旨在统一两个强大的协议：ActivityPub (AP) 和 AT Protocol (ATProto)。
Berjon 认为，虽然两者都致力于打破社交媒体的壁垒，但它们解决的是不同的问题。ActivityPub 擅长社交网络，但与电子邮件类似，容易受到服务器管理员的控制。相反，ATProto 在用户自主权和“可信退出”方面提供了更优越的架构，允许用户拥有自己的数据，并在不同提供商之间迁移，而不会丢失身份或关注者。
作者提出了一个设计构想：在 ATProto 个人数据服务器 (PDS) 之上实现 ActivityPub 路由。通过利用 ActivityPub 中“Actor”文档指向 ATProto 端点的灵活性，用户既能享受 AP 去中心化和联邦化的覆盖范围，又能保留 ATProto 主权且可迁移的数据所有权。
尽管存在一些细微的技术障碍——例如协调 REST/RPC 方法以及统一身份/句柄系统——但 Berjon 认为这些是可以克服的实际挑战，而非决定性的阻碍。通过整合这些互补技术，我们可以构建一个比传统联邦和封闭平台壁垒更具韧性、以用户为中心的网络。
抱歉。
**Runloom** 是一个高性能库，为 Python 引入了 Go 风格的有栈协程（stackful coroutines）。通过利用手写的汇编上下文切换、基于 C 语言的工作窃取调度器以及高效的 `netpoll` 实现，它使开发者能够编写跨所有 CPU 核心并发运行的阻塞式代码。 主要特性包括： * **易用性**：支持 `monkey.patch()`，无需 `async/await` 即可将标准阻塞式 I/O（套接字、时间等）转换为非阻塞的协作式代码。 * **高性能**：专为自由线程（free-threaded）CPython (3.13t/3.14t) 设计，吞吐量和生成速率可与 Go 媲美。 * **架构**：实现了 M:N 调度器，将任务分配到多个操作系统线程中，有效绕过了传统单线程 Python 并发的限制。 * **兼容性**：为旧代码提供 `asyncio` 桥接，并可通过预编译的 wheel 包在主流操作系统和架构上使用。 尽管由于 CPython 执行帧的原因，Runloom 每个纤程的内存开销约为 Go 的 3.3 倍，但它为 Python 实现多核并行提供了一种强大的方式。它并不会加速单个 Python 字节码的执行，但能够让单个进程的阻塞式 Python 逻辑扩展到所有可用的硬件核心上。
Hacker News
最新 | 过往 | 评论 | 提问 | 展示 | 招聘 | 提交
登录
Show HN: Runloom – 为 Python 自由线程版（free-threaded）提供 Go 风格的协程 (github.com/robertsdotpm)
7 分，由 Uptrenda 发布于 1 小时前 | 隐藏 | 过往 | 收藏 | 1 条评论
ksdme9 16 分钟前 [–]
这与 gevent 相比如何？
回复
准则 | 常见问题 | 列表 | API | 安全 | 法律 | 申请加入 YC | 联系
搜索：
Scarf 已经不再使用 Haskell。 After 7 years in production, Scarf has reluctantly moved away from Haskell
12 小时前
Haskell 的长期拥护者兼董事会成员 Avi Press 解释了为什么他的公司 Scarf 在新项目开发中放弃 Haskell，转而选择 Python。
在承认 Haskell 的可靠性和类型安全性的同时，Press 指出，人工智能驱动的开发浪潮已从根本上改变了编程的经济学。AI 代理依赖于快速反馈循环、低成本执行和低摩擦环境。Haskell 较长的构建时间、复杂的依赖管理以及较高的“冷启动”开销，造成了严重瓶颈，阻碍了 AI 辅助的工作流程。相比之下，Python 提供了有效利用现代大语言模型（LLM）所需的敏捷性，能够实现快速迭代和交付。
Press 警告说，如果 Haskell 社区继续侧重于学术研究（如依赖类型），而非构建性能和 AI 集成等工业需求，将面临停滞的风险。他敦促社区优先考虑“对代理友好”的工具（如更快的编译速度和更好的文档），以保持竞争力。最终，他认为如果 Haskell 不进化以适应 AI 驱动的范式，它将难以在快速发展的生态系统中竞争。对于 Scarf 而言，这一决定是对现代软件领域中生产力和速度紧迫需求的务实响应。
Scarf 从 Haskell 转向 Python 的决定在 Hacker News 上引发了针锋相对的争论。批评者认为，Haskell 强大的类型系统是 AI 生成代码的必要保障，能够捕捉到 Python 动态特性所忽略的错误。许多评论者认为，为了 Python 的“直觉编码”速度而牺牲编译时的安全性是违背常理的，尤其是在 AI 工具已经能够高效处理复杂类型系统的情况下。
相反，一些参与者认为这种转换是对现代开发现实的务实回应。他们指出，Python 庞大的训练数据使其更具“AI 原生性”和易用性，而 Haskell 缓慢的编译速度和陡峭的学习曲线阻碍了 AI 辅助工作流所需的快速迭代循环。
这场讨论凸显了行业内一个更广泛的矛盾：软件开发的主要瓶颈究竟是执行性能和类型安全，还是“LLM 人机工程学”——即模型在特定语言生态系统中读取、生成和迭代的便捷程度。归根结底，这场辩论反映了一种转变，即语言的选择正越来越多地由 AI 兼容性和工具可用性驱动，而非纯粹的美学或架构偏好。
墨西哥洞穴鱼为企业停滞提供了一个生动的隐喻：正如生活在洞穴中的鱼因黑暗环境不再提供奖励而进化到失去视力一样，成功的公司也常会患上“能力盲点”。 当高增长公司将员工人数置于标准之上时，它们创造了一个让工程卓越性退化为残余特征的环境。那些带着“视力”——即识别糟糕基础设施或过时实践的能力——入职的员工，往往会被否决。这导致了一种职业层面的细胞凋亡，他们对质量的追求被逐渐抹除。 为了掩盖这种腐败，公司建立了以官僚控制为先的“卓越中心”，进一步扼杀了内在动力。在市场壁垒的保护下，这些公司凭借早期成功积累的“脂肪”生存，依然保持盈利。管理者常将这种衰退误认为是企业文化，并将员工离职归咎于外部因素，而非自身内部的黑暗。归根结底，留在这样的环境中是一种自我适应；想要重获“视力”，唯一的办法就是离开洞穴，去新的水域游弋。
本次讨论探讨了创新的内在难度以及各类规模企业所面临的结构性挑战。
一种观点认为，大众普遍认为“成功企业会因盲目而衰落”，这种看法忽视了商业周期的现实。创造真正有价值的事物极其困难；随着企业规模扩大，工作的重点会从纯粹的创新转向维护、安全及行政优化等复杂且枯燥的工作。作者指出，大企业的员工并非能力不足，而是因为他们处于一种难以推动变革的结构中；与初创公司动荡的生存状态相比，大企业中那些“安静”的成功往往会被忽视。
另一种观点认为，大语言模型（LLM）的兴起可能加剧了这些问题。通过使群体思维常态化和代码生成标准化，人工智能工具可能会在无意中加速团队的停滞，并导致原创性、高影响力的问题解决能力下降。最终，共识在于：无论是在初创公司还是大型企业，核心难点都在于如何平衡构建创新方案与维持现有复杂系统之间的张力。
请启用 JavaScript 和 Cookie 以继续。
```Hacker News最新 | 过往 | 评论 | 提问 | 展示 | 招聘 | 投稿登录瑞安航空航班上，一男子险些被吸出“脱落”的窗户 (rte.ie)4分 由 theanonymousone 发布于 25 分钟前 | 隐藏 | 过往 | 收藏 | 3 条评论 帮助
LorenDB 16 分钟前 | 下一条 [–]
也许他们会因为这“游乐园套餐”向他额外收费。回复ChrisArchitect 10 分钟前 | 上一条 | 下一条 [–]
更多讨论：https://news.ycombinator.com/item?id=48858997回复spiderfarmer 11 分钟前 | 上一条 [–]
是时候更新 Windows 了。回复
准则 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：```
我们目前正在经历一起影响 Proton 服务登录的故障。我们的工程团队正在积极调查，并致力于尽快恢复正常访问。对于此次服务中断，我们深表歉意，并在有进一步消息时会及时更新。
Proton AG 目前正经历服务中断，这引发了 Hacker News 用户的不满。评论者们表达了对该平台不可靠性的怨言，一些用户指出，为一项缺乏稳定性的服务付费颇具讽刺意味，这种不稳定性是他们几十年来从未遇到过的。一位新订阅用户表示，自己在购买年度计划几分钟后就遭遇了中断，并称这次宕机让他重新考虑是否要将 Proton 用于域名注册等关键通信。另一些人则借此将 Proton 的不稳定性与 Azure 等其他主要服务提供商进行了对比。
这篇文章哀悼了以参与为基础的本真文化的消亡，认为其已被表演性的“奇观”和精心策划的营销所取代。作者主张，以人工智能、社交媒体和算法消费为特征的现代数字生活，导致了“电极刺激（wireheading）”现象，即用户在缺乏现实参与的情况下，体验到一种虚假的成就感。 作者指出，互联网这台“机器”已有效地胜过了真正的人类体验，将个人身份转变为统一且顺从的数据。随着我们的“内在现实”成为全球信息战的主要战场，作者警告称，我们已不再是遭遇物理上的征服，而是正经历心理上的同化。尽管作者认为现代人工智能不过是自我长达数十年退化的顶点，却并未提供简单的解决方案，并指出这场“新战争”需要的是灵魂本身。归根结底，本文以愤世嫉俗的视角观察了技术如何吸收人类文化，剥离其棱角，并将空洞、预先咀嚼过的版本反馈给人类，最终使个体失去了人生的方向盘。
```Hacker News
最新 | 过往 | 评论 | 提问 | 展示 | 招聘 | 提交
登录
朋克，或者我为什么不再直播了 (geohot.github.io)
21 点，由 surprisetalk 发布于 31 分钟前 | 隐藏 | 过往 | 收藏 | 讨论
帮助
准则 | 常见问题 | 列表 | API | 安全 | 法律 | 加入 YC | 联系
搜索：```
人们很容易任由大语言模型（LLM）生成冗余代码，并想当然地认为既然是 AI 在写代码，那么诸如“DRY”（不要重复自己）之类的可维护性问题就不再重要了。然而，这是一种危险的谬误。 大语言模型通过模仿你代码库中已有的模式、捷径和架构习惯来生成代码。当你不断合并重复的逻辑或“快速而草率”的解决方案时，你不仅是在外包工作，更是在训练模型将糟糕的编码习惯作为你项目的标准。每一次复制粘贴的条件语句都在强化一种错误的模式，导致模型在未来的响应中优先采用这些“反模式”。 最终，你的代码库将充斥着技术债务，而你将越来越难以通过提示词（Prompt）来摆脱困境。为避免这种情况，你必须将代码库视为一份高质量的蓝图。通过保持代码整洁且结构化，你可以确保 LLM 提供持续的高质量输出，而不是自动制造未来的维护难题。归根结底，你依然应该像对待人类维护者那样去编写代码，因为 AI 终究会学会模仿你最坏的习惯。
Hacker News 上的讨论揭示了开发者在使用 AI 智能体（AI agents）方面的分歧。一些人主张采用“AI 原生”工作流，通过详细的清单、多个子智能体和复杂的提示词来确保质量；而另一些人则认为，这反映了工具的匮乏和行业标准的下降。
**主要观点包括：**
* **“清单”式方法：** 许多用户创建自定义指令（如 `/review`）来强制执行质量标准。这些指令充当了 AI 的“操作手册”，涵盖最佳实践、测试要求和架构约束，以缓解模型生成通用或重复代码的倾向。
* **可维护性差距：** 批评者警告说，依赖 AI “大量生产”代码往往会导致逻辑臃肿混乱，使人类难以理解。他们强调，代码应为人类维护者而写，因为 AI 生成的代码往往缺乏长期的结构完整性。
* **编码的未来：** 争论的焦点在于：一方认为手动编码是一项核心且令人愉悦的技能，能够确保质量；另一方则认为 AI 辅助的“集群”开发已成现实，其优先考量是速度和迭代优化，而非精雕细琢的手工编程。
总而言之，目前共识认为 AI 是提高生产力的强大工具，但它需要人类的积极监督、严格的测试以及明确的架构边界，以防止积累长期技术债务。