OpenRouter Ox Alpha 사용 후기 - Sol 설계를 구현하고 진짜 병목을 찾다

오늘 runNburn 작업을 하다가 OMP 모델을 새로 나온 Ox Alpha로 바꿔 봤습니다. OpenRouter에 갑자기 등장한 익명 모델이고, 현재 무료로 풀려 있거든요.

처음에는 잠깐 찍먹할 생각이었어요.

“무료 스텔스 모델이 실제 저장소 코딩을 얼마나 하겠어?”

그런데 생각보다 제법 잘 만들었습니다. GPT-5.6 Sol이 처음 작성한 packed-GQA 설계서를 읽고 runNburn 구현을 이어갔는데, 코드 작성과 작업 진행이 꽤 안정적이었어요. 특히 투두 항목을 하나 끝낼 때마다 바로 완료 처리하는 모습이 눈에 들어왔습니다.

도구를 쓰다 사소한 실수도 두 번 했습니다. 그래도 원인을 스스로 찾아 바로 복구했어요.

Sol의 첫 설계대로 구현한 결과는 프리필이 이전보다 느렸습니다. 이후 Dual-head와 pipe2는 Ox Alpha가 직접 제안하고 시험했지만 둘 다 프리필 시간을 줄이지 못했어요. 세 실험이 끝난 뒤 NVIDIA 프로파일러로 다시 분석했고, 작업을 184개로 나누는 기본값에서 진짜 병목을 찾았습니다. 이 값을 바꾸자 최종 프리필 시간이 8% 줄었습니다.

먼저 핵심부터 정리하면

1. Ox Alpha는 OpenRouter에서 무료로 제공되는 익명 추론 모델입니다. 입력 컨텍스트는 1,048,576토큰이고 최대 출력은 131,072토큰입니다.
2. runNburn 실작업 60회 요청에서 OMP가 기록한 평균 생성 속도는 21.27 tok/s, 평균 첫 토큰 시간은 7.42초였습니다.
3. Sol의 packed-GQA 설계와 Ox Alpha가 후속으로 시도한 Dual-head·pipe2는 프리필 성능에서 모두 실패했습니다. Ox Alpha는 프로파일러에서 진짜 병목을 찾아 기본 청크 값을 256에서 1024로 바꿨고 프리필 시간을 8% 줄였습니다.
4. 투두를 작업 직후 바로 완료 처리하고 도구 호출 실수도 원인을 찾아 복구했습니다.
5. 기술 지문은 Zhipu AI의 차세대 멀티모달 GLM을 가리키지만 개발사는 아직 공개되지 않았습니다.

Ox Alpha가 갑자기 왜 화제가 됐을까요?

OpenRouter는 한국 시간으로 8월 21일 Ox Alpha를 공개했습니다. 공식 설명은 코딩, 장시간 에이전트 작업, 복잡한 추론, 프로덕션 워크로드에 맞춘 모델이라는 내용입니다.

OpenRouter 공식 X 게시물은 조사 시점에 좋아요 1,943개, 재게시 130개, 답글 116개를 기록했습니다. Reddit에서는 r/singularity의 코딩 성능 글이 317점과 댓글 111개, r/LocalLLaMA의 정체 추정 글이 101점과 댓글 59개를 모았어요.

r/opencode의 무료 모델 소개 글에도 300점과 댓글 78개가 달렸습니다. 곧 OpenCode와 OMP에 연결한 실제 사용기가 올라오기 시작했어요.

정체와 벤치마크는 아직 참고 자료입니다

초기에는 Xiaomi MiMo V3라는 추측이 많았습니다. Xiaomi가 과거 Hunter Alpha와 Healer Alpha를 익명으로 시험한 전례가 있기 때문입니다.

기술 지문은 Zhipu AI의 차세대 멀티모달 GLM 쪽과 더 많이 겹쳤습니다. 독립 블랙박스 분석에서는 Ox Alpha와 GLM 계열의 영상 토큰 사용량, 텍스트 토크나이저, 오디오 처리 방식이 일치했습니다. 분석자는 미공개 GLM-5.3V 또는 GLM-5.5일 가능성을 약 90%로 봤습니다.

개발사 발표는 아직 없습니다. 지금 확정할 수 있는 이름은 stealth/ox-alpha뿐입니다. 비슷한 익명 공개 사례는 LongCat 2.0과 Owl Alpha 글에서도 정리했습니다.

DeepSWE 80%라는 숫자도 화제가 됐습니다. 정확한 조건은 전체 평가 80%가 아니라 고정한 열 개 과제 중 여덟 개를 한 번에 통과한 결과입니다. 같은 과제의 비교 평균은 Claude Fable 5 65%, GLM-5.3 62%, GPT-5.6 Sol 52%였습니다.

