小編精選 - 技術文章翻譯 · 05月14日

我的完全離線 AI 輔助 Linux 開發機器

標題：“我的全離線AI輔助Linux開發機器”

描述：“我在華碩 ROG Flow Z13 上建造的 Arch Linux、Niri 和本地 AI 編碼環境”

已發布：是

標籤：

- "linux"

- "archlinux"

- "development"

- "ai"

系列：“面向開發者的 GNU/Linux 環境”

canonical_url: "https://deepu.tech/my-fully-offline-ai-assisted-linux-development-machine"

日期：2026-05-07

圖片："https://deepu.tech/assets/images/linux-2026/main.png"

封面圖片："https://deepu.tech/assets/images/linux-2026/main.png"

devto_id：3652261

devto_url: "https://dev.to/deepu105/my-fully-offline-ai-assisted-linux-development-machine-3lnl"

原文發表於deepu.tech 。

我最受歡迎的文章之一是2019年我寫的關於我漂亮的Linux開發機的文章。 2021年我又寫了一篇關於我時尚現代的Linux開發機的文章。從那以後，我的配置發生了很大的變化。

我從 Fedora 和 KDE 遷移到了幾乎完全原生的Arch Linux系統。我從傳統的桌面環境切換到了niri ，一個基於 Wayland 的滾動合成器。當然，和所有開發者一樣，我的工作流程現在也融入了 AI。但這一次，我想要一些不同的東西：能夠在我自己的機器上完全離線執行的 AI 輔助開發。

是的，在Linux系統上進行本地AI編碼。這有什麼理由不喜歡呢？

這並非一份教你如何復現我所有配置的教學。我的完整個人配置是私有的，因為它包含太多機器相關的和個人化的東西。但我正在製作一個精簡的公開版本，其中包含 Arch、niri、DMS、OpenCode 和 llama.cpp 所需的最低限度元件，地址在deepu105/archdots 。

這篇文章主要介紹我目前的 Linux 開發機器的配置，以及我最終選擇這套配置的原因。

這是我執行以下所有操作的主要機器。

Rust、JavaScript、TypeScript、Java、Go、Python、Linux 和 Web 開發
本地執行多個 Web 應用程式
執行 Docker 容器和本地 Kubernetes 集群
Kubernetes、Terraform 和雲端 CLI 協同工作
寫作、部落格、演講和演示
大量使用瀏覽器
電子郵件、聊天和視訊會議
螢幕錄製、截圖、影片剪輯和輕媒體製作
執行本地LLM進行編碼、重構和程式碼審查
測試人工智慧工具時，無需將每個提示都傳送到雲端供應商

機器配置

對於這種部署方式來說，機器的配置至關重要。執行瀏覽器、幾個整合開發環境（IDE）、Docker、終端機和本機LLM（語言學習管理器）並非輕量級任務。

我目前的電腦是華碩 ROG Flow Z13 2025 型號。它真是個奇特的小傢伙。嚴格來說它是一款平板電腦，但它的 CPU、GPU 和記憶體都足夠強大，可以像行動工作站一樣運作。

以下是目前的配置。

型號：華碩 ROG Flow Z13 GZ302EA
處理器：AMD Ryzen AI Max+ 395，16 核心 32 執行緒
顯示卡：AMD Radeon 8060S 整合顯示卡，附 40 個運算單元
記憶體：128GB統一記憶體。我已將64GB分配給GPU，64GB分配給CPU。這可以在BIOS中配置。
儲存：2TB NVMe SSD
內建顯示器：13英寸，2560x1600分辨率，180Hz刷新率
外接顯示器：34吋3440x1440顯示器和27吋2560x1440顯示器
攝影機：Razer Kiyo Pro
鍵盤和滑鼠：Keychron K2 和 Logitech MX Vertical

記憶體是這裡最關鍵的部分。對於一般的開發工作，32GB 記憶體足夠，64GB 則非常理想。但對於本地 AI 開發來說，記憶體的使用情況就截然不同了。一個 270 億量化的模型、一個大型上下文視窗、Docker、Chrome 瀏覽器以及一個編輯器，都會毫不留情地消耗大量記憶體。

