ghfind, 자사 GitHub 로스트 뒤에 MiniCPM-V 4.7을 배치했다 — 그리고 자사 문서는 그것이 무엇을 바꾸는지에 대해 엇갈린다

ghfind.com의 맨 아래로 스크롤하면 예전에는 없던 작은 문구가 있습니다: 모델 스폰서, MiniCPM 마크, 그리고 modelbest.cn으로 나가는 링크입니다. 그 마크 뒤에 있는 모델은 2026년 10월 12일 OpenBMB가 공개한 비전-언어 모델 MiniCPM-V 4.7입니다. 모든 GitHub 계정에 대해 재현 가능한 0–100 "가치와 신뢰" 점수를 제공하는 것이 제품의 핵심 제안인 만큼, 모델 스폰서십은 겉치레용 세부 사항이 아닙니다 — 그것은 그 모델이 무엇에 손댈 수 있도록 허용되는지에 대한 문제입니다. 그리고 ghfind 자체 문서는 그 질문에 서로 다른 두 가지 답을 내놓습니다. 이와 같은 릴리스와 관련해 문서화된 AI 실패 및 에이전트 사건은 OrcaRouter AI Incident Archive에 수집되어 있으며, 각 항목에는 자체 출처, 심각도, 신뢰도 등급 및 이의 제기 플래그가 포함됩니다.

그것이 쓸 가치가 있는 이야기다. 왜냐하면 표면적인 버전인 "GitHub를 조롱하는 사이트가 모델을 바꿨다"는 보도자료일 뿐이기 때문이다. 그 밑에 깔린 이야기는, 자신의 숫자가 단순한 느낌이 아니라는 점을 사람들에게 납득시켜야 하면서 동시에 언어 모델을 도입하는 스코어링 제품에 관한 것이다.

페이지가 실제로 보여주는 것, 그리고 보여주지 않는 것

스폰서십 스트립은 실제로 존재하며 공개 영어 홈페이지에서 눈에 띕니다. 그것은 다른 두 개의 컨트롤 옆에 자리합니다. 자체 모델 / API 키 사용 옵션과, 여기에 로고를 넣으세요라고 표시된 빈 로고 슬롯입니다. 따라서 ghfind가 광고하는 구조는 "우리 모델, 필수"가 아니라 기본 스폰서에 자체 키를 가져오는 탈출구를 더한 것입니다. 이는 모든 로스팅에 모델 크레딧을 소모하는 제품에 합리적인 설계입니다.

이 변경에 대해 반복되는 세 가지는 페이지에 없습니다. 첫째, ghfind는 사이트 어디에도 트래픽 수치를 게시하지 않으므로, 일일 방문 수를 나타내는 어떤 숫자든 ghfind가 아닌 다른 곳에서 나온 것입니다. 둘째, "main model"이라는 표현은 ghfind의 것이 아닙니다 — 페이지에는 모델 스폰서라고 적혀 있습니다. 셋째, 가장 유용한 점은, 오픈소스 저장소가 여전히 완전히 다른 기본값을 제공한다는 것입니다: 해당 .env.example 파일은 roast LLM을 StepFun의 step-3.7-flash에 맞춰 구성하며, 기본 제공자가 텍스트가 스트리밍되기 전에 중단되거나 속도 제한을 적용하는 경우를 대비한 D​eepSeek 폴백이 있습니다. ghfind를 소스에서 자체 호스팅하는 사람은 MiniCPM 엔드포인트가 아니라 그 구성을 받게 됩니다.

그래서 정확한 진술은 범위가 좁고, 넓은 진술보다 더 흥미롭습니다. 호스팅 제품에서는 MiniCPM이 이름이 명시된 모델 스폰서입니다. 오픈 코드에서는 기본값이 아닙니다. 이는 서로 다른 주장이며, 독자가 볼 수 있는 것으로 뒷받침되는 것은 첫 번째뿐입니다.

모델보다 먼저인 제품

