LLM

翻译：Transwan 校改：Carl Cui MLX、oMLX 和 MTPLX 都是跑在 Apple Silicon 上的本地 LLM 工具，它们都强调速度，并且名字相近，这很容易让人把它们当成三个互相竞争的产品，然后问“谁是最快的”。 实际上，它们其中一个是引擎，另外两个是建立在该引擎之上的服务器：MLX 是底层引擎，oMLX 是面向并发和长上下文的推理服务器，MTPLX 是面向单用户低延迟的推理运行时。 如果你要做底层开发、训练、微调，或者想控制生成循环，用 MLX； 如果你要服务多个用户、长上下文、本地 RAG，或者模型刚好卡在内存边界上，用 oMLX； 如果你是单人使用，主要跑编码代理或交互式助手，希望输出更快，并且模型带有原生 MTP 头，用 MTPLX； 本文围绕上面这个判断展开。 三者分别处于什么位置 可以先用一句话理解这三层： MLX：Apple 的原始计算基座，为 Apple Silicon 打造的底层框架，其他两者都导入了它。 oMLX：为服务多用户而调优的推理服务器，在 MLX 之上做连续批处理、KV Cache 分层和 SSD 缓存，适合多人请求、长上下文场景。 MTPLX：为单用户场景调优的运行时，在 MLX 之上利用模型原生 MTP 头做推测解码，适合追求速度的单用户。 MLX 直接面向 Apple Silicon 的统一内存架构。oMLX 和 MTPLX 都构建在 MLX 之上，它们本身不直接和底层硬件打交道，而是通过 MLX 来利用 Apple Silicon 的 CPU/GPU 共享内存能力。 因此把 MLX 拿去和 oMLX、MTPLX 做横向比较并不合理：MLX 是底座，另外两个是建立在底座上的运行时和服务器。 ...

翻译：Transwan 改写：Codex 校对：Carl Cui 很多人看 Claude Opus 4.8 的发布，第一反应是：又一次模型升级。 把 claude-opus-4-7 换成 claude-opus-4-8，跑一遍基准测试，编程能力更强了，agent 任务更稳了，fast mode 更便宜了，模型也更愿意承认不确定。看起来，这就是一次常规的版本迭代。 但如果你真的在生产环境里搭过 agent 系统，会发现这次变化不只是“模型更聪明”。Opus 4.8 更像是 Anthropic 往开发者自己搭的那套工程脚手架里伸了一只手，把其中一部分能力收进了模型和平台。 这才是这次发布更值得关注的地方。 模型之外，真正值钱的是 harness 一个前沿模型本身还不是产品。真正能在生产环境里工作的，是围绕模型搭起来的那套 harness。 这里的 harness，可以理解成一套把模型变成可靠系统的外部结构。它通常包括五层： 第一层是约束层（Constraint）：比如模型路由、token 预算、成本和质量之间的权衡。什么时候用强模型，什么时候用便宜模型，什么时候多思考，什么时候快速返回，这些都属于约束； 第二层是上下文层（Context）：也就是你给模型喂什么信息，包括检索、记忆、领域知识、上下文窗口的组织方式。 第三层是执行层（Execution）：比如工具调用、多 agent 编排、任务拆分、重试、状态管理。模型不是只回答一句话，而是要真的把事情跑完； 第四层是验证层（Verification）：模型生成结果之后，如何确认它没有骗你、没有过早宣布完成、没有把错误代码当成正确结果。这一层通常由测试、linter、评判模型、人工 review 或业务规则组成。 第五层是生命周期层（Lifecycle）：包括评估、部署、监控、告警、回滚，以及你如何判断这个系统在真实业务里是否真的有效。 过去两年，模型厂商主要提供“发动机”，这五层大多由应用团队自己搭。也正因为如此，很多 AI 产品的护城河并不在模型本身，而在这套 harness 里。 Opus 4.8 的信号是：Anthropic 开始把其中几层通用能力收回去了。 验证层，正在被模型内化 Opus 4.8 最值得注意的变化之一，是所谓的“诚实度”提升。Anthropic 官方说，相比 Opus 4.7，Opus 4.8 在自己写的代码中让缺陷不被提醒地通过的概率大约降低了四倍。 这句话换成工程语言就是：模型更会检查自己了。 过去，我们为什么需要外部验证层？因为模型经常会自信地说“已经完成”，但实际上代码可能没跑通，边界条件没处理，甚至测试都没执行。于是我们在外面加测试、加评判器、加人工检查，防止模型把半成品当成成品交付。 如果一个模型自己发现问题、标记不确定、拒绝过早下结论的能力显著增强，那么验证层的一部分工作就被提前吸收到模型内部了。 更有意思的是，Anthropic 这次不只是在模型能力上做验证。Claude Code 的 Dynamic Workflows 也把验证放进了执行流程里：模型先规划任务，再启动多个并行子 agent，最后在汇报前验证输出。 也就是说，验证同时发生在两个地方：一部分进了模型权重，一部分进了平台编排循环。 ...