擁有如此大的統一記憶體意味著這台機器可以執行實用的本地編碼模型，而不會讓人感覺像是在做科學實驗。這意義重大。

作業系統

我在之前的文章中讚揚過 Fedora，現在仍然認為 Fedora 是大多數開發者的最佳 Linux 發行版之一。它的更新流暢，新軟體包發布頻繁，而且通常不會造成太多幹擾。

但這次我選擇了純淨版的Arch Linux 。所以，沒錯，我用的是 Arch！ 😉 我知道，滾動更新什麼的。我用 Linux 這麼久了，早就知道自己在做什麼了。

主要原因很簡單：我想要最新的核心、 Mesa 、 ROCm相關元件、Wayland 工具和桌面軟體包，而無需等待下一個發行版發布。像 Flow Z13 這樣的新硬體通常受益於更接近前沿的技術。 Arch 正好滿足了我的需求。好吧，我還愛上了像 niri 和 Hyprland 這樣酷炫的新合成器，而 Arch 讓我無需等待移植就能執行它們。我一開始使用的是 Hyprland，但最終發現 niri 更適合我的工作流程，而 Arch 讓切換和嘗試變得非常容易。

我的裝置仍然相當乏味，我這麼說可不是貶義。

Btrfs 檔案系統用於根目錄、使用者目錄、快取目錄和日誌目錄子卷
GRUB引導程式
paru用於 pacman 和 AUR 包
Timeshift和grub-btrfs用於快照
PipeWire音訊
用於網路的NetworkManager
Docker 、 Distrobox 、 Flatpak ，以及在適當的情況下使用一些Homebrew。

我還使用Topgrade來保持系統更新。我的私人配置甚至將其與DankMaterialShell連接起來，這樣我就可以從更新欄看到可用的更新，並在 Kitty 中觸發系統上所有資源的更新，包括 pacman/AUR、brew、cargo、npm、VS Code 插件、Docker 映像等等。

再說一遍，這很簡單，至少在我看來是這樣。

桌面環境，或缺乏桌面環境

這大概是我之前配置中最大的變化。我不再使用 GNOME 或 KDE 作為我的主要桌面環境。我使用niri ，它是一個可滾動平舖的 Wayland 合成器。

如果你之前沒用過 niri，它的工作流程與傳統的平鋪式視窗管理器截然不同。它不會將所有視窗強制排列在固定的網格中，而是以列的形式排列，你可以水平滾動瀏覽。這聽起來可能有點奇怪，但上手之後就會覺得非常順手。一旦習慣了，在超寬顯示器和筆記型電腦螢幕上使用起來就非常自然。我尤其喜歡它提供的觸控板手勢，可以用來切換工作區和移動視窗。這是一種非常流暢的視窗管理方式。

niri 中的滾動工作區

我目前的會話狀態如下。

登入管理器：Wayland 上的SDDM
視窗管理器：niri 26.04 on Wayland
Shell ： DankMaterialShell ，通常簡稱為DMS。
終端機：小貓
主題：到處都是貓咪瑪奇朵。我太喜歡這個配色了。
字體：Inter Variable 和 JetBrainsMono Nerd Font

Niri 和 DMS

Niri 為我提供了合成器。 DMS 為我提供了桌面外殼元件，否則我需要自己將它們拼接起來。

DMS 取代了許多常用的 Wayland 桌面底層機制：

頂部欄
應用程式啟動器、控制中心、媒體控制
剪貼簿管理器、通知中心
流程和系統監控
電源選單，鎖定螢幕
螢幕截圖和螢幕錄製插件
壁紙和主題切換

如果一個專案就能很好地完成任務，我就不想維護五種不同的工具和一大堆腳本。 DMS 雖然還很年輕，但已經相當實用，尤其是在配合 niri 使用時。它的可擴展性也很強，我已經開始加入一些我需要的工具了。例如，一個本地儲存的待辦事項小工具。

Flow Z13 也需要一些特殊處理。我的私人配置中修復了華碩快捷鍵、觸控板行為、鍵盤背光、Thunderbolt 重新掃描以及 Wi-Fi 的一些小問題。公開的 archdots 程式碼庫只會包含可重複使用的部分。畢竟這是在新硬體上執行 Linux，所以出現一些小問題在所難免。沒有小故障的 Linux 體驗還能叫 Linux 體驗嗎？

