跳至主要內容

標籤「LLM」的 2 篇文章

查看所有標籤

【2026年7月】生成式 AI 模型比較（Claude、GPT、Gemini、Grok、DeepSeek、Kimi、GLM、Mistral）

ひかり

透過 OpenRouter，無論是 Claude、GPT、Gemini 這類封閉模型，還是源自中國的開源權重模型， 都能自由切換使用。不過「到底該選哪一個」還是常常讓人猶豫，這次就大致比較了一下主要模型的 價格與實力。

「開源」與「封閉」到底是什麼意思​

  • 封閉（Closed）：像 Claude、GPT、Gemini、Grok 這類模型，其內部（權重）並未公開， 只能透過該公司的伺服器使用。
  • 開源權重（Open-weight）：像 DeepSeek、Kimi、GLM、Mistral 這類模型，內部是公開的， 任何人都能在自己的電腦或雲端上運行。

依等級劃分的價格​

先從最重量級的價格開始看。

Pro 等級 價格比較

可以看到，Claude Fable 5 貴得驚人（輸出每 1M token $50），而 DeepSeek V4 Pro 的輸出 僅需 $0.87。即使同樣掛著「Pro」的名號，價差竟然超過 50 倍。開源陣營（綠色標籤）全面 偏低價，一目瞭然。

再來看看中量級和輕量級。

Mid 等級 價格比較 Nano 等級 價格比較

到了輕量級，GPT-5 nano 的輸出價格僅 $0.40，幾乎達到「隨便用」的等級。若只是做簡單的 分類作業或草稿生成，這個等級往往就綽綽有餘。

看看性價比​

單看價格，容易讓人覺得「便宜的模型性能應該也差」，但實際上並非如此。這裡先不分等級， 把價格與 Intelligence Index 分數都齊全的 20 個模型彙整成一張圖。盡量涵蓋了 GPT、Gemini、 Qwen、Llama、Gemma、Mistral 等眾多模型，不分開源或封閉。

成本 vs 性能散點圖（全部模型）

縱軸是「Intelligence Index」這項綜合能力分數（詳見後述）。虛線連接的「性價比前緣」由 跨越 Nano、Mid、Pro 三個等級的 7 個模型構成：Gemma 3 27B → DeepSeek V4 Flash → DeepSeek V4 Pro → Kimi K2.6 → Gemini 3.1 Pro → Claude Opus 4.8 → Claude Fable 5。 DeepSeek V4 Pro 輸出價格僅 $0.87，分數卻逼近 Gemini 3.1 Pro（$12.00），實質上已成為 性價比的起點，一枝獨秀。另一方面，位於前緣內側的 Qwen3.7 Max、MiniMax M3、GLM 5.2、 Claude Sonnet 5、Gemini 3 Flash、Grok 4.20、Claude Haiku 4.5、Gemini 3.1 Flash-Lite、 Qwen3-Coder、Mistral Large 3、Llama 4 Maverick、Llama 4 Scout 等模型，相較同價位的其他 模型，實力則略顯遜色。

若重視性價比，不妨先從最便宜的位置開始嘗試。

到底哪個模型最聰明​

再來看看綜合能力與程式撰寫能力的排名。

綜合基準測試：Artificial Analysis Intelligence Index 程式實務能力：SWE-bench Verified

第一張圖的「綜合能力」，是第三方基準測試機構 Artificial Analysis Intelligence Index 的分數；第二張圖的「程式撰寫能力」，是 SWE-bench Verified 的分數，這項測試衡量的是 模型能解決多少實際存在的軟體錯誤修復課題。兩者都不是模型廠商的自我申報，而是由外部評測 網站實際測量並公布的數值。

在綜合能力上，Claude Fable 5 以領先 GPT-5.5 約 5 分的成績奪冠，Claude Opus 4.8、 GPT-5.5、Gemini 3.1 Pro 則以些微差距緊隨其後。僅看程式撰寫能力的話，Claude Fable 5 更是以 95% 的分數一枝獨秀。有趣的是，緊追在後的開源模型 DeepSeek V4 Pro，居然能與 封閉陣營並駕齊驅。

附贈：開源模型「內部規模」有多大​

開源權重模型由於內部公開，因此也能得知其參數量（模型規模）。長條圖中深綠色部分是實際 推理時使用的「活性化參數」，淺綠色則是 MoE（Mixture of Experts）架構下，當下未被使用的 其餘專家部分。

開源權重模型的參數量

DeepSeek V4 Pro 以總計 1.6 兆參數居冠，但實際運行時只使用其中的 490 億（得益於 MoE 機制）。規模雖大卻能輕快運行，正是重點所在。圖中唯獨 Gemma 3 27B 的長條全為深綠色， 這是因為它並非 MoE，而是每次都會用到全部參數的「dense（密集）」架構。密集模型的總參數量 等於活性化參數量，因此與 MoE 陣營相比，其規模比較的意義略有不同，需特別留意。

結論：該選哪一個​

  • 不管怎樣就是要最聰明的 → Claude Fable 5 或 Claude Opus 4.8（要有花大錢的心理準備）
  • 重視性價比，也想拿來寫程式 → DeepSeek V4 Pro（便宜到不行卻相當優秀）
  • 日常使用的均衡型 → Claude Sonnet 5 或 Gemini 3 Flash
  • 不管怎樣就是要便宜大量處理 → GPT-5 nano 或 DeepSeek V4 Flash

