Nemotron 3.5 Lightning を Hermes Agent で動かして実効コストを測ってみた

はじめに

こんにちは、クラスメソッド製造ビジネステクノロジー部の嶋田です。

本日、NVIDIA が Nemotron 3.5 Lightning を公開し、Fireworks AI にも追加されました。

https://app.fireworks.ai/models/fireworks/nemotron-lightning-3p5-30b-a3b

nemotron-lightning-3p5-30b-a3b は長時間動くエージェント向けを謳うモデルで、目を引くのは価格です。
入力 100 万トークンあたり 0.05 ドル、出力 0.20 ドル。
Fireworks のサーバーレスでは最安クラスに位置します。

私は以前、常駐型のエージェントの Hermes Agent を Fireworks のオープンモデルで動かす記事を書きました。

https://dev.classmethod.jp/articles/reona-hermes-agent-fireworks-slack/

その記事の結びで、コストは測っていないと書きました。
毎朝の定型処理に安いモデルを充てるという判断は、実際の消費量を見てから評価すべきものです。
ちょうど「安さ」を看板にしたモデルが出てきたので、この宿題を回収することにしました。

なお同じモデルについては、DGX Spark 上でのローカル実行という切り口で既に 2 本の記事が出ています。

https://dev.classmethod.jp/articles/dgx-spark-nemotron-3-5-lightning-first-touch/

https://dev.classmethod.jp/articles/nvidia-nemotron-3-5-lightning-dspark-dflash-mtp-dgx-spark/

本記事はサーバーレス API 経由で、エージェントの常駐モデルとして使えるかどうかを見ます。
結論を先に書くと、単価の安さは実効コストの安さと同じではありませんでした。
タスクの性質によって、既に使っていたモデルより安くなる場合と、9.7 倍高くつく場合の両方が出ました。

Nemotron 3.5 Lightning の位置づけ

モデルページの記載を整理します。

• 32B パラメータのうち 3B がアクティブな MoE。NVIDIA Nemotron-H ファミリー
• Mamba-Transformer のハイブリッド構成で、投機的デコーディングヘッドを持つ
• 推論トレースを生成してから最終応答を返す
• context 262k、ツール呼び出し対応

投機的デコーディングの効果はローカル環境での測定が本題になるので、先行記事に譲ります。
API 経由で使う側から見て重要なのは、思考してから答えるモデルであること、そして context が 262k であることです。
Fireworks の主要モデルの多くが 1M を持つので、そこは控えめな部類になります。

単価を並べてみます。100 万トークンあたりの USD で、Standard tier の値です。

前回から既定モデルにしている deepseek-v4-flash-0731 と比べると、入力が 1/2.8、出力が 1/1.4 です。
以降はこの 2 モデルを比較していきます。

つないでみる

まず素の API で疎通を確認しました。

ここで 1 つ気になる点がありました。
GET /v1/models の応答が、このモデルについて supports_chat: false を返すのです。

{
  "id": "accounts/fireworks/models/nemotron-lightning-3p5-30b-a3b",
  "kind": "HF_BASE_MODEL",
  "supports_chat": false,
  "supports_tools": true,
  "context_length": 262144
}

ところが実際に chat/completions を叩くと 200 が返ります。

$ curl -s https://api.fireworks.ai/inference/v1/chat/completions \
    -H "Authorization: Bearer $FW" -H 'Content-Type: application/json' \
    -d '{"model":"accounts/fireworks/models/nemotron-lightning-3p5-30b-a3b",
         "messages":[{"role":"user","content":"Reply with exactly: PONG"}],"max_tokens":256}'

{
  "choices": [
    {
      "message": {
        "role": "assistant",
        "content": "PONG",
        "reasoning_content": "Here's a thinking process:\n\n1. **Analyze User Input**..."
      }
    }
  ],
  "usage": { "prompt_tokens": 22, "completion_tokens": 184 }
}

応答は 1.0 秒でした。
カタログのフラグを信じてモデル選択を自動化していると、候補から漏れることになります。
明示的に指定すれば使えます。

注目したいのは usage です。
content は PONG の 4 文字ですが、completion_tokens は 184 あります。
差分は reasoning_content に入った思考です。
つまり思考トークンは出力トークンとして課金されます。
ツール呼び出しも同じ形式で成立し、finish_reason: tool_calls と正しい JSON が返りました。

Hermes 側の指定は、前回と同じく provider と model を分けて渡します。
Fireworks のモデル ID 自体がスラッシュを含むため、連結形式では通りません。

$ hermes -z 'Reply with exactly: PONG' \
    --provider fireworks -m accounts/fireworks/models/nemotron-lightning-3p5-30b-a3b
PONG

コストを測る準備

Hermes には --usage-file というグローバルオプションがあり、セッションの使用量を JSON に書き出せます。

$ hermes -z '...' --usage-file usage.json

{
  "estimated_cost_usd": 0.0,
  "cost_status": "unknown",
  "cost_source": "none",
  "input_tokens": 15067,
  "output_tokens": 93,
  "cache_read_tokens": 14992,
  "reasoning_tokens": 0,
  "api_calls": 2
}

