離大譜，向 vLLM 提交虛假PR，給簡(jiǎn)歷注水，被拉出在全世界面前示眾

vllm剛剛發(fā)了一個(gè)推：

vLLM官方還把這個(gè)專(zhuān)門(mén)鉆空子的培訓(xùn)機(jī)構(gòu)的小紅書(shū)拉出來(lái)做了英文翻譯

全世界面前丟人現(xiàn)眼了

我也湊熱鬧去看了小紅書(shū)，發(fā)現(xiàn)好幾個(gè)和我一樣看樂(lè)子的兄弟留言了

看之前的評(píng)論區(qū)，更多的是——這是一門(mén)生意

投機(jī)取巧，丟人顯眼那種

我順著 PR 鏈接進(jìn)去仔細(xì)扒了一遍，從標(biāo)題到 commit，從描述到測(cè)試方案，越看越離譜

PR 看起來(lái)「專(zhuān)業(yè)到不行」

先說(shuō) PR 標(biāo)題：

? fix(eagle3): read norm_before_fc from eagle_config for NVIDIA checkpoint

修一個(gè) Eagle3 投機(jī)解碼在加載 NVIDIA 官方 GPT-OSS 系列 checkpoint 時(shí)，norm_before_fc 這個(gè)字段被藏在嵌套字典 eagle_config 里讀不到的問(wèn)題，導(dǎo)致 RMSNorm 被靜默跳過(guò)、接受率下降

光看標(biāo)題就讓人覺(jué)得：這哥們兒對(duì) vLLM v1 worker 里的 speculative decoding 模塊門(mén)兒清，還順手幫 NVIDIA 兜底，妥妥的核心貢獻(xiàn)者氣質(zhì)

正文 Purpose 寫(xiě)得頭頭是道：

• 明確指出問(wèn)題：NVIDIA 的 Eagle3 checkpoint 把 norm_before_fc 塞在嵌套的 eagle_config 字典里，vLLM 只讀了頂層字段

• 修復(fù)方案：先從 eagle_config 讀，讀不到再 fallback 到頂層 attr

• 給了對(duì)照：「Same pattern already used for use_aux_hidden_state in the same block」——還知道仿照已有同模式，專(zhuān)業(yè)感拉滿

PR 的 Test Plan 直接貼了三段 Python 腳本，分別做：

1. 正確性測(cè)試 ：貪心解碼對(duì)比 baseline 和 eagle3 輸出是否一致

2. 性能測(cè)試 ：?jiǎn)?request 512 tokens 解碼，對(duì)比 baseline 和 eagle3 的 tok/s，輸出 speedup

3. 單元測(cè)試 ：手動(dòng)構(gòu)造 mock config，驗(yàn)證兩個(gè)分支都能正確讀取 norm_before_fc

結(jié)尾還來(lái)一句：「Tested with Qwen3-32B + Qwen3-32B_eagle3 on 1x H200」

H200！H200 啊老鐵們，整套下來(lái)300萬(wàn)的機(jī)器

測(cè)試結(jié)果也寫(xiě)得明明白白：

• Correctness: 4/4 greedy 輸出一致

• 性能：baseline xx tok/s → eagle3 xx tok/s

正常 reviewer 看到這個(gè) PR，心里想的是：「問(wèn)題清晰、修復(fù)點(diǎn)小、測(cè)試齊全、還在大模型上跑過(guò)——閉眼合」

事實(shí)上，PR 最后真的就被合了，63 項(xiàng) CI 全綠，benchislett 直接打了 ready 標(biāo)簽 merge 進(jìn) main

為啥 vLLM 又把人 ban 了

PR 都合了，結(jié)果社區(qū)有人舉報(bào)：這個(gè) PR 解決的根本是個(gè)不存在的問(wèn)題

什么意思呢？

NVIDIA 那批 Eagle3 checkpoint 實(shí)際跑的時(shí)候根本沒(méi)有這個(gè) bug——norm_before_fc 該讀到的地方都讀到了。所謂「RMSNorm 被靜默跳過(guò)、接受率下降」是這哥們兒憑空想象出來(lái)的，目的就是制造一個(gè)看起來(lái)很專(zhuān)業(yè)、很硬核、但其實(shí)改了等于沒(méi)改的 PR

