Ripple-65B Preview: $0.20 엔드포인트, 네이티브 vLLM 병합, 그리고 세 가지 컨텍스트 수치

가중치는 11월 4일 02:41 UTC에 도착했습니다. 19시간 뒤 누군가 이를 vLLM의 메인 브랜치에 넣는 풀 리퀘스트를 열었고, 11월 5일 17:36 UTC에 병합되었습니다. 27개 파일에 걸쳐 1,153줄이 추가된 것입니다. 이는 많은 관심을 받은 모델 릴리스 기준으로도 빠른 편이며, 구체적으로 한 가지를 바꿉니다. 그 병합 전까지 Ripple-65B Preview — Ricursive Intelligence의 65B dense Apache 2.0 체크포인트 — 에는 문서화된 서빙 경로가 정확히 하나뿐이었습니다. 저자들이 엔진 외부에 배포한 플러그인이었습니다. 이제 이를 평가하는 사람에게 질문은 더 이상 서빙이 가능한지가 아닙니다. 자신의 하드웨어에 맞는 것은 이제 공식이 된 서빙 방식 중 어느 것인지, 그리고 각 방식이 조용히 무엇을 대가로 치르게 하는지입니다.

그 질문 뒤에는 두 가지 사실이 자리 잡고 있으며, 둘은 서로 반대 방향으로 당긴다. 네이티브 vLLM 지원은 out-of-tree SGLang 스크립트를 작동시키지 못했던 팀들에게 셀프 호스팅을 그럴듯하게 만든다. 한편 호스팅 목록들은 실제로 얼마나 많은 컨텍스트를 얻는지에 대해 모델 카드와 여전히 불일치한다. 한 서비스 페이지는 사양 사이드바에 128K를 헤드라인으로 내세우는 반면, 같은 페이지의 모델 카드 섹션은 최대 1,048,576 토큰이라고 말하며, 이 모델을 제공한 첫 상용 엔드포인트는 16,384를 제공했다. 어느 사실도 백만 토큰 컨텍스트를 광고하는 65B 모델이, 그 앞에 있는 엔드포인트가 128K라고 말할 때 무엇을 해야 하는지를 해결하지 못한다.

병합 전에 실제로 빠져 있던 것

단서는 풀 리퀘스트 자체의 설명에 있습니다. 그 설명에 따르면, 이 변경 이전에는 "유일한 서빙 경로는 작성자들의 아웃오브트리 SGLang 플러그인이었다"고 합니다. 그 플러그인은 모델 카드와 함께 SGLang 0.5.19 설정으로 제공되었는데, 이는 Ripple-65B Preview를 서빙하려는 사람이라면 누구나 외부 스크립트와 함께 특정 엔진 버전을 채택하거나, 사용자 지정 아키텍처를 선언하는 체크포인트에 대해 자체 모델 정의를 작성해야 했음을 의미합니다.

두 번째 요점은 조용히 도입을 막는 바로 그 지점이다. BF16 저장소에는 custom_code 태그가 붙어 있고, config는 아키텍처를 RicursiveForCausalLM으로 식별하는데, 이는 일주일 전만 해도 어떤 엔진도 들어본 적 없는 이름이었다. 이를 로드하려면 --trust-remote-code가 필요했는데, 대부분의 프로덕션 환경에서 이는 기술적 결정이 되기 전에 보안 검토자와의 대화를 뜻했다.

병합은 그 단계를 우회하는 대신 제거합니다. 이 PR은 내장된 RicursiveConfig를 추가하여 체크포인트가 --trust-remote-code 없이도 로드되도록 하며, 해당 아키텍처를 다른 모든 일급 모델 패밀리와 함께 모델 레지스트리에 등록합니다. SGLang에 동일한 작업을 적용하려는 병렬 작업은 아직 열려 있고 병합되지 않았으므로, 현재 vLLM은 이 모델이 스크립트가 아닌 지원 대상으로 취급되는 유일한 주류 엔진입니다.

모델 파일보다 더 중요한 병합의 부분들

413줄짜리 모델 구현은 화려하지 않은 절반이다. 흥미로운 추가 사항은 모델이 벤치마크 수치가 설명하는 대상처럼 동작하게 만드는 것들이다.