トークンは取れましたが、コストが 0 です。
cost_status が unknown になっています。

調べると、Hermes は Fireworks の価格表を内蔵していました。
agent/usage_pricing.py に ("fireworks", <モデル名>) をキーとする辞書があり、pricing_version は fireworks-pricing-2026-07 です。

つまり 7 月時点のスナップショットなので、本日出たモデルは載っていません。
~/.hermes/models_dev_cache.json の Fireworks エントリ（17 件）にも Nemotron はありませんでした。

ここで、比較対象の deepseek-v4-flash-0731 でも unknown になることに気付きました。
こちらは 7 月より前からあるモデルです。

原因は ID の末尾でした。
価格表のキーは deepseek-v4-flash で、deepseek-v4-flash-0731 は別物として扱われます。
モデル名の正規化処理は Anthropic と Bedrock にしか適用されず、Fireworks は完全一致のみです。

サフィックスを外して実行すると、値が入りました。

model = accounts/fireworks/models/deepseek-v4-flash
cost_status = estimated
cost_source = official_docs_snapshot
estimated_cost_usd = 0.00200718

前回の記事で、私は挙動を再現しやすくするためにバージョン固定の -0731 を選びました。
その選択が、コスト表示を失うトレードオフを伴っていたわけです。

そこで自分で計算することにしました。
使用量はセッション DB（~/.hermes/state.db）の sessions テーブルにも記録されるので、そこから読みます。

PRICE = {
    "nemotron-lightning-3p5-30b-a3b": (0.05, 0.01, 0.20),
    "deepseek-v4-flash-0731": (0.14, 0.028, 0.28),
}

rows = con.execute("""
    SELECT id, model, api_call_count, input_tokens, cache_read_tokens, output_tokens
      FROM sessions WHERE started_at > strftime('%s','now') - ?
""", (7200,)).fetchall()

for sid, model, calls, inp, cache, outp in rows:
    pin, pcache, pout = PRICE[model.rsplit("/", 1)[-1]]
    cost = (inp * pin + cache * pcache + outp * pout) / 1_000_000

1 点注意があります。
input_tokens はキャッシュにヒットしなかった入力だけを表します。
cache_read_tokens とは加算関係にあり、total_tokens = input + cache_read + output が成立します。
両方を別単価で計算する必要があります。

なお reasoning_tokens は常に 0 でした。
Fireworks が思考トークンを分離報告しないためで、実体は出力トークンに含まれています。

実測 1: 単発のツール呼び出し

まず前回と同じ、ディレクトリ内の .md を数えるタスクです。

$ hermes -z 'Use your tools to count how many .md files are in the current directory. Reply with just the number.'
2

どちらも一発で正答し、消費もほぼ同じです。
単価の差がそのまま出て、Nemotron が 2.6 分の 1 になりました。
以降の円換算はすべて 150 円/USD です。

実測 2: 毎朝の定型ジョブ

次に実運用に近いタスクを試します。
前回作った cron ジョブと同じプロンプトで、RSS を 3 本 curl して日本語 5 件に要約させるものです。

各モデル 2 回ずつ実行しました。

Nemotron が 20〜30% 安く、しかも速く終わりました。

興味深いのは、Nemotron の出力トークンが 2〜3 倍多いという点です。
思考してから答えるモデルなので当然ではあります。
どれくらい考えているかは、セッション DB に保存された reasoning_content の文字数で比較できます。

3 倍ほど考えています。
それでも総額が下回るのは、出力単価の差が小さい（0.20 対 0.28）一方で、入力単価の差が大きい（0.05 対 0.14）ためです。
エージェントの消費は、毎ターン履歴を送り直す入力側が支配的になります。
思考量の不利が、入力単価の有利で打ち消された形です。

実測 3: 探索を伴うタスクでは逆転する

ここで結果が反転しました。

前回の記事で Slack から頼んだのと同じ調査タスクを与えます。
DevelopersIO で今日投稿された NVIDIA 関連記事を調べ、タイトルと URL を日本語で答えてもらうものです。
検索 API のキーは設定していないので、ブラウザ操作か curl で自力でたどることになります。

deepseek は 3 ターンで終わりました。
RSS フィードから 3 件を挙げ、そのうえで「NeMo Switchyard の記事はタイトルに NVIDIA が無いが関連として含めた、判断基準によっては変わる」と注記まで付けてきました。

Nemotron は 22 ターン、次の試行では 51 ターン費やしました。
コストは deepseek の 2.5 倍から 6.5 倍です。

金額よりも、ツールを呼んだ回数のほうが差を素直に表しています。

原因はターン数です。
エージェントはツールを呼ぶたびに、それまでの履歴を丸ごと送り直します。
迷走してターン数が増えると、入力トークンが二次関数的に積み上がります。

51 ターンの試行では、3.79 円のうち 2.79 円がキャッシュ入力でした。
1M あたり 0.01 ドルという、表で見れば無視できそうな単価が支配項になっています。
出力トークンの寄与は 0.53 円にすぎません。

単価表で比べられるのは 1 トークンあたりの値段だけで、エージェントの費用はターン数で決まります。

