LLM 토큰마다 같은 너비를 차지하는 글꼴 만들기

AI 요약

Token-space font compiler는 글꼴과 토크나이저를 결합해 각 토큰을 같은 너비로 표시하는 TTF를 생성합니다. 생성 글꼴에는 토크나이저 규칙이 셰이핑 규칙으로 들어가므로, 화면에 표시할 때 별도 토크나이저 스크립트를 실행하지 않습니다. 글꼴과 함께 CSS, 빌드 보고서도 내려받을 수 있으며, Discord의 Vesktop이나 웹 Slack에서 특정 사용자의 메시지에 적용하는 방법을 안내합니다.

생성과 렌더링 방식

지원 프리셋은 DeepSeek, OpenAI, Kimi, Qwen, GLM, Llama 3, Trinity, Laguna 등입니다. Gemma와 Gemini는 공백 표식 및 바이트 폴백 지원이 실험 단계이며, ctok는 별도의 최소 비용 백엔드를 씁니다. Raw ByteLevel BPE도 일부 설정으로 입력할 수 있습니다. 임의의 토크나이저 파이프라인을 모두 받는 것은 아닙니다. 지원하지 않는 정규화기나 전처리기, WordPiece, Unigram은 대체로 지원 대상이 아닙니다.

지원되는 셰이핑 구간에서 각 토큰은 3em 너비를 차지하고, 추가 토큰 간격은 기본값 0이며 최대 0.5em입니다. CSS는 단어 간격과 줄 높이를 바꾸지 않습니다. 글꼴에 없는 문자는 글리프가 비어 있거나 시스템 글꼴로 대체될 수 있습니다. 폴백 글꼴의 글리프를 생성 글꼴에 포함하는 기능도 있지만, 실제 표시 범위는 선택한 글꼴에 달려 있습니다. 기본 이모지 폴백은 Noto Emoji이며, 사전 생성된 DeepSeek + Inter 미리보기에도 들어 있습니다.

테스트 결과와 남은 오차

작성자는 제공된 글꼴 바이너리 6종에서 BPE 공백 관련 검사 17,904건을, ctok에서 2,355건을 비교했습니다. 브라우저에서는 너비 60종과 줄바꿈 사례 20종을 확인했습니다. 특정 입력에 대한 테스트이며 전체 텍스트에서 정확성을 보장하지는 않습니다.

DeepSeek는 제어 문자 U+001C–U+001F를 공백으로 잘못 분류합니다. 공백 두 개 뒤에 U+001C를 붙이면 하나의 공백 토큰으로 합쳐지는 사례가 있으며, 2,984건 검사 중 토큰 ID 불일치가 59건 나왔습니다. GLM-5.3과 Llama 3의 실험 프리셋은 정규식 경계, 순위화된 BPE, 전체 조각 단축 경로를 씁니다. 테스트한 문학 텍스트와 문장·코드·공백·문장부호 사례는 통과했지만, 일부 입력은 64바이트 또는 32회 탐색 한도에 걸립니다. 해당 한도에 걸린 사례는 GLM 353건, Llama 354건입니다. Trinity Large Thinking과 Laguna M.1은 전처리 파이프라인과 병합 순서를 보존하며, 각 2,984건의 공백 검사에서 모두 통과했습니다. 단, 특수 토큰과 자동 메시지 프레이밍은 포함하지 않습니다.

Claude의 토크나이저를 비공식적으로 흉내 내는 ctok는 검증된 구현이 아닙니다. 구성요소별 탐색은 256단계 제한이 있고, 제한을 넘으면 [limit]를 표시합니다. v3, v4.7, v4.8의 검사에서도 토큰 수·너비 또는 의미상 불일치가 남았습니다. 이 검증에는 Claude API 호출이 없었으며, 비교 통과가 Claude 토크나이저와 일치한다는 뜻은 아닙니다. Qwen의 NFC 처리는 분해 후 연속 비시작 문자 8개까지만 지원합니다. 브라우저와 컴파일러의 유니코드 버전 차이도 결과를 바꿀 수 있습니다.

브라우저는 서식 구간, 링크, 문자 체계, 양방향 텍스트, 폴백 글꼴, 줄바꿈을 기준으로 셰이핑을 나눕니다. 글꼴은 분리된 구간을 가로질러 토큰화하지 못합니다. 복잡한 문자 셰이핑, 합자, 발음 구별 부호 위치도 항상 보존되지 않습니다. 공백 처리와 탭, 줄바꿈은 일반적인 토큰 칸처럼 동작하지 않습니다. 예를 들어 24px에서 ‘Hello world’는 한 구간 전체를 셰이핑할 때 144px였지만, 앞 공백이 별도 구간으로 나뉘면 216px로 측정됐습니다. 브라우저와 앱의 화면 결과가 테스트와 같다고 보장할 수 없습니다.