• 추론 및 도구 호출 — 이 병합은 --reasoning-parser ripple과 --tool-call-parser ripple을 추가합니다. 이들은 선택적 think 블록과 Hermes 스타일 JSON 도구 호출을 처리하며, 스트리밍 출력은 비스트리밍 형식과 일치합니다. 이것들이 없으면 에이전트형 모델은 직접 파싱해야 하는 텍스트를 반환하며, 배포된 에이전트가 실패하는 지점이 바로 이 파싱입니다.

• 검증된 레시피 — recipes/models/ricursiveAI/Ripple-65B-Preview.yaml, 97줄, 단일 B300에서 NVFP4 체크포인트를 기본으로 사용하며, BF16 변형과 파서가 연결되어 있습니다. 이 레시피는 recipes 저장소 자체의 validate-source.mjs를 통과합니다. 이 모델에 대해 존재하는 "이렇게 실행하라"는 공식에 가장 가까운 것입니다.

• 드래프트 체크포인트를 통한 추측 디코딩 — 이 저장소에는 4.04B 드래프터가 포함되어 있으며, 이번 병합으로 vLLM이 no_rope_layers를 통해 해당 드래프터의 NoPE 레이어 레이아웃을 읽을 수 있게 되었습니다. GSM8K에서 이 PR은 검증 단계당 평균 수용 길이가 4.98개 토큰에서 7.34개 토큰으로 증가한다고 보고합니다.

• 158줄의 파서 테스트와 트레이스 빌더가 있으며, 이는 가장 눈에 띄지 않으면서도 가장 안심이 되는 부분입니다. 추론 파서의 동작이 주석이 아니라 테스트로 고정되어 있습니다.

왜 초당 토큰 수가 아니라 acceptance length(수용 길이)를 주목해야 하는 수치인가

Ricursive가 자체적으로 제시한 효율 수치는 배치 크기 8에서 B200 두 장으로 초당 250토큰이며, 양자화나 커스텀 커널을 적용하기 전 기준입니다. 이 수치는 저자들이 직접 빌드한 SGLang과 그들이 테스트한 체크포인트 리비전에서 측정한 것입니다. 이는 훌륭한 상한선이지만 계획 수립 입력으로는 부족합니다. 에이전트 루프가 빠르게 느껴지는지를 결정하는 것은 드래프트 패스당 검증을 통과하는 토큰 수이기 때문입니다.

드래프터는 바로 그 지점에서만 도움을 줍니다. 위치당 32개의 후보를 가진 16토큰 블록을 제안하고, 대상 모델의 1, 20, 39, 58, 77층에서 중간 은닉 상태를 읽습니다. 즉, 64.8B 모델이 다음에 무엇을 말할지 추측하는 것이 전부인 4.04B 모델입니다. 자체 모델 카드는 조건에 대해 신중합니다. 검증은 RL-step-500 체크포인트를 대상으로 ripple-sglang 환경에서 H100 8대에서 실행되었으며, 카드에는 이것이 "다른 대상 리비전이나 런타임 버전에 대한 호환성이나 성능을 입증하지 않는다"라고 분명히 명시되어 있습니다.

7.34에 지연 예산을 세우기 전에 그 문장을 두 번 읽어 보세요. 그것은 동일 리비전, 동일 런타임에서의 측정값입니다. vLLM 병합은 런타임을 바꿉니다. 병합된 경로에 대한 수용 길이 수치는 아직 아무도 발표하지 않았는데, 그건 남의 것을 빌려오기보다 제 트래픽에서 가장 먼저 측정할 항목입니다.

다운로드에 드는 비용과 어떤 하드웨어에 적합한지

BF16 instruct 저장소는 16개 샤드에 걸쳐 129.6GB이며, safetensors 메타데이터의 총 파라미터 수는 64,782,689,360개입니다. 전부 dense이고 모든 토큰에서 전부 활성화됩니다. 활용할 수 있는 expert routing도 없고, 활성 파라미터를 품질과 맞바꿀 방법도 없습니다. 전체 정밀도 모델을 원한다면 KV 캐시에 더해 바로 그 수치만큼을 프로비저닝해야 합니다.