표본이 열 개라 전체 코딩 순위를 정할 수는 없습니다. 저는 벤치마크보다 실제 runNburn 저장소에서 어떻게 일하는지가 더 궁금했습니다.

Sol 설계서를 Ox Alpha에게 넘겼습니다

GPT-5.6 Sol이 맡은 건 최초 packed-GQA 설계까지였습니다. Ox Alpha는 그 설계를 구현한 뒤 프리필 성능 회귀를 확인했고, Dual-head와 pipe2를 직접 제안해 추가로 시험했습니다. 병목 수정과 최종 검증도 Ox Alpha가 이어갔습니다.

Sol의 첫 설계는 충실하게 구현했습니다. 결과 코드를 확인했을 때 구현 품질도 괜찮았어요. 이후 두 구조는 Ox Alpha가 프리필 성능 회귀를 해결하려고 직접 만든 시도였습니다.

제가 먼저 눈여겨본 건 투두 처리였습니다. GPT-5.6 Sol은 투두를 열 개나 스무 개 만든 뒤 작업을 모두 끝내고 마지막에 한꺼번에 완료 처리하는 경우가 많습니다. 이 방식도 구현 흐름을 유지하는 장점이 있습니다.

Ox Alpha는 항목 하나가 끝날 때마다 바로 완료로 바꾸고 다음 작업으로 넘어갔습니다. 진행 상황이 실제 코드 상태와 계속 맞아 있었어요.

도구 호출에서 사소한 실수도 두 번 나왔습니다. 작업 디렉터리를 잘못 잡아 편집 도구가 실패했을 때 원인을 바로 파악하고 올바른 디렉터리에서 재시도했습니다. 편집 범위를 잘못 선택했을 때도 의도와 다른 변경을 알아채고 범위를 다시 잡았어요.

두 번 모두 작업 흐름이 길게 끊기지 않았고 잘못된 변경도 남지 않았습니다.

코드 작성도 괜찮았지만, 작업 상태를 바로 갱신하고 실수를 스스로 복구하는 모습이 더 인상적이었습니다.

실제 OMP 세션 속도는 21.27 tok/s였습니다

OpenRouter 공개 페이지에는 캡처 시점 기준 지연 시간 4.33초, 처리량 28 tok/s가 표시됐습니다. 제 OMP 세션은 첫 토큰 7.42초와 21.27 tok/s로 더 느렸어요. 긴 저장소 문맥과 추론, 도구 호출이 섞인 실제 작업이라 단순 생성 요청과 조건이 다릅니다.

요청 실패 0회는 API 요청 기준입니다. 앞에서 말한 편집 도구 실수는 여기에 실패로 기록되지 않습니다.

복잡한 커널 개조보다 기본값 하나가 이겼습니다

Ox Alpha의 실력이 더 잘 보인 건 구현을 끝내고 runNburn 프리필 성능을 측정한 뒤였습니다.

첫 번째 packed-GQA는 Sol의 설계였습니다. 이 방식이 느려지자 Ox Alpha가 Dual-head와 pipe2를 차례로 제안해 구현했습니다. 두 시도도 프리필 시간에서는 탈락했어요.

Ox Alpha는 실패한 구조를 조금씩 고치는 대신 NVIDIA 프로파일러로 GPU 작업이 실행되는 모양을 다시 봤습니다.

진짜 병목은 184개의 중간 결과였습니다

테스트한 작업의 윈도 크기는 1024였는데, 기본 청크 값이 256이라 K/V 계산이 184개로 잘게 나뉘었습니다. 나뉜 작업은 중간 결과를 만들고 마지막에 다시 합칩니다.

GPU 작업을 한 번 실행할 때 이 중간 결과를 약 4.5GB씩 쓰고 읽고 있었습니다. 쉽게 말하면 계산 자체보다 184장의 중간 보고서를 작성하고 다시 읽는 비용이 더 커진 셈이에요.

Ox Alpha는 기본 청크를 256에서 1024로 올렸습니다. 새 커널을 더 만드는 대신 작업을 덜 잘게 나누는 정책 변경이었습니다.

47,166토큰 입력의 프리필을 RTX 3090에서 측정한 결과입니다. 기존 방식과 새 방식을 번갈아 실행한 세 번의 측정에서 모두 개선됐고, 정리된 최종 바이너리도 108.989초, 108.335초, 109.958초를 기록했습니다. 세 실행의 출력 해시는 모두 같았습니다.

실험 코드는 모두 걷어냈습니다

최종 소스 변경은 tuning.rs의 기본 청크 값을 1024로 바꾼 것만 남았습니다. packed, Dual-head, pipe2 커널과 실험용 인프라는 모두 삭제해 기존 코드 구조로 복원했습니다.

