하지만 몇 년 뒤 회사가 그 규모에 도달했고 이 모델을 코드 리뷰나 코딩 에이전트 세션에 조금이라도 사용했다면 그 조건에 걸리게 되는 것 아닌가. 솔직히 이런 라이선스가 나를 멀게 만드는 주된 이유다. 사실상 코드베이스를 '오염'시키는 셈이다.

이 주제로 따로 글을 써야겠다. vllm으로 며칠간 반복 작업을 거쳐 이제 32tok/s 생성 속도에 도달했다. 약간의 패치 없이는 제대로 로드되지 않는데, 개발 측이 110 아키텍처를 완전히 잊었지만 사소한 수정으로 바로 다시 활성화할 수 있었다. thor는 CUDA 코어 수는 적지만 fp4 성능이 터무니없이 강하다. unsloth의 qwen3.6-nvfp4-fast(모든 레이어를 w4a4 nvfp4로)는 50W 미만에서 80tok/s, 프롬프트 처리는 5k tok/s를 낸다. unsloth 팀이 언젠가 3.8-flash-next-nvfp4-fast를 내놓아 내 32tok/s를 아득히 뛰어넘어 주기를 바란다…

그것과 같은 것인가. '엔그램'에는 두 가지 버전이 있는 것으로 보인다. 앞서 인용한 스니펫에 나온 방식(그리고 DeepSeek 논문의 방식)은 활성값을 캐시해 두었다가 마지막 n개 토큰의 n-그램에 따라 그 활성값을 다시 주입하는 것이다. 그와 별개로 레이어별 임베딩 버전이 있는데, 임베딩이 마지막 n개 토큰의 n-그램에 의존하는 방식이다. Qwen이 사용하는 것은 후자로 보인다.