언어 모델 안에 계산용 CPU를 넣은 Qwenputer의 구조와 한계

배경과 문제

언어 모델은 긴 자릿수 곱셈이나 나눗셈에서 틀릴 수 있다. 이 실험의 기본 Qwen3.5-4B는 DeepMind mul_big 40문항에서 55%를 맞혔다. 기존에는 모델의 도구 호출을 외부 Python 인터프리터가 계산하고 결과를 다시 넣는 방식으로 정확한 연산을 맡겼다. Qwenputer는 이런 계산 기능을 모델의 추가 층으로 표현할 수 있는지를 시험한다.

Qwenputer는 계산기를 모델 밖에 두지 않고 모델의 층으로 만들어 넣는 실험이다. 기반 모델인 Qwen3.5는 전체 어텐션 층과 Gated DeltaNet(GDN) 층을 섞은 하이브리드 모델인데, 4개 층 중 3개가 GDN이다. GDN은 선형 RNN의 일종으로 각 헤드가 고정 크기의 상태 행렬을 들고 토큰마다 갱신한다. 저자는 이 상태 행렬을 조건만 맞추면 정확하게 읽고 쓰는 메모리로 쓸 수 있다는 점에 주목했다.

기존 접근의 한계

외부 계산기는 언어 모델의 부정확한 산술을 보완하지만 호출 규약과 실행 환경을 연결해야 한다. Qwenputer에서도 호출 형식과 실행 관리가 사라지는 것은 아니다. 달라진 것은 수식을 계산하는 핵심 회로가 모델에 추가한 층으로 구현된다는 점이다. 이는 배포가 무조건 간단해졌다는 제품 평가와 구별된다.

어텐션의 KV 캐시는 토큰이 늘수록 커지는 반면 GDN 헤드의 상태 행렬은 고정 크기다. 저자는 이 상태를 주소가 있는 메모리로 이용한다. 고정 크기는 무한한 기억을 뜻하지 않고 저장 용량에도 한계가 있다. 기본 Qwen3.5의 상태가 처음부터 정확한 RAM인 것도 아니어서, 추가 회로의 읽기·쓰기 조건을 설계해야 한다.

연구방법을 단계별로

먼저 GDN 상태를 정확한 RAM으로 만들기 위해 세 가지 조건을 건다. 게이트 α=1로 두어 아무것도 잊지 않게 하고, 쓰기 강도 β=1로 두어 기존 값을 섞지 않고 완전히 바꾼다. 그리고 키를 원-핫 벡터로 만들어 상태의 한 행만 가리키게 한다. 이 조건에서 쓰기 한 번은 정확히 한 행을 덮어쓰고, 원-핫 쿼리는 그 행의 값을 정확히 돌려준다.

다음으로 CPU를 회로로 기술하면 컴파일러가 각 단계를 트랜스포머 층의 부품으로 바꾼다. 값을 찾아오는 일은 어텐션 헤드가, 산술은 피드포워드 유닛이, RAM은 DeltaNet 헤드가 맡는다. CPU는 RV32IM 명령어 집합에 Zba 확장과 큰 수 연산용 보조 회로를 갖추며 11개 층으로 구현된다. 기존 Qwen의 가중치는 그대로 두므로 모델이 훈련을 통해 CPU 사용법을 새로 배운 실험은 아니다.

Qwen은 익숙한 <tool_call> 형식으로 calc 계산을 요청한다. 회로 안의 브리지는 호출 문자를 메모리 버퍼에 담고 CPU가 출력한 문자를 Qwen 토큰으로 돌려준다. RvChat 드라이버는 프롬프트 뒤에 펌웨어·RAM·레지스터 상태를 넣어 부팅하고, 계산용 트레이스 토큰을 Qwen의 언어 층에서 가린다. 현재 구현은 회로 토큰을 참조 기계와 나란히 검사한다. 검사가 정답을 대신 넣는 것은 아니지만, 호스트 프로그램이 전혀 필요 없다는 뜻도 아니다.

결과와 숫자의 의미

최종 README의 RISC-V 표에서 mul_big은 97.5%(기본 55%), div_big은 97.5%(기본 72.5%), mul_div_multiple_longer는 100%(기본 90%), add_or_sub_big은 97.5%(기본 87.5%)였다. 세트당 40문항을 그리디 디코딩, Qwen 토큰 예산 4,096개, 정확한 유리수 일치로 채점했다. 97.5%는 39문항 정답이며 2.5%포인트 차이가 한 문제여서 작은 차이를 보편적 우위로 읽기 어렵다.

표의 Python 도구 열에는 서로 다른 시험이 섞였다. 설계 문서의 calc v1은 L4·배치 1에서 회로와 호스트 도구를 비교했고, 도구 없는 기본 모델의 DeepMind 시험은 A10G·배치 16이었다. 중간 분수도 계산하도록 고친 v2 재시험은 A10G에서 회로 배치 8, 비교군 배치 16을 썼다. 이때 비교군은 실제 Python이 아니라 같은 C 펌웨어를 실행하는 reference bridge였다. v2의 mul_div 40/40 대 39/40, div_big 39/40 대 38/40은 이런 조건의 결과다. README의 일반적인 Python 표기만으로 동일 조건의 Python보다 우수하다고 결론 내릴 수 없다.

