토큰 (token)

이론·모델

토큰 (token)

LLM 이 입력과 출력을 세는 최소 단위. 단어보다 잘고 글자보다 크다. 요금과 한도의 기준.

1줄 정의

LLM 이 입력과 출력을 세는 최소 단위. 단어보다 잘고 글자보다 크다. 요금과 한도의 기준.

전체 시스템에서 맡는 역할

토큰은 LLM 세계의 “미터법” 이다. 길이, 비용, 한도 전부 토큰으로 잰다.

감각적으로 말하면,

  • 영어: 1 단어 ≒ 1~2 토큰 (평균)
  • 일본어: 1 글자 ≒ 1~2 토큰 (모델과 문자 종류에 따라)
  • 한국어: 일본어와 비슷한 거동
  • 코드: 언어·기호에 따라. 공백이나 들여쓰기도 1 토큰이 되기도 한다

왜 토큰이라는 단위가 있느냐 하면, LLM 이 내부에서 다루는 단위가 그것이기 때문이다. 모델은 글자나 단어를 그대로 읽지 않고 토크나이저 라는 전처리로 텍스트를 토큰 열로 바꿔 다룬다. BPE (Byte Pair Encoding) 같은 게 대표적.

실무에서 영향이 오는 장면은 3개.

  • 비용: API 요금은 입력 토큰 × N + 출력 토큰 × M 으로 결정. 기사 대량 처리 시 예산 견적에 직결
  • 컨텍스트 한도: 모델마다 한 번에 처리할 수 있는 최대 토큰 수 (context window) 가 정해져 있다. 넘으면 앞쪽이 잘리거나 에러
  • 응답 속도: 출력 토큰이 많을수록 생성 시간이 길어진다

프롬프트 가 장황하면 비용도 처리 시간도 나빠진다. 반대로 너무 짧으면 중요 정보가 빠진다. 토큰은 “딱 적당함” 을 의식하는 지표가 된다.

흔한 오해

  • 오해 1: 토큰 = 단어, 로 단순화되기 쉽다.

– 실제로는 언어·모델·토크나이저에 따라 입자가 많이 다르다. 같은 문장이어도 Claude 와 GPT-4 의 토큰 수가 다르다. 견적은 실측이 확실하다.

  • 오해 2: 토큰 수를 줄이면 품질이 떨어진다, 라고 여겨지기 쉽다.

– 실제로는 장황한 프롬프트를 정리하면 오히려 품질이 오르는 경우가 많다. 모델이 중요 지시를 찾기 쉬워지기 때문.

  • 오해 3: 긴 context window 가 있으면 다 집어넣으면 된다, 라고 낙관하기 쉽다.

– 실제로는 context window 안에서도 “어느 위치에 두느냐” 에 따라 참조 정밀도가 바뀐다 (lost in the middle 현상). 토큰을 줄이는 설계는 여전히 효과가 있다.

이 용어가 중요한 이유

토큰을 의식하면서 설계할 수 있으면 AI 운영 비용과 품질의 트레이드오프를 스스로 제어할 수 있다. 이게 T2 에서도 잡아 두는 이유.

  • 월간 API 비용 견적 (처리 100만 기사 × 평균 500 토큰 × 단가 = 예산)
  • 프롬프트 압축 (같은 지시를 절반 토큰으로 다시 쓰기)
  • 컨텍스트 설계 (전체 파일 넣을지, 검색으로 좁힐지)
  • 캐시 전략 (Anthropic 의 prompt caching 은 특정 위치 토큰을 재활용)

이런 판단을 숫자로 논의할 수 있는 팀은 AI 비용 구조를 쥘 수 있다. 반대로 체감으로만 “비싼 것 같다”, “빠른 거 같다” 로 이야기하는 팀은 스케일할 때 무너진다.

이 용어가 나오는 기사

  • API 요금, Claude Code, context window 관련 기사

다음에 읽을 용어 3개

  • prompt — 토큰으로 계량되는 대상.
  • LLM — 토큰을 다루는 본체.
  • context window — 한 번에 다룰 수 있는 토큰 상한.
最終更新: 2026-04-18 · shuntailor.net テイラー百科事典

トークン

理論・モデル

トークン

LLM が入力と出力を数える最小単位。単語より細かく、文字より大きい。料金と制限の基準。

一行定義

LLM が入力と出力を数える最小単位。単語より細かく、文字より大きい。料金と制限の基準。

全体システムの中での役割

トークンは LLM の世界の「メートル法」だ。長さ、コスト、制限のすべてがトークンで計られる。

具体的な感覚としては、

  • 英語: 1 単語 ≒ 1〜2 トークン(平均)
  • 日本語: 1 文字 ≒ 1〜2 トークン(モデルと文字種で変動)
  • 韓国語: 日本語と近い挙動
  • コード: 言語・記号次第。空白やインデントも 1 トークン相当になることがある

なぜトークンという単位があるかというと、LLM が内部で扱う単位だからだ。モデルは文字や単語をそのまま読まず、トークナイザー という前処理でテキストをトークン列に変換して扱う。BPE(Byte Pair Encoding)などが代表的。

実務で効いてくる 3 つの場面がある。

  • コスト: API 料金は入力トークン × N + 出力トークン × M で決まる。記事を大量に処理する時の予算見積もりに直結
  • コンテキスト制限: 各モデルは一度に処理できる最大トークン数(context window)が決まっている。超えると古い部分が切り捨てられたりエラーになる
  • レスポンス速度: 出力トークンが多いほど生成時間が延びる

プロンプト が冗長だとコストも処理時間も悪化する。逆に短すぎると重要情報が抜ける。トークンは「ちょうどよさ」を意識するための指標になる。

よくある誤解

  • 誤解 1:トークン = 単語、と簡略化されがち。

– 実際には、言語やモデル、トークナイザーで粒度が全然違う。同じ文章でも Claude と GPT-4 でトークン数が変わる。見積もりは実測が確実。

  • 誤解 2:トークン数を削れば質が落ちる、と思われがち。

– 実際には、冗長なプロンプトを整理するとむしろ品質が上がることが多い。モデルが重要指示を見つけやすくなるからだ。

  • 誤解 3:長い context window があれば全部入れればいい、と楽観されがち。

– 実際には、context window 内でも「どの位置に置くか」で参照精度が変わる(lost in the middle 現象)。トークンを減らす設計は依然として効く。

この用語が重要な理由

トークンを意識しながら設計できると、AI の運用コストと品質のトレードオフを自分でコントロールできる。これが T2 でも押さえる理由。

  • 月間 API コストの見積もり(処理 100 万記事 × 平均 500 トークン × 単価 = 予算)
  • プロンプトの圧縮(同じ指示を半分のトークンで書き直す)
  • コンテキスト設計(全ファイル入れるか、検索で絞るか)
  • キャッシュ戦略(Anthropic の prompt caching は特定位置のトークンを使い回せる)

こういう判断を数字で議論できるチームは、AI のコスト構造を握れる。逆に体感だけで「高い気がする」「速いかも」の議論をしているチームは、スケールした時に破綻する。

この用語が登場する記事

  • API 料金、Claude Code、context window 関連記事

次に読むべき用語 3 つ

  • prompt — トークンで計量される対象。
  • LLM — トークンを扱う本体。
  • context window — 一度に扱えるトークン上限。
最終更新: 2026-04-18 · shuntailor.net テイラー百科事典
JAKO