화제가 되고 있는 Fujitsu의 새로운 AI 아키텍처 **「PHOTON」**에 대해, 기술적인 접근 방식이나 보도 자료에서 주장하는 수치의 이면을 자세히 분석해 보았습니다.

계기는 개발자인 Fujitsu의 Ichikawa Yuma 씨가 출연한 YouTube 해설 영상(Teleto BIZ 『이계통신(理系通信)』)을 시청한 것이었습니다.

※ 개요란에서 일부 인용: 「현재 PHOTON은 모델 사이즈가 12억 파라미터(parameter)인 소규모 연구 모델이지만, 『모델 사이즈가 커지면 승리한 것이나 다름없다』며 자신감을 보입니다.」

하지만 영상 내에서 언급된 "모델 사이즈가 커지면 승리한 것이나 다름없다"라는 발언이나, "ChatGPT나 Claude를 뛰어넘는다"와 같은 미디어의 자극적인 문구에 대해서는 솔직히 말해 "역시 너무 과장된 것이 아닌가?" 라는 강한 의구심을 갖지 않을 수 없었습니다.

기술적인 아이디어로서는 흥미롭지만, **「기존의 Transformer (Claude, Gemini, ChatGPT 등)의 완전한 대체」**가 될 것이라는 기대는 구조적으로 불가능하다고 생각합니다.

그 이유를 「표현력과 계산 효율의 트레이드오프 (trade-off)」 및 **「다수결 (멀티 쿼리 통합)의 한계」**라는 관점에서 해설하겠습니다.

먼저, PHOTON이 해결하려는 과제와 그 아이디어 자체는 매우 이해하기 쉽습니다.

기존의 Transformer는 긴 문장을 읽을 때 모든 글자와 글자 사이의 관계성을 동시에 계산하기 때문에, 입력이 길어질수록 계산량과 메모리 소비량이 폭발($O(N^2)$의 벽)합니다.

이에 대해 PHOTON은 인간이 두꺼운 책을 읽을 때의 사고 방식을 모방하여, 처리를 세로 2층 구조로 분업화했습니다.

「2층 (대국적 파악)」: 문장 전체의 흐름을 「요약 데이터」로서 대략적으로 유지한다. -
「1층 (상세 생성)」: 2층으로부터 지시를 받으면서, 눈앞의 문맥을 한 글자씩 세밀하게 생성한다.

생데이터(raw data)를 모두 메모리에 올리는 것이 아니라, 2층이 만든 「요약 데이터」를 재사용함으로써 메모리 소비량을 극적으로 억제하는 데 성공했습니다.

하지만 이 **「정보를 요약하여 유지한다」**는 접근 방식에는 구조적인 약점이 존재합니다.

정보의 압축 = 확실한 정보의 결손이기 때문입니다.

문장의 요약이나 일상 대화 정도라면 문제가 되지 않지만, **「기호 한 글자, 한 줄의 어긋남이 치명상이 되는 영역」**에서는 할루시네이션 (Hallucination, 환각)이나 정밀도 저하가 현저하게 나타납니다.

예를 들어, Python으로 로그인 처리의 패스워드 비교를 수행하는 코드를 생각해 보겠습니다.

# 정상적인 판정 코드
if password == input_password:
    allow_login()

요약 과정에서 기호의 연속성이 노이즈로 처리되어 버리면, == (비교 연산자)가 = (대입 연산자)로 누락될 리스크가 발생합니다. Python에서 이는 보안 붕괴를 의미합니다.

"구매 버튼이 1번 눌렸는지, 연타되어 2번 처리되었는지"와 같은 섬세한 문맥·로그의 차이도, 요약에 의해 「비슷한 처리의 중복」으로 지워져 버릴 우려가 있습니다.

※ 저수준(Low-layer) 개발에서의 영향

C 언어 (Linux 커널 등), CUDA, Triton과 같은 분야에서의 포인터 한 글자나, 레지스터의 비트 마스크 (예: 0x0F가 0x0E가 되는 등)의 어긋남을 「미세한 노이즈」로 압축해 버릴 경우, 시스템 전체의 크래시(crash)로 이어지기 때문에 미션 크리티컬(mission-critical)한 개발에 적용하기는 매우 어렵다고 할 수 있습니다.

보도 자료 등에서 눈길을 끄는 **「475배」**라는 경이로운 수치. 이를 들으면 "응답 속도가 475배 빨라졌다" 혹은 "성능이 475배 똑똑해졌다"라고 착각하기 쉽지만, 실체는 다릅니다.

