私たちは、生の1秒あたりトークン数（tokens per second）に夢中です。どんなハードウェア投稿もそれを最初に出します。量子化の比較はすべて、それによって順位づけられます。すべての人が「この1つは報告すべき」と合意している唯一の数字です。

しかし、それは間違ったものを測っています。

生のTPSは、トークンがどれだけ速く画面にヒットするかを教えてくれます。正しく、有用な答えを得るまでがどれくらい速いかについては、ほとんど何もわかりません。継続的なマルチターンのワークフローでは、そのギャップが非常に大きくなります。

幻覚を起こし、複数回の修正が必要で、さらにこちらが以前与えた文脈を忘れてしまう、より速いモデルは、最初から正しく出せる、より遅いモデルよりも、簡単に役に立たないことがあります。

eTPS（Effective Tokens Per Second：実効トークン/秒）は、単なるトークンのスループットではなく、有用な答えへ向かう実際の進捗を測る補完的な指標です。

基本的な考え方はこうです。最終的に受け入れられた出力を、その答えに至るまでの道筋の「きれいさ」で重みづけする（初回で正しいスコアを最も高くする）— その後、総時間で割ります。修正ループ、幻覚、そして繰り返しの説明はすべてスコアを下げます。正しい答えに一度も到達しない応答は、速度にかかわらずスコアはゼロです。

生のTPSに取って代わるものではありません。横に並ぶだけです。

結果 — 同じプロンプト、4回の実行、同じハードウェア：

• gemma-4-e2b（4.6B）：53.2 生TPS → eTPS 53.18 ✓
• qwen3.5-0.8b：173.1 生TPS → eTPS 86.57 ✗ partial（部分的）
• qwen3.5-9b（optimized）：1.8 生TPS → eTPS 1.78 ✓
• qwen3.5-9b（baseline）：0.5 生TPS → eTPS 0.32 ✗ partial（部分的）

0.8Bは生の速度で大差をつけて先行しましたが、負けました。生のTPSは「勝ち」と言いました。eTPSは「違う」と言いました。

ハードウェア： RTX 5060 Laptop、8GB VRAM。eTPSスコアはハードウェアをまたいで持ち運べません。必ず、あなたの環境（全セットアップ）を報告してください。

既知の制約（v0.1）：

• スコアリングには人間の判断が必要です。「必要な明確化」と「事実として間違っていた」の境界は、いつもきれいに引けるわけではありません。客観的な合否基準でのコード生成は、より明確なターゲットであり、次のベンチマーク実行の焦点です。
• 1つのタスクだけでは、継続的なマルチターンのワークフローを代表しません。そこで、この指標が最も面白くなる領域であり、私は次にそこへ向かっています。
• システムプロンプトのログが完全にないと、簡単に不正に「稼ぐ」ことができます。仕様ではそれを要求します。

これらは、隠れた欠陥ではなく、認識された制約です。

方法論、タスクリスト、スコアリング手順、再現性の基準を含む完全な仕様は近日公開予定です。最終的な重みを固定する前に、率直に言って次の2つの未解決の質問について、ご意見をいただきたいです：

誤りを自信満々に断言するモデルと、曖昧すぎて確認のフォローアップをしなければならなかっただけのモデルでは、ペナルティはどう違えるべきでしょうか？そして、ハードウェア正規化はコアとなる式に含めるべきか、それとも別途報告すべきでしょうか？

ご意見歓迎します。