ghfind는 Next.js 애플리케이션이며 AGPL-3.0 라이선스이고, GitHub에서 약 260개의 스타를 받았으며, 이 글을 쓴 그 주에도 계속 푸시가 이뤄졌습니다. 그 핵심은 전혀 LLM이 아닙니다. 결정론적 TypeScript 엔진은 — github-account-value라는 오픈소스 Python 스킬에서 한 줄씩 포팅되었고, 두 구현을 서로 묶어 고정하는 패리티 테스트가 함께합니다 — 공개 GitHub 데이터를 읽어 여섯 가지 가중 차원에 걸친 점수를 산출합니다. 계정 성숙도, 원본 프로젝트 품질, 기여 품질, 생태계 영향력, 커뮤니티 영향력, 활동 진위성입니다. 여기서 파밍 행위를 나타내는 10가지 위험 신호가 점수에서 차감되는데, 위조하는 데 비용이 많이 드는 신호, 예컨대 계정이 소유하지 않은 저장소에 병합된 풀 리퀘스트 쪽에 가중치를 두고, 스타나 팔로워처럼 사기 쉬운 신호 쪽은 가중치를 낮춥니다.

그 설계의 핵심은 감사 가능성입니다. 동일한 GitHub 계정과 동일한 수집 날짜가 주어지면, 그 숫자는 모든 사람에게 매번 같은 숫자여야 합니다. 바로 그 점이 점수를 이슈 큐 분류 같은 용도에 쓸 수 있게 해 줍니다. ghfind도 작성자의 밴드로 들어오는 이슈에 라벨을 붙이는 GitHub App을 통해 그렇게 합니다.

모델이 개입하는 지점은 다운스트림입니다. 고정된 결과를 로스팅 문구, 태그 세트, 서면 리포트로 바꾸는 것이죠. 바로 이 부분이 사용자들이 스크린샷을 찍어 공유하는 부분이며, 스폰서십이 자연스럽게 붙을 수 있는 부분입니다.

주목할 만한 모순

여기에서 두 문서가 갈라집니다.

저장소 README는 두 개로 분리된 LLM 패스를 설명합니다: 사실 심사자는 제한된 ±10 보정을 적용할 수 있고, 그다음 작성자는 고정된 결과를 태그, 최고의 독설 문구, 보고서로 바꿉니다. 작성자는 점수를 변경할 수 없습니다. 그 문장을 두 번 읽어 보세요. 작성자는 명시적으로 숫자를 움직이는 것이 금지되어 있고, 심사자는 최대 10점까지 숫자를 움직이는 것이 명시적으로 허용됩니다 — 100점 척도에서 그것은 전체 범위의 10분의 1입니다.

사이트 자체의 llms.txt는 에이전트와 기계를 위해 작성되었으며, 더 강한 주장을 합니다: 완전히 결정론적인 엔진 … 동일한 입력은 항상 동일한 점수를 산출하며, 어떤 LLM도 그 숫자에 관여하지 않습니다.

둘 다 동시에 참일 수는 없다. 판정 패스가 기본 경로에 존재하고 ±10 경계가 실제라면, 그 경우 점수는 모델에 따라 달라지는 보정을 제외하면 결정적이다 — 아니면 판정기가 기본 경로에 없고 README가 선택적 모드를 설명하고 있는 것이다. 논쟁의 여지가 없는 것은 저장소 자체의 텍스트는 모델이 그 숫자에 제한된 영향력을 갖는 것을 상정하는 반면, 공개용 기계 판독 설명은 그러한 영향력이 없다고 말한다는 점이다.

이것은 덜이 아니라 더 중요하다. 이제 한 모델 스폰서가 페이지에 명시되어 있기 때문이다. 어떤 모델이 점수를 10점이나 움직일 수 있다면, 어떤 모델이 심사를 맡고 있는지는 사용자가 물을 권리가 있는 질문이다 — 누군가 부정행위를 하고 있어서가 아니라, 재현성 주장은 문서화된 가장 약한 예외만큼만 강하기 때문이다. 방법론 페이지를 공개하는 제품은 독자에게 두 설명 중 어느 것이 현재의 것인지 확정해 주는 한 문장을 제공해야 한다.

텍스트 제품인데 왜 비전 모델일까

GitHub 점수 산정 사이트에 멀티모달 모델을 선택한 것은 모델이 실제로 무엇을 받는지 보기 전까지는 이상해 보인다. {{1}}MiniCPM-V 4.7{{/1}}은 저장소를 읽으라는 요청을 받는 것이 아니라 프롬프트를 읽으라는 요청을 받는다. {{2}}비전-언어 모델{{/2}}은 점점 더 저렴한 범용 판정자로 사용되는데, 이는 인터리브된 입력으로 훈련되어 구조화된 출력 지시를 잘 따르는 경향이 있고, 스크린샷도 받아들일 수 있는 단일 모델이 사용자가 지원 흐름에 프로필 캡처를 붙여넣는 순간 유용하기 때문이다.

