tokenspeed は、LLMの tokens-per-second（1秒あたりに出るtoken数） を「数字」ではなく「体感」で理解するためのツールcode / text / think / agent の4モードがあり、出力内容によって「同じ速度でも速くも遅くも感じる」ことを見せてくれるLLMのベンチマークを見ていると、よく出てくるのが「47 tok/s」「180 tok/s」「500 tok/s」といった数字です。
でも正直、こういう数字ってピンと来にくいんですよね。
1秒に30 tokenって、速いの？ 遅いの？ 生活の中のどの感覚に近いの？ となりがちです。
そこで登場するのが tokenspeed です。
これは、LLMが出力する token の流れを画面上で再現して、「tokens-per-second」を目で見て、なんとなくじゃなく体で感じられるようにしたものです。
発想がかなりよくて、僕はこういう「数字を視覚と体感に変換する」ツールが大好きです。ベンチマークの世界って数字ばかりが独り歩きしやすいので、こういう翻訳装置はかなり価値があると思います。
tok/s は、LLMが1秒間に何 token 生成できるかを表す指標です。
token は、ざっくり言うと 文章やコードを細かく切った部品 です。
たとえば英語なら、短い単語は1 token くらいで済むこともありますが、長い単語は分割されることがあります。
コードならもっと細かくなりやすく、processUserInput のような識別子が process + User + Input のように分かれることもあります。
記号や演算子も token になるので、コードは文章より token が多くなりやすい。
ここが大事で、同じ 30 tok/s でも、コードが流れるのと自然文が流れるのでは体感がかなり違うんです。
tokenspeed はまさにそのズレを見せてくれます。
ベンチマークの数字自体は嘘じゃない。でも、人間がどう感じるか は別問題、というわけです。
このツールには4つのモードがあります。
code
syntax-highlighted な pseudo-code が流れるモード。
いちばん「LLMが書いてるっぽい」見た目で、コード生成の雰囲気をつかみやすいです。
text
lorem ipsum 風の文章が流れるモード。
ふつうのチャット回答や説明文に近い感覚を見られます。
think
reasoning model が考えているような、薄くイタリックな思考文とコードが交互に出るモード。
「考えながら出してる感」を演出していて、これはかなりそれっぽいです。
agent
tool call と code generation が交互に出て、途中に処理の間も入るモード。
AI coding agent の雰囲気を再現していて、実際のエージェント系UIに近い空気があります。
個人的には、同じ tok/s を code と text で切り替えて比較できるのがいちばん面白いと思います。
数字だけ見ていると見落としがちですが、内容が違うと体感速度はかなり変わるんですよね。
これは「速度の絶対値」だけ見ても、ユーザー体験はわからない、ということのいい例です。
元記事では、まずデフォルトの 30 tok/s から読んでみることがすすめられています。
そのうえで、いくつかのプリセットを試すと感覚がつかみやすいです。
この例えがうまいんですよね。
LLMの速度は、単なる「遅い/速い」ではなく、どの層の体験に属するか で見たほうがしっくり来ます。
5 tok/s だと「あ、待ってるな」と強く感じるし、60 tok/s くらいになると、もうかなり自然に見える。
200 tok/s を超えると、逆に人間の読解速度のほうが追いつかない瞬間が出てきます。
800 tok/s なんて、たしかに「速い」のですが、速すぎて今度は読む側の目が詰まる。この指摘はかなり本質的だと思います。
tokenspeed の本質は、単にスピードを測ることではありません。
同じ速度でも、出力内容が違うだけで体感は変わる、という当たり前だけど見落としやすい事実を、かなりわかりやすく見せてくれます。
たとえば、
つまり、速度の数字は一つでも、ユーザーの体感は一つじゃない。
このズレを見せるのがとても上手いです。
元記事では、token の数え方は BPE-style tokenization をざっくり近似していると説明されています。
BPE は、文字列を細かい単位に分ける仕組みの一種で、LLMのtokenizerでよく使われる考え方です。
ただしここで大事なのは、各ベンダーの tokenizer を厳密に再現しているわけではない という点です。
たとえば tiktoken や Claude の tokenizer とは、細部が少しずつ違います。
でもこれは欠点というより、体感ツールとしてはむしろ自然です。
厳密な一致より、「だいたいこういう分かれ方をするんだな」 をつかむほうが、このツールの目的に合っています。
元記事では、英語の prose は平均して 1 word あたり約1.3 token としています。
そのため、30 tok/s はおおよそ 23 words/s に相当する、という見積もりが示されています。
もちろん、これはざっくりした目安です。
でも、こういう換算があると「30 tok/s って意外と速いのかも」とか「思ったより普通だな」といった感覚が持てます。
数字を生活感に落とし込む、いい橋渡しです。
この tokenspeed は、派手な機能があるわけではありません。
でも、LLMの性能をどう理解するか という点ではかなり本質的です。
ベンチマークの数字って、どうしても「高いほうが勝ち」に見えます。
でも実際の体験は、速度だけでは決まりません。
何が出力されるのか、どんな文体なのか、途中で待ちがあるのか、ユーザーは読むのか眺めるだけなのか。
そのあたりを全部ひっくるめて「速さの感じ方」は変わります。
だからこそ、このツールの価値は大きいと思います。
tok/s を知る のではなく、tok/s を感じる。
この一歩だけで、LLMの見え方がかなり変わるはずです。