• 양자화 경로 — NVFP4 저장소는 39,616,865,360개의 파라미터를 저장하며, 이는 BF16 개수의 약 61%이고, 병합된 레시피는 단일 B300에서 이를 기본값으로 사용합니다.

• 드래프트 경로 — DFlash2를 활성화하면 4.04B 파라미터와 두 번째 KV 경로가 추가됩니다. 레시피에서는 이를 기본값이 아닌 선택 사항으로 남겨 둡니다.

• 단일 워크스테이션 주장 — Ricursive는 이 모델이 NVIDIA DGX Spark에 들어간다고 말하며, 커뮤니티 보고에서는 ROCm 7.2.1 환경의 Radeon AI PRO R9700 카드 세 장에서 실행된다고 합니다. 둘 다 양자화된 체크포인트 기준으로는 신뢰할 만하지만, 어느 쪽도 제가 서비스 수준으로 인용할 만한 처리량 수치를 제시하지는 않습니다.

• 병렬성 — 이 병합은 텐서 병렬, 파이프라인 병렬, torch.compile 및 CUDA 그래프를 명시적으로 내세우며, 이것이 65B dense 모델의 멀티 GPU 서빙을 바람이 아닌 실용적인 것으로 만든다. Dense 모델은 깔끔하게 분할되며, 4개의 80GB 카드에 걸친 65B는 BF16에서 편안한 tensor-parallel-4 배치이다.

컨텍스트 창은 여전히 세 가지 서로 다른 숫자입니다.

이것은 해결되지 않은 항목이며, 엔진 문제가 아니라 서빙 구성 문제이기 때문에 병합에서 그대로 남아 있었습니다.

모델 카드는 "최대 1M 컨텍스트 길이"를 광고하며, 구성은 그보다 훨씬 더 큰 위치를 지원합니다. 장문 컨텍스트 학습 단계에서는 2M 토큰 시퀀스를 사용했습니다. 이번 주에 게시된 상업용 목록은 128K 컨텍스트 창을 헤드라인으로 내세우고 사양 사이드바에서도 128K를 반복하지만, 같은 페이지의 모델 카드 섹션에는 "최대 1,048,576 토큰의 컨텍스트 길이"라고 적혀 있습니다. 출시 당시 이 모델을 탑재한 첫 호스팅 엔드포인트는 16,384를 제공했습니다.

세 개의 숫자, 하나의 체크포인트. 가장 그럴듯한 설명은 별다를 것 없다. 1M 수치는 아키텍처와 가중치가 할 수 있는 일을 설명하고, 더 작은 수치들은 특정 서빙 배포가 구성되고 검증된 범위를 설명한다. 이는 정상적인 격차다. 또한 이 격차는 모델이 저장소 규모 에이전트 작업에 사용 가능한지를 결정하는 격차이기도 하다. 16K 창은 큰 diff와 그 테스트 출력을 담을 수 없고, 128K 창은 대략 하나를 담을 수 있기 때문이다.

Ripple-65B Preview를 에이전트 코딩용으로 평가하고 있다면, 컨텍스트 수치를 모델의 속성이 아니라 엔드포인트의 속성으로 간주하고 엔드포인트를 테스트하세요. vLLM 레시피에서 직접 설정할 수 있습니다.

이로써 라우팅 결정은 어떻게 되는가

이 중 어느 것도 선택의 형태를 바꾸지 않으며, 다만 그 선택에 이르는 실행 가능한 경로의 수만 바꿀 뿐입니다. 이제 공식 레시피를 사용해 vLLM에서 모델을 직접 실행하거나, 입력 100만 토큰당 약 $0.20, 출력 100만 토큰당 $0.60에 호스팅 엔드포인트를 호출할 수 있으며, 캐시된 입력은 그 일부 비용으로 청구됩니다. 이들은 동일한 가중치를 가진 서로 다른 제품입니다. 하나는 컨텍스트 창과 청구서를 통제할 수 있게 해주고, 다른 하나는 신용카드와 남의 대기열을 건네줍니다.