비용 논리도 있습니다. 35B-A3B 변형은 256개 전문가 mixture에서 토큰당 약 30억 개의 파라미터를 활성화하며, 1B 변형은 휴대폰에서 실행할 수 있을 만큼 작은 dense 모델입니다. 모든 프로필 스캔마다 로스트 패스가 실행되는 제품에서, 저렴하게 서빙하거나 직접 실행할 수 있는 모델은 로스트당 프런티어 API를 호출하는 것과는 다른 경제적 제안입니다. 이 사이트가 bring-your-own-key 경로를 제공하는 이유도 같습니다. 모델 비용은 트래픽에 따라 늘어나고, 트래픽은 바로 스코어링 사이트가 키우려는 대상이기 때문입니다.

그런 종류의 파이프라인을 직접 구축하고 있다면 — 결정론적 코어 위에 모델 기반 내레이션 계층을 얹은 구조라면 — 운영상의 질문은 키를 몇 개의 제공업체에 대해 보유하고 싶은가입니다. OrcaRouter 는 200개가 넘는 호스팅 모델을 0% 마크업으로 하나의 OpenAI 호환 엔드포인트 뒤에 배치하며, 각 제공업체의 정가를 그대로 전달하고 제공업체 성능이 저하되면 자동 페일오버가 작동합니다. 라우팅 DSL은 한 번의 호출 안에서 저렴한 judge 패스와 더 비싼 writer 패스를 서로 다른 모델로 보낼 수 있습니다. 한 가지 솔직한 한계: MiniCPM-V 4.7은 저희 카탈로그에 없으므로, 그것이 원하는 모델이라면 OpenBMB 자체 플랫폼에서 받으셔야 합니다. 라우터는 스폰서 엔드포인트 하나만이 텅 빈 로스팅 박스와 여러분 사이를 가르는 유일한 것일 때 폴백 경로를 따뜻하게 유지해 주는 부분입니다.

이번 주 기준, MiniCPM-V 4.7이 실제로 무엇인지

모델 쪽도 같은 정밀성을 기대할 만하다. OpenBMB의 저장소에는 2026-10-12자 News 항목이 “MiniCPM-V 4.7 출시”라고 적혀 있으며, Hugging Face 저장소는 그 직전 며칠에 만들어졌다 — 1B는 10월 6일, 35B-A3B는 10월 7일 — 이는 단계적 가중치 업로드의 양상이다. 이어서 모델 카드가 나왔다. 2026-10-15의 두 번째 News 항목은 두 크기 모두에 대해 BF16 및 GGUF의 DSpark 추측 디코딩 헤드를 발표했다.

• 크기 — 총 매개변수 352.1억 개인 35B-A3B 희소 전문가 혼합, 그리고 15.5억 개인 1B 밀집 변형

• 라이선스 — 둘 다 Apache 2.0, 가중치 다운로드 가능, 게이트 없음

• 컨텍스트 — 두 가지 변형 모두 262,144 토큰

• 아키텍처 — 35B에서 토큰당 8개가 활성화되는 256개 전문가; 40개 레이어 전반에 걸친 3:1 선형 대 전체 어텐션 패턴; 980픽셀 입력 타일을 사용하는 1152 히든 폭의 비전 타워

• 양자화 — GGUF, bitsandbytes, AWQ, GPTQ, FP8 및 int4 빌드가 BF16 가중치와 함께 공개됩니다

• 서빙 — SGLang, vLLM, llama.cpp 및 Ollama가 지원 대상으로 나열됨; Ollama에는 자사 제공 항목이 있음

• 공급업체 주장 — iPhone 17 Pro Max에서 약 3GB 메모리로 초당 13개 이상의 토큰, 그리고 Lookahead Expert Scheduling을 통한 온디바이스 5배 속도 향상

• 배포 — 35B-A3B 저장소에서 월 약 95,000회 다운로드, 1B에서 46,000회 다운로드되었으며 좋아요는 각각 약 1,079개와 398개입니다

그 목록의 모든 항목은 카드와 구성 파일에서 확인할 수 있다. 아직 이용할 수 없는 것은 독립적 평가다. 이 글을 쓰는 현재 Artificial Analysis 모델 카탈로그에는 MiniCPM-V 4.7 변형 중 어느 것에 대한 항목도 없으므로, 초당 13토큰이라는 수치, 5배 속도 향상, 그리고 35B-A3B가 "Qwen3.6 35B-A3B보다 더 적은 추론 시간에 더 높은 종합 점수를 달성한다"는 주장은 모두 벤더가 보고한 것이며 재현되지 않았다. 이는 출시된 지 8일 된 모델로서는 정상이며, 바로 그 때문에 후원 배치를 모델 품질에 대한 신호가 아니라 ghfind의 비용 구조에 대한 신호로 봐야 한다.

