完全离线 AI 编程开发机搭建实战

系列 · 面向开发者的 GNU/Linux 环境

我漂亮的 Linux 开发环境

必备的 GNOME 扩展

在 Unix 上使用 Zsh 配置一个漂亮的终端

我的 VS Code 配置——充分发挥 VS Code 的能力

2021 年 Linux 作为日常操作系统的现状

我在 2021 年打造的简洁现代 Linux 开发设备

我的全离线 AI 辅助 Linux 开发设备

LlamaStash 简介：零额外开销、终端原生的 llama.cpp 启动器

我有史以来最受欢迎的文章之一，是 2019 年写的那篇关于我漂亮的 Linux 开发设备的文章。随后，我又在 2021 年写了《我简洁现代的 Linux 开发设备》。从那以后，我的配置发生了很大变化。

我从 Fedora 和 KDE 转向了基本保持原生的 Arch Linux 配置。我从传统桌面环境转向了 niri——一个滚动式 Wayland 合成器。当然，就像所有开发者一样，我如今的工作流中也加入了 AI。但这一次，我想要一些不太一样的东西：能够完全离线、在我自己的设备上运行的 AI 辅助开发环境。

没错，就是在 Linux 上进行本地 AI 编程。这有什么理由不让人喜欢呢？

LlamaStash 简介：零额外开销、终端原生的 llama.cpp 启动器

一个快速的 TUI、CLI、守护进程和 OpenAI 兼容代理，通过单个 Rust 二进制文件使用 llama.cpp 运行本地 LLM

这并不是一篇教你完整复刻我所有配置细节的教程。我的完整个人配置是私有的，因为其中包含太多与特定设备和个人相关的内容。不过，我正在制作一个精简的公开版本，其中只保留 Arch、niri、DMS、OpenCode 和 llama.cpp 所需的最低限度配置，项目位于 deepu105/archdots。

这篇文章更多是在介绍我目前这台 Linux 开发设备的整体形态，以及我为什么最终选择了这套技术栈。

以下所有工作都主要在这台设备上完成。

• Rust、JavaScript、TypeScript、Java、Go、Python、Linux 和 Web 开发

• 在本地运行多个 Web 应用程序

• 运行 Docker 容器和本地 Kubernetes 集群

• Kubernetes、Terraform 和云平台 CLI 相关工作

• 写作、撰写博客、制作演示文稿和现场演示

• 电子邮件、聊天和视频会议

• 屏幕录制、截图、视频编辑和轻量级媒体处理

• 运行本地 LLM，用于编程、重构和代码审查

• 在不把每条提示词都发送给云服务提供商的情况下测试 AI 工具

设备配置

设备配置对于这套方案至关重要。同时运行浏览器、几个 IDE、Docker、多个终端和本地 LLM，绝对算不上轻量级负载。

我目前使用的是 2025 款 ASUS ROG Flow Z13。它是一台有些奇特的小怪兽。严格来说，它是一台平板电脑，但它拥有足够强大的 CPU、GPU 和内存，完全可以像移动工作站一样运行。

以下是目前的配置。

• 型号：ASUS ROG Flow Z13 GZ302EA

• 处理器：AMD Ryzen AI Max+ 395，16 核 32 线程

• 显卡：AMD Radeon 8060S 集成 GPU，拥有 40 个计算单元

• 内存：128GB 统一内存。我为 GPU 分配了 64GB，为 CPU 分配了 64GB，可以在 BIOS 中调整这一配置。

• 存储：2TB NVMe SSD

• 内置显示屏：13 英寸，2560×1600，180Hz

• 外接显示器：34 英寸 3440×1440 显示器和 27 英寸 2560×1440 显示器

• 摄像头：Razer Kiyo Pro

• 键盘和鼠标：Keychron K2 和 Logitech MX Vertical

这里最有意思的部分是内存。对于普通开发工作来说，32GB 目前仍然够用，64GB 则相当充裕。但对于本地 AI 工作而言，内存会改变一切。一个量化后的 27B 模型、一个很大的上下文窗口，再加上 Docker、Chrome 和编辑器，可以轻而易举地疯狂吞噬内存。

如此大的统一内存意味着，这台设备可以运行真正实用的本地编程模型，而不会让人觉得自己是在做科学实验。这一点非常重要。

我在之前的文章中称赞过 Fedora，现在依然认为它是最适合大多数开发者的 Linux 发行版之一。更新过程顺畅，新软件包上线得很快，而且大多数时候不会给你添麻烦。

但这一次，我选择了原生 Arch Linux。所以没错，我用 Arch，顺便一提！😉 我知道，滚动更新之类的问题。我使用 Linux 已经足够久，很清楚自己选择的是什么。

