如何在 Continue 中將 Tab 程式碼補全與聊天路由至不同的專用模型

在 VS Code 或 JetBrains 中使用 Continue 外掛模組時，開發者經常面臨一項架構抉擇：按鍵級的 Tab 程式碼補全要求極致的反應速度（首字延遲通常需低於 300 毫秒），而側邊欄對話與全專案重構則仰賴具備龐大上下文與深層推理能力的前沿模型。若將 Claude 3.5 Sonnet 或 GPT-4o 等重量級推理模型套用在 Tab 補全上，打字過程將遭遇嚴重的延遲與高昂的 API Token 費用；反之，若為了追求速度而在對話中僅使用微型補全模型，則難以勝任複雜的架構審查與除錯需求。

解決此困境的關鍵在於「基於角色的模型路由機制」（Role-based Model Routing）。Continue 在架構上徹底將行內即時補全與探索性對話推理進行解耦。本文將詳細說明如何在現代 config.yaml 規範與傳統 config.json 環境中，將 Tab 補全與 Chat 分流至不同專用模型，並深入探討本機與雲端端點的效能調校技巧。

架構分流：Tab 補全與 Chat 對話的本質差異

Tab 自動補全與 Chat 對話在效能門檻與模型架構需求上存在根本差異：

透過雙模型分流，開發者能藉由本機輕量模型獲得零成本、高隱私且即時的鍵入補全輔助，同時在側邊欄完整保留前沿大模型的深度分析能力。

方案一：現代標準配置（config.yaml）

在最新版本的 Continue 中，設定檔案採用位於 ~/.continue/config.yaml 的 YAML 格式。模型的職責分工由各模型區塊下的 roles 陣列直接決定。

實現模型分流的配置流程：

1. 定義一個參數量小、支援 FIM 模式的專用模型，並賦予 roles: [autocomplete]。
2. 定義一個或多個適用於程式碼解析與多輪問答的雲端模型，並賦予 roles: [chat, edit]。

實際配置範例

name: Continue Hybrid Routing
version: 0.0.1
schema: v1

models:
  # 1. 專用 Tab 補全模型（透過本機 Ollama 執行）
  - name: Qwen2.5 Coder 1.5B (Autocomplete)
    provider: ollama
    model: qwen2.5-coder:1.5b
    roles:
      - autocomplete
    autocompleteOptions:
      debounceDelay: 250
      maxPromptTokens: 1024

  # 2. 深度推理模型，負責對話與重構（Anthropic 雲端 API）
  - name: Claude 3.5 Sonnet (Chat & Edit)
    provider: anthropic
    model: claude-3-5-sonnet-latest
    apiKey: YOUR_ANTHROPIC_API_KEY
    roles:
      - chat
      - edit

  # 3. 備用雲端對話模型（OpenAI）
  - name: GPT-4o (Chat)
    provider: openai
    model: gpt-4o
    apiKey: YOUR_OPENAI_API_KEY
    roles:
      - chat

關鍵參數解析

• roles：控制模型在介面中的露出與呼叫途徑。包含 autocomplete 的模型將專門負責行內淺灰色幽靈文字建議，不會進入側邊欄模型切換清單；標註 chat 的模型則會列入對話切換選單。
• autocompleteOptions.debounceDelay：防抖延遲（毫秒）。指按鍵停止後發起推論請求的等待時間，建議設定於 200ms 至 350ms 之間，避免在連續鍵入過程中向本機 GPU 送出大量無效運算。
• autocompleteOptions.maxPromptTokens：傳送給補全模型的上下文 Token 上限。設定在 1024 至 2048 能確保小型模型在硬體限制下以極高速度產出程式碼。
• 關閉思考模式：若採用支援長思考鏈（Reasoning / Thinking）的模型版本，請務必在補全配置中加入 extraBodyProperties: { think: false }，避免模型在行內輸出思維鏈，造成格式混亂與極度嚴重的延遲。

方案二：傳統相容配置（config.json）

若工作團隊仍在維護舊版 Continue，設定檔通常位於 ~/.continue/config.json。在此結構中，補全模型是透過獨立的頂層欄位與對話模型分開定義。

[!NOTE] Continue 官方已將 config.json 及其頂層 tabAutocompleteModel 屬性標記為已棄用（Deprecated），強烈建議轉換為 config.yaml，但既有版本依然維持向下相容。

舊版配置範例

