Qwenputer RISC-V CPU, AI 가중치 내부에서 실행… 제한적인 Doom 데뷔

개발자 Divyansh Agrawal에 따르면 Qwenputer는 Qwen3.5의 가중치 안에 32비트 프로세서를 넣었으며, 별도 프로젝트는 이를 활용해 Doom의 첫 번째 맵을 탐색한다. Qwenputer RISC-V CPU는 수정된 모델 안에서 일부 예측 기반 산술 연산을 명령어 실행으로 대체한다. 다만 공개된 Doom 저장소는 원본 게임 엔진이 아니라 단순화된 맵 렌더러를 설명한다.

이 차이는 이야기를 더 명확하게 만든다. Agrawal은 기존 언어 모델과 함께 학습이 아닌 컴파일을 통해 구성된 프로세서를 설명한다. 관련 비교 대상은 외부 Python 인터프리터, 즉 Python 명령어를 실행하는 소프트웨어를 사용하는 Qwen3.5다. 두 방식 모두 모델에 정확한 계산 능력을 제공하지만, 그 계산이 이뤄지는 위치는 다르다.

개발자에게 중요한 질문은 실행을 모델 가중치 안으로 옮기는 일이 추가 복잡성을 정당화할 만큼의 이점을 제공하는지다. Doom 헤드라인을 따라온 독자에게 당면한 과제는 프로세서 주장과 게임 시연을 구분하는 일이다. 현재 공개된 문서는 AI가 자발적으로 컴퓨터가 되는 법을 배웠다는 이야기보다 더 제한적이면서도 기술적으로 흥미로운 설명을 뒷받침한다.

Qwenputer RISC-V CPU가 실제로 바꾸는 것

Agrawal이 2026년 10월 22일 공개한 컴파일된 CPU 설명에 따르면, 원래 모델의 가중치를 보존한 채 Qwen3.5-4B에 프로세서 로직을 추가했다. RISC-V는 호환 프로세서가 실행하는 연산을 정의하는 공개 명령어 세트다. 여기서 그 연산은 추가된 신경망 레이어에 존재한다.

Agrawal에 따르면 컴파일러는 추가 가중치를 직접 계산한다. 이는 이 프로젝트가 프로세서 동작을 근사하도록 모델을 학습시키는 데 의존하지 않는다는 점에서 중요하다. 핵심 주장은 사전학습 언어 모델과 함께 작동하는, 의도적으로 구성된 실행 장치에 관한 것이다.

변화의 핵심은 선택된 계산이 실행되는 위치이지, 모델의 일반적인 추론 능력이 향상되는 것이 아니다.

이 구분은 실험을 평가하는 방식을 바꾼다. 산술 문제에 정확히 답하는 모델은 여러 경로를 통해 그 결과에 도달할 수 있다. 답을 예측하거나, 계산을 생성하거나, 실행을 위임할 수 있다. 이 경로들은 겉으로는 같은 답을 낼 수 있지만 신뢰성과 배포 특성은 서로 다르다.

Qwenputer는 실행 경로를 수정된 모델의 일부로 만든다. 따라서 그 중요성은 컴파일된 장치가 의도된 명령어를 신뢰성 있게 따르는지에 달려 있다. 설득력 있는 시연은 익숙한 곱셈 문제의 정답 이상을 입증해야 한다.

또한 언어 모델과 프로세서 사이에 분명한 경계가 필요하다. 어느 구성 요소가 식을 선택하는가? 어느 구성 요소가 계산을 수행하는가? 어느 구성 요소가 결과를 최종 답으로 바꾸는가? 이런 구분이 없다면 성공적인 응답은 정확성의 원천을 거의 보여주지 못한다.

공개 릴리스는 이런 질문들을 검증 가능하게 한다. 연구자들은 영상으로부터 메커니즘을 추론하는 대신 구성 방식을 살펴볼 수 있다. 이는 내부 실행 경로를 확인할 수 없는 시연보다 의미 있는 장점이다.

그럼에도 검증 가능성이 독립적 검증과 같은 뜻은 아니다. 문서와 공개된 산출물은 다른 이들이 주장을 시험할 방법을 제공한다. 그렇다고 보고된 모든 결과가 이미 무관한 평가자에 의해 재현됐다는 뜻은 아니다.

