초당 토큰 수, 숫자로만 보면 감이 안 오는 이유

• 로컬 대규모 언어 모델(LLM) 벤치마크에서 자주 보이는 47 tok/s, 180 tok/s, 500 tok/s 같은 숫자를 실제 눈으로 체감하게 해주는 렌더링 도구가 나옴

  • 그냥 숫자만 보면 “빠르네” 정도로 끝나는데, 실제로 토큰이 흘러나오는 걸 보면 속도의 의미가 훨씬 선명해짐
  • 특히 코드 생성, 일반 답변, 추론 출력, 에이전트 작업처럼 출력 형태가 바뀌면 같은 속도도 다르게 느껴짐

• 도구는 4가지 모드로 토큰 스트리밍을 보여줌

  • code는 문법 강조가 들어간 의사 코드 출력이라, 개발자가 LLM에서 가장 자주 보는 화면에 가까움
  • text는 일반 산문 응답이고, 채팅 답변이나 설명형 응답을 떠올리면 됨
  • think는 흐릿한 이탤릭 추론 문장과 코드가 번갈아 나오는 형태라, 추론 모델이 생각을 풀어놓는 느낌을 흉내 냄
  • agent는 도구 호출, 코드 생성, 중간 처리 대기 시간이 섞인 형태라 AI 코딩 에이전트 UX에 더 가까움

• 글에서 추천하는 체감 구간도 꽤 현실적임

  • 기본값 30토큰/초에서 먼저 읽어보고, 5토큰/초는 라즈베리 파이급 로컬 모델 느낌으로 보면 됨
  • 60토큰/초는 일반적인 호스팅 Claude나 GPT 응답에 가까운 구간으로 제시됨
  • 200토큰/초는 Groq 쪽 속도감, 800토큰/초는 Cerebras급으로 사실상 사람 눈이 병목이 되는 구간임

• 핵심은 “토큰”이 사람이 생각하는 단어와 1:1로 맞지 않는다는 점임

  • 이 도구는 특정 벤더의 토크나이저가 아니라 BPE 스타일 토큰화를 대략 흉내 냄
  • 짧은 단어는 보통 토큰 하나지만, processUserInput 같은 긴 식별자는 process, User, Input처럼 여러 조각으로 쪼개질 수 있음
  • 문장부호, 연산자도 토큰으로 잡히는 경우가 많아서 코드 출력은 산문보다 훨씬 토큰 밀도가 높음

• 영어 산문 기준으로는 평균 약 1.3토큰이 단어 1개에 해당함

  • 그래서 30토큰/초는 대략 23단어/초 정도로 볼 수 있음
  • 이 정도면 읽는 사람 입장에서는 이미 꽤 빠른 편이라, 더 높은 처리량이 항상 더 좋은 UX로 이어지지는 않음

---

기술 맥락

• LLM 서비스에서 tok/s를 보는 이유는 응답이 얼마나 빨리 “흘러나오는지”를 가장 단순하게 보여주기 때문이에요. 서버 처리량이나 모델 비교에는 유용한데, 사용자가 실제로 읽는 속도와는 별개의 문제라서 UX 판단에는 한계가 있어요.

• 코드 생성이 특히 애매한 이유는 토큰 밀도가 높기 때문이에요. 함수명, 괄호, 연산자, 들여쓰기 주변 문자가 모두 토큰을 잡아먹을 수 있어서, 산문에서는 빠르게 느껴지는 속도가 코드에서는 답답하게 보일 수 있어요.

• 에이전트형 코딩 도구에서는 순수 생성 속도만으로 체감 성능을 설명하기 더 어려워요. 도구 호출, 파일 탐색, 실행 대기, 다시 코드 생성하는 흐름이 섞이기 때문에 사용자는 tok/s보다 “작업이 멈춘 것처럼 보이는 시간”에 더 민감하게 반응하거든요.

• 그래서 모델 벤치마크를 볼 때는 숫자 하나만 보지 말고 출력 타입을 같이 봐야 해요. 채팅 답변용인지, 코드 생성용인지, 에이전트 워크플로우용인지에 따라 같은 처리량도 제품 경험에서는 완전히 다르게 읽혀요.