텍스트 보존 검사는 프롬프트 16개로 제한됐다. 병합 모델과 기본 모델의 평균 KL 발산은 6.1e-4로 기본 모델의 두 커널 간 차이 5.1e-4와 비슷했고, 그리디 텍스트는 10개에서 같았다. 이 작은 검사로 일반 언어 품질 전체가 유지됐다고 확정할 수는 없다. 또 회로 출력 위치 약 23만 개가 참조 기계와 모두 일치한 것은 그 기록의 구현 일치 검사이며, 모든 프로그램이나 펌웨어가 수학적으로 항상 옳다는 보장은 아니다.

구체적인 예시

포럼이 소개한 저자의 시각화 예시에서는 −2241842 × 8077을 받아 CPU가 상태의 레지스터와 메모리를 갱신하고 −18107357834를 출력한다. 여기서 새로 실행해 확인한 벤치마크는 아니다. 블로그의 ADDR·VAL·STEP 설명은 행 주소·값·명령 종료를 보여 주는 개념도다. 현재 RISC-V 설계 문서의 최적화된 기록 형식은 F0·F1·F2·J 등도 쓰므로 그 세 토큰만으로 모든 명령을 실행한다고 이해하면 안 된다.

calc 펌웨어는 최대 62자리 값, 정수 연산과 괄호, 소수 연산을 지원한다. v2의 /는 기약분수로 중간값까지 정확하게 계산한다. v1은 분수를 최종값에만 허용해 mul_div에서 20/40에 그쳤고 v2 재시험은 40/40이었다. 이는 계산기 펌웨어의 제약을 바꾼 결과다. 앞서 GPU·배치와 비교군도 달라졌으므로 언어 모델 자체의 학습 능력이 향상됐다는 해석과 구분해야 한다.

한계와 오해하기 쉬운 점

bf16 체크포인트는 18.8GB다. 표준 형식에서 모든 층의 폭을 맞추느라 기존 Qwen 층까지 히든 크기 3968로 넓어졌고, 추가 공간 대부분은 0이다. L4에서 CPU 계산 토큰은 일반 HF 경로 약 250개/초, 전용 실행기 약 3,200개/초였지만 이는 전체 답변 속도가 아니다. 언어 토큰은 배치 1에서 약 68ms, mul_div 문제의 중앙 시간은 실행기 경로에서도 242초였다. 최적 커널 대신 대체 구현을 쓴 특정 설정의 관찰이다.

블로그 차트의 NUPA 48.6%→100%는 별도 CHIP-8 판의 576문항, 3~20자리 정수 평가다. 해당 모델카드는 개발 체크포인트들에서 벤치마크별 최선 모드를 골랐다고 명시한다. RISC-V의 40문항 시험과 합쳐 단일 고정 모델이 모든 산술을 맞혔다고 할 수 없다. RISC-V 판은 기본 generate()만으로 작동하지 않고 RvChat가 필요하며, 정확한 계산 결과를 받아도 Qwen이 부호를 빼거나 호출을 반복해 최종 답을 틀릴 수 있다.

MicroPython은 단독 코어와 실행기에서 작동했지만, 설계 문서 P3의 미완료 목록은 병합 모델 연결을 후속 작업으로 남겼다. 따라서 현재 Qwen3.5 언어모델이 MicroPython을 완전히 지원한다고 단정할 수 없다. 이번 작업은 공개 원문과 표를 대조했으며 코드를 실행해 독립 재현한 검증은 아니다.

실제로 어떻게 활용할까

활용 가치는 계산 가능한 회로를 언어 모델 층에 넣고 오류의 위치를 나누어 연구할 수 있다는 점에 있다. 모델이 잘못된 식을 요청했는지, 펌웨어가 지원하지 않는 연산인지, 계산 후 답을 잘못 옮겼는지 구분하는 실험대가 된다. 모델카드는 24GB GPU 환경을 설명하지만 이 글은 설치 안내나 안정적인 서비스 운영을 보장하는 자료가 아니다.

저자는 RNN 상태의 정확한 제어를 추론의 관찰 가능성과 연결하고 후속 감시·파일시스템 실험도 소개한다. 다만 별도 Filesystem 모델의 대화 간 기억은 호스트가 상태를 저장하고 다시 읽어 오는 방식이다. 이번 산술 모델이 자동으로 영구 기억을 얻거나 AI 안전성을 입증한 것은 아니다. 새 해설의 날짜와 원프로젝트의 날짜를 구분하고, 회로의 가능성과 완성된 제품의 성능을 나눠 보는 데 의미가 있다.