ghfind 將 MiniCPM-V 4.7 用作其 GitHub 吐槽功能的後端——而自家文件對這會改變什麼卻說法不一

Scroll to the bottom of ghfind.com and there is a small line that did not used to be there: Model sponsor, a MiniCPM mark, and a link out to modelbest.cn. The model behind that mark is MiniCPM-V 4.7, OpenBMB's vision-language release from October 12, 2026. For a product whose entire pitch is a reproducible 0–100 "value and trust" score for any GitHub account, a model sponsorship is not a cosmetic detail — it is a question about what the model is allowed to touch. And ghfind's own documentation gives two different answers to that question. The documented AI failures and agent incidents behind releases like this one are collected in the OrcaRouter AI Incident Archive where each entry carries its own sources, severity, confidence grade and disputed flag.

那才是值得寫的故事，因為表面版本——「一個 GitHub 吐槽網站換了模型」——只是新聞稿。底下的版本則關於一個評分產品，它必須讓人相信它的數字不是憑感覺，同時還得採用一個語言模型。

頁面實際顯示了什麼，以及沒有顯示什麼

這條贊助橫幅是真的，而且就公開顯示在英文首頁上。它旁邊還有另外兩個控制項：使用你自己的模型／API 金鑰選項，以及標著你的 Logo 放這裡的空白 Logo 欄位。所以 ghfind 所宣傳的架構並不是「只能用我們的模型、別無選擇」——而是預設贊助商再加上一條自備金鑰的逃生出口；對於一個每次吐槽都要消耗模型額度的產品來說，這樣的設計是合理的。

Three things that get repeated about this change are not on the page. First, ghfind publishes no traffic figure anywhere on the site, so any number describing its daily visits is coming from somewhere other than ghfind. Second, the phrase "main model" is not ghfind's — the page says Model sponsor. Third, and most usefully, the open-source repository still ships a different default entirely: its .env.example configures the roast LLM against StepFun's step-3.7-flash, with a D​eepSeek fallback for the case where the primary provider drops or rate-limits before any text streams. Anyone self-hosting ghfind from source gets that configuration, not a MiniCPM endpoint.

所以準確的說法範圍較窄，也比概括的說法更有意思：在託管產品上，MiniCPM 是具名列出的模型贊助者。在開放程式碼中，它並非預設選項。這是兩種不同的主張，而讀者所能看到的內容只支持第一種。

產品，先於模型

ghfind 是一個 Next.js 應用程式，採用 AGPL-3.0 授權，在 GitHub 上約有 260 顆星，並在撰寫本文的這一週內持續推送。它的核心完全不是 LLM。一個確定性的 TypeScript 引擎——從一個名為 github-account-value 的開源 Python 技能逐行移植而來，並以對等性測試將兩套實作鎖定在一起——會讀取公開的 GitHub 資料，並依據六個加權維度產生分數：帳號成熟度、原創專案品質、貢獻品質、生態系影響力、社群影響力與活動真實性。針對刷量行為的十項紅旗警示會從中扣分，權重偏向難以偽造的信號，例如合併進該帳號並不擁有的儲存庫的拉取請求，並遠離容易購買的信號，例如星數與追蹤者。

那個設計的重點就在於可稽核性。只要 GitHub 帳號相同、收集日期相同，這個數字就應該對每個人、每次都一樣。正因如此，分數才能用於像問題佇列分流這類用途——ghfind 也透過一個 GitHub App 做到這點，用作者所屬的分級區間為新進問題加上標籤。

模型切入的位置在下游：把固定結果轉化成一句吐槽、一組標籤和一份書面報告。這正是使用者會截圖分享的部分，也是贊助自然而然會附著的地方。

值得注意的矛盾

兩份文件正是在這裡分道揚鑣。

儲存庫的 README 描述了兩個彼此分離的 LLM 階段：事實裁判可以套用有界的 ±10 校準，接著由寫手將固定後的結果轉成標籤、最嗆的吐槽句，以及報告。寫手不能改變分數。把那句話讀兩遍。寫手被明確禁止更動這個數字，而裁判則被明確允許最多更動十分——在百分制上，那是整個範圍的十分之一。