翻译：Transwan 校对：Carl Cui 引言：对于想构建本地 AI 环境的人来说，如何选择硬件一直是个难题。毕竟现在跟 AI 有关的硬件，价格一路水涨船高，即便是玩硬件的富哥，“我都懂”也肯定比“我都有”来得地道。这篇文章从应用场景出发，讨论该如何选择本地 AI 硬件。作者压根没有考虑那些入门级或者中等程度的选项，直接在 M5 MBP、DGX Spark 和 RTX PRO 6000 之间比较，主打一个退烧。不知道你看完会不会有收获，反正我决定老老实实先用 API 套餐吧。以下是翻译正文： 在决定购买 M5 MBP、DGX Spark 还是 RTX PRO 6000 之前，让我们先思考这个问题： 你的硬件究竟应该加速代理循环（agent loop）的哪个部分？ 聊天会话和本地 AI 代理系统对硬件的要求不同。AI 编程代理任务侧重于长上下文的重复读取、工具调用、缓存频繁失效（churn）、后台并行工作的子代理、检索、子进程、执行测试、容器这些方面，并且经常会出现多个代理同时使用同一个 LLM 服务的情况。 相比在 Mac 和 NVIDIA 或者统一内存 和 VRAM 之间权衡，我们更应该关注工作负载拆解问题。 在开始讨论硬件之前，我想纠正一种常见的误区：通过比较 token/sec 指标来决定要购买的硬件。我们应该试着将本地代理工作流映射到以下四个瓶颈上： 模型匹配度 预填充延迟 解码吞吐量 并发服务表现 这样尝试以后，你就不太容易做出"冲动"的购买决定，也更能把好钢用在刀刃上。 基准测试引发的争议 最近 M5 对比 DGX Spark 对比 Strix Halo 对比 RTX PRO 6000 讨论中最有用的部分是如何设计基准测试。MMBT fleet study 考虑了其他许多硬件对比测试经常会忽略的事情：它尽量保持模型大小和运行时引擎不变。 ...

翻译：Transwan 校对：Carl Cui 引言：看上去确实有点不可思议，但作者 Manjunath Janardhan 跑通了：通过 per-expert disk streaming 技术和 turboquant-mlx-full 在 16GB 的 Mac Mini 上成功运行起 122B LLM 量化版本。尽管 token 生成速度有限，但可以运行这件事本身就足够梦幻。这篇文章是作者 TurboQuant 系列文章的第 5 部分，展现出当前 AI 工程领域热点技术 —— expert Streaming 和 turboquant —— 的巨大潜力。以下是翻译全文： Per-expert disk streaming 专家流式技术在 Mac 上运行了一个 122B 参数的混合专家模型 —— 这个模型的体积是 Mac RAM 的 3 倍。相同条件下输出结果能保持一致，不会触发操作系统内存交换机制，不需要 sysctl 调优。 图片由 Manjunath Janardhan 提供，通过 TurboQuant-MLX 专家流技术在 16 GB Mac mini 上运行的 122B 参数 LLM 我在一台拥有 16 GB RAM、价值 $599 的 Mac mini 上运行了一个 122B 参数的 LLM，并且可以生成连贯的内容。请注意，这不是我的笔误，这个模型是 Qwen3.5–122B-A10B，一个拥有 256 个专家的混合专家模型：在 BF16 格式下它的权重大约有 240 GB，使用 TurboQuant-MLX 量化到 3-bit 后，它在磁盘上仍然占用大约 54 GB 的空间，这个数字超过了这台机器所有 RAM 的 3 倍，按照以往的方式，它根本不可能在这台 16 GB 的 Mac 上运行。 ...