{
  "models": [
    {
      "title": "Claude 3.5 Sonnet",
      "provider": "anthropic",
      "model": "claude-3-5-sonnet-latest",
      "apiKey": "YOUR_ANTHROPIC_API_KEY"
    },
    {
      "title": "GPT-4o",
      "provider": "openai",
      "model": "gpt-4o",
      "apiKey": "YOUR_OPENAI_API_KEY"
    }
  ],
  "tabAutocompleteModel": {
    "title": "Qwen2.5-Coder 1.5B",
    "provider": "ollama",
    "model": "qwen2.5-coder:1.5b"
  },
  "tabAutocompleteOptions": {
    "debounceDelay": 250,
    "maxPromptTokens": 1024
  }
}

在此設定下：

• "models" 陣列中的項目會出現在側邊欄聊天視窗的切換選單中。
• 獨立的頂層物件 "tabAutocompleteModel" 則專責行內即時補全。
• 全域補全參數設定於 "tabAutocompleteOptions"。

典型場景模型組合建議

依據本地硬體配置、資料隱私需求與預算，推薦採用以下三種工程實踐組合：

組合 A：本機 + 雲端混合架構（兼顧速度與智慧的首選）

• Tab 補全：本機 Ollama 載入 qwen2.5-coder:1.5b 或 qwen2.5-coder:7b。首字延遲可控制在 150ms 內，無雲端費用且不受網路波動影響。
• Chat 對話：雲端採用 Anthropic claude-3-5-sonnet 或 OpenAI gpt-4o。在側邊欄獲得頂級的程式碼重構與架構設計能力。

組合 B：全本機離線與嚴格隱私保護架構

• Tab 補全：本機 Ollama / vLLM 運行 qwen2.5-coder:1.5b（Q4 或 Q8 量化版本）。
• Chat 對話：本機託管 qwen2.5-coder:32b 或 deepseek-coder-v2:16b。建議主機具備 16GB 至 32GB 的統一記憶體或獨立顯示卡記憶體。

組合 C：極致精準的雲端專用補全

• Tab 補全：呼叫 Mistral API 的 codestral-latest。該模型天生支援 FIM 結構，支援超過 80 種程式語言且上下文視窗充裕。
• Chat 對話：雲端呼叫 OpenAI gpt-4o 或 Claude 3.5 Sonnet。

端點效能調校與排錯實務

完成模型路由配置後，必須進一步優化推論引擎的底層設定，排除潛在的資源衝突。

1. 調校 Ollama 平行處理與記憶體常駐

若在本機同時調用補全模型與較大的對話模型，Ollama 預設設定可能導致排隊壅塞：

• 在作業系統環境變數中設定 OLLAMA_NUM_PARALLEL=2（或更高值），確保補全推論不會被進行中的對話生成阻斷。
• 設定環境變數 OLLAMA_KEEP_ALIVE=24h。預設情況下模型閒置 5 分鐘後會釋放記憶體，保持常駐能防止長時間未打字後的首次鍵入產生長達 5 到 10 秒的「冷啟動」凍結。

2. 精準設定防抖延遲與上下文長度

• 鍵入節奏快速的開發者（每分鐘 80 字以上）：建議將 debounceDelay 調整為 300ms 至 350ms，以防快速輸入時產生過多中途作廢的推論請求。
• 穩健節奏的開發者：可維持於 200ms 至 250ms。
• 將 maxPromptTokens 維持於 1024 至 2048 之間。Tab 補全不需要過大的上下文歷史，過長的前綴計算只會成倍拖慢首字吐字速度。

3. 排除 IDE 擴充功能衝突

若修改配置後編輯器未出現行內幽靈文字：

• 前往 Continue 設定頁面，確認已勾選 Enable Tab Autocomplete。
• 檢查編輯器是否安裝了其他行內補全外掛（如 GitHub Copilot、Supermaven 或全行補全套件）。多套補全工具並存時常會引發衝突，導致 Continue 的建議被抑制。

驗證設定

完成設定檔儲存後，可依照下列步驟驗證路由是否生效：

1. 展開 Continue 側邊欄（Ctrl+L / Cmd+L），檢查底部的模型選單，確認僅出現指定的 Chat 模型（例如 Claude 3.5 Sonnet）。
2. 在任意程式碼檔案中輸入函式簽名並稍作停頓（約 300 毫秒），編輯器應立即顯現淡灰色的建議文字。此時查看本機 Ollama 終端或監控工具，即可確認該補全請求已由輕量模型獨立處理。

參考資料

• Autocomplete Role in Continue Models | Continue Docs
• Chat Role | Continue Docs
• Continue Autocomplete Setup and Configuration Guide | Continue Docs
• How to Understand Configuration | Continue Docs
• Migrating Config to YAML | Continue Docs
• config.json Reference (Deprecated) | Continue Docs
• Using Ollama with Continue: A Developer's Guide | Continue Docs