網站自家的 llms.txt，是為代理程式與機器而寫，說得更強：一個完全確定性的引擎……相同的輸入永遠產生相同的分數；沒有任何 LLM 會碰觸那個數字。

兩者不可能同時成立。要麼 judge pass 存在於預設路徑中，且 ±10 界限是真實的；在這種情況下，分數是確定性的，唯一變數是取決於模型的校準——要麼 judge 不在預設路徑中，而 README 描述的是可選模式。沒有爭議的是，該儲存庫自身的文字設想模型對該數字具有有限影響，而對外的機器可讀描述卻說它沒有任何影響。

{{1}}這點更重要，而非更不重要，因為頁面上現在已明確點名某個模型贊助商。{{/1}} {{2}}如果某個模型能讓分數變動十分，那麼究竟是哪個模型在擔任評審，就是使用者有權提出的問題——不是因為有人在作弊，而是因為可重現性主張的強度，只取決於其最薄弱且有記錄的例外。{{/2}} {{3}}一個發布方法論頁面的產品，應向讀者交代一句話，釐清其兩種描述中哪一種才是現行版本。{{/3}}

為什麼文字產品要用視覺模型？

為 GitHub 評分網站選用多模態模型乍看之下很奇怪，直到你看到模型實際拿到的是什麼。MiniCPM-V 4.7 並非被要求閱讀儲存庫；它被要求閱讀的是一段提示詞。視覺語言模型越來越常被當作廉價的通用評審，因為它們是在交錯輸入上訓練的，且往往能很好地遵循結構化輸出指令，也因為一個同時能接受螢幕截圖的單一模型，在使用者把個人檔案截圖貼進支援流程的那一刻就很有用。

這背後還有一套成本邏輯。35B-A3B 變體在 256 個專家的混合架構中，每個 token 大約啟用三十億個參數；而 1B 變體則是稠密模型，小到可以在手機上執行。對於一個每次設定檔掃描都會觸發烘焙流程的產品來說，能低成本提供服務——或自行執行——的模型，與每次烘焙都呼叫前沿 API 相比，是截然不同的經濟命題。這也是本站提供自帶金鑰（bring-your-own-key）途徑的相同原因：模型帳單會隨流量擴增，而流量正是評分網站想要成長的東西。

如果你要自己打造那樣的流程——一個確定性的核心，上頭疊著由模型驅動的敘述層——營運上的問題就是：你想替多少家供應商保管金鑰。OrcaRouter 把 200 多個託管模型放在同一個相容 OpenAI 的端點後方，且零加成，並將各家供應商的定價直接原樣傳遞，在供應商效能退化時自動容錯切換；其路由 DSL 可以在同一次呼叫中，把便宜的評審階段與較昂貴的撰寫階段送往不同的模型。有一個必須誠實說明的限制：MiniCPM-V 4.7 不在我們的目錄中，所以如果那是你要的模型，就得去 OpenBMB 自家的平台取得。路由器就是那個在你和空蕩蕩的吐槽箱之間只剩單一贊助端點時，仍讓備援路徑保持暖機狀態的部分。

截至本週，MiniCPM-V 4.7 究竟實際上是什麼

模型端也值得同樣的精確度。OpenBMB 的儲存庫中有一則日期為 2026-10-12 的 News 條目，寫著「MiniCPM-V 4.7 released」，而 Hugging Face 儲存庫是在那之前幾天建立的——1B 版本為 10 月 6 日，35B-A3B 版本為 10 月 7 日——這正是分階段上傳權重時會出現的情況。模型卡隨後發布。2026-10-15 的第二則 News 條目宣布，兩種尺寸都推出了 BF16 與 GGUF 格式的 DSpark 推測解碼頭。

• 尺寸 — 35B-A3B 稀疏混合專家模型，總參數量達 352.1 億；以及 1B 稠密變體，參數量為 15.5 億

• 授權條款 — 兩者皆採用 Apache 2.0，權重可下載，無需申請

• 上下文 — 兩個版本皆為 262,144 個權杖

• 架構 — 35B 模型中有 256 個專家，每個 token 啟用其中 8 個；40 層採用線性注意力與全注意力 3:1 的模式；視覺塔的隱藏寬度為 1152，輸入圖塊為 980 像素