由於價格與排名的變動速度都很快，實際使用前別忘了到 openrouter.ai/models 確認最新資訊。

分數的資料來源​

本文所使用的基準測試分數，來源如下。兩者皆為獨立於模型廠商之外的第三方評測網站所測量並 公布的數值。

另外，Kimi K2.6 / Qwen3.7 Max 的 SWE-bench Verified 分數在不同資料來源間存在近似值混雜的 情形，故僅作為參考值處理。

開發了連接 Claude Code、Codex、Gemini 的 LLM API 轉換代理伺服器「llmglot」

ひかり

在 AI 開發現場，比起模型本身，越來越常被 API 規格差異所困擾。

Claude Code 使用 Anthropic Messages API。OpenAI 系工具使用 Chat Completions API 或 Responses API。Gemini 則有自己的獨立 API，而在本機 LLM 環境中，Ollama 與 LM Studio 會提供 OpenAI 相容 API。

明明想用的模型已經存在，卻因為 API 規格不同而無法連接。必須改寫 SDK、實作轉換層，並針對不同環境分別設定。

解決這類問題的就是 llmglot。

GitHub: https://github.com/Himeyama/llmglot

llmglot 是什麼​

llmglot 是一個可在多種 LLM API 之間相互轉換的代理伺服器。

它會接收 Anthropic Messages API、OpenAI Responses API、OpenAI Chat Completions API、Gemini API 等請求，並適當轉換後轉送到上游 API。

也就是說，即使客戶端要求的 API 規格與實際想使用的模型 API 規格不一致，也仍然可以使用。

支援範圍​

以客戶端來說，支援：

  • Claude Code
  • Anthropic SDK
  • OpenAI SDK
  • Responses API 用戶端
  • Gemini SDK

等。

作為連接端則可使用：

  • Ollama
  • LM Studio
  • OpenAI
  • Gemini
  • OpenRouter
  • Azure OpenAI
  • vLLM

等。

例如：

  • Claude Code → Ollama
  • OpenAI SDK → Gemini
  • Responses API → Chat Completions API

這類連接都能實現。

連接 Claude Code 與本機 LLM​

llmglot 的用途之一，就是連接 Claude Code 與本機 LLM。

例如使用 Ollama 時，可以用：

CHAT_BASE_URL=http://localhost:11434/v1 llmglot

來啟動。

接著只要把 Claude Code 的連接目的地改成 llmglot，就能從 Claude Code 使用本機 LLM。

不用昂貴的 API 就能試用程式碼代理，這點非常有吸引力。

（補充：Ollama 支援 Messages API，所以其實不需要代理）

也支援 Responses API​

近年來，使用 Responses API 的工具越來越多。

llmglot 實作了 /v1/responses 端點，除了 HTTP 之外也支援 WebSocket。

因此，像 Codex CLI 這類以 Responses API 為基礎的客戶端也更容易連接。

日誌功能很方便​

llmglot 配有日誌顯示功能。

可確認的資訊包括：

  • 模型名稱
  • 供應商
  • 輸入 token 數
  • 輸出 token 數
  • 快取使用量
  • 預估成本
  • 生成速度

等。

在使用多個 LLM 的環境中，能集中管理使用情況的優點非常大。

與 LiteLLM 的差異

這裡令人好奇的是與 LiteLLM 的差異。

兩者都是位於 LLM 中間層的軟體，但目標方向大不相同。

LiteLLM 的思路​

LiteLLM 會將多數 LLM 供應商統一成 OpenAI 格式。

也就是：

應用程式
    ↓
LiteLLM
    ↓
各 LLM 供應商

這樣的架構。

可以說，它是為了讓應用程式開發者使用統一 API 的機制。

llmglot 的思路​

另一方面，llmglot 則是：

Claude Code
Codex CLI
Gemini SDK
       ↓
     llmglot
       ↓
各 LLM 供應商

這樣的架構。

其目的在於轉換客戶端的 API 規格。

以 Claude Code 來比較​

Claude Code 使用 Anthropic Messages API。

LiteLLM 基本上是以 OpenAI 相容 API 為中心，因此要直接連接 Claude Code 並不容易。

相對地，llmglot 可以直接接收 Anthropic Messages API。

因此可以實現：

Claude Code
    ↓
llmglot
    ↓
Ollama

這樣的架構。

這是 llmglot 非常大的特色。

該選哪一個​

適合 LiteLLM 的是：

  • 開發 AI 應用程式的人
  • 想把 OpenAI SDK 當作統一介面的人
  • 想做負載平衡或 fallback 的人

另一方面，適合 llmglot 的是：

  • 想讓 Claude Code 使用其他模型的人
  • 想讓既有客戶端使用本機 LLM 的人
  • 想把 Responses API 轉成其他 API 的人
  • 不想改寫 SDK 的人

總結​

在 LLM 的世界裡，越來越多情況下，問題不在模型本身，而在 API 的差異。

想使用 Claude Code，卻想搭配 Ollama。想使用 OpenAI SDK，卻想搭配 Gemini。這類需求未來只會越來越多。

llmglot 就是在中間吸收這些 API 規格差異。

  • Claude Code → Ollama
  • OpenAI SDK → Gemini
  • Responses API → Chat Completions API
  • Gemini API → OpenAI 相容 API

如果說 LiteLLM 是「給開發者的統一 API」，那麼 llmglot 就可以說是「客戶端相容代理」。