따라서 이번 개발은 구체적이지만 범위가 제한돼 있다. 한 엔지니어가 일반적인 언어 생성과 컴파일된 프로세서 동작을 결합하는 실험적 방식을 공개했다. 이는 모든 실행 작업을 외부 도구 인터페이스 뒤에 두는 방식에 대한 검증 가능한 대안을 만든다.

이를 기존 컴퓨터를 대체한다는 주장으로 확대할 필요는 없다. 이 실험은 이미 유용한 아키텍처 질문을 던진다. 결정론적 계산 중 얼마나 많은 부분이 AI 모델의 실행 경로 안에 속해야 하는가?

그 가치는 포장의 새로움이 아니라 측정 결과에서 나오는 답에 달려 있다.

Doom 시연에 더 제한적인 설명이 필요한 이유

Doom과의 연결은 이 실험을 이해하기 쉽게 만드는 데 도움이 됐다. 널리 알려진 게임 환경은 독자에게 프로세서 다이어그램보다 더 구체적인 대상을 제공한다. 동시에 실제로 어떤 소프트웨어가 실행되는지에 관한 큰 오해의 여지도 만든다.

별도의 Doom 맵 렌더러는 Doom 엔진을 실행하는 대신 E1M1의 평면도를 탐색한다고 명시한다. 맵을 통과하는 시야선을 투영하는 렌더러인 레이캐스터를 사용하고 텍스트 프레임을 출력한다. 저장소는 이 경험에서 몬스터, 텍스처, 피해 시스템 및 기타 원작 게임 기능이 빠졌다고 설명한다.

보고된 성과는 완전한 Doom 포트가 아니라 변환된 Doom 맵을 프로세서로 구동해 탐색한 것이다.

이 단서가 시연을 무의미하게 만들지는 않는다. 위치를 유지하고, 이동을 처리하며, 바뀌는 시점을 렌더링하는 프로그램은 단순한 산술 연산 이상을 수행한다. 눈에 보이는 상태 변화가 있는 이해하기 쉬운 워크로드를 제공한다.

하지만 워크로드의 범위가 어떤 결론을 내릴 수 있는지 결정한다. 단순화된 환경을 탐색하는 것은 원본 엔진과 게임플레이 시스템을 실행하는 것과는 다른 사실을 입증한다. 이 성과들을 서로 바꿔 말하면 증거를 부풀리게 된다.

저장소는 호스트 소프트웨어가 참조 머신과 실행 결과를 대조한다고도 설명한다. 참조 머신은 기대 결과를 정립하는 데 쓰이는 구현체다. 이 검사는 불일치를 드러내는 데 도움이 된다. 하지만 시연에 주변 소프트웨어가 없다는 증거가 아니라 실험 설정의 일부로 이해해야 한다.

게임 프로그램을 실행하는 것과 AI가 자율적으로 게임을 플레이하는 것 사이에는 또 다른 차이가 있다. 프로젝트는 플레이어 입력이 시연을 구동하며, 이 모드에서는 언어 모델의 일반 예측을 사용하지 않는다고 밝힌다. 따라서 독자는 영상을 에이전트가 길 찾기를 학습했다는 증거로 해석하지 않아야 한다.

이러한 경계는 Tom’s Hardware가 11월 2일 보도한 더 광범위한 Doom 실행 헤드라인에 단서가 필요한 이유를 설명한다. 프로세서 실험과 시각적 쇼케이스는 관련돼 있지만 동일한 주장은 아니다.

유용한 시연이 문화적 참조가 암시하는 모든 기능을 담을 필요는 없다. 다만 무엇을 담고 있는지는 정확히 설명해야 한다. 여기서는 프로젝트 자체의 설명이 그 정확성을 제공한다.

작업을 평가하는 개발자에게 렌더링된 장면은 편리한 진입점이다. 더 강한 증거는 그 아래의 실행 경로에 있다. 익숙한 복도가 흥미로운 이유는 명시된 프로그램이 컴파일된 프로세서를 통해 그것을 생성했다고 보고됐기 때문이다.

