概要

Mac StudioMac StudioのM3 Ultraが発売された。512GBのメモリを積んでいる
ollamaのgemma3:27bは4bit量子化版で17GBある。そして、128kのコンテキストwindowに対応している。
- デフォルトではコンテキスト長が2048に設定されている。コンテキスト長を超えたプロンプトは無視されてしまう
- コンテキスト長を伸ばす設定をすると、コンテキストキャッシュのための追加のメモリが必要にn
128kのコンテキスト長の設定で動くかを試してみた

内容

128kのコンテキスト長で動く設定を行う

ollama pull gemma3:27b
ollama show gemma3:27b --modelfile > gemma3.modelfile

gemma3.modelfileに対して以下の変更を加えたgemma3_128k.modelfileを作成する

--- gemma3.modelfile    2025-03-19 15:47:38                                                                                                                               
+++ gemma3_128k.modelfile       2025-03-19 17:24:10                                     @@ -1,8 +1,7 @@                                                                                                                                                   
 # Modelfile generated by "ollama show"                                                                                                                           
 # To build a new Modelfile based on this, replace FROM with:                                                                                                     
-# FROM gemma3:27b                                                                                                                                                
+FROM gemma3:27b                                                                                                                                                  
                                                                                                                                                                  
-FROM /Users/username/.ollama/models/blobs/sha256-afa0ea2ef463c87a1eebb9af070e76a353107493b5d9a62e5e66f65a65409541                                           
 TEMPLATE """{{- range $i, $_ := .Messages }}                                                                                                                     
 {{- $last := eq (len (slice $.Messages $i)) 1 }}                                                                                                                 
 {{- if or (eq .Role "user") (eq .Role "system") }}<start_of_turn>user                                                                                            
@@ -16,6 +15,7 @@                                                                                                                                                 
 {{- end }}"""                                                                                                                                                    
 PARAMETER stop <end_of_turn>                                                                                                                                     
 PARAMETER temperature 0.1                                                                                                                                        
+PARAMETER num_ctx 128000                                                                                                                                         
 LICENSE """Gemma Terms of Use                                                                                                                                    
                                                                                                                                                                  
 Last modified: February 21, 2024

設定を更新したモデルを作成する

ollama create gemma3_128k:latest -f gemma3_128k.modelfile

長いテキストファイルを準備する

今回はRoo-Codeのレポジトリをuithubを使ってテキストファイルにした

$ wc -l roo_code.txt 
8239 roo_code.txt
$ wc -c roo_code.txt 
300061 roo_code.txt
$ wc -w roo_code.txt 
34373 roo_code.txt

計測する

import requests
def measure_inference(num_ctx: int, model: str):
    url = "http://localhost:11434/api/generate"
    with open('roo_code.txt') as f:
        codes = f.read()

        prompt = f"""
あなたは優秀なソフトウェアエンジニアです。コードに関する質問に答えてください
以下はRoo Codeのデータです。

# コード

{codes}