開發工具

我的開發工具大多依然很乏味，不過這倒也挺好。這些都是個人選擇，只要你用順手就行，其他都不重要。

我的開發工具

Shell ：我使用Zsh，搭配zinit 、 Powerlevel10k 、 zoxide和fzf 。我仍然使用大量別名來管理 Git、Docker、套件管理工具、Jekyll 和本機 AI 工具。

終端：我用的是Kitty 。它支援標籤頁、分割畫面顯示、剪貼簿綁定、快速存取終端，還有一些自訂快捷鍵。它速度很快，在 Wayland 下運作良好，而且不會妨礙我的工作。

編輯器：我使用Neovim ，預設編輯器是LazyVim 。根據專案和測試內容的不同，我有時也會使用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助手一起編寫程式碼，而無需將程式碼、提示、日誌或未完成的想法傳送到遠端API。這並非因為每個專案都必須保密，而是因為本地優先的工具功能非常實用，尤其是在這個日益走向科技寡占的世界。

我目前的技術棧是：

OpenCode作為編碼代理
這是一個經過定制的llama.cpp建置版本，支援 HIP。它的性能遠高於 Ollama 或 LM Studio。
本地llama-server在127.0.0.1:18080/v1上公開了一個與 OpenAI 相容的 API。
根據任務的不同，我使用 Qwen3.6 27B 和 Gemma 4 31B 作為本地模型。我根據需要使用不同的量化級別，從 4 位到 8 位不等。
LM Studio用於管理模型和離線聊天。
Radeon 8060S 上的 ROCm/HIP 加速
opencode-telegram-bot用於透過 Telegram 遠端管理 OpenCode 會話

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

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "llama.cpp": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "llama.cpp ROCm (local)",
      "options": {
        "baseURL": "http://127.0.0.1:18080/v1"
      },
      "models": {
        "qwen3-6-27b-q8-0": {
          "name": "Qwen3.6 27B Q8_0 (local ROCm)",
          "limit": {
            "context": 262144,
            "output": 16384
          }
        },
        "qwen3-6-27b-q6-k": ...,
        "qwen3-6-27b-q4-k-m": ...,
        "gemma-4-31b-it-q4-k-m": ...,
        "gemma-4-31b-it-q8-0": ...
      }
    },
    "openrouter": {
      "models": {
        "moonshotai/kimi-k2.6": {
          "name": "Kimi K2.6 (OpenRouter backup)",
          "limit": {
            "context": 262144,
            "output": 16384
          }
        },
        "deepseek/deepseek-v4-pro": {
          "name": "DeepSeek V4 Pro (OpenRouter backup)",
          "limit": {
            "context": 1048576,
            "output": 384000
          }
        }
      }
    }
  }
}

我使用別名啟動本地模型伺服器。

llamaServer

這指向一個小腳本。它允許我選擇 GGUF 模型、上下文大小和推理模式。它會記住上次的選擇，所以大多數時候我只需啟動它就能開始工作。

目前的預設模型和上下文如下：

Qwen3.6-27B-Q8_0.gguf - 256k context

以下是我機器上本機模型的llama-bench快速比較。數值為每秒產生的 token 數，啟用了 ROCm、完全 GPU 卸載、快閃注意力機制、f16 KV 快取、4096 個 token 的提示、256 個 token 的產生以及 3 次重複測試。

| 模型 | 量化 | 大小 | 提示令牌/秒 | 產生令牌/秒 |

| -------------- | -----------: | --------: | --------------: | ------------------: |

| Qwen3.6 27B | Q4_K_M | 15.40 GiB | 260.06 | 10.41 |

| Qwen3.6 27B | Q6_Q | 20.56 GiB | 279.37 | 279.37 8.70 |

| Qwen3.6 27B | Q8_0 | 26.62 GiB | 260.12 | 260.12 7.18 | 7.18

| Gemma 4 31B IT | Q4_K_M | 17.39 GiB | 209.57 | 9.12 |