따라서 적절한 질문은 이미지가 Doom과 충분히 비슷해 보이는지가 아니다. 문서화된 조건 아래에서 주장된 명령어가 그 이미지를 만들었는지다. 이 질문이 흥미로운 사례를 더 큰 실행 논쟁과 연결한다.

Qwenputer가 프로세서를 학습하지 않고 작동하는 방식

프로젝트의 프로세서 구현은 기존 Qwen의 32개 레이어 앞에 11개의 컴파일된 레이어를 배치한다. 레이어는 신경망 안에서 수학적 처리가 이뤄지는 한 단계다. 저장소에 따르면 추가된 레이어는 예시로부터 학습하는 대신 프로세서 연산을 구현한다.

메모리는 모델의 진행 중인 내부 상태를 유지하고 갱신하는 메커니즘인 Gated DeltaNet에서 온다. 프로젝트는 이 상태를 정확하고 주소 지정 가능한 저장소로 구성한다. 실행 중인 프로그램 데이터를 보관하는 작업 메모리인 RAM은 모델의 계산 내부에 표현된다.

Qwenputer의 핵심 메커니즘은 의도적으로 구성된 로직과 의도적으로 제어된 메모리를 결합한다.

두 부분 모두 중요하다. 신뢰할 수 있는 저장소가 없는 산술 로직은 실행 중인 프로그램을 지원하기 어렵다. 명령어 실행이 없는 저장소는 메모리는 제공하지만 주장된 프로세서 동작은 제공하지 못한다.

저장소는 모델에 익숙한 도구 호출 형식을 재사용하는 브리지를 설명한다. Qwen이 계산을 요청하면 컴파일된 구성 요소가 이를 실행하고, 결과 출력은 텍스트로 반환된다. 프로젝트에 따르면 계산은 외부 도구 실행기로 전달되지 않는다.

이 인터페이스는 흥미로운 설계 선택이다. 언어 모델이 이미 인식하는 형식을 통해 다른 실행 메커니즘과 상호작용할 수 있게 한다. 계산이 다른 경로를 거치더라도 보이는 요청은 기존 도구 사용과 닮을 수 있다.

프로젝트는 펌웨어를 불러오고 프로세서 트레이스 토큰을 관리하기 위해 시작과 실행을 조율하는 소프트웨어인 드라이버도 사용한다. 펌웨어는 내장된 머신을 작동시키기 위해 로드되는 프로그램이다. 트레이스 토큰은 실행 단계를 기록하는 생성된 기호다.

이는 “가중치 내부”라는 표현에 신중한 해석이 필요하다는 뜻이다. 가중치는 장치를 구현하고, 변화하는 실행 상태는 실행 프로그램의 정보를 담는다. 산술 연산이 내부로 이동한다고 해서 주변 애플리케이션 전체가 사라지는 것은 아니다.

이 구분은 배포를 논할 때 필수적이다. 모델 실행에는 여전히 물리적 하드웨어와 그 하드웨어를 조율하는 소프트웨어가 필요하다. 더 제한적인 주장은 그 시스템 안에서 프로세서 연산이 어디에 표현되고 실행되는지에 관한 것이다.

이 메커니즘은 구성과 학습도 분리한다. 컴파일러는 학습이 연산을 발견하도록 요구하지 않고 선택된 연산을 인코딩할 수 있다. 이는 연구자에게 모델 아키텍처 안에 내장된 명시적 로직이라는 다른 검토 대상을 제공한다.

그렇다고 컴파일된 구성 요소가 자동으로 유지보수하기 쉬워지는 것은 아니다. 정확성은 여전히 구현 세부 사항과 실행 환경의 수치적 동작에 달려 있다. 이런 의존성은 모델이 실행되는 모든 환경에서 시험돼야 한다.

그럼에도 아키텍처적 매력은 분명하다. 언어 생성과 정확한 실행은 모델 패키지를 공유하면서도 서로 다른 책임을 유지할 수 있다. 이는 Qwenputer를 언어 모델이 근사할 필요 없는 계산을 지시하는 구성 실험으로 만든다.

Qwenputer RISC-V CPU에서 이러한 역할 분담이 핵심 기술 이야기다. Doom 장면은 이를 보여주지만 그 중요성을 정의하지는 않는다.

외부 Python은 여전히 적절한 비교 대상이다