為啥要這么做？答案就藏在 vLLM 公告里那六個(gè)字——「PR training」workflow for resume building

簡(jiǎn)歷注水流水線

套路拆解

我順手翻了下作者的 GitHub 個(gè)人頁(yè)，自稱(chēng)是 ZTE（中興通訊）的工程師，做國(guó)產(chǎn) NPU 推理引擎，從編譯到運(yùn)行時(shí)全棧

但是真要去給 vLLM、PyTorch、SGLang 這種頂級(jí)開(kāi)源項(xiàng)目修真問(wèn)題，門(mén)檻極高：

• 得讀懂幾十萬(wàn)行 C++/CUDA/Python 代碼

• 得復(fù)現(xiàn)真實(shí) bug，給出最小可復(fù)現(xiàn)樣例

• 得跑得起多卡集群驗(yàn)證

這門(mén)檻對(duì)絕大多數(shù)人都不友好，但「把簡(jiǎn)歷寫(xiě)上『vLLM core contributor，merged PR 』」這件事，對(duì)找工作（尤其是出海大模型崗）極具誘惑

于是這門(mén)生意就來(lái)了：

1. 培訓(xùn)機(jī)構(gòu)教你怎么扒 vLLM 的代碼模式

2. 找一處不痛不癢的邏輯分支，偽裝成 bug

3. 用 AI 寫(xiě)一段看起來(lái)很專(zhuān)業(yè)的 Purpose + Test Plan

4. 聲稱(chēng)在 H200 / 8×A100 上跑過(guò) （反正 reviewer 沒(méi)法驗(yàn)證）

5. 等合并，截圖發(fā)朋友圈，寫(xiě)進(jìn)簡(jiǎn)歷

低成本、低風(fēng)險(xiǎn)、高回報(bào)——直到撞上 vLLM 這種頂級(jí)項(xiàng)目的人肉舉報(bào)

這件事的離譜之處

vLLM 這次發(fā)飆的真正原因，不是「合了一個(gè)錯(cuò) PR」（畢竟 PR 真錯(cuò)了 revert 就行），而是：

? AI coding agents 讓大批量低質(zhì)量 PR 的生成成本無(wú)限趨近于 0，維護(hù)者卻要花真金白銀的時(shí)間去 review

一個(gè) PR review 哪怕只花 maintainer 半小時(shí)，幾百個(gè)這種「PR training 學(xué)員」一起沖，整個(gè)核心團(tuán)隊(duì)就被廢了

更狠的一個(gè)數(shù)據(jù)：vLLM 現(xiàn)在每個(gè)月收到的 PR 已經(jīng)過(guò)千，社區(qū)還在以指數(shù)增長(zhǎng)

所以這次 vLLM 不僅把人 ban 了，還順手掛出小紅書(shū)的英文翻譯——等于把整個(gè)產(chǎn)業(yè)鏈曝光給全世界看

給同行提個(gè)醒

這事兒對(duì)國(guó)內(nèi)開(kāi)發(fā)者的殺傷其實(shí)挺大的：

• 簡(jiǎn)歷上寫(xiě)過(guò)開(kāi)源 contribution 的，未來(lái)招聘方會(huì)按圖索驥去驗(yàn)證

• 頂級(jí)項(xiàng)目對(duì)中文社區(qū)貢獻(xiàn)者的信任度，被這幫人拉低了一檔

• 真有心做開(kāi)源的同學(xué)，提 PR 反而會(huì)被懷疑「是不是又來(lái)注水的」

我自己也用 AI coding agent 干活，Claude Code、Codex、Cursor 切著用，效率確實(shí)是過(guò)去的幾倍

但 AI 是放大器，放大你的真實(shí)能力，也放大你的水貨含量

把 AI 當(dāng)工具，去解決你真正遇到的問(wèn)題，那是生產(chǎn)力革命

把 AI 當(dāng) PR 生成器，去騙簡(jiǎn)歷騙 offer，那是把整個(gè)開(kāi)源生態(tài)的信任資產(chǎn)燒給你自己取暖