|傑瑪 4 31B IT | Q8_0 | 30.38 GiB | 202.31 | 6.19 |

完整資料為 25.6 萬個代幣。以下是 Qwen 各變體的完整資料基準測試。

| 模型 | 量化 | 大小 | 提示+生成令牌/秒 |

| ----------- | -----------: | --------: | -------------------------: |

| Qwen3.6 27B | Q4_K_M | 15.40 GiB | 67.15 |

| Qwen3.6 27B | Q6_K | 20.56 GiB | 65.77 | 65.77

| Qwen3.6 27B | Q8_0 | 26.62 GiB | 64.34 |

在我的配置下，使用 256k 上下文的 Qwen3.6 27B Q8_0 模型在推理模式下執行，會佔用大約 70% 的 GPU 內存，提示加生成過程的處理速度約為 64 個 token/s。對於一個擁有如此大上下文的本地模型來說，這個速度相當不錯。

llama.cpp 的建置也是透過一個小腳本實現的自動化。

cmake -S /mnt/work/Workspace/llms/llama.cpp \
  -B /mnt/work/Workspace/llms/llama.cpp/build-hip \
  -G Ninja \
  -DGGML_HIP=ON \
  -DAMDGPU_TARGETS=gfx1151 \
  -DCMAKE_BUILD_TYPE=Release

cmake --build /mnt/work/Workspace/llms/llama.cpp/build-hip \
  --config Release \
  -j "$(nproc)" \
  --target llama-server llama-bench

伺服器底層運作原理如下。

ROCBLAS_USE_HIPBLASLT=1 llama-server \
  --model "$model" \
  --alias "$alias_name" \
  --host 127.0.0.1 \
  --port 18080 \
  --ctx-size "$ctx" \
  --n-gpu-layers 999 \
  --flash-attn on \
  --no-mmap \
  --cache-type-k f16 \
  --cache-type-v f16 \
  --batch-size 4096 \
  --ubatch-size 512 \
  --reasoning "$reasoning"

伺服器執行後，OpenCode 會像與任何 OpenAI 相容的供應商通訊一樣與它通訊。不同之處在於，整個流程都停留在我的機器上。

我覺得它非常優雅！

不過，我並非只使用本地模型。對於複雜的任務，我也會透過OpenRouter使用前沿模型，主要是Kimi K2.6和DeepSeek V4 。偶爾我也會使用 Copilot CLI，在工作中，我也會使用 Claude Code。

就框架而言，我更喜歡 OpenCode。就我目前主要從事的程式設計任務（主要是用 Rust 和 TypeScript 編寫的開源專案）而言，我感覺到 Claude Code 和 OpenCode 搭配 Kimi 或 DeepSeek 時，效能上並沒有明顯的差別。當然，這可能因人而異，但對我來說，OpenCode 的表現相當不錯，而且我特別喜歡它的使用者體驗。我同時也在嘗試使用Pi ，看看是否最終會選擇它。

為什麼本地AI編碼對我很重要

本地AI並非萬能。在許多任務中，尤其是在需要最高推理品質或極快反應速度時，最好的託管模型仍然更勝一籌。但本地模型也有其獨特的優勢。

對我來說，優勢顯而易見。

教育/樂趣：執行本地模型是了解這些模型的工作原理、所需硬體以及如何優化它們的絕佳方式。這本身就是一項有趣的嗜好。就更好地理解人工智慧領域以及解決工作中遇到的問題而言，這已經帶來了回報。
隱私：我可以將其用於私人程式碼、不成熟的想法、本地日誌和實驗，而無需考慮哪些內容會離開機器。
離線使用：無需網路連線即可使用。這在旅行或網路不穩定時非常實用。
成本控制：長時間編碼和實驗無需擔心費用問題。我可以隨心所欲地執行，無需擔心賬單。
可自訂性：我可以隨時更改模型、上下文、快取類型、建置標誌、伺服器參數和客戶端配置。

但凡事都有利弊。