가장 유용한 비교 대상은 이미 프로젝트 평가에 있다. 즉 호스트 Python 도구에 접근할 수 있는 기본 Qwen3.5다. 여기서 “호스트”는 애플리케이션을 실행하는 주변 컴퓨터를 뜻한다. 이 비교는 실행 위치를 옮기는 일이 결과를 바꾸는지 묻는다.

공개된 산술 벤치마크 결과는 세트당 40개 문제를 사용한다. 큰 수 곱셈 세트에서 보고된 정확도는 기본 Qwen의 55%에서 Qwenputer의 97.5%로 상승한다. Python 도구 구성은 100%에 도달한다.

큰 수 나눗셈에서는 순위가 달라진다. 모델 카드는 기본 Qwen 72.5%, Qwenputer 97.5%, Python 도구 구성 95%를 보고한다. 이는 이 기사를 위해 수행된 독립 비교가 아니라 개발자가 공개한 측정치다.

이 결과는 계산이 어디에서 이뤄지는지의 이점보다 정확한 계산에 대한 접근이 주는 이점을 더 분명하게 뒷받침한다.

그것이 경쟁의 핵심 지점이다. 두 실행 방식 모두 도구 없이 모델이 답하는 경우보다 보고된 산술 성능을 크게 개선한다. 다만 그 차이는 헤드라인에 나온 백분율만으로 판단하기보다 더 면밀히 검토해야 한다.

평가 세트가 작으면 개별 응답 하나가 보고된 점수를 눈에 띄게 바꿀 수 있다. 프롬프트, 실행 제한, 중간 결과 처리 방식의 차이도 결과에 영향을 줄 수 있다. 이런 과제의 순위를 AI 아키텍처 전반의 순위로 확대해서는 안 된다.

기저에 있는 사용자 과제 역시 중요하다. 계산기가 정확한 값을 반환하더라도 요청의 실행 부분만 해결할 뿐이다. 언어 모델은 여전히 의도한 계산을 구성하고 그 결과를 적절하게 사용해야 한다.

공학 요청에서 수량을 계산하는 가상의 어시스턴트를 생각해 보자. 정확한 곱셈은 어시스턴트가 올바른 수량과 단위를 식별한 뒤에야 유용하다. 곱셈을 모델 가중치 내부로 옮긴다고 해서 그 이전의 판단이 정확하다는 뜻은 아니다.

같은 논리는 외부 인터프리터에도 적용된다. 외부 인터프리터가 있다고 해서 최종 답변이 정확하다는 보장은 없다. 따라서 비교는 전체 워크플로를 측정하면서 각 구성 요소의 실패도 분리해 살펴봐야 한다.

애플리케이션 개발자에게 이는 즉각적인 마이그레이션 요건이 아니라 평가 부담을 의미한다. 임베디드 프로세서는 정의된 워크로드에서 측정 가능한 이점을 통해 도입 가치를 입증해야 한다. 아키텍처의 새로움만으로 운영 부담이 줄거나 사용자 결과가 더 좋아진다고 볼 수는 없다.

외부 실행은 프로젝트가 이미 측정하고 있으므로 여전히 유용한 기준선이다. 연구자들은 논의를 구성하기 위해 동떨어진 경쟁 대상을 새로 만들 필요가 없다. 같은 언어 모델과 유사한 계산 지원을 서로 다르게 배치한 방식을 비교할 수 있다.

압력은 실행 설계에 관한 주장에 집중된다. 내부 실행이 더 낫다면, 지지자들은 어느 영역에서 어떤 조건 아래 더 나은지 보여줘야 한다. 외부 도구가 여전히 더 낫다면, 그 옹호자들은 같은 워크로드에서의 실질적 이점을 밝혀야 한다.

따라서 Qwenputer vs Python은 시스템 설계의 문제다. 보고된 점수는 이 문제를 살펴볼 가치를 만들지만, 더 폭넓은 결론은 열어 둔다.

정확한 실행이 정답을 보장하지는 않는다

상세한 프로세서 검증 노트는 중요한 실패 양상을 지적한다. 언어 모델이 정확한 기계 결과를 잘못 처리할 수 있다는 점이다. 보고된 사례에는 반복 호출과 잘못된 최종 응답이 포함된다. 신뢰할 수 있는 산술 장치가 신뢰할 수 없는 오케스트레이션을 없애지는 않는다.