이 수치의 정체는, **「모델을 경량화·단축화하여 메모리를 철저하게 깎아낸 결과, GPU 1장에 동시에 담을 수 있는 요청(멀티 쿼리)의 수가 최대 475배가 되었다」**는 **「스루풋 (Throughput, 처리량)」**에 관한 이야기입니다.

1톤의 짐을 잘게 분쇄하여 475대의 경트럭에 나누어 담아, "동시에 나열해서 운반할 수 있는 양(용량)이 늘어났다"라고 말하는 상태에 가까우며, 사용자 1명에 대한 처리 능력이 폭발적으로 향상된 것은 아닙니다.

사용자 1명이 이용할 때의 체감 속도라는 관점에서는, PHOTON에는 다음과 같은 구조적 병목(bottleneck)이 있습니다.

계층 간의 데이터 버킷 릴레이

「상위 모델에서 요약을 생성 ➔ 하위 모델로 전달」이라는 직렬 처리(serial processing)가 발생하기 때문에, **계층을 넘나드는 데이터 전송 대기로 인한 지연(latency)**이 발생한다.

다수결(Multi-query integration)에 의한 오버헤드(overhead)

정보 압축으로 인한 정밀도 저하를 보완하기 위해, 동일한 질문에 대해 표현을 바꾼 쿼리(query)를 여러 개 실행하여 다수결로 답변을 통합하는 수법을 취하고 있다.

"다수결을 통해 정밀도를 보완할 수 있다면 괜찮은 것 아닌가?"라고 생각할 수도 있겠지만, 여기에도 명확한 한계와 비용이 존재합니다.

다수결이 유효한 것은, "머릿속에 지식 자체는 존재하지만, 확률적 변동(fluctuation)으로 인해 올바른 출력을 얻지 못했을 때"뿐입니다.

압축 프로세스에 의해 처음부터 소멸하거나 결락되어 버린 지식은, 몇 번의 추론을 반복하여 다수결을 내더라도 복원할 수 없습니다. 사라진 기억은 아무리 애를 써도 꺼낼 수 없는 것입니다.

Claude나 Gemini와 같은 고도화된 LLM의 진가는, 문맥의 행간, 감정, 독특한 관점 및 논리 전개에 있습니다.

다수결(통합 처리)은 답변의 **"최대공약수"**를 구하는 작업이기 때문에, 이러한 고도화되고 섬세한 표현이나 날카로운 고찰은 **"노이즈(noise)"**로서 평균화되어 사라져 버리고, 무난하고 지루한 출력으로 귀결되고 맙니다.

예를 들어 9번의 다수결을 수행하는 경우, 배후에서는 9개의 모델을 동시에 실행해야 합니다.

어렵게 475배의 효율화를 달성했더라도, 한 번의 답변을 위해 9배의 계산을 수행한다면, 실질적인 계산 비용 및 전력 절감 효과는 9분의 1로 감소합니다.

게다가 9개의 결과가 모두 나올 때까지 기다려야 하므로, 사용자에 대한 응답 속도는 더욱 느려집니다.

PHOTON의 논문 등에서 제시된 "기존 Transformer와 동등한 수준의 성능"이라는 결과는, 어디까지나 1.2B(12억 파라미터) 정도의 초소형 사이즈 모델에서, 특정 벤치마크를 대상으로 다수결을 수행하여 따라잡았다는 제한적인 조건하의 것입니다.

현재 최전선에서 구동되는 **거대 모델(수천억~조 단위의 파라미터군)이 가진 "수만 줄의 코드 분석", "고도의 논리 추론", "복잡한 문맥 이해"**와 같은 영역에서는, 구조적으로 할루시네이션(hallucination)의 벽을 돌파하기는 어렵다고 생각됩니다.

PHOTON이 적합한 영역: 기억의 완전성이 엄격하게 요구되지 않는 에지 디바이스(edge device)나, 대량의 요청을 저메모리로 처리하고 싶은 특정 태스크
PHOTON이 취약한 영역: 단 한 글자의 실수도 허용되지 않는 프로그래밍·인프라 구축, 고도의 창의성이나 섬세한 뉘앙스가 요구되는 문장 작성

새로운 기술적 접근법으로서는 매우 혁신적이고 훌륭한 것이지만, 보도자료의 수치에 현혹되지 않고, **"표현력과 계산 효율의 트레이드오프(trade-off)"**라는 본질을 파악하여 사용처를 판단하는 것이 중요하다고 느꼈습니다.