HybridAgent, 잠재 사고와 텍스트를 오가며 토큰 55% 절감

코드는 다음에서 확인할 수 있습니다: https://github.com/togethercomputer/HybridAgent

LLM 모델 및 데이터: https://huggingface.co/collections/togethercomputer/hybridag...

평가: https://arxiv.org/html/2610.18861v1#S5

이걸 올인하는 방식과 비교하면 어떨지 궁금하네요: 입력 임베딩을 넓혀서 출력(‘Hybrid Link’ 이후) 잠재 벡터와 토큰 임베딩을 모두 담고, 텍스트 모드일 때도 둘 다 통과시키는 겁니다. 결국 텍스트를 생성할 때도 잠재 모드 모델을 돌리는 비용을 거의 전부 지불하고 있으니, 동시에 잠재적으로 추론하게 두지 않을 이유가 없지 않나요?

(아니면 넓은 벡터를 쓰는 대신 그냥 벡터들을 더하는 것도 좋습니다 - 다들 벡터를 단순 덧셈으로 뭉개도 좋은 결과를 얻는 것 같더군요.)

Qwen 3.8 27B에 적용된 걸 보고 기대됩니다. 이 모델의 추론 출력은 반복 설명이 많은 편인데, 이런 하이브리드 추론에서는 그런 부분이 잠재 공간에 더 많이 유지될 것 같네요.

저는 llama.cpp(어제 버전)에서 14B를 돌리고 있고, bartowski의 8비트 양자화를 쓰는데, 아주 간단한 채팅 요청—비슷한 크기의 다른 모델들(예: Gemma 4 12B)은 문제없이 처리하는 웹 검색 및 데이터 요약 작업, 이 크기 모델의 적정 용도죠—에 대해 같은 문단의 변형들을 5분 동안 반복하다가 턴 예산을 다 써버렸습니다. llama.cpp가 이 모델과 작동하려면 업데이트가 필요할 수도 있지만, Qwen 3 기반이니 꽤 잘 지원될 거라고 생각했습니다. 채팅 템플릿은 업스트림에서 배포하는 것과 같은데, 맞는지 아닌지는 모르겠습니다. 지금 16비트 버전을 다운로드 중인데, 양자화 병리 현상인지 확인해보려는 겁니다.

또한 이 모델이 CSV가 뭔지 아는지도 확신이 안 서네요. 추론 단계에서 데이터를 어떻게 제시할지 예시로 마크다운 표에 넣었거든요(제 프롬프트는 CSV 형식의 데이터를 요청합니다). 대부분의 Qwen 파인튜닝 경험상 더 멍청해지는데, 벤치마크 결과는 다르게 나오니 llama.cpp 비호환성이라고 가정할 수밖에 없습니다.

수정: BF16에서도 같은 반복이 발생합니다. 그러니 아마 llama.cpp 업데이트를 기다려야 할 것 같습니다.

Astra의 루프 트랜스포머와 어떻게 다른가요? 그 아키텍처도 잠재 공간에서 추론하잖아요.

이건 제 이해를 완전히 벗어나는 내용이라, 아는 분이 계시길 바라며 질문합니다:

근본적으로 다른(그렇게 들리는데) 모델들을 통해 추론한다는 이 아이디어를 훨씬 더 먼 모델이나 시스템을 연결하는 데 쓸 수 있을까요?

작은 도약을 할 수 있다면, 연쇄를 통해 더 큰 도약을 만들 수 있죠. 잠재 공간은 또 무엇과 연결될 수 있을까요?

텍스트를 통한 도구 사용 대신, 아날로그 신호를 통한 도구 사용?

언어 프롬프트 대신, 아날로그 센서?

저는 항상 언어가 때로는 LLM의 제약 요인이 될 수 있다고 생각했고, 벡터 임베딩 기반 내부 추론이 더 빠르고 더 나은 모델의 핵심이 될 거라고 봤습니다.