이 노트는 광범위한 MicroPython 주장에도 조건을 단다. Python의 경량 구현인 MicroPython은 문서화된 단계에서 독립형 코어와 실행기에서 구동됐다. 노트는 이 작업과 병합된 언어 모델 내부 통합을 구분한다.

프로세서의 정확성과 어시스턴트의 정확성에는 별도의 근거가 필요하다.

이는 시스템의 실제 책임 분담을 따르기 때문에 가장 강력한 회의적 관점이다. 컴파일된 프로세서는 정확하게 실행할 수 있지만, 언어 모델은 부적절한 연산을 선택할 수 있다. 또한 프로세서가 올바른 값을 반환해도 모델이 이후에 이를 잘못 서술할 수 있다.

유용한 평가는 이러한 결과를 구분해야 한다. 그렇지 않으면 성공한 프로세서 테스트를 성공한 어시스턴트 테스트로 오해할 수 있다. 반대로 실패한 최종 답변은 할당된 프로그램을 정확히 실행한 프로세서를 가릴 수 있다.

같은 분리는 소프트웨어 지원에도 적용된다. 독립형 실험 코어에서 프로그램을 실행한다고 해서 통합된 대화형 워크플로가 자동으로 입증되는 것은 아니다. 통합을 위해서는 주변 구성 요소가 요청과 결과를 정확하게 전달해야 한다.

이 때문에 MicroPython에 관한 단서는 표현상의 정정을 넘어 중요하다. 이는 기능 주장이 서로 다른 개발 단계에 걸칠 수 있음을 보여준다. 독자는 출시된 시스템이 무엇을 할 수 있는지 판단하기 전에 어떤 구성에서 어떤 결과가 나왔는지 알아야 한다.

성능 주장에도 비슷한 주의가 필요하다. 프로세서 트레이스는 내부 실행 활동을 측정하는 반면, 사용자는 완전한 답변에 필요한 시간을 경험한다. 트레이스 생성이 더 빠르다고 해서 대화형 응답 시간이 비례해 개선되는 것은 아니다.

이 실험은 환경 전반에서의 평가도 필요하다. 개발자 환경에서 의도대로 동작하는 구성이라도 다른 환경에서 재현돼야 한다. 정확한 동작이 수치 실행의 세부 사항에 좌우될 때 이는 특히 중요하다.

이는 프로젝트를 일축할 이유가 아니라 엔지니어링 질문이다. 이러한 질문은 흥미로운 구현과 신뢰할 수 있는 구성 요소의 차이를 규정한다. 상세한 한계가 공개돼 있어 그 차이를 조사하기가 더 쉬워진다.

엔터프라이즈 구매자도 신뢰성에 관한 더 광범위한 주장에 같은 원칙을 적용해야 한다. 임베디드 계산 메커니즘이 문서 해석, 권한 또는 외부 작업의 정확성을 입증하지는 않는다. 각 기능에는 고유한 실패 양상에 맞는 근거가 필요하다.

내부 실행이 더 강한 보안을 자동으로 보장하지도 않는다. 계산이 이루어지는 위치만으로는 어떤 프로그램이 허용되는지, 상태가 어떻게 처리되는지에 대해 거의 알 수 없다. 이러한 문제에는 문서화된 보안 설계와 이에 상응하는 테스트가 필요하다.

적절한 결론은 구체적으로 유지된다. Qwenputer RISC-V CPU는 수정된 모델 내부에서 정확한 실행을 수행하는 것으로 보고된 경로를 제공한다. 이것이 애플리케이션을 개선하는지는 이를 둘러싼 전체 시스템에 달려 있다.

이 실험이 데모를 넘어 의미를 가지려면 무엇이 필요할까?

다음으로 유용한 진전은 순서대로 독립 재현, 조건을 맞춘 성능 비교, 더 폭넓은 통합 워크로드다. 각각은 서로 다른 미해결 질문에 답할 것이다. 이들이 함께 갖춰지면 시각적 인상을 넘어 실험을 더 쉽게 평가할 수 있다.

가장 강력한 다음 결과는 재현 가능한 실행을 완전한 과제에서 측정 가능한 개선과 연결하는 것이다.