模型品質很大程度取決於模型本身和量化方式。例如，Qwen3.6 27B 在我目前測試的大多數任務中表現良好，但隨著上下文資訊的不斷增長，模型會變得過於緊湊，甚至出現錯誤。因此，對於需要長時間處理上下文資訊的任務，我會使用 Kimi 或 DeepSeek。我做了一些非正式的基準測試，給 Claude Opus 4.7、Qwen3.6 27B 和 Kimi K2.6 相同的提示訊息，結果發現模型質量存在差異，但差異並不顯著。有時，本地模型甚至表現得比其他模型更好，例如在複習過程中發現 Claude Opus 遺漏的資訊。
大上下文很有用，但它並非免費，因為它會影響每秒令牌數。 Qwen3.6 27B 在 256k 上下文的情況下執行速度明顯慢於託管的 Frontier 模型，可能慢兩到三倍。
在全新的 AMD 硬體上，ROCm 的效能可能會有些不穩定，但由於目前的型號，任何問題都能很快解決。
某些代理程式工作流程在本地執行時比在託管模型上執行時速度更慢。
您需要關注模型儲存、更新、伺服器標誌、GPU 記憶體和散熱。

所以，不，我不認為每個人都應該採用本地編碼模式。但如果你喜歡掌控自己的技術棧，並且擁有相應的硬件，那麼這是一個非常令人滿意的方案。

人工智慧工作流程

我通常的工作流程很簡單。

使用llamaServer啟動本機模型伺服器。
如果我想更改模型和上下文預設，請選擇它們。
如果我想更改模型，請在程式碼庫中啟動opencode並選擇一個模型。
請它在進行更改之前檢查程式碼庫。
讓它進行編輯、測試和迭代，同時我透過 Telegram 使用opencode-telegram-bot遠端審查變更。

對於一些小任務，我會關閉推理功能，因為它能加快工具密集型工作的速度。而對於設計問題、除錯或程式碼審查，我會開啟推理功能。腳本會提示我執行這些操作，而不是強迫我記住冗長的命令。

我喜歡這種略顯枯燥的自動化。它消除了摩擦，但又不掩蓋實際發生的情況。

生產力與媒體工具

我的大部分生產力工具都沒有太大變化。

瀏覽器：Google瀏覽器仍然是我的主要瀏覽器。我也保留了火狐瀏覽器。

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

通訊工具：Zoom、Signal、Telegram 以及其他常用工具。

螢幕截圖：DMS 截圖插件、螢幕錄製插件，以及在需要更多控制時使用的 OBS Studio。

圖片和影片：Gimp、Inkscape、Kdenlive 以及一些 Flatpak 工具，如 Upscape 和 Buzz。

檔案管理器：Dolphin，因為即使 KDE 不是我的主要桌面環境，KDE 應用程式仍然非常出色。

還有什麼不完美之處

當然，世事難料。這可是搭載了最前沿Linux系統的全新華碩二合一筆記型電腦，配備了AMD最新晶片、Wayland合成器和本地AI堆疊。如果第一天就一切完美執行，我反而會心存疑慮。

以下是一些目前尚不完善的地方。

連接擴充座後，我的電腦有時會出現睡眠和喚醒故障。通常情況下，顯示器無法喚醒，我需要重新啟動電腦或重新掃描 Thunderbolt 裝置。我找到了一個臨時解決方法，但這仍然很煩人。
由於記憶體佔用大，Hibernate 並不實用。
在 Wayland 上使用 OBS 進行螢幕錄製可能有點棘手，尤其是在使用 niri 時。內建的 DMS 螢幕錄製功能適合快速錄製，但不適合長時間錄製或需要更多控制的情況。我仍在調整我的 OBS 設定以適應這種情況。
Flow Z13 背面有一個很酷的透明窗口，帶有 RGB 燈光。但它在 Linux 系統下無法正常運作。我計劃嘗試使用 Qwen3.6 27B 和 OpenCode 來修復這個問題。這將是一個複雜的硬體專案，可以用來測試該模型的性能。
新型整合顯示卡的 ROCm/HIP 支援需要一些時間。我最近沒遇到任何問題，所以可能已經穩定下來了。

這些對我來說都不是致命缺陷。大多數問題要么已經在我的私人配置中修復，要么已經列入我的待辦事項清單。