以前「Gemma-4がでた」という記事を書いたんですが、この時VMに対して割り当てるCPU数を2に制約してたので、今回このCPU数を3に増やしてちょっと実行してみました。再推論したらこの通り、300%近傍まで負荷を上昇させることができましたので、これで実際どういうやり取りができてるのか確認してみました。
1ターン目
今回、マルチターンでの処理を眺めていくことにしました。1ターン目のやり取りはこんな感じです。
一気に出力速度が向上しましたね。7.63tok/s出ていることが確認できます。
コンソール出力にも以下のようなパフォーマンス情報が記録されました。
prompt eval time = 1806.40 ms / 28 tokens ( 64.51 ms per token, 15.50 tokens per second)
eval time = 59134.48 ms / 451 tokens ( 131.12 ms per token, 7.63 tokens per second)
total time = 60940.88 ms / 479 tokens2ターン目
これにさらに返してみます。
応答はこんな感じです。
さらに以下の通り続きます。
海外の車だけでなく、ちゃんと日本車も紹介してくれるのがうれしいですね。この時のReasoningも併せて覗いてみます。
Here's a thinking process for responding to the user's request:
1. **Analyze the Request:** The user is asking for recommendations on cars suitable for a "drive" (presumably leisure driving, road trips, or general driving). The context is a beautiful, clear day (implying enjoyable driving).
2. **Identify Missing Information (Crucial Step):** To give a *good* recommendation, I need to know:
* **Budget:** High-end luxury? Mid-range comfort? Budget-friendly?
* **Purpose/Type of Drive:** Coastal highway cruising? Mountain driving? City commuting/exploring? Family trips (many people/luggage)? Solo adventures?
* **Priorities:** Fuel efficiency? Performance/Speed? Cargo space? Comfort/Ride quality? Eco-friendliness?
* **Driving Style:** Do they prefer automatic or manual?
3. **Determine Strategy (Handling Ambiguity):** Since I lack specific constraints, the best approach is to offer categorized suggestions based on common driving needs.
4. **Develop Categories and Examples (The Core Recommendations):**
* **Category 1: Comfort & Luxury (For long, leisurely drives):** Focus on smooth ride, quiet cabin, and premium features. (Examples: Lexus, Mercedes-Benz, BMW, high-end SUVs).
* **Category 2: Versatility & Space (For family/luggage/road trips):** Focus on spaciousness and practical utility. (Examples: Large SUVs, Minivans).
* **Category 3: Efficiency & Practicality (For daily driving/fuel economy):** Focus on reliability and low running costs. (Examples: Hybrids, compact/mid-size sedans).
* **Category 4: Performance & Driving Experience (For enthusiasts):** Focus on handling and speed. (Examples: Sports cars, performance SUVs).
5. **Draft the Response (Structuring and Tone):**
* *Greeting/Acknowledgement:* Validate the question.
* *The Disclaimer/Key Question:* State that the best choice depends on their needs.
* *Present the Categories:* Present the recommendations clearly.
* *Call to Action:* Ask the user follow-up questions so I can refine the advice.
6. **Review and Refine (Self-Correction/Tone Check):** The tone should be helpful, enthusiastic, and consultative. (The drafted response below follows this structure.) (Self-check: Are the suggestions diverse? Yes. Are they relevant? Yes.)
7. **Final Output Generation.** (This matches the detailed Japanese response.)日本語訳を記述してみます。
ユーザーのリクエストに対する対応手順を以下のように整理します：
- リクエスト内容の分析： ユーザーは「ドライブ」に適した車のおすすめを求めています。「ドライブ」とはおそらく、レジャー目的の運転や長距離旅行、あるいは一般的な運転シーンを指していると考えられます。背景には美しく晴れ渡った日の情景が想定され（快適な運転環境を示唆しています）、ユーザーはドライブに適した車種を探していることがわかります。
- 不足情報の特定（重要なステップ）： 適切なアドバイスを提供するためには、以下の情報が必要です：
- 予算範囲： 高級ラグジュアリーカー？ ミドルレンジの快適性重視？ コストパフォーマンス重視？
- 目的・運転シーン： 海岸沿いのハイウェイ走行？ 山岳地帯での運転？ 都市部での通勤・観光？ 大人数・大量荷物を伴う家族旅行？ 一人旅？
- 重視するポイント： 燃費性能？ 走行性能・スピード？ 積載スペース？ 快適性・乗り心地？ 環境への配慮？
- 運転スタイル： オートマチックトランスミッションとマニュアルトランスミッションのどちらを好むか？
- 対応方針の決定（曖昧さへの対応）： 具体的な制約条件が不明なため、一般的な運転ニーズに応じたカテゴリー別の提案を行うのが最適なアプローチです。
- カテゴリーと具体例の設定（核心的なおすすめ内容）：
- カテゴリー1：快適性とラグジュアリー性（長距離・ゆったりドライブ向け）： 乗り心地の良さ、静粛性の高い車内空間、プレミアムな装備を重視。（例：レクサス、メルセデス・ベンツ、BMW、ハイエンドSUV）
- カテゴリー2：多用途性とスペース（家族・荷物・長距離旅行向け）： 広々とした室内空間と実用的な機能性を重視。（例：大型SUV、ミニバン）
- カテゴリー3：効率性と実用性（日常運転・燃費重視向け）： 信頼性とランニングコストの低さを重視。（例：ハイブリッド車、コンパクト/ミドルサイズセダン）
- カテゴリー4：走行性能と運転体験（車好き向け）： ハンドリング性能とスピードを重視。（例：スポーツカー、高性能SUV）
- 回答の作成（構成と表現方法）：
- 挨拶・確認事項： 質問内容を確認する文言
- 免責事項／核心的な質問： 最適な選択肢はユーザーの具体的なニーズによって異なる旨を明記
- カテゴリーの提示： 推奨内容を明確かつ体系的に提示
- 行動喚起： ユーザーに追加質問を行い、より適切なアドバイスを提供できるよう促す
- 内容の見直しと改善（自己校正／表現チェック）： 回答のトーンは、親切で熱意があり、相談相手としての親しみやすさが感じられるものにします。（以下に示す作成済み回答はこの構成に沿っています）（自己チェック：提案内容は多様か？ → はい 関連性は十分か？ → はい）
- 最終出力の生成。（これは詳細な日本語回答と完全に一致しています）
回答を作成するにあたり、メーカー判断は比較的日本向けに配慮しているからというわけではなさそうで、グローバルに見た結果として提示しているように見受けられました。特筆するポイントとしては、回答の作成をするにあたり、その項目をあらかじめ準備していることです。
- リクエスト内容分析
- 不足情報の特定
- 対応方針の決定
- カテゴリーと具体例の設定
- 回答の作成
- 内容のチェック
- 最終出力の生成
これらが満たされているかどうか、適切かどうかをそのあとの項目で判断して最終出力につなげています。おそらくはこのあたりのCoTなつくりをあらかじめ学習しているということなのでしょう。それがどのように確認項目としてピックアップされているかはわかりませんが、いずれにしてもそれ自体はGemma-4の頭の中にあるということなのだろうと推察しています。
パフォーマンスは以下の通りでした。
prompt eval time = 5338.71 ms / 85 tokens ( 62.81 ms per token, 15.92 tokens per second)
eval time = 186326.08 ms / 1357 tokens ( 137.31 ms per token, 7.28 tokens per second)
total time = 191664.79 ms / 1442 tokensこの時点で、7tok/s前後ぐらいのパフォーマンスが通常のConversationでは出てきそうです。ただ、Prompt Evalのトークン量が少なすぎて読み込み部分のパフォーマンスがいまいち不明瞭です。もう1ターン繰り返してみます。
3ターン目
では、このターンのやり取りが1,000tok超えてることを活用し、もう1ターン質問をしてみます。
回答内容は以下です。
このあたり、きちんと長めの答えをたとえ短い質問が来ても継続できる点は、Gemma2以来継続してできている一つのパターンのような気もします。この時のReasoningは以下の通りです。
Here's a thinking process that leads to the suggested response:
1. **Analyze the User's Input:** The user noticed a similarity between Mazda and Suzuki's concepts ("よくよく見てみるとマツダとスズキのコンセプト似てるね"). This is an observation, not a direct question, but it signals an interest in the *philosophy* or *market positioning* of these two brands.
2. **Identify the Core Connection (Mazda vs. Suzuki):**
* **Mazda's Core Identity:** "Jinba Ittai" (horse and rider as one). Focus on driving dynamics, emotional connection, design purity, premium feel in a compact package. (Focus: Driving pleasure, design, premium experience.)
* **Suzuki's Core Identity:** Reliability, practicality, fuel efficiency, accessibility, robust performance. (Focus: Utility, affordability, reliability, volume sales.)
3. **Determine the Shared "Concept":** What do they have in common?
* *Shared Ground:* They both offer excellent *value* and *driving experience* within their respective market segments. They both prioritize *driving* (though Mazda emphasizes emotion, Suzuki emphasizes practicality/fun).
4. **Structure the Response:** A good response should validate the observation, explain the nuance, and connect it back to practical car choices.
* **Acknowledge/Validate:** Agree that there are conceptual overlaps.
* **Detail Mazda's Concept:** Explain *why* Mazda feels premium/emotional.
* **Detail Suzuki's Concept:** Explain *why* Suzuki is the champion of practicality/economy.
* **The Synthesis (The Bridge):** Show how they both appeal to different drivers seeking different things.
* **Conclusion/Call to Action:** Reiterate that the choice depends entirely on the driver's priority.
5. **Draft the Content (Iterative Refinement):**
* *(Self-Correction during drafting: Avoid just listing specs. Focus on the *feeling*.)* Instead of just saying "Mazda is design-focused," talk about the *experience* of driving.
6. **Final Review (Ensuring Tone and Clarity):** The tone should be thoughtful and insightful. (The resulting Japanese response reflects this structure.) (This leads to the final output.)日本語に訳すとこうです。
以下に、提案された回答に至る思考プロセスをご説明します：
- ユーザーの入力内容の分析： ユーザーは「よく見てみると、マツダとスズキのコンセプトが似ている」と指摘しています。これは直接的な質問ではなく、単なる観察意見ですが、これら2つのブランドの企業理念や市場ポジショニングに対する関心の表れと解釈できます。
- 中核的な関連性の特定（マツダ vs スズキ）：
- マツダの中核的アイデンティティ： 「人馬一体」のコンセプト。運転ダイナミクス、ドライバーとの感情的なつながり、デザインの純粋性、コンパクトながら上質な乗り心地を重視。（重点分野：運転の楽しさ、デザイン、プレミアムな体験価値）
- スズキの中核的アイデンティティ： 信頼性、実用性、燃費効率、アクセスのしやすさ、力強いパフォーマンス。（重点分野：実用性、手頃な価格、信頼性、大量販売）
- 共有する「コンセプト」の明確化： 両者にはどのような共通点があるのか？
- 共通基盤： それぞれの市場セグメントにおいて、優れた価値提案と運転体験を提供している点です。両者とも運転を重視していますが（マツダは感情的な側面を強調し、スズキは実用性と楽しさを重視する傾向があります）、これが共通の特徴と言えます。
- 回答の構成： 良い回答とは、ユーザーの観察を認め、そのニュアンスを説明した上で、実際の車選びに結びつけるものです。
- 承認/確認： コンセプトに共通点があることを認める。
- マツダのコンセプト詳細： マツダがなぜプレミアム感や感情的な訴求力を持つのかを解説。
- スズキのコンセプト詳細： スズキがなぜ実用性と経済性のチャンピオンと言えるのかを解説。
- 統合的な視点（橋渡し）： 両者がそれぞれ異なるニーズを持つドライバー層にアピールしている点を示す。
- 結論/行動喚起： 最終的な選択はドライバーの優先事項によって決まることを改めて強調する。
- コンテンツの作成（反復的なブラッシュアップ）：
- （作成過程での自己修正：単なるスペックの羅列は避けること。「感覚」に焦点を当てる） 単に「マツダはデザイン重視」と言うのではなく、運転する体験について語るようにしましょう。
- 最終チェック（トーンと明確性の確認）： 回答のトーンは思慮深く洞察に富んだものであるべきです。（完成した日本語の回答はこの構成を反映しています。）（これが最終的なアウトプットにつながります。）
今度は前のやり取りに比べて少し章立てが減っています。こんな風にまとまってるようです。
| 章番号 | ターン2 | ターン3 |
|---|---|---|
| 1 | リクエスト内容分析 | リクエスト内容分析 |
| 2 | 不足情報の特定 | 分析結果に基づく中核内容の特定 |
| 3 | 対応方針の決定 | ↓ |
| 4 | カテゴリーと具体例の設定 | 内容の明確化 |
| 5 | 回答の生成 | 回答の作成 |
| 6 | 内容のチェック | 内容のチェック |
| 7 | 最終出力の生成 | ↓ |
パフォーマンスを確認してみると以下のような内容です。なるほど、それなりのトークンをもってしてもおよそPrompt Eval速度は出力速度の2倍強の速度が出ていることが確認できました。このあたりはCPU特性と言えるかもしれません（後述します）
prompt eval time = 61065.15 ms / 897 tokens ( 68.08 ms per token, 14.69 tokens per second)
eval time = 162519.12 ms / 1135 tokens ( 143.19 ms per token, 6.98 tokens per second)
total time = 223584.27 ms / 2032 tokensパフォーマンス傾向を見て感じたこと
内容が長くなれば長くなるほどパフォーマンスが緩やかに落ちていくことを確認したとともに、2CPUと3CPUというたった1CPUの差でトークン出力速度が向上しただけでなく、以下のように速度劣化度合いが少なくなったことに驚きを感じました。
- 2CPU構成：初期段階5.0tok/s→最終状態3.0tok/s（2ターン程度）
- 3CPU構成：初期段階8.0tok/s→最終状態7.0tok/s (3ターン程度)
これが今度はGPUを使うとどうなるのかはちょっと試したいところです。
Reasoning内容を確認して感じたこと
こうしてみてみると、分析→応答内容の中核特定→具体例など挟んで内容を明確化→回答作成→チェックののち最終生成版作成という流れはそれほど変わらないようです。Qwen3.5とも違い、WaitもButも言いませんでした。
このあたりはGeminiと相通ずるものを感じました。Geminiもあまり振り返りをしませんで、比較的天才的な閃きを描くようなReasoningを行う傾向があります。しかし、その内容は決して貧弱なものではなく、ボリュームにとんだ反応が多いなぁという印象です。テキストでチャットする場合において、無機質感をより少なくする工夫が凝らされているのかなという印象を受けました。
そして何より、E2Bモデルですでに以前存在したGemma2-9B-IT相当の能力を備えてることに驚きました。これでマルチモーダルな上に、128kトークンまで入出力できるのだからさらに驚きです。（Gemma2-9Bでは、8kが上限でした）
Geminiにだいぶ似てきた
動きがだいぶGeminiに似てきた気がします。その応答内容がぶっきらぼうになることはなく、常にユーザフレンドリであり、一言でいうなら「チャット用途に特化したような動き」が目立つ点は非常にGeminiに近しいものを感じます。Google AI Studioを使ったときのGemini 2.5 Pro当たりの動きによく似ている印象を受けました。
また、Reasoningにおいて非常に細やかなReasoningは行いつつも、ほぼ振り返らずに念のためチェックしとくわーぐらいの勢いでさらっとReasoningを終わらせてるわーって感じに一発屋の閃きくん敵動きをしてるところもどこかGeminiの面影を感じちゃいます。その学習の仕方などの共通フレームワーク的なものがあるんですかね・・・生産ラインにてるなー感が半端ない結果となりました。
アーキテクチャも新しく、小規模モデルでもそれなりの実力を併せ持つGemma4、ちゃんと動かせる時が来るかな？できればこういうモデルこそきちんとした設備であれこれしたいですね。
コメント