이 글꼴은 일반 텍스트를 시각화하는 도구입니다. 특수 토큰, 채팅 템플릿, 멀티모달 콘텐츠, API의 자동 메시지 오버헤드까지 표현하지 않습니다. 따라서 실제 API 청구 토큰 수를 정확히 세는 용도로 안내하지 않습니다. 글꼴은 Pyodide와 fontTools로 로컬에서 컴파일합니다.

Hacker News 반응

• @LoganDark — Safari에서는 커닝이 정말 엉망입니다. Chrome에서는 괜찮아 보입니다.
• @dTal — 제 환경에서는 이 페이지가 Firefox 155를 CPU 100% 상태로 멈추게 합니다.
  • @ampdot — 저는 대부분 Firefox 156에서 테스트했는데 제 쪽에서는 괜찮습니다.
  • @devindotcom — Windows 10의 152에서는 아주 부드럽습니다. 다들 경험을 공유하는 김에 저도 적습니다.
  • @bbor — 이 사이트에는 심각한 문제가 있는 것 같습니다. 이런 문제는 본 적이 없는 것 같네요. 솔직히 꽤 인상적입니다. 연산량이 너무 많아서 스크롤이 버벅이는데, 아주 낯선 느낌입니다.
• @nxtfari — 하하, 이걸 보니 assistant에게 공감하게 됐습니다. 재미있는 아이디어네요.
• @kittikitti — 중국어에서는 어떻게 보일지 궁금합니다.
  • @fyredge — 문장부호가 줄 아래쪽에 붙지 않고 가운데에 놓이는 점만 빼면 일반 텍스트와 완전히 같습니다. CJK 한자는 글자 하나가 토큰 하나로 인코딩될 가능성이 큽니다. 그러면 의미를 가진 단어가 부분 토큰으로 잘리지 않는다는 점에서 중국어가 NLP에 더 효율적인지 궁금해집니다.
  • @altairprime — 관련 자료일 수 있습니다. 「중국어는 바이브 코딩에서 영어보다 효율적이지 않다: 토큰 비용과 문제 해결률에 관한 예비 연구」입니다.
  • @fyredge — 흥미롭네요, 감사합니다. 이 연구는 stochastic parrot 이론도 뒷받침하는 것 같습니다. 언젠가 전 세계 코드베이스 대부분이 CJK 한자로 작성되면 바이브 코딩이 중국어에서 더 효율적일지도 모르겠습니다.
  • @numpad0 — 데모 글꼴에 중국어 글리프가 없을 수도 있다고 생각합니다. 라틴 글꼴 대부분은 CJK를 포함하지 않으니 시스템이 사용 가능한 중국어 글꼴로 대체하겠죠. 반대로 CJK 글꼴에는 라틴 문자가 들어 있습니다. 토크나이저는 대부분 CJK에 맞게 최적화되지 않았을 겁니다. 충분히 쓸 만한 수준이고, 지금까지 AI의 CJK 언어 성능이 최우선 과제는 아니었으니까요.
• @croemer — 독일어를 입력했더니 영어보다 단어가 훨씬 더 많이 쪼개졌습니다. 토크나이저가 가장 자주 쓰이는 텍스트에 맞춰져 있다면 놀랄 일은 아니죠. 최신 OpenAI 토크나이저로 여러 언어 번역 코퍼스의 토큰 효율을 비교한 결과는 영어 1.00배, 포르투갈어 1.23배, 중국어 간체 1.25배, 독일어 1.31배, 스페인어 1.32배, 프랑스어 1.37배, 아랍어 1.38배, 중국어 번체 1.42배, 한국어 1.47배, 스와힐리어 1.49배, 힌디어 1.57배, 일본어 1.66배, 버마어 3.16배, 암하라어 5.78배, 산탈리어 13.70배입니다. FLORES-200을 사용한 「Tokenizer Fairness in 2026」의 재현·확장 연구입니다.
• @Applejinx — ‘재버워키’ 첫 연을 입력해 봤습니다. 예상한 대로 작동하네요. :D
• @totetsu — 평소 LLM에 입력을 보낼 때 정확도 80%로 오타를 잔뜩 내며 입력하는 습관이 입력 토큰 수를 늘릴 수 있다는 걸 깨달았습니다.
  • @synthos — 프롬프트 입력창에 맞춤법 검사를 넣으면 몇 푼 아낄 수 있을지도 모르겠네요.

원문: ampdot.mesh.host / 번역·요약: Trawling