아직 아무도 검증할 수 없는 부분

이것이 이 이야기의 두 절반을 다시 하나로 묶어 준다. ghfind의 신뢰성은 재현 가능하다고 주장하는 숫자에 달려 있다. MiniCPM-V 4.7의 신뢰성은 공급업체가 일주일 전에 공개한 벤치마크에 달려 있다. 이 후원은 모델이 심사자로서 어떻게 행동하는지에 관한 공개된 증거가 전혀 없이 둘을 결합한다 — 인간 평가자와의 일치율도, 모델 버전 간 드리프트 측정도, 후원자를 바꾸면 누군가의 점수가 달라질지에 대한 언급도 없다.

그것들은 모두 공개하기는 쉬운 것들이고 나중에 질문받으면 비싼 것들이다. 이것을 해결할 구체적인 측정은 재점수 테스트다: 고정된 계정 샘플을 잡고, judge pass를 활성화한 경우와 비활성화한 경우로 파이프라인을 실행한 뒤 차이의 분포를 보고하는 것이다. 차이가 0에 몰리면 ±10은 아무도 건드리지 않는 안전장치이고 "no LLM touches the number"라는 문구는 사실상 맞다. 퍼져 있으면 캘리브레이션이 실제로 일을 하고 있는 것이므로 방법론 페이지에 그렇게 명시해야 한다.

그때까지 정직한 해석은 이렇다. ghfind는 자체 수치와 산문 사이의 구분이 유난히 명확한, 잘 만들어진 결정론적 스코어러이며, 이제는 파이프라인에서의 역할이 자체 파일들마다 일관성 없이 문서화된, 이름 붙은 모델 스폰서를 두고 있다. MiniCPM-V 4.7은 8일 전 모델 카드와 DSpark 후속 자료를 갖추고 등장한, 실제로 Apache 라이선스가 적용된, 메모리 측면에서 진짜로 작은 멀티모달 릴리스이며, 독립적인 벤치마크는 없다. 이 두 사실 중 어느 것도 스캔들은 아니다. 둘 다 홈페이지 대신 리포지토리를 읽어야만 알아차리는 종류의 일이다 — 다른 사람들의 작업에 점수를 매기는 제품이라면, 독자가 할 수 있는 최소한의 일이 바로 그것이다.

구체적으로 자신의 점수를 확인하는 방법

사이트에 프로필이 있다면 테스트해야 할 것은 결정론적 경로입니다. ghfind는 인증도 모델 호출도 필요 없는 점수 엔드포인트를 제공하며, 기반이 되는 채점 스킬은 오픈 소스이므로 API에서 얻은 숫자와 사이트에서 얻은 숫자는 일치해야 합니다. 일치하지 않는다면 그 차이는 수집 시점 — 사이트는 하루 동안 캐시합니다 — 또는 보정 패스 때문이며, 이 둘은 반복 실행에서 격차가 안정적인지 확인하면 구분할 수 있습니다.

비슷한 도구를 만드는 사람이라면 누구나, ghfind에서 얻을 수 있는 아키텍처 교훈이 모델 관련 뉴스보다 더 가치 있다: 숫자는 코드에 두고, 산문은 모델에 두며, 둘 사이의 경계를 독자가 검사할 수 있을 만큼 명시적으로 만들어라. 실패 모드는 LLM을 사용하는 것이 아니다. 실패 모드는 경계를 두 곳에 문서화하고 두 설명이 서로 어긋나도록 내버려 두는 것이다.

다음에 지켜볼 사안은 좁다. ghfind는 공개 체인지로그와 거의 매일 푸시되는 저장소를 갖고 있으므로, ±10 보정을 “no LLM” 방침과 조화시키는 방법론 노트가 나온다면 금방 드러날 것이다. 모델 쪽에서는 MiniCPM-V 4.7에 대한 첫 독립 벤치마크, 또는 대량 사용 시 로스트당 비용이 얼마인지에 대한 첫 보고서가 후원을 논쟁으로 바꿔 놓을 숫자다. 둘 다 아직 존재하지 않는다. 둘 모두 발표 하나만 남겨두고 있다.