검증도 다시 돌렸습니다.

• 직접 비교에서 중간 결과와 메타데이터가 정확히 일치했습니다.
• 비정상 값 감지와 반복 실행 결과의 일관성 검사를 통과했습니다.
• CUDA 테스트는 713개 통과, 실패 0개, 제외 50개였습니다.
• rnb-llm CUDA 테스트와 Qwen3.6 35B 교차 모델 실행도 통과했습니다.
• 환경 변수 없이 정리된 바이너리로 실행했고 세 번 모두 같은 출력 해시를 확인했습니다.

결국 살아남은 건 새 커널이 아니라 기본값 하나였습니다. Ox Alpha는 실패한 실험 코드를 모두 지웠습니다. 저는 이 마무리가 좋았어요.

OpenRouter 경로는 프롬프트를 보관합니다

공식 페이지 상단에는 눈에 띄는 안내가 하나 있습니다.

Ox Alpha는 제3자 제공자가 개발하고 운영하며, 프롬프트와 완성 결과를 제공자가 보관합니다. 학습에는 사용하지 않는다고 적혀 있습니다.

OpenCode Zen 문서에는 Ox Alpha 제공자가 제로 리텐션 정책을 따른다고 나옵니다. 제가 사용한 경로는 OpenRouter입니다. 두 서비스의 데이터 처리 조건이 같지 않습니다.

코딩 에이전트는 저장소 코드, 설계서, 오류 로그, 작업 기록을 대화에 넣습니다. 공개 저장소나 실험용 코드에서는 무료 프리뷰를 활용하기 쉽습니다. 비공개 제품 코드와 인증 정보가 섞인 작업에는 OpenRouter 페이지에 표시된 보관 조건이 그대로 적용됩니다.

이런 작업에는 잘 맞았습니다

• 다른 모델이 만든 설계서를 따라 구현할 때
• 구조 변경이 실패한 뒤 프로파일러로 병목을 다시 찾을 때
• 무료로 장시간 코딩 에이전트를 시험하고 싶을 때
• 진행 상황이 투두에 바로 반영되는 흐름을 선호할 때
• 결과를 사람이 검토하며 저장소 작업을 이어갈 때

아직 확인하지 못한 부분도 있습니다

• 청크 1024가 다른 문맥 길이와 모델에서도 같은 폭으로 개선되는지는 더 측정해야 합니다.
• 다음 병목인 양자화 행렬 곱과 데이터 전송 구간은 아직 남아 있습니다.
• 며칠씩 이어지는 장기 세션의 안정성은 더 봐야 합니다.
• 비공개 코드 보관이 허용되지 않는 작업에는 OpenRouter 경로를 쓸 수 없습니다.
• 개발사와 정확한 모델 계보는 아직 공개되지 않았습니다.

정리하면

Ox Alpha는 Sol이 만든 최초 packed-GQA 설계를 충실하게 구현했습니다. 프리필 성능이 회귀하자 Dual-head와 pipe2를 직접 제안해 시험했지만 두 방식도 느려지거나 차이가 없었어요.

Ox Alpha는 자기 가설까지 실패하자 NVIDIA 프로파일러로 실행 모양을 다시 확인했습니다. 184개로 나뉜 작업이 약 4.5GB의 중간 결과를 반복해서 쓰고 읽는 비용을 찾았고, 기본 청크를 256에서 1024로 바꿔 프리필 시간을 약 8% 줄였습니다.

디렉터리와 편집 범위에서 사소한 실수가 나왔지만 원인을 찾아 바로 복구했습니다. 투두 갱신, 실패한 실험 코드 정리, 713개 CUDA 테스트와 교차 모델 검증까지 마치는 걸 보고 제 평가도 꽤 올라갔어요.

제 한 줄 평은 이렇습니다.

Ox Alpha는 Sol의 첫 설계를 구현했습니다. 이어 자기 가설도 시험했고, 실패를 인정한 뒤 더 단순한 해법으로 프리필 시간을 8% 줄였습니다.

다음 병목 분석과 추가 모델 측정 결과는 후속 작업이 끝난 뒤 반영할 생각입니다. 정체가 공개되면 현재 구현 경험과 함께 별도 후속 글로 확인하겠습니다.

참고 자료

• OpenRouter Ox Alpha 모델 페이지
• OpenRouter Ox Alpha 공식 X 발표
• OpenRouter Ox Alpha 제공자 API 정보
• OpenCode Zen 모델 목록과 데이터 정책
• Ox Alpha 블랙박스 정체 분석
• DeepSWE 공식 평가 페이지
• r/singularity Ox Alpha 코딩 성능 토론
• r/LocalLLaMA Ox Alpha 정체 토론
• r/opencode Ox Alpha 중간 종료 경험