OrcaRouter는 Ripple-65B Preview를 제공하지 않습니다. 카탈로그는 200개 이상의 모델이며 이 모델은 그중 하나가 아닙니다. 이를 다르게 암시하기보다 분명히 말하는 편이 좋습니다. 실제로 이것이 의미하는 바는, 이 모델을 살펴보는 이유가 저렴하고 개방적이라는 점이라면 실제로 필요한 비교는 동일한 키로 접근할 수 있는 대상과 해야 한다는 것입니다. DeepSeek V4 Pro는 1M 컨텍스트와 384K 최대 출력으로 백만 토큰당 $0.66 및 $1.98입니다. Kimi K3.1 Pro는 1M 컨텍스트와 943K 출력 상한으로 $2.00 및 $10.00입니다. 이 두 모델을 자동 장애 조치와 함께 하나의 엔드포인트로 실행하는 부분은 저희가 맡아 드릴 수 있는 스택의 일부입니다. Ripple 쪽은 직접 호스팅하거나 구매하시면 됩니다.

무엇이 여전히 공급업체 보고 사항이고, 외부인이 발견한 것은 무엇인가

이 모델에 붙은 모든 성능 수치는 Ricursive에서 나온 것입니다. 80.52의 Terminal-Bench 2.1이 대표 수치이며, 카드에는 Terminus 2에서 80.5, SWE-bench Verified에서 76.5, SWE-bench Pro v1.0에서 61.42, SWE-bench Pro v2.0 Hard에서 79.1, DeepSWE 1.1에서 44.3, SciCode에서 39.4, MCP Atlas에서 71.67도 함께 표기되어 있습니다. 이 중 어느 것도 독립 연구소에서 재현되지 않았고, Artificial Analysis에는 이 모델에 대한 항목이 없습니다. 제가 시도한 모든 Ripple 슬러그에 대해 해당 모델 디렉터리가 404를 반환하는데, 이것이 외부에서 보이는 '미채점'의 모습입니다.

존재하는 유일한 독립적 신호는 반대 방향을 가리키며, 정확히 명시할 가치가 있다. Cold Iron이라는 157개 테스트 모음은 이 모델에 157점 만점에 93점을 주었고, 28개 중 28위로, 바로 위 항목보다 5점 뒤진 순위에 올렸다. 작성자 자신의 분석은 순위보다 더 흥미롭다. 64개 실패 중 12개는 토큰을 전혀 반환하지 않은 제공자 타임아웃이었고, 49개는 finish=length였다. 즉 모델은 채점 가능한 답변을 내놓기 전에 4,096토큰 출력 예산을 소진했다. 내용 누락은 단 세 건이었다. 타임아웃을 인정해 주면 105점으로 올라가지만, 여전히 약 26위다.

그것은 역량만큼이나 서빙 구성에 관한 결과이며, 검증된 레시피를 갖춘 네이티브 엔진 지원이 줄여야 하는 바로 그 부류의 실패입니다. 코딩 작업에서 4K 출력 상한을 소진하는 모델은 잘못 실행되고 있는 모델이지, 반드시 코딩을 못하는 모델은 아닙니다.

다음에 볼 콘텐츠

추가 보도보다 이 모델에 대한 결론을 더 빨리 내리게 할 세 가지가 있다. 독립적인 점수 — Artificial Analysis나 LMArena가 이를 다루기 시작하는 순간, 벤더 표는 인용할 수 있는 표가 아니라 검증할 수 있는 표가 된다. SGLang 쪽의 머지 — 이는 단일 엔진 상황을 끝낼 것이다. 그리고 이름에 "Preview"가 들어가지 않은 체크포인트 — Ricursive가 이번 릴리스를 의도적으로 가볍게 포스트트레이닝했다고 설명했고, 실제 내부 제품은 칩 설계 변형이기 때문이다.

그때까지, 이번 주에 대한 정직한 요약은 범위가 좁지만 유용합니다. 서빙 이야기는 36시간 만에 실질적으로 개선되었고, 역량 이야기는 전혀 바뀌지 않았으며, 컨텍스트 윈도우 문제는 모델 카드에서 당신의 구성 파일로 옮겨갔습니다.