• 量化 — GGUF、bitsandbytes、AWQ、GPTQ、FP8 與 int4 版本，與 BF16 權重一同發布

• 服務 — SGLang、vLLM、llama.cpp 和 Ollama 列為支援；Ollama 有第一方項目

• 廠商宣稱——在 iPhone 17 Pro Max 上以約 3 GB 記憶體達到每秒 13+ 個 token，且透過 Lookahead Expert Scheduling 在裝置端帶來 5× 加速

• 分布——35B-A3B 儲存庫每月約有 95,000 次下載，1B 則約 46,000 次，並分別獲得約 1,079 和 398 個讚

那份清單上的每一項，都能從模型卡與設定檔核查。目前尚未取得的是獨立評估。截至本文撰寫時，Artificial Analysis 的模型目錄中，兩個 MiniCPM-V 4.7 變體都沒有收錄，因此每秒 13 個 token 的數字、5 倍加速，以及 35B-A3B「在更少推論時間內達到比 Qwen3.6 35B-A3B 更高的整體分數」的說法，全都由廠商自行回報且尚未被重現。對一個推出才八天的模型來說，這很正常；而這也是為何應把贊助版位視為有關 ghfind 成本結構的訊號，而不是有關模型品質的訊號。

還沒有人能夠驗證的那部分

這就把這個故事的兩半重新接在一起。ghfind 的可信度建立在一個它聲稱可重現的數字上。MiniCPM-V 4.7 的可信度則建立在其廠商一週前公布的基準測試上。這項贊助把兩者連結起來，卻沒有任何已公布的證據說明該模型作為評審時如何表現——沒有與人類評分者的一致率、沒有跨模型版本的漂移量測、也沒有說明若更換贊助商是否會改變任何人的分數。

那些都是發表起來便宜、日後被追問卻代價高昂的東西。真正能定案的具體量測是重新評分測試：取一組固定樣本帳戶，分別在啟用與停用評審環節的情況下跑完整流程，並回報差異的分布。如果差異集中在零，那 ±10 就是没人會觸發的安全護欄，而「沒有任何 LLM 碰過這個數字」這句話實質上成立。如果差異發散，那校準確實在發揮作用，方法論頁面就必須如實說明。

在此之前，誠實的解讀是這樣。ghfind 是一個打造精良的確定性評分器，其數字與文字說明之間有著異常清楚的分隔，而且它現在有一個具名的模型贊助者，其在流程中的角色，卻在其自家檔案中的記載並不一致。MiniCPM-V 4.7 是真實存在、以 Apache 授權、記憶體占用確實很小的多模態發布，八天前問世，附有模型卡、DSpark 後續，且沒有獨立基準測試。這兩件事都不是醜聞。兩者都是唯有當你讀的是儲存庫而非首頁時才會注意到的事——對於一個替他人作品評分的產品而言，這已是讀者所能做的最低限度。

具體來說，如何查看自己的分數

如果你在該網站上有個人檔案，要測試的就是確定性路徑。ghfind 提供一個分數端點，不需要身分驗證，也不需要呼叫模型，而且底層的評分技能是開源的，因此你從 API 取得的數字與從網站取得的數字應該要一致。如果不一致，差異不是來自蒐集時機——網站會快取一天——就是來自校準流程；而要區分這兩者，可以問：這個差距在重複執行時是否穩定。

對於任何正在打造類似工具的人而言，ghfind 的架構教訓比模型新聞更有價值：把數字留在程式碼中，把文字描述留在模型中，並讓兩者之間的界線明確到讀者可以檢視。失敗模式不是使用 LLM。失敗模式是在兩個地方記錄這條界線，並讓這兩種描述逐漸漂移。

接下來值得關注的範圍很窄。ghfind 有公開的更新日誌，還有一個幾乎每天都有推送的儲存庫，所以一份能調和 ±10 校準與「不用 LLM」這條說法的方法論說明，很快就會浮上檯面。在模型這一側，MiniCPM-V 4.7 的第一份獨立基準測試——或者第一份說明它在規模化烘焙下每鍋成本多少的報告——才是能把一筆贊助變成爭論的那個數字。兩者目前都還不存在。兩者都只差一次發表。