翻译：Transwan 一份关于如何根据硬件层级、工作流、延迟和隐私来选择本地编程模型的实用指南，而不是仅仅看基准测试截图。 我们都经历过这样的过程：试图在自己的本地机器上运行一个数十亿参数的模型。你花费时间下载权重并将其加载到内存中，结果当你真正尝试输入 prompt 时，机器却彻底卡死。最后通常以一些残缺的输出告终，并意识到还是坚持使用 API 密钥更简单。 我认为最好的本地编程模型不是数学分数最高的那个。而是你的机器能够真正运行而不卡顿的那个。它应该能融入你特定的日常工作流，并符合你对延迟的确切容忍度。 在本文中，我将尝试拆解在 2026 年你应该在自己的硬件上运行什么。我们会审视内存带宽的真实限制、让这些模型发挥效用所需的软件栈，以及在生产环境中真正有效的特定配置。 我们为什么真正需要本地模型 无论是在初创企业还是大型公司，远离云端 API 的转变都是由非常现实的工程因素驱动的。 隐私通常是最主要的触发因素。如果你在一家金融科技初创公司工作，将专有的后端逻辑粘贴到公共云 API 中往往会违反严格的合规规则。本地模型让你的代码库完全保留在自己的机器上。你可以将整套未经文档化的遗留代码库输入到上下文窗口中，而无需签署企业数据协议。 成本可预测性是另一个因素。代理工作流会消耗大量的输出 token。如果你有一个自动化脚本，它读取测试失败信息、建议修复方案、编译代码，并且每天重复这个循环五十次，那么云端 API 账单将会失控增长。本地模型具有固定成本。你一次性购买硬件，然后可以运行无限量的 token。 但本地 AI 是一种严格的权衡。你是在用云服务商庞大的计算集群换取你笔记本的散热极限。配置这些模型需要处理量化格式和内存分配问题。 本地技术栈 你运行的不只是一个模型，而是一整套栈。模型只是一个包含数十亿数字的文件。将这些数字加载到内存中并为你的编辑器提供服务的软件层，决定了整个系统的表现。 运行时引擎是这个栈的核心。Ollama 目前是大多数开发者的默认选择。它将复杂的推理引擎封装成一个简单的命令行工具。LM Studio 是另一个出色的选择，它提供了用于管理不同模型文件和量化版本的图形界面。这些运行时负责跨 CPU 和 GPU 分配内存的繁重工作。 以下是使用 Ollama 的 Python 客户端进行最基本的本地交互时的样子。你拉取模型并发送一个 prompt。无需 API 密钥，也不需要向外部服务器发起网络调用。 # Terminal: pull the model first # ollama pull qwen3-coder:30b from ollama import chat stream = chat( model="qwen3-coder:30b", messages=[ { "role": "system", "content": "You are a senior Python developer. Be concise.", }, { "role": "user", "content": "Write a function that retries an async HTTP call with exponential backoff.", }, ], stream=True, ) for chunk in stream: print(chunk["message"]["content"], end="", flush=True) 这些现代本地运行时的真正威力在于标准化。Ollama 和 LM Studio 都提供了 OpenAI 兼容的 API 端点。这意味着任何为云端模型构建的现有脚本或框架，都能立即与本地模型协同工作。只需更改 base URL 即可。 ...