主要原因很简单：我希望使用最新的内核、Mesa、ROCm 相关组件、Wayland 工具和桌面软件包，而不必等待下一个发行版版本。像 Flow Z13 这样的新硬件，通常越接近技术前沿，获得的支持就越好。Arch 可以满足我的需求。好吧，我也确实迷上了 niri 和 Hyprland 这类性感的新型合成器，而 Arch 非常适合运行它们，不需要等待软件包回移植。我一开始使用的是 Hyprland，但后来发现 niri 更适合我的工作流，而 Arch 让切换和试验变得很容易。

我的安装配置依然相当朴素，这是在夸它。

• 为根目录、主目录、缓存和日志创建 Btrfs 子卷

• 使用 paru 管理 pacman 和 AUR 软件包

• 使用 Timeshift 和 grub-btrfs 创建快照

• 使用 NetworkManager 管理网络

• 使用 Docker、Distrobox、Flatpak，并在适合的地方使用少量 Homebrew

我还使用 Topgrade 来保持系统更新。我的私有配置甚至把它集成到了 DankMaterialShell 中，因此我可以直接在状态栏中看到可用更新，并在 Kitty 中触发更新，一次性更新系统里的所有内容，包括 pacman/AUR、brew、cargo、npm、VS Code 插件、Docker 镜像等等。

再说一次，至少在我看来，这套配置非常简单。

桌面环境，或者说没有桌面环境

这可能是与我之前配置相比最大的变化。我不再把 GNOME 或 KDE 作为主要桌面环境，而是使用 niri，一个可滚动的平铺式 Wayland 合成器。

如果你没有使用过 niri，它的工作方式与常规平铺式窗口管理器很不一样。它不会强迫所有窗口进入固定网格，而是让窗口排列在不同列中，你可以在这些列之间水平滚动。听起来有些奇怪，直到你真正理解并习惯它。一旦习惯之后，它在超宽显示器和笔记本电脑屏幕上都会显得非常自然。我尤其喜欢用触控板手势切换工作区和移动窗口。这是一种非常流畅的窗口管理方式。

我目前的会话配置如下。

• 登录管理器：运行于 Wayland 的 SDDM

• 窗口管理器：运行于 Wayland 的 niri 26.04

• Shell：DankMaterialShell，通常简称为 DMS

• 主题：所有地方都使用 Catppuccin Macchiato。我就是非常喜欢这个配色主题。

• 字体：Inter Variable 和 JetBrainsMono Nerd Font

niri 为我提供合成器，DMS 则提供桌面 Shell 组件，否则这些组件就需要我自己拼装起来。

DMS 替代了大量常见的 Wayland 桌面基础组件：

• 应用程序启动器、控制中心、媒体控制

• 剪贴板管理器、通知中心

• 进程和系统监控

• 电源菜单、锁屏

• 截图和屏幕录制插件

• 壁纸和主题切换

对于这类功能，如果一个项目已经做得足够好，我就不想再维护五种不同的工具和一堆脚本。DMS 仍然很年轻，但它已经相当实用了，尤其是与 niri 搭配时。它的可扩展性也很强，我已经开始添加自己想要的工具。例如，一个将数据保存在本地的 TODO 小组件。

Flow Z13 还需要一些特殊处理。我的私有配置中包含针对 ASUS 热键、触控板行为、键盘背光、Thunderbolt 重新扫描和 Wi-Fi 异常的修复。公开的 archdots 仓库只会包含可复用的部分。这毕竟是在新硬件上运行 Linux，当然会遇到一些小问题。没有故障的 Linux 体验，还能叫 Linux 体验吗，对吧？

我的开发工具大多依然很朴素，这是一件好事。这些都是主观选择，只要你用得舒服，具体选择什么工具并不重要。

• Shell：我使用 Zsh，并搭配 zinit、Powerlevel10k、zoxide 和 fzf。我仍然为 Git、Docker、软件包管理、Jekyll 和本地 AI 工具使用大量别名。

• 终端：我使用 Kitty。我配置了标签页、分屏、剪贴板快捷键、快速访问终端以及一些自定义快捷键。它速度很快，在 Wayland 上运行良好，而且不会妨碍我的工作。

• 编辑器：我使用搭配 LazyVim 的 Neovim 作为默认编辑器。根据项目以及正在测试的内容，我仍然会使用 Visual Studio Code。

• 工具链：我使用 SDKMAN! 管理 JDK，使用 NVM 管理 Node.js，使用 rustup 管理 Rust，此外还使用 Bun、Go、Python、Deno 和常见的 Linux 构建工具。

• DevOps：Docker、Docker Compose、kubectl、kdash、Terraform、Distrobox 等等。其中一些来自 pacman 或 AUR，一些来自 Homebrew，另一些来自特定编程语言的安装器。

