👋 欢迎来到楠楠老爹的博客！

翻译：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。 ...

1. 什么是 Steering 文件 Steering 文件是 Kiro IDE 中的一种上下文注入机制，用于在与 AI 交互时自动加载和应用特定的规则、指南和上下文信息。 简单来说：Steering 文件让你能够定义一套规则，然后在每次与 AI 交互时自动应用这些规则。 1.1 为什么需要 Steering 文件 想象你有一个翻译项目，需要遵循特定的术语表、格式规范和风格指南。如果每次都手动告诉 AI 这些规则，会很低效。Steering 文件解决了这个问题： 一次定义，多次使用：定义一次规则，在所有交互中自动应用 保证一致性：确保每次 AI 的输出都遵循相同的标准 减少重复工作：无需每次都重新输入相同的指令 易于维护：修改规则时只需更新一个文件 1.2 Steering 文件的位置 项目根目录/ ├── .kiro/ │ ├── steering/ # Steering 文件目录 │ │ ├── translation-workflow.md │ │ ├── code-style.md │ │ └── documentation-rules.md │ └── skills/ # Skill 文件目录 └── docs/ └── glossary.yaml # 术语表等参考文件 2. Steering 文件的结构 2.1 基本格式 --- inclusion: manual --- # 文件标题 ## 第一部分 内容... ## 第二部分 内容... 2.2 FrontMatter 配置 Steering 文件的 FrontMatter 决定了它如何被加载和使用： ...

每个用过 Cluade Code 的开发人员都有过这种体会：关闭一个会话时感觉挺好的，第二天早上打开一个新的会话，Claude 像是“失忆”了一样。你得在新的会话中跟 Claude 重新解释项目的技术决策，然后 Claude 重新读取项目文件，在能解决问题之前，就已经用掉很多 token。每天重复这么几次，会浪费大量的 token。 解决方案：这篇文章分享一个名为 claude-code-memory-setup 的 GitHub 仓库。这个仓库通过组合两个免费工具为 Claude Code 建立持久化记忆系统，可以让 token 消耗降低至原来的 1.4%。 1. 本质上是一个两层结构 第一层：Obsidian 作为声明性记忆 为所有项目创建单一的 Obsidian 仓库 Obsidian 仓库包含原子化的 Zettelkasten 风格笔记、会话日志、架构决策等 Obsidian 仓库根目录下包含一个 CLAUDE.md 文件，告诉 Claude Code 如何读写这个仓库 通过 /resume 和 /save 命令实现会话间记忆传递 /resume 让 Claude 在回答任何问题之前读取最后几个会话日志和当前项目的决策文件 /save 写入一个新的会话日志，并可选择运行 git commit 解决“昨天做了什么”的失忆问题，不需要重复解释 第二层：Graphify 作为结构性记忆 Graphify 是一个免费的 CLI 工具，它使用 tree-sitter（支持 20 多种语言）在本地解析代码库，生成知识图谱 将代码结构转换为可查询的 JSON 文件，Claude Code 查询这个文件，不需要重新读取源文件 对于一个包含 126 个 TypeScript 文件的项目，生成的图谱大小为 172KB，包含 332 个节点和 258 条边，查询成本从 20,000+ token 降至约 280 token 通过与 git hook 配对，可以在每次提交自动更新知识图谱 2. 工作流程 打开 Claude Code -> /resume 加载 Obsidian 上下文 Claude 查询 graph.json 理解代码结构 工作完成后 -> /save 写入日志 git commit 自动重建图谱 3. 记忆 vs 提示词 超越提示词工程：给 AI 提供持久化记忆和代码结构地图 记忆复合效应：提示词是短暂的，记忆是累积的 4. 实际价值 这个项目一个实用、低成本的技术方案，解决了 Claude Code 用户普遍面临的 token 浪费问题，通过建立系统化的记忆机制大幅提升工作效率和成本效益。 ...

我们经常听到这样一些术语：LLM、Agent、向量数据库、tokens、embeddings、RAG，等等。大多数文章会跳过这些基本知识，围绕某个概念直接展开。实际上，理解了这些核心概念，AI 会变得容易很多。 这篇文章主要普及 10 个最重要的 AI 概念，同时会附上相关的资料。 1. Tokens - 文本信息处理的基本单位 AI 模型在理解一个句子之前，并不是像我们人类那样去阅读它，它首先把句子分成一个个小片段，这些小片段就叫做 token。 Token 的正式译法是词元。2026 年 3 月，全国科学技术名词审定委员会与国家数据局正式将 token 在人工智能领域的中文名称确定为“词元”。 我们会把句子当成一个完整的语义来理解，但 AI 是一个 token 一个 token 地处理。跟 AI 模型聊天时，我们输入一句话，它看到的是一连串的 token。 一般来说，一个英文单词大约对应 1 ~ 2 个 token，而一个中文字符大约对应 1 ~ 3 个 token。 例如毛主席的这句话：“世界是你们的，也是我们的，但是归根结底还是你们的”，包括标点在内共 24 个字符，在 GPT-5 中对应 16 个 token： AI 通过 token 来衡量一切： 输入大小 输出大小 价格 上下文窗口 记忆 1.1 尝试 Tokenization 你可以通过下面两个在线词元分词器（Tokenizer）来尝试词元切分（tokenization）： OpenAI Tokenizer Tiktokenizer 2. Embeddings - AI 如何理解语义 在词元切分（tokenization）后，文本被转换为一连串数字（见下图），这些数字被称为“词嵌入”或“词向量”（embeddings）。Embeddings 通过数学方式来表示语义，想象一个包含很多词语的集合： ...

之前写了名为 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，测试了三种场景： ...