翻译：Transwan 校对：Carl Cui 在 Mac 上运行本地 LLM，近期有一些新的变化： 其中一项重要的变化：2026 年 3 月 30 日发布的 Ollama 0.19 版本，将 Apple Silicon 上的推理引擎替换为 MLX。通过 Ollama 在 M5 Max 上运行 Qwen3.5–35B-A3B，基准测试显示，预填充（prefill）速度从 1,154 token/sec 提升到 1,810 token/sec（+57%）；解码（decode）速度从 58 token/sec 提升到 112 token/sec（+93%）。这并非一次不起眼的优化，而是在最常用的本地 LLM 上实现了接近 2 倍的提升。 第二：Apple Foundation Models 框架于 2025 年随 macOS 26 / iOS 26 发布，在 2026 年第一季度和第二季度逐步成熟，成为 Swift 应用可以真正依赖的框架。通过 @Generable 宏实现的引导式生成（Guided generation）可产生类型安全的结构化输出，它内置工具调用（Tool calling），支持多轮会话。这个模型拥有 3B 参数，针对大多数应用实际执行的任务（例如摘要、分类、结构化提取）进行了优化。对了，它是完全免费的。 第三：macMLX 于 4 月 18 日发布，它是一个原生的 SwiftUI LLM 运行时，提供兼容 OpenAI 的 API。任何已经支持 OpenAI API 的应用只需修改配置即可切换到 macMLX。 ...

之前写了名为 GitHub 宝藏：免费 LLM 资源列表 的文章，分享了一个专门搜集免费 LLM 的 GitHub 项目。这篇文章介绍其中提到的 NVIDIA NIM 服务。 1. 什么是 NVIDIA NIM NVIDIA NIM 是一套易于使用的预构建容器工具，可在任何 NVIDIA 加速基础设施 (云、数据中心、工作站和边缘设备) 上快速部署最新 LLM。它提供免费额度的托管 API，通过访问 build.nvidia.com，用户可以访问大量企业级 LLM，例如 Kimi-k2.6，DeepSeek-V4-Pro，GLM-5.1 等等，这些模型都针对 NVIDIA GPU 运行了优化。 目前 NIM 提供的免费 API 端点采用速率限制模型，限制为 40 请求每分钟。 NVIDIA NIM 提供的一个独特功能是良好的可移植性：用户可利用免费额度的托管 API 构建原型，在完成概念验证后，用户可以下载相同的 NIM 容器，直接在本地 NVIDIA 硬件（RTX PC 或工作站）或私有云上运行 LLM。 除了上面提到的可移植性，NVIDIA NIM 还有下面这些优点： OpenAI 兼容 API - 所有支持的模型都遵循标准 OpenAI API 格式，现有应用程序只需要简单地将 base_url 更改为 NVIDIA NIM 端点并提供 API 密钥既可完成 LLM 切换； 提供丰富的 LLM - 提供纯文本、图像和视频 LLM，还提供专为编程优化的 LLM 以及专门用于药物发现和蛋白质结构预测的 LLM； 2. 如何使用 在 https://build.nvidia.com/ 上进行注册，注册过程中确认电子邮件，并验证手机号码（见下图），然后就可以使用了。 ...