离线 AI 辅助开发

我也使用云端 AI 工具，它们确实很有用。但我还希望拥有这样一套环境：可以借助 AI 助手编程，而不必将代码、提示词、日志或写到一半的想法发送到远程 API。并不是因为每个项目都是秘密，而是因为本地优先的工具能力值得拥有，尤其是在这个正走向技术寡头统治的世界里。

• 使用 OpenCode 作为编程 AI 智能体

• 使用启用了 HIP 支持的自定义 llama.cpp 构建版本。它的性能远高于 Ollama 或 LM Studio。

• 在 127.0.0.1:18080/v1 上运行本地 llama-server，对外提供与 OpenAI 兼容的 API

• 根据任务选择 Qwen3.6 27B 和 Gemma 4 31B 作为本地模型。我会按需采用不同的量化级别，从 4-bit 到 8-bit。

• 使用 LM Studio 管理模型并进行离线聊天。

• 在 Radeon 8060S 上使用 ROCm/HIP 加速

用于通过 Telegram 远程管理 OpenCode 会话的 opencode-telegram-bot

以下是我的 OpenCode 提供商配置：

我通过一个别名启动本地模型服务器。

这个别名指向一个小脚本。它允许我选择 GGUF 模型、上下文大小和推理模式。它会记住上次的选择，所以大多数时候我只需启动它，就可以开始工作。

目前默认的模型和上下文是：

下面是我机器上本地模型的 llama-bench 快速对比。数据单位是 token/秒，测试条件为：使用 ROCm、完全 GPU 卸载、flash attention、f16 KV 缓存、4096-token 提示词、生成 256 个 token，并重复测试 3 次。

完整上下文长度为 256k token。下面是 Qwen 各个变体在完整上下文下的基准测试。

在我的配置中，以推理模式运行具有 256k 上下文的 Qwen3.6 27B Q8_0，会占用大约 70% 的 GPU 显存，提示词处理加生成的速度约为 64 token/秒。对于一个拥有如此大上下文的本地模型来说，这已经相当不错了。

llama.cpp 的构建也通过一个小脚本实现了自动化。

服务器底层是这样运行的。

服务器启动后，OpenCode 与它通信的方式，就像与任何兼容 OpenAI 的提供商通信一样。不同之处在于，整个工作循环都留在我的机器上。

在我看来，这非常优雅！

不过，我并不只使用本地模型。对于复杂任务，我也会通过 OpenRouter 使用前沿模型，主要是 Kimi K2.6 和 DeepSeek V4。偶尔我也会使用 Copilot CLI；在工作中，我还会使用 Claude Code。

在智能体运行框架方面，我更喜欢 OpenCode。对于我所处理的编程任务——主要是 Rust 和 TypeScript 开源项目——使用 Kimi 或 DeepSeek 时，我没有发现 Claude Code 和 OpenCode 之间存在任何明显的性能差异。当然，其他人的体验可能不同，但对我而言，OpenCode 一直表现得相当不错，而且我尤其喜欢它胜过其他工具的用户体验。我也在同时尝试 Pi，看看是否会把它保留在我的工具组合中。

为什么本地 AI 编程对我很重要

本地 AI 并不能取代一切。对于许多任务来说，最好的托管模型依然更强，尤其是在你需要最高的推理质量或极快的响应速度时。不过，本地模型也有自己最适合的应用场景。

对我来说，它的优势很明确。

教育/乐趣：运行本地模型是了解这些模型如何工作、需要什么样的硬件，以及如何对其进行优化的绝佳方式。这本身就是一项有趣的爱好。它已经让我更深入地理解了 AI 领域，并能够排查工作中遇到的问题，因此早已产生了实际回报。

隐私：我可以把它用于私有代码、尚未成熟的想法、本地日志和实验，而不必考虑哪些内容会离开这台机器。

离线使用：无需互联网也能工作。这在旅行途中或网络不稳定时非常方便。

成本控制：长时间编程和实验时，不必为 token 消耗感到焦虑。我想运行多久就运行多久，无需担心账单。

可折腾性：我可以随时更改模型、上下文、缓存类型、构建标志、服务器参数和客户端配置。

但它也存在一些取舍。

模型质量在很大程度上取决于所选模型和量化方式。例如，到目前为止，Qwen3.6 27B 在我交给它的大多数任务中表现都很好，但随着上下文不断增长，模型会压缩上下文并开始产生幻觉。因此，对于长上下文任务，我会使用 Kimi 或 DeepSeek。我做过一些非科学的基准测试：把同一组提示词分别交给 Claude Opus 4.7、Qwen3.6 27B 和 Kimi K2.6。它们之间的质量差异很明显，但没有大到特别夸张。有时本地模型甚至比其他模型表现得更好，比如在代码审查中发现了 Claude Opus 遗漏的问题。