# 質問
コード上に現れるモデルで、コアドメインに関わる箇所について、erDiragramをmermaidで描いてください。
モデル間の多重度は重要なので丁寧に書いてください。
モデルの全てのプロパティについて書く必要はなく、モデル間の関係に関わるプロパティのみで問題ありません。
        """.strip()
    payload = {
        "prompt": prompt,
        "model": model,
        "stream": False,
        "option": {"num_ctx": num_ctx},
    }

    response = requests.post(url, json=payload)

    response_data = response.json()
    elapsed = response_data["total_duration"] // 1000000000
    tokens_per_sec = response_data["eval_count"] / elapsed
    print(response_data["response"])

duration, tps = measure_inference("128000", "gemma3_128k:latest")
print(f"Inference took: {duration:.2f}s")
print(f"Tokens per second: {tps:.2f}")

結果

生成することができた。
生成時間約20分とかなり遅いものの、レスポンスは返って来た。
メモリの利用は270GB程度だった。
生成部分の生成速度は2.5トークン/秒(470トークン/188秒) だった

## コアドメインのER図 (Mermaid)

以下に、提供されたコードベースから抽出したコアドメインのER図をMermaid記法で示します。  モデル間の関係性と多重度を重視しています。

```mermaid
erDiagram
    User {
        string id
        string name
    }
    Post {
        string id
        string content
        string userId
    }
    Comment {
        string id
        string content
        string postId
        string userId
    }
    Category {
        string id
        string name
    }
    Post "1" -- "many" Comment : has
    User "1" -- "many" Post : creates
    Post "1" -- "1" Category : belongs to
    User "1" -- "many" Comment : creates
```

**解説:**

*   **User:** ユーザーを表します。`id` と `name` を持ちます。
*   **Post:** 投稿を表します。`id`、`content`、そして作成者である `userId` を持ちます。
*   **Comment:** コメントを表します。`id`、`content`、そして投稿と作成者を指す `postId` と `userId` を持ちます。
*   **Category:** 投稿のカテゴリを表します。`id` と `name` を持ちます。

**関係性:**

*   **User -- Post:** 1人のユーザーは複数の投稿を作成できます (1対多)。
*   **Post -- Comment:** 1つの投稿には複数のコメントが付けられます (1対多)。
*   **Post -- Category:** 1つの投稿は1つのカテゴリに属します (1対1)。
*   **User -- Comment:** 1人のユーザーは複数のコメントを作成できます (1対多)。

**多重度:**

*   `1` は 1対多の関係の「1」側を表します。
*   `many` は 1対多の関係の「多」側を表します。

**補足:**

*   このER図は、提供されたコードベースから抽出された情報に基づいて作成されています。
*   実際のアプリケーションでは、より多くのモデルと関係が存在する可能性があります。
*   ER図は、アプリケーションの構造を理解するためのツールとして役立ちます。

この回答が、あなたの質問に役立つことを願っています。
Inference took: 1248.00s
Tokens: 516.00
Tokens per second: 0.41

メモリ利用

$ ollama ps                                                                                                                                                            
NAME             ID              SIZE      PROCESSOR    UNTIL 
gemma3_128k:latest    6cf1a4878723    318 GB    100% GPU     Stopping...

コーディングの能力がそこまで強くないからか長いコンテキストの解釈が弱いためか、良い回答は得られなかった。

参考にhhao/qwen2.5-coder-tools:32b で128kのコンテキスト長で試した結果

こちらの回答と比べると、コーディングに関してはqwen2.5-coder:32bの方に軍配があがりそう。
生成時間は18分、生成速度は2.3トークン/秒(606トークン/256秒) なので、精度・速度ともにqwen2.5-coderは強い。
メモリ利用量も125GB程度とgemma3と比べると少なくて済んでいる。コンテキストキャッシュ用のトークンあたりのメモリ量が異なっていると思われる。

Roo Codeプロジェクト内のコアドメインに関連する主要なモデルを分析し、それらの間の関係をMermaid形式のER図として描きました。主に以下のモデルが対象となりました：

1. **McpServer**: MCP（Model Context Protocol）サーバーに関する情報
2. **McpTool**: MCPサーバーが提供するツールに関する情報
3. **McpResource**: MCPサーバーが管理するリソースに関する情報
4. **McpResourceTemplate**: リソースのテンプレートに関する情報
5. **Checkpoint**: タスクのチェックポイントに関する情報

これらのモデル間の関係を以下のMermaid形式で描きました。

```mermaid
erDiagram
    MCP_SERVER {
        string name PK
        string config
        string status
        string? error
        boolean? disabled
        int? timeout
    }
    
    MCP_TOOL {
        string name PK
        string server_name FK
        string description?
        object inputSchema?
        boolean alwaysAllow?
    }

    MCP_RESOURCE {
        string uri PK
        string server_name FK
        string name
        string mimeType?
        string description?
    }

    MCP_RESOURCE_TEMPLATE {
        string uriTemplate PK
        string server_name FK
        string name
        string mimeType?
        string description?
    }
    
    CHECKPOINT {
        int ts PK
        string taskId FK
        object checkpoint?
        boolean isFirst?
        string from?
        string to?
    }

    MCP_SERVER ||--o{ MCP_TOOL : provides
    MCP_SERVER ||--o{ MCP_RESOURCE : manages
    MCP_SERVER ||--o{ MCP_RESOURCE_TEMPLATE : defines

    CHECKPOINT }o--|| MCP_SERVER : belongs_to
```

### 説明:
- **MCP_SERVER**: MCPサーバーの情報を保持します。各サーバーは一意の`name`を持ちます。
- **MCP_TOOL**: 各MCPサーバーが提供するツールを表します。ツールは`server_name`によってどのサーバーに属しているかを示す外部キーを持っています。
- **MCP_RESOURCE**: MCPサーバーが管理するリソースを表します。リソースも`server_name`によってどのサーバーに属しているかを示す外部キーを持っています。
- **MCP_RESOURCE_TEMPLATE**: リソースのテンプレートを定義します。テンプレートも`server_name`によってどのサーバーに属しているかを示す外部キーを持っています。
- **CHECKPOINT**: タスクのチェックポイントを表します。各チェックポイントは特定のタスク（`taskId`）に関連しています。

このER図は、Roo Codeプロジェクト内の主要なモデル間の関係と多重度を視覚的に表現しています。

メモリ利用

$ ollama ps 
NAME                ID              SIZE      PROCESSOR    UNTIL  
qwen_128k:latest    dd20f9cdb25f    199 GB    100% GPU     Stopping...

追記（Ollama 0.6.4で再検証）

前回検証時はOllama 0.6.2でした。その後Ollama 0.6.3, 0.6.4にGemma 3に関する改善項目があったため、再検証してみました。

リリースされた内容は以下

Ollama 0.6.3
- New sliding window attention optimization for Gemma 3, improving inference speed and memory allocation for long context windows
- Improved loading speed of Gemma 3
- ollama create will now automatically select the right template when importing Gemma 3 from Safetensors
Ollama 0.6.4
- Fixed issues with 0.6.3 where Gemma 3's output quality would worsen after 512 or 1024 tokens

Gemma 3に関して精度・速度ともに改善されるという内容だったので、試してみました。

結果は以下

Response: ## コアドメインのER図 (Mermaid)

以下に、提供されたコードベースから抽出したコアドメインのER図をMermaid記法で示します。  モデル間の関係性と多重度を重視しています。

```mermaid
erDiagram
    User {
        string id
        string name
    }
    Post {
        string id
        string title
        string content
        string userId
    }
    Comment {
        string id
        string content
        string postId
        string userId
    }
    Category {
        string id
        string name
    }
    Post ||--o{ Category : belongs_to
    User ||--o{ Post : creates
    User ||--o{ Comment : creates
    Post ||--o{ Comment : has
```

**解説:**

*   **User:** ユーザーを表します。`id`と`name`の属性を持ちます。
*   **Post:** 投稿を表します。`id`、`title`、`content`、`userId`の属性を持ちます。`userId`は投稿を作成したユーザーのIDを指します。
*   **Comment:** コメントを表します。`id`、`content`、`postId`、`userId`の属性を持ちます。`postId`はコメントが投稿された投稿のIDを指します。`userId`はコメントを作成したユーザーのIDを指します。
*   **Category:** カテゴリを表します。`id`と`name`の属性を持ちます。

**関係性:**

*   **UserとPost:** 1対多の関係です。1人のユーザーは複数の投稿を作成できます。
*   **UserとComment:** 1対多の関係です。1人のユーザーは複数のコメントを作成できます。
*   **PostとComment:** 1対多の関係です。1つの投稿には複数のコメントが付けられます。
*   **PostとCategory:** 多対1の関係です。1つの投稿は1つのカテゴリに属します。

**多重度:**

*   `||--o{`: 1対多の関係を表します。
*   `o{--||`: 多対1の関係を表します。

**補足:**

*   このER図は、提供されたコードベースから抽出した情報に基づいて作成されています。
*   実際のアプリケーションでは、より多くのモデルと関係が存在する可能性があります。
*   ER図は、アプリケーションの構造を理解するためのツールとして役立ちます。

この回答が、あなたの質問に役立つことを願っています。

メモリ使用量は70GB未満と大幅に改善されていました！
制度については、上記出力なのであまり変化はありませんでした。
生成速度については、10トークン/秒となったので、だいぶ改善されていました！

長いコンテキストの場合、内容をきちんと理解してくれていないことはやや致命的なものの、メモリ利用・生成速度はかなり改善されていたので驚きました。

追記（Gemma3:27b QATで再検証）

4/18 に精度を担保しつつ量子化する手法で量子化したモデルがリリースされた
https://developers.googleblog.com/en/gemma-3-quantized-aware-trained-state-of-the-art-ai-to-consumer-gpus/
それを使って再検証した結果は以下。

以下に、Roo Code Webview UI コアドメインの主要なエンティティとそれらの関係をMermaid形式で表現したEntity Relationship Diagramを示します。

```mermaid
erDiagram
    USER {
        string id PK
        string name
    }

    SESSION {
        string id PK
        string userId FK
        datetime createdAt
        datetime updatedAt
    }

    WORKSPACE {
        string id PK
        string name
        string userId FK
    }

    FILE {
        string id PK
        string workspaceId FK
        string name
        string path
        string content
    }

    HIGHLIGHT {
      string id PK
      string fileId FK
      int start
      int end
      string highlightClassName
    }

    PATH {
        string id PK
        string relativePath
    }

    USER ||--o{ SESSION : owns
    USER ||--o{ WORKSPACE : owns
    WORKSPACE ||--o{ FILE : contains
    FILE ||--o{ HIGHLIGHT : has
    FILE ||--o{ PATH : includes
```

**エンティティの説明:**

*   **USER:** Webview UIを使用するユーザーを表します。
*   **SESSION:** ユーザーのログインセッションを表します。
*   **WORKSPACE:** ユーザーが作成する作業スペースを表します。
*   **FILE:** 作業スペースに保存されるファイルを表します。
*   **HIGHLIGHT:** ファイル内のハイライト部分を表します。
*   **PATH:** ファイルパスを表します。

**関係の説明:**

*   **USER - SESSION:** 1人のユーザーは複数のセッションを持つことができます。(1対多)
*   **USER - WORKSPACE:** 1人のユーザーは複数の作業スペースを持つことができます。(1対多)
*   **WORKSPACE - FILE:** 1つの作業スペースは複数のファイルを含むことができます。(1対多)
*   **FILE - HIGHLIGHT:** 1つのファイルは複数のハイライト部分を持つことができます。(1対多)
*   **FILE - PATH:** 1つのファイルは1つのパスを持つことができます。(1対1)

**補足:**

*   上記の図は、Roo Code Webview UI コアドメインの主要なエンティティと関係を簡略化したものです。
*   実際のシステムでは、より多くのエンティティと関係が存在する可能性があります。
*   多重度は、システム要件に基づいて調整する必要があります。

このDiagramが、Roo Code Webview UI コアドメインの理解に役立つことを願っています。

Prompt Eval Count: 91482
Prompt Eval Duration (seconds): 351
Eval Count: 555 , Eval Duration (seconds): 53, tokens per sec: 10.47

長いコンテキストの理解はやや改善されている？と感じるものの、まだQwenの方が良いように感じた