译者：Carl Cui 通常我们训练 Transformer 是希望它们内部出现有用的模式识别回路，但是如果我们已经知道了路径呢？如果我们不是从数据中学习权重，而是分析性地构建它们，使模型直接执行计算图呢？ 以上其实是我一个周末项目背后的想法。 我不把 Transformer 看作一个必须通过优化来发现算法的系统，而是把它当作一台可编程的机器： 调度序列（schedule）规定了每一步应该计算哪些中间量； 隐藏维度（Hidden dimensions）被分配给各个变量，就像微型计算机中的寄存器一样； 注意力头（Attention heads）通过布线（设置权重）来执行查找和路由； 前馈网络（Feed-forward network）用来实现局部门控计算； 残差更新（Residual updates）将下一时刻的机器状态写回流中（token 的残差流）。 结果就是一个普通的 Transformer 在执行一个确定性的程序。 图 1：执行程序的 Transformer。残差流存储当前机器状态 (x,y,z)；嵌入之后，状态包含输入 x=B；注意力块执行查找步骤 y=lookup[x]=5，并通过残差加法将该结果写回状态中；然后 FFN 执行局部计算 z=y+1=6；最后，输出头读取更新后的状态，并输出结果。 在这种观点下，残差流（residual stream）是工作内存，每一层成为一个机器步骤。有的值被读取，有的被转换，有的被传递，有的则在其槽位可以安全复用时被覆写。Transformer 开始变得像一个由注意力、线性投影（linear projections）和门控块（gating blocks）构建而成的小型编译计算机。 这一切都不需要训练。如果你已经有了一个计算图，以及一张关于每个中间变量应该存在于哪一步的调度表（schedule），那么你就可以直接构造出模型的权重。这样一来，Transformer 就变成了一个执行引擎（execution engine），它的行为由设计决定，而不是由梯度下降（gradient descent）决定。 有一点会让这件事变得有意义：它为外部工具调用提供了一种替代方案。我们不再需要迫使模型在需要进行精确计算时离开自身的执行循环，而是可以设想给模型一个内部确定性模式。在一种模式下，模型表现得像一个灵活的语言系统：生成、抽象、推理；在另一种模式下，它则更像一台编译好的机器：更新状态、遵循固定的计算图、可靠地执行精确步骤。这与标准的“LLM + 工具”模式完全不同。它表明至少某些形式的精确计算，可以存在于模型内部，而不是外部。 一个有用的对比是 Percepta 最近关于在 Transformer 内部执行程序的工作。他们的方案将一个通用的执行机制，实际上是一个解释器，编译进了模型权重，同时将具体的程序在推理时作为提示词的一部分提供。而我这里的设定则更狭窄、更专门化。我并非在权重中放入一个解释器，而是将目标程序本身编译进了权重。换句话说，他们的模型更像一个为提供的程序而设的通用执行器，而这个模型则更像一个为固定计算图打造的专用编译机器。这使得它的通用性较差，但也更简单、更透明，便于理解确定性计算是如何被直接嵌入到标准 Transformer 模块中的。 在本文的剩余部分，我将通过一个小例子来具体说明上面的思路。我们会从一个简单的程序出发，将其变量分配到隐藏状态的各个槽位中，然后逐步展示：如何通过解析设计来“布线”注意力层、前馈层和残差更新，从而让一个标准的 Transformer 一步一步地执行这个程序。 1. 编译到 Transformer 中的示例程序 与其停留在比喻的层面，不如亲眼看看一个非常小的程序是如何运行的。下这是我在本文其余部分将使用的示例程序： lookup = { "A": 2, "B": 5, "C": 9, } x = input y = lookup[x] z = y + 1 output z 这个程序故意很小，但它包含我们需要的三个要素： ...

译者：Carl Cui Ollama 每月有 5200 万次下载，这几乎是每个教程都推荐的工具。我使用了六个月，觉得它“可以用于生产环境”，并把它部署给 40 个内部用户。结果响应时间从 3 秒增加到超过一分钟，并且请求开始超时。模型并没有问题，出问题的是 Ollama。 这次事件促使我深入测试了三大本地 LLM 运行工具：Ollama、vLLM 和 llama.cpp。测试结果彻底改变了我对本地 AI 部署的看法。一个让人难以接受的事实是：推荐给新手用的工具，其实在生产环境下表现不佳；而那些所谓“复杂”的工具，其实设置起来并不难。 1. 为什么本地 LLM 部署越来越流行 这里有一组数字：llama.cpp 在 2026 年 3 月达到 100,000 个 GitHub star，比 PyTorch 或 TensorFlow 更快到达这一里程碑，llama.cpp 只是一个三年前还不存在的项目；Ollama 在 2026 年第一季度达到了 5200 万次月下载量，是 2023 年第一季度 10 万次月下载量的 520 倍；Hugging Face 上超过 60% 的量化模型现在以 GGUF 格式发布，这是 llama.cpp 创建的标准。 这已经不再是业余爱好者在笔记本电脑上运行聊天机器人的阶段了。团队正在通过部署本地 LLM 来控制成本，避免数据离开他们的网络，并获得云 API 难以达到的百毫秒内延迟。这些区别，不仅仅在于开发体验，关键还在于你的应用能不能经受住真实用户的考验。 2. 如何测试三大工具 我在相同的硬件（配置 RTX-4090 24GB VRAM 和 64GB RAM 的工作站）上运行每个工具，基于相同的模型 Llama-4-Scout-17B-Instruct，测试了三种场景： ...