大上下文很有用，但并非没有代价，因为它会影响每秒处理的 token 数。与托管的前沿模型相比，拥有 256k 上下文的 Qwen3.6 27B 明显更慢，可能要慢两到三倍。

在刚推出的 AMD 硬件上，ROCm 的情况有时会不断变化，不过多亏了现在的模型，任何问题的解决方案通常只需要问一句提示词。

某些智能体工作流在本地运行时，会比使用托管模型更慢。

你必须关注模型存储、更新、服务器标志、GPU 显存和散热。

所以，我并不认为每个人都应该运行本地编程模型。但如果你喜欢掌控自己的整套技术栈，而且拥有相应的硬件，那么这会是一套非常令人满足的配置。

我通常的工作流非常简单。

使用 llamaServer 启动本地模型服务器。

如果想要更改，就选择模型和上下文预设。

在代码仓库中启动 opencode；如果想要更改，就选择一个模型。

让它先检查代码库，然后再进行修改。

让它编辑、测试并迭代，同时我通过 opencode-telegram-bot，从 Telegram 远程审查这些修改。

对于小任务，我会关闭推理，因为这样可以加快大量使用工具的工作。对于设计问题、调试或代码审查，我会开启推理。这个脚本把这些操作变成了一个交互式提示，我不必再记住一长串命令。

这正是我喜欢的那种朴实无华的自动化。它减少了摩擦，同时又不会掩盖实际发生的事情。

生产力与媒体工具

我的大部分生产力工具栈没有太大变化。

浏览器：Google Chrome 仍然是我的主力浏览器。我也保留了 Firefox。

密码管理：我使用 Bitwarden 和 YubiKey。

通信：Zoom、Signal、Telegram，以及其他常见工具。

屏幕捕获：DMS screenshot plugin、screen recorder plugin，以及在需要更多控制时使用 OBS Studio。

图像和视频：Gimp、Inkscape、Kdenlive，以及 Upscayl 和 Buzz 等一些 Flatpak 实用工具。

文件管理器：Dolphin，因为即使 KDE 不是我的主要桌面环境，KDE 应用依然非常出色。

仍不完美的地方

当然，并非所有方面都完美无缺。这是前沿版本的 Linux，运行在一台全新的 ASUS 二合一设备上，搭载全新的 AMD 芯片、Wayland 合成器和本地 AI 技术栈。如果第一天所有东西就都能完美运行，我反而会觉得可疑。

下面是目前存在的一些粗糙之处。

连接扩展坞时，偶尔会出现挂起和唤醒异常。通常是显示器拒绝唤醒，我不得不重新启动，或者重新扫描 Thunderbolt 设备。我有一个解决办法，但它仍然有点烦人。

由于内存容量很大，休眠并不实用。

在 Wayland 上配置 OBS 进行屏幕录制，并让它正常工作，可能有些棘手，使用 niri 时尤其如此。DMS 内置的屏幕录制器很适合快速捕获，但不适合长时间录制，也不适合需要更多控制的场景。我仍在为此调整 OBS 配置。

Flow Z13 背面有一个很酷的透明窗口，配有 RGB 灯光。它在 Linux 下无法工作。我计划尝试使用 Qwen3.6 27B 和 OpenCode 来解决这个问题。这会是一个复杂的硬件项目，可以用来测试模型的能力。

新款集成 GPU 上的 ROCm/HIP 支持需要耐心。我最近没有遇到任何问题，所以它可能已经稳定下来了。

这些问题对我来说都不是什么致命缺陷。大多数问题要么已经在我的私有配置中解决，要么已经列入了我的待办事项。

这无疑是我迄今使用过最有趣的 Linux 机器。我 2019 年的配置很漂亮，2021 年的配置很时尚，而这一套则像是一台真正的本地优先 AI 开发工作站。

原版 Arch 为我提供最新的软件。Niri 带来的工作流既适合小巧的内置屏幕，也适合我的超宽显示器。DMS 提供了精致的桌面体验，却不需要完整的桌面环境。OpenCode 加上 llama.cpp，则为我提供了一个无需云端也能运行的 AI 编程助手。

这套配置并不适合所有人。如果你想要的是一台从不要求你操心内核、ROCm、合成器配置或模型文件的机器，那么它可能并不适合你。但对我而言，这恰好就是那种能让我感到愉悦的开发者机器。

为正确的任务选择正确的工具。

如果你喜欢这篇文章，请点赞或留言。

你可以在 Bluesky 和 LinkedIn 上关注我。