我的想法很單純：Pi 留在 Mac 上，貼著我的檔案工作；推論交給一台裝了 RX 7900 XT（20GB VRAM）的 PC，用 LM Studio 跑。
Qwen3.8-27B 以 128K 上下文載入，64 層全部設為 GPU offload。我透過 Pi 用它做了一個 React 加 ECharts 的視覺化。下面是跑得起來的設定，還有我還沒量的東西。
配置
LM Studio 用 Vulkan 而不是 ROCm 跑模型，並在區域網路上開一個 OpenAI 相容的 API。
Pi on Mac
-> LM Studio API on PC (Vulkan runtime)
-> Qwen3.8-27B
-> RX 7900 XT 20GB
LM Studio 裡的設定值：
| 設定 | 數值 |
|---|---|
| 模型 | Qwen3.8-27B |
| GGUF | Qwen3.8-27B-UD-Q3_K_XL.gguf |
| 模型來源 | unsloth/Qwen3.8-27B-GGUF |
| Runtime | Vulkan |
| 上下文長度 | 128,000 |
| GPU offload | 64 層中的 64 層 |
| Flash Attention | 開啟 |
| K 快取 | Q4_0，位於 GPU |
| V 快取 | Q4_0，位於 GPU |
| CPU 執行緒池大小 | 4 |
| 評估批次大小 | 512 |
| 實體批次大小 | 1024 |
| 同時推論數 | 1 |
| RoPE | 預設 |
| 推測解碼 | 關閉 |
| MTP | 關閉 |
Qwen3.8-27B 官方模型卡寫的是 270 億參數、64 層，原生上下文 262,144 tokens。我停在 128K，平常寫程式用不到這麼多，而且放得下。
為什麼選 Q3_K_XL
Unsloth 釋出了好幾種 Qwen3.8-27B 的 GGUF 量化版本。我看過的是這幾個：
| 量化版本 | 檔案大小 |
|---|---|
UD-IQ3_S | 12GB |
UD-Q3_K_XL | 13.1GB |
UD-IQ4_XS | 14.3GB |
UD-Q4_K_M | 16.5GB |
UD-Q5_K_XL | 20.9GB |
檔案大小取自 Unsloth GGUF 儲存庫。我選了 UD-Q3_K_XL：13.1GB 比 4-bit 的版本多留一些空間，又不用退到最小的那幾個 3-bit 檔。
選它是因為放得下，不是因為它品質最好。我沒有拿 UD-Q3_K_XL 和 UD-IQ3_S 跑同一組任務，所以說不出哪個寫程式或用工具比較強。
在 LM Studio 載入模型
Runtime 選 Vulkan。載入之前，我先看了一下記憶體估算：
lms load --estimate-only <model-key> --gpu max --context-length 128000
模型 key 從 lms ls 查，不一定等於 GGUF 檔名。LM Studio 的載入命令文件說，這個估算有把上下文長度、Flash Attention 和視覺支援算進去。
13.1GB 的檔案只是 VRAM 帳單的一部分。執行時的緩衝區、視覺元件和 KV 快取都要佔空間，而 128K 的快取比 8K、16K 大上許多。我把 Q4_0 的 K、V 快取都放在 GPU 上，跟模型各層一起分那 20GB。
LM Studio 的模型載入 API 可以透過 offload_kv_cache_to_gpu 把 KV 快取搬到系統 RAM。這樣或許能換到更長的上下文，但會變慢，而且有些計算緩衝區還是會留在 VRAM。系統 RAM 多一點，對放在 CPU 端的快取或模型層有幫助，但沒辦法讓一張 20GB 的卡變成更大的卡。
估算我只當參考。上下文長度、快取放哪裡、批次大小，都會改變實際載入的結果。載入之後 LM Studio 面板上顯示的，才是該記下來的數字。
將 PC 上的 LM Studio 接到 Mac 上的 Pi
Pi 在 Mac 上讀寫檔案，LM Studio 在 PC 上做推論。LM Studio 的本機伺服器預設用 1234 埠，所以 Pi 指向 PC 的區網位址：
http://<PC-LAN-IP>:1234/v1
改 Pi 的設定之前，我先問 LM Studio 模型 ID 是什麼：
curl http://<PC-LAN-IP>:1234/v1/models
這個端點的說明在 LM Studio 的 OpenAI 相容模型 API 文件。當時的 ID 是 qwen3.8-27b。我一開始猜 qwen/qwen3.8-27b，猜錯了。
Pi 從 ~/.pi/agent/models.json 讀取自訂供應商：
{
"providers": {
"lmstudio": {
"baseUrl": "http://<PC-LAN-IP>:1234/v1",
"api": "openai-completions",
"apiKey": "lm-studio",
"models": [
{
"id": "qwen3.8-27b",
"name": "Qwen3.8-27B",
"reasoning": true,
"input": ["text"],
"contextWindow": 128000,
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"compat": {
"maxTokensField": "max_tokens",
"supportsDeveloperRole": false,
"thinkingFormat": "qwen-chat-template"
}
}
]
}
}
}
models.json 的格式和 openai-completions 供應商類型，Pi 的自訂模型文件裡都有寫。上面的 apiKey 只是給沒開驗證的伺服器用的佔位值。如果開了驗證，真正的 token 請留在本機，別進 Git。
pi --list-models | grep qwen3.8-27b
輸出是 lmstudio qwen3.8-27b 128K。如果 LM Studio 不只監聽 localhost，就要開驗證，而且別讓它暴露在公開網路上。
程式實測：單色網際網路圖
只看一次聊天回覆，稱不上測試。所以我請 Pi 用 React 和 Apache ECharts 做一個單色的網路視覺化。
做出來的示範畫的是一份網際網路拓樸資料，有 17,184 個節點、29,340 條邊、31 個類別。用了 ECharts GL、ForceAtlas2 佈局、灰階配色和一個小 HUD。節點一開始擠在一個三角形裡，接著力導向模擬把它們拉開成圖。
模型是在一個既有的 Vite 專案裡工作，要載入外部資料檔，之後的修改也得保住 WebGL 互動。示範是成功的。不過我沒有記錄它的工具呼叫、失敗的修改或重試次數。這是真實專案，不是受控的 AI Agent 基準測試。
我還沒測量的部分
我沒記每秒 token 數、提示處理速度、RAM 峰值或載入時間，也沒做受控的 64K 對 128K 比較。所以這套配置能用，但這些結果沒辦法可靠地告訴你，它跟其他量化版本比起來快不快、好不好。
下次我會先從 64K 開始，再用 128K 重跑同樣的測試。每次載入都記錄：
- 最終 offload 到 GPU 的層數。
- 模型載入時間。
- 使用同一份長提示的處理速度。
- 使用相同輸出上限的生成速度。
- VRAM 與系統 RAM 峰值。
- 固定的多步驟 Pi 任務能否在不需手動修復的情況下完成。
我也想拿 UD-Q3_K_XL 跟 UD-IQ3_S 比一比。小一點的檔案也許能騰出空間給更長的上下文或更多 GPU 層。我不知道的是，這樣做會不會讓寫程式和用工具變得比較不可靠。
結果
在這個專案裡，這種分工是行得通的：Pi 在 Mac 上，推論在 PC 上。要說它快，或放心讓它跑長時間的工作，我還得先做一次像樣的受控測試。