독립 재현이 먼저인 이유는 공개된 구성이 작성자의 환경 밖에서도 설명된 대로 동작하는지 검증하기 때문이다. 별도의 팀은 모델 버전, 실행 경로, 테스트 조건을 식별해야 한다. 결과가 일치하면 보고된 메커니즘에 대한 신뢰가 높아진다.

정확히 문서화된다면 불일치 역시 유익한 정보가 된다. 구현 문제, 환경 의존성 또는 모호한 주장을 드러낼 수 있다. 유용한 재현 보고서는 결과를 성공 또는 실패로만 축소하지 않고 불일치의 이유를 설명해야 한다.

이는 Doom 데모에서 특히 중요하다. 설명된 맵 렌더러를 재현하면 해당 조건에서 그 워크로드를 뒷받침할 수 있다. 그러나 누군가 실제 Doom 엔진을 구현하고 테스트하지 않는 한, 원래의 Doom 엔진 주장은 여전히 뒷받침되지 않는다.

그다음은 조건을 맞춘 비교다. Qwenputer vs Python은 동등한 과제, 비교 가능한 실행 규칙, 주변 소프트웨어에 대한 투명한 산정을 사용해야 한다. 그러면 내부 실행 자체에 기인하는 이점을 더 쉽게 식별할 수 있다.

측정에는 완전한 응답 시간과 최종 답변 정확도가 포함돼야 한다. 리소스 사용량과 설정 노력은 애플리케이션 개발자가 실질적 적합성을 판단하는 데 도움이 된다. 전체 사용자 워크플로의 운영이 더 어려워진다면, 더 빠른 내부 연산의 설득력은 떨어진다.

내부 실행에 유리한 결과는 선택된 계산 기능을 임베드해야 한다는 근거를 강화할 것이다. 외부 실행에 유리한 결과는 실험의 실용적 역할을 좁힐 것이다. 어느 결과든 계산이 어디에 있어야 하는지에 관한 추측을 넘어 논의를 진전시킬 수 있다.

더 폭넓은 통합 워크로드가 마지막 신호를 이룬다. 중요한 진전은 모델이 과제를 선택하는 시점부터 임베디드 구성 요소가 이를 완료하는 시점까지의 문서화된 경로가 될 것이다. 이는 실행과 함께 조정을 시험하게 된다.

실제 Qwenputer 작동 방식을 이해할 때 가장 중요한 것은 이 구분이다. 작동하는 독립형 프로그램은 프로세서에 관한 근거를 제공한다. 완료된 대화형 과제는 프로세서, 모델, 드라이버의 조합에 관한 근거를 제공한다.

이러한 변화를 추적하는 연구자들은 모든 릴리스를 하나의 기능 주장으로 합치기보다 버전별 노트를 유지해야 한다. 테스트 결과를 정확한 구성과 연결하면 초기의 한계가 이후 요약에서 사라지는 일을 막을 수 있다.

팀은 기술 평가를 위한 검색 가능한 지식 기반을 구축할 때도 같은 원칙을 적용할 수 있다. 유용한 기록은 각 결론을 이를 뒷받침하는 코드, 문서, 실행 조건과 연결한다.

조사를 시작할지 결정하는 개발자라면 실제로 완료해야 하는 과제에서 출발해야 한다. 현재 시스템이 어디에서 실패하는지 파악하라. 연산 선택, 실행, 상태 유지, 결과 해석 중 어느 부분인지 확인해야 한다. 그런 다음 계산을 가중치 내부로 옮기는 일이 그 실패를 해결하는지 물어야 한다. Doom 장면은 구현을 살펴보라는 초대로 받아들이고, 산술 점수는 재현의 출발점으로 받아들여야 한다. 드라이버와 검증 설정을 포함해 문서화된 구성 전반에서 Qwenputer RISC-V CPU를 추적하라. 배포에 관한 결론을 내리기 전에 전체 워크플로를 외부 실행기와 비교하라. 어떤 결과가 아키텍처 결정을 바꾸겠는가? 재현된 프로세서, 더 빠르게 완료된 과제, 아니면 입증할 수 있을 만큼 더 신뢰할 수 있는 최종 답변인가?