Q4_K_M 양자화된 Qwen3.6-35B-A3B, llama.cpp, 이 모든 것이 휴대폰에서 실행되었습니다. 저는 Pocket Interpreter라는 앱을 호출했습니다. 사용자가 원하는 것을 설명하면 모델이 p5.js 스케치를 작성하고, 휴대폰이 이를 실행하는 방식입니다. 템플릿도, 번들된 코드도 없습니다. 영상 속의 모든 것은 즉석에서 생성되었습니다. 저는 "스와이프 컨트롤이 있는 Snake 게임"을 요청했고 약 1600개의 토큰을 받았습니다: 게임 루프(game loop), 먹이 생성(food spawn), 벽 및 자기 충돌(wall and self collision), 점수(score), 먹을수록 빨라지는 속도(speed that ramps as you eat), 그리고 엄지손가락이 실수로 두 번 꺾이지 않도록 최소 거리 임계값을 가진 스와이프 핸들러(swipe handler)가 포함되었습니다. 단 한 번의 시도만에 작동했습니다. 영상은 시작과 끝은 정상 속도이며, 중간 부분은 배속 처리되었습니다. 작은 모델은 이를 수행할 수 없습니다. 3B 모델에게 같은 것을 요청하면 겉보기에는 그럴듯하지만 첫 번째 벽에서 죽어버리는 코드를 받게 되고, 이후 네 번의 수정 과정을 거쳐야 합니다. 초당 5토큰(5 tok/s)의 속도라면 네 번의 수정은 한 번의 제대로 된 생성보다 훨씬 더 많은 비용이 듭니다. 한 번에 제대로 해내는 모델이 필요하며, 이는 곧 큰 모델을 의미합니다. 문제는 큰 모델은 휴대폰에 들어가지 않는다는 점입니다. 그것이 바로 BigMoeOnEdge ( https://github.com/Helldez/BigMoeOnEdge )가 존재하는 이유입니다: 120B MoE, 60 GB 규모를 12 GB 휴대폰에서 CPU 전용으로, 손실 없이(lossless), 순정 llama.cpp로 실행합니다. 항상 필요한 부분은 상주하고, 전문가(experts)는 플래시(flash)에서 스트리밍됩니다. 토큰당 오직 몇십억 개의 파라미터(params)만 활성화되므로 RAM이 한계점이 되지 않습니다. Pocket Interpreter가 존재하는 것도 바로 그 덕분이며, 여기서 사용된 35B 모델은 동일한 개념의 쉬운 단계에 해당합니다. 기기 외부로 나간 데이터는 아무것도 없습니다. 질문은 환영합니다. /u/dai_app 님이 제출함 [link] [comments]