品質面でも問題が出た

コストより気になったのはこちらです。
51 ターンの試行で、Nemotron は存在しない URL を出力しました。

- **Canonical URL:** `https://dev.classmethod.jp/guri/hajime-oguri/nvidia-nemotron-3-5-lightning-3-speculative-decoding-dsg-dflash-mtp`
  (based on author slug structure)

「著者スラッグの構造から推定した」と自分で書いています。
しかも同じ URL を 2 件に重複させていました。

日本語で答えるよう指示したのに、冒頭が英語になる回もありました。
無人で回すジョブに URL を扱わせる用途では、これは無視できません。

思考を削っても改善しない

ターン数が問題なら思考を減らせばよいのではと考え、--reasoning low を試しました。
結果は 90 ターン、5.61 円で最悪でした。
end_reason は通常終了だったので、上限による打ち切りではありません。

考えるモデルから考える余地を奪うと、探索が発散する方向に働いたようです。
DGX Spark で検証した記事も、このモデルには十分なトークン予算（16,000 程度）が必要だと指摘しています。
API 経由でも同じ性質が出たことになります。

ツールを絞ると速くはなる

-t terminal,file でブラウザツールを外すと、51 ターンから 19 ターン、131.8 秒から 35.2 秒に改善しました。
日本語の指示も守られました。

ただし URL の捏造は起きました。
ターン数の問題と事実性の問題は別物で、前者だけ解決しても後者は残ります。

cron ジョブで実運用してみる

定型タスクなら有利という結果が出たので、cron に載せて確かめます。
ジョブ単位でモデルを固定できます。

$ hermes cron create '0 6 * * *' "<プロンプト>" --name nvidia-daily-nemotron \
    --deliver slack:C0BPS3PR13K --provider fireworks \
    --model accounts/fireworks/models/nemotron-lightning-3p5-30b-a3b
Created job: 3d8c095ef30e

手動実行して Slack への配信を確認しました。

INFO cron.scheduler: Job '3d8c095ef30e': delivered to slack:C0BPS3PR13K

なお hermes cron pause した状態では手動実行も拒否されます。

Job is paused/disabled; resume it before running.

停止したジョブは hermes cron list の一覧から消えます。
--all を付けないと存在自体が見えないので、検証用のジョブを止めたまま忘れないよう注意が要ります。

既存ジョブとの比較です。

32.3 秒で完走し、CLI での測定と同じ傾向が出ました。
毎日 1 回なら 30 日で 28 円程度です。

ただし出力に固有名詞の誤りがありました。
「Apollo・BlackRock ら」と書くべきところを **「Apache、BlackRockら」**としています。
1 行だけ英語が混じった行もありました。
同じジョブの deepseek 版には、この種の誤りは出ていません。

安く済むかわりに、固有名詞は疑ってかかる必要があります。
毎朝ざっと目を通すニュース要約なら許容できますが、そのまま引用する用途には向きません。

使い分けの結論

今回の実測から、次のように振り分けることにしました。

• 定型の cron ジョブは Nemotron。手順が決まっていてターン数が読めるタスクでは、20〜30% 安く、速い
• 対話と探索は deepseek-v4-flash。ターン数が読めないタスクでは、単価の安さがターン数の増加で打ち消され、逆に高くつく

一般化するなら、こう言えると思います。
安いモデルに任せてよいのは、エージェントに考えさせる余地が少ないタスクです。
プロンプトで手順を固定でき、使うツールを絞れて、出力形式が決まっているもの。
逆に、どう調べるかをモデルに委ねるタスクでは、単価表の順位は意味を持ちません。

おわりに

Nemotron 3.5 Lightning を Fireworks 経由で Hermes Agent につなぎ、実効コストを測りました。

分かったことを整理します。

• 単価はサーバーレス最安クラス。定型タスクでは実測でも 20〜30% 安く、速い
• 探索を伴う多段タスクではターン数が 3 から 22〜51 に膨らみ、実効コストが最大 9.7 倍に逆転する
• 思考量を削っても改善しない。ツールを絞るとターン数は減るが、事実性は改善しない
• URL や固有名詞の誤りが出る。無人で回すジョブでは出力の使い道を選ぶ必要がある
• Hermes 内蔵の価格表は 7 月時点のスナップショットなので、新しいモデルではコスト表示が効かない。バージョン付きのモデル ID でも効かない

前回の記事では、常駐エージェントを立てて動かすところまでを書きました。
今回はそこに費用の目安が付きました。
1 日 1 円弱という水準が見えたので、ジョブを増やす判断もしやすくなりました。

確かめられていないこともあります。
Slack 経由の対話セッションを長時間続けたときの挙動は見ていません。
捏造の頻度も、探索タスク 2 回という試行数では傾向としか言えません。
長期的に運用した上での評価はどう変化が起きるのか、検証する価値がありそうです。

参考資料

• NVIDIA Nemotron 3.5 Lightning 発表ブログ
• Nemotron Lightning 3.5 30B A3B（Fireworks AI）
• Fireworks AI サーバーレス価格
• Hermes Agent 公式ドキュメント
• NousResearch/hermes-agent