LLM을 제품에 붙일 때 가장 귀찮은 입력은 "정상적인 문장"이 아닙니다. 사용자는 한국어와 영어를 섞고, 오타를 내고, 이모지를 붙이고, 코드 조각과 로그를 그대로 복사합니다. 이때 토크나이저는 보이지 않는 전처리 계층이지만, 실제 품질과 비용에 계속 영향을 줍니다.
최근 Meta, Stanford, University of Washington 연구진은 Byte Latent Transformer(BLT)의 느린 생성 문제를 줄이는 Fast Byte Latent Transformer 계열 기법을 제안했습니다. 핵심 결과는 바이트 단위 모델이 토크나이저 없이도 생성 작업에서 기존 BLT 대비 추론 메모리 대역폭 비용을 50% 이상 낮출 수 있다는 주장입니다1. MarkTechPost도 이 연구를 "토큰화 없는 추론 대역폭 절감" 관점에서 소개했습니다2.
토크나이저는 공짜가 아니다
대부분의 LLM은 텍스트를 단어보다 작은 subword 토큰으로 쪼갭니다. 효율적이지만, 이 방식은 언어와 문자열을 균등하게 다루지 않습니다. 희귀어, 저자원 언어, 깨진 문자, 숫자, 코드, 특수기호는 예상보다 이상한 단위로 쪼개질 수 있습니다.
BLT의 출발점은 이 문제를 피하는 것입니다. 텍스트를 UTF-8 바이트로 보고, 고정 어휘 대신 바이트 묶음인 "패치"를 동적으로 만듭니다. 기존 BLT 논문은 엔트로피 기반 패칭으로 예측하기 쉬운 구간은 길게, 어려운 구간은 짧게 묶어 계산을 배분한다고 설명합니다3.
실무적으로는 "토크나이저가 싫으니 모두 바이트 모델로 가자"가 아닙니다. 제품 입력이 영어 위주의 정제된 문서라면 기존 토큰 기반 모델이 여전히 싸고 빠를 수 있습니다. 반대로 다국어 채팅, OCR 결과, 사용자 로그, 보안 문자열, 코드 자동완성처럼 입력의 모양이 계속 깨지는 환경이라면 토크나이저가 품질 리스크가 됩니다.
바이트 모델의 약점은 아름답지만 느리다는 점이었다
바이트 단위 모델은 어휘 문제가 단순합니다. 거의 모든 텍스트를 같은 규칙으로 받을 수 있습니다. 문제는 길이입니다. subword 토큰 하나가 여러 바이트를 담는 반면, 순수 바이트 생성은 훨씬 더 많은 단계를 필요로 합니다.
BLT는 이 부담을 줄이기 위해 로컬 인코더, 큰 글로벌 Transformer, 로컬 디코더로 나뉜 계층 구조를 사용합니다. 하지만 생성 단계에서는 여전히 바이트를 한 번에 하나씩 내보내는 병목이 남습니다. 현대 LLM 서빙에서는 연산량보다 모델 가중치와 KV 캐시를 반복적으로 읽는 메모리 대역폭이 병목이 되는 경우가 많기 때문에, forward pass 횟수 증가는 곧 지연시간과 비용으로 이어집니다4.
Fast BLT의 핵심은 "한 바이트씩 말하지 말고, 여러 바이트를 한꺼번에 초안으로 만들자"입니다. BLT-D는 블록 단위 discrete diffusion 목표를 추가해 여러 바이트를 병렬로 생성합니다. BLT-S는 기존 BLT의 가벼운 로컬 디코더가 패치 경계를 넘어 초안을 더 쓰게 한 뒤 전체 모델이 검증합니다. BLT-DV는 diffusion으로 만든 블록을 다시 autoregressive 방식으로 검증합니다1.
제품 관점에서 보면 세 가지 선택지다
이 연구를 모델 아키텍처 뉴스로만 보면 놓치는 부분이 있습니다. Fast BLT는 품질, 속도, 구현 복잡도 사이의 선택지를 넓힌 제안에 가깝습니다.
BLT-D는 가장 공격적인 속도 카드입니다. 논문과 후속 분석에 따르면 블록 크기를 키우면 메모리 대역폭 절감 폭이 커지지만, 코드 생성 같은 작업에서는 품질 하락이 더 민감하게 나타납니다5. 번역처럼 비교적 문맥 흐름이 안정적인 작업에서는 더 유리할 수 있지만, 한 글자나 기호의 오류가 치명적인 코드·수식·프로토콜 생성에서는 검증이 필요합니다.
BLT-S는 보수적인 선택입니다. 별도 draft model 없이 기존 로컬 디코더를 사용하며, greedy decoding에서는 표준 BLT와 동일한 출력을 보장하는 방식으로 설명됩니다6. 즉, "품질을 바꾸지 않고 비싼 글로벌 호출을 줄이는" 쪽에 가깝습니다.
BLT-DV는 중간 지대입니다. diffusion으로 빠르게 초안을 만들고 autoregressive 검증으로 품질 손상을 줄입니다. 추론 비용을 크게 줄이고 싶지만, 순수 병렬 생성의 오류를 그대로 받아들이기 어려운 팀이 볼 만한 방식입니다.
아직 봐야 할 것은 실제 지연시간이다
중요한 한계도 있습니다. 논문이 제시한 메모리 대역폭 비용은 주로 parameter bytes와 forward pass 수를 기반으로 한 추정치입니다. 실제 wall-clock latency가 얼마나 줄어드는지는 최적화된 inference 구현, 배치 크기, KV 캐시 정책, 하드웨어 메모리 계층에 따라 달라집니다2.
그래서 지금 당장 판단 기준은 단순합니다. 입력이 깨끗하고 비용 최적화된 토큰 기반 스택이 이미 잘 돈다면 Fast BLT는 관찰 대상입니다. 그러나 다국어·노이즈·코드·로그·엣지 추론처럼 토크나이저 문제와 추론 비용이 동시에 터지는 시스템이라면 적극적으로 추적할 만합니다.
Fast BLT가 말하는 변화는 "토크나이저가 끝났다"가 아닙니다. 더 정확히는, 텍스트를 단어 비슷한 단위로 고정해 다루던 시대의 비용 함수가 흔들리고 있다는 신호입니다. 앞으로 제품 빌더와 인프라 팀은 모델 품질만이 아니라, 입력의 지저분함과 메모리 대역폭까지 포함해 아키텍처를 고르게 될 가능성이 큽니다.
참고
3Byte Latent Transformer: Patches Scale Better Than Tokens
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.