今天发现一个 Github 宝藏项目：free-llm-api-resources。它是一个免费 LLM API 资源列表，汇总了可以免费访问的 AI 模型资源，涉及各种规模，甚至包括 400B+ 参数的巨型模型。 ⚠️ 使用过程中注意保护个人数据 1. 免费提供商列表 1.1 OpenRouter 限制：20 请求/分钟，50 请求/天（可通过 $10 终身充值提升至 1000 请求/天） 支持模型： Hermes 3 Llama 3.1 405B（4050亿参数） Llama 3.3 70B Instruct（700亿参数） google/gemma-4-26b-a4b-it（260亿参数） nvidia/nemotron-3-super-120b-a12b（1200亿参数） openai/gpt-oss-120b（1200亿参数） 1.2 Google AI Studio 数据使用：在欧盟/欧洲经济区/瑞士/英国之外使用时，数据可能用于训练 主要模型： Gemini 3 Flash：250,000 token/分钟，20 请求/天 Gemma 3 27B Instruct：15,000 token/分钟，14,400 请求/天 Gemma 3 12B Instruct：15,000 token/分钟，14,400 请求/天 1.3 NVIDIA NIM 要求：需要手机号验证 限制：40 请求/分钟 特点：上下文窗口有限，支持各种开源模型 1.4 Mistral 免费层：需要选择加入数据训练，需要手机号验证 限制：1 请求/秒，500,000 token/分钟，1,000,000,000 token/月 支持模型：开放和专有的 Mistral 模型 1.5 Groq 支持模型： Llama 3.3 70B：1,000 请求/天，12,000 token/分钟 openai/gpt-oss-120b：1,000 请求/天，8,000 token/分钟 qwen/qwen3-32b：1,000 请求/天，6,000 token/分钟 1.6 Cerebras 支持模型： gpt-oss-120b：30 请求/分钟，60,000 token/分钟 Llama 3.1 8B：30 请求/分钟，60,000 token/分钟 1.7 Cloudflare Workers AI 限制：10,000 神经元/天 支持模型： @cf/nvidia/nemotron-3-120b-a12b（1200亿参数） @cf/openai/gpt-oss-120b（1200亿参数） Llama 3.3 70B Instruct（700亿参数） 2. 提供试用额度的服务商 2.1 Fireworks 额度：$1 支持模型：各种开源模型 2.2 Baseten 额度：$30 计费方式：按计算时间付费 支持模型：任何支持的模型 2.3 Hyperbolic 额度：$1 支持模型： DeepSeek V3 0324 Llama 3.3 70B Instruct deepseek-ai/deepseek-r1-0528 qwen/qwen3-coder-480b-a35b-instruct（4800亿参数） 2.4 SambaNova Cloud 额度：$5（3个月） 支持模型： Qwen/Qwen3-235B（2350亿参数） deepseek-ai/DeepSeek-V3.2 openai/gpt-oss-120b（1200亿参数） 2.5 Scaleway Generative APIs 额度：1,000,000 免费token 支持模型： Llama 3.3 70B Instruct gpt-oss-120b（1200亿参数） qwen3-235b-a22b-instruct-2507（2350亿参数） qwen3.5-397b-a17b（3970亿参数） 3. 如何选择适合的免费服务 3.1 根据需求选择： 需要最大模型（400B+ 参数）： ...