第一章底層基石 —— 主流大模型分詞器詳解1.1 為什么分詞器對LLM推理很重要模型只能處理數字文本必須先經過 Tokenizer 轉化為 Token ID 序列。原始文本 “Hello, world!” → Tokenizer 切分 編碼 → Token IDs [15496, 995, 0] → Embedding 向量查表 → 語言模型 Transformer有三種切分粒度字符級、詞級、子詞級?，F在的llm都用的子詞級字符級詞表極小但是序列極長、并且字符本身沒有語義詞級序列最短但是詞表巨大并且新詞是UNK。理想的Tokenizer要滿足三個目標零 UNK 覆蓋率不要出現[UNK]高壓縮率 token盡量少多語言公平性避免中文幾個字就消耗大量token而英文同樣語義只消耗很少token。分詞器直接決定 token 序列長短token 越多上下文窗口消耗越大KV?Cache 占用的顯存就越高出現[UNK]會丟失原始文本信息而后面 vLLM 的約束解碼能力更是完全運行在 token 粒度之上。理解分詞算法是看懂 LLM 推理底層邏輯的第一步。1.2 BPE 原始算法BPEByte?Pair Encoding字節(jié)對編碼最早并不是為大模型發(fā)明的它是一種無損數據壓縮算法后來被引入NLP領域做子詞分詞。核心思想自底向上貪心合并先把訓練集全部文本按空格切分成獨立單詞再把每個單詞拆解成最基礎的字符序列。統(tǒng)計所有相鄰字符對的出現頻次。選出出現頻率最高的字符對合并成一個新子詞單元加入詞表。重復上面統(tǒng)計?合并的過程直到詞表達到預設大小。??關鍵前置約束原始BPE必須依賴空格預先切分單詞單詞邊界是提前確定好的算法本身不會處理句子。優(yōu)勢實現簡單訓練、編碼解碼速度快高頻片段會被合并為完整token取得不錯的壓縮效果子詞由訓練數據統(tǒng)計得來貼合真實文本分布。劣勢強依賴預分詞需要依靠空格切分單詞對中文、日文這類沒有天然空格分隔的語言處理很麻煩。存在OOV/UNK問題遇到訓練中從未見過的生僻字符、特殊Unicode符號比如這個表情如果詞表里沒有對應單元就只能輸出未知token[UNK]丟失信息。單詞邊界被固化切分行為高度依賴預分詞結果預分詞出錯后續(xù)BPE合并結果也跟著出錯。早期部分開源模型使用原始BPE現在生成式大模型基本不再直接使用它更多是作為BBPE的理論原型。1.3 BBPEByte?Level BPE字節(jié)級BPEBPE的缺陷Unicode 覆蓋不完全。邊緣字符仍出現UNK詞表大小爆炸。多語言模型要覆蓋所有的字符難以管理新 emoji 在部署后會出現UNKUnicode字符不管是中文、日文、emoji還是生僻符號最終都能編碼成1~4個UTF?8字節(jié)。而字節(jié)總共只有256種可能全部在初始詞表里。BBPE就是在BPE的基礎上把初始詞表換成了256字節(jié)值。實現了零UNK。比如說同樣語義的問候語英文hello占 5 個 UTF?8 字節(jié)中文你好占 6 個 UTF?8 字節(jié)阿拉伯語問候則要 10 個 UTF?8 字節(jié)BBPE 會直接在這些原始字節(jié)之上執(zhí)行 BPE 合并操作。1.4 WordPieceBPE、BBPE都是按共現頻次選擇子詞對進行合并而WordPiece走了另一條路線它不再看單純出現次數而是以最大化訓練集語言模型似然概率作為合并判斷標準由Google提出最知名使用者就是BERT系列編碼器模型。WordPiece使用打分公式score(A,B)freq(AB)freq(A)×freq(B)score(A,B)\frac{freq(AB)}{freq(A) \times freq(B)}score(A,B)freq(A)×freq(B)freq(AB)?分子越大AB 常見分母越小A、B 單獨罕見說明合并這對更能減少不確定性。1.5 SentencePieceBPE / WordPiece 需要先按空格/標點預切分文本預分詞步驟這一步依賴語言規(guī)則中文無空格。SentencePiece的做法是把空格替換為特殊字符 ▁U2581文本變成純字符流。算法直接在原始 Unicode 上運行不需要任何語言特定預處理。比如輸入“我 like 大模型”子詞切分結果示例[我, ▁like, ▁大, 模型]1.6 UnigramBPE 從小詞表出發(fā)不斷合并自下而上Unigram 從大詞表出發(fā)不斷剪枝自上而下核心思想是優(yōu)先刪掉那些刪掉之后整體效果幾乎沒怎么變壞的子詞。1.7 分詞算法橫向對比小結bbpe分詞方法現在是主流。對比維度BPE(Sennrich原版)BBPE(字節(jié)級BPE)WordPieceUnigram初始詞表字符256字節(jié)字符大詞表剪枝合并策略頻次最大頻次最大似然最大EM 剪枝UNK風險極低存在UNK零UNK極低極低存在UNK分詞確定性確定確定確定可概率化多語言友好中高中高第二章KV Cache——vLLM高吞吐背后的底層根基2.1 推理性能的關鍵指標指標全稱含義參考標準/說明TTFTTime to First Token從發(fā)送請求到收到第一個token的時間 500ms 為優(yōu)秀影響用戶體驗感知TPOTTime Per Output TokenDecode階段每生成一個token的平均耗時 50ms 流暢體驗Throughput系統(tǒng)吞吐量單位時間內處理的總token數所有并發(fā)請求之和高并發(fā)部署核心指標單位token/sMFUModel FLOPs UtilizationGPU實際算力利用率 vs 峰值算力Decode通常 20%Prefill可達40%核心矛盾低延遲 / 高吞吐 / 低顯存三者難以同時最優(yōu) —— 推理優(yōu)化的本質是在三角約束中找最佳平衡點。2.2 LLM自回歸推理兩個階段Prefill 和 Decode推理的流程是這樣Prefill 階段處理 prompt輸入整段 promptn 個 token一次性進入模型計算對所有 n 個位置并行做 Attention輸出下一個 token 的概率分布特點算力密集compute-boundDecode 階段逐 token 生成輸入上一步生成的 1 個 token計算對當前位置做 Attention看前面所有 token輸出下一個 token循環(huán)到 EOS特點訪存密集memory-bound2.3 樸素推理的致命冗余每一步重復計算K/V樸素推理過程把已有的 t 個 token 重新輸入模型每一層都重新計算所有 t 個位置的 Q、K、V做完整 Attention取最后一個位置的輸出代價前 t-1 個位置的 K、V 在上一步早就算過這一步又算了一遍 → 純粹浪費2.4 KV Cache引入的問題問題類型具體表現產生原因影響顯存壓力巨大KV Cache占用隨序列長度線性增長長上下文/高并發(fā)場景下顯存占用甚至超過模型權重每個請求都需要存儲全部歷史token的K、V向量顯存成為推理瓶頸限制并發(fā)數和上下文長度內部碎片按max_seq_len預分配連續(xù)顯存但實際生成長度遠小于最大值大量空間閑置傳統(tǒng)實現為每個請求預留最大長度的連續(xù)內存塊顯存利用率低實際情況可能浪費一半的顯存調度低效靜態(tài)Batch一批請求必須全部生成結束才統(tǒng)一釋放KV緩存短請求完成后原地等待長請求傳統(tǒng)靜態(tài)批處理同進同出的調度機制GPU算力大量空轉閑置吞吐量上不去2.5 vLLM如何改造KV CachePagedAttention 分頁注意力復刻OS虛擬內存分頁機制不再連續(xù)分配一整塊的顯存。先把顯存按size劃分在需要用到顯存的時候按需分配顯存塊。2.6 Continuous Batching 連續(xù)批處理一個token生成后立刻開始運行新的請求2.7 本章小結KV Cache解決自回歸重復計算問題是LLM推理基礎但原生連續(xù)分配靜態(tài)批處理帶來嚴重碎片、低利用率、調度低效PagedAttention借鑒OS虛擬內存分頁解決顯存碎片、利用率、前綴緩存復用拉高并發(fā)上限Continuous Batching借鑒OS搶占式調度解決GPU算力空轉拉高整體吞吐量一句話分工PagedAttention負責省顯存讓更多請求裝下Continuous Batching負責吃滿GPU讓請求跑得更快第三章vLLM實戰(zhàn)——本地項目復現3.1 環(huán)境搭建我在autodl云平臺租的5090顯卡做的實驗。用到社區(qū)鏡像3.2 吞吐量對比實驗bench_throughput.py[A] transformers 串行逐條循環(huán)處理請求每次只向模型輸入 1 條 prompt這條完整生成完畢之后才處理下一條。GPU 同一時刻只在計算 1 個請求大部分算力處于空閑狀態(tài)。KV 緩存處理完一條就完整釋放沒有批處理加速。[B] transformers 靜態(tài) batch24把 50 條請求按每 24 條切分成若干個固定分組一組一組送入model.generate()。同一組最多 24 條同時推理組內請求做 padding 補齊長度。必須等待本組內全部 24 條請求全部生成結束才釋放顯存、再執(zhí)行下一組。只要組內存在生成較慢的長請求其余已經完成的請求會占用位置和 KV 緩存GPU 算力空等產生尾部算力空洞。batch 開到 24已經充分利用 32GB 顯存相比串行有巨大提升但依然受靜態(tài)批處理機制限制。[C] vLLM 批處理Continuous Batching PagedAttention把全部 50 條請求一次性提交給 vLLM。連續(xù)批處理Continuous Batching不以整組請求為調度單位以單步 token 迭代做調度。某條請求生成完成立刻將它剔除馬上補入排隊的新請求不需要等待一整批全部跑完。PagedAttention 分頁 KV 緩存KV 緩存拆成獨立小塊 block 管理請求結束立刻回收 block消除內存碎片顯存利用率大幅提升。內部動態(tài)調整同時活躍的請求數量充分打滿 GPU 算力。結果對比模式總耗時QPS請求/秒tokens/s相對 vLLM[A] transformers 串行43.10s1.16870.02×[B] transformers batch244.76s10.517750.18×[C] vLLM 批處理0.84s59.1941341.00×3.3 約束解碼實戰(zhàn)四大模式逐個拆解3.3.1 guided_choice 枚舉約束每步解碼時屏蔽非法 token 的 logits輸出了“查”之后就只能輸出“股價”、“財報”、“新聞”了。INTENT_CHOICES[查股價,查財報,查新聞,對比分析,其他]defrun_with_guided_choice(user_msg:str)-tuple[str,float]:guided_choice 約束底層 FSM 屏蔽非法 tokent0time.time()respclient.chat.completions.create(modelMODEL,messages[{role:system,content:SYSTEM_PROMPT},{role:user,content:user_msg},],temperature0,max_tokens10,extra_body{guided_choice:INTENT_CHOICES},# ★ 關鍵參數)returnresp.choices[0].message.content.strip(),time.time()-t0運行結果指標 裸 prompt guided_choice ---------------------------------------------------------------------- 輸出合法在枚舉內 248/257 (96%) 257/257 (100%) 預測正確 55/257 (21%) 57/257 (22%) 平均延遲秒 0.041 0.0423.3.2 guided_regex 正則約束DATE_REGEXr\d{4}-\d{2}-\d{2}defrun_generate(system:str,user:str,regex:str|NoneNone)-tuple[str,float]:t0time.time()extra{guided_regex:regex}ifregexelse{}respclient.chat.completions.create(modelMODEL,messages[{role:system,content:system},{role:user,content:user},],temperature0,max_tokens30,extra_bodyextra,)returnresp.choices[0].message.content.strip(),time.time()-t0運行結果 輸入 裸 prompt guided_regex --------------------------------------------------------------------------- 2024年5月12日 ? 2024-05-12 ? 2024-05-12 2023/12/1 下午開會 ? 2023-12-01 14:00:00 ? 2023-12-01 三月三號我去北京 ? 2017-03-03 ? 2017-03-03 2024.11.30 是截止日期 ? 2024-11-30 ? 2024-11-30 明天假設今天是2026-05-11 ? 2027-04-12 ? 2027-04-12 2024 年 10 月的第一天 ? 2024-10-01 ? 2024-10-01 --------------------------------------------------------------------------- 格式合法率裸 prompt 5/6 (83%) | guided_regex 6/6 (100%)3.3.3 response_format JSON 約束保證輸出json格式defrun(user:str,mode:str)-tuple[str,float]:mode: raw | json_objectkwargs{}ifmodejson_object:kwargs[response_format]{type:json_object}t0time.time()respclient.chat.completions.create(modelMODEL,messages[{role:system,content:SYSTEM_PROMPT},{role:user,content:user},],temperature0,max_tokens150,**kwargs,)returnresp.choices[0].message.content.strip(),time.time()-t0運行結果 200 條測試結果 指標 裸 prompt response_format ------------------------------------------------------------ 合法 JSON 200/200 (100%) 200/200 (100%) 有 sentiment 字段 200/200 (100%) 200/200 (100%) sentiment 值合法 200/200 (100%) 200/200 (100%) 有 confidence 字段 200/200 (100%) 200/200 (100%) 有 keywords 字段 200/200 (100%) 200/200 (100%) 裸 prompt也是100%但是依靠模型自覺3.3.3 guided_json JSON Schema約束比json約束更定制化不光保證json格式還能約束取值范圍等內容INTENT_SCHEMA{type:object,properties:{company:{type:string,description:公司全稱如 招商銀行、貴州茅臺,},year:{type:integer,minimum:2015,maximum:2025,},metric:{type:string,enum:[營收,凈利潤,ROE,毛利率,總資產,經營現金流],},},required:[company,year,metric],additionalProperties:False,}defrun_generate(user_msg:str,mode:str)-tuple[str,float]:mode: raw | guided_json | response_formatextra{}kwargs{}ifmodeguided_json:extra{guided_json:INTENT_SCHEMA}elifmoderesponse_format:kwargs{response_format:{type:json_object}}t0time.time()respclient.chat.completions.create(modelMODEL,messages[{role:system,content:SYSTEM_PROMPT},{role:user,content:user_msg},],temperature0,max_tokens120,extra_bodyextra,**kwargs,)returnresp.choices[0].message.content.strip(),time.time()-t0運行結果指標 裸 prompt response_format guided_json ------------------------------------------------------------------------------ 合法 JSON 9/9 (100%) 9/9 (100%) 9/9 (100%) 字段齊全 9/9 (100%) 9/9 (100%) 9/9 (100%) year 在 2015~2025 8/9 (89%) 8/9 (89%) 9/9 (100%) metric 在枚舉內 9/9 (100%) 9/9 (100%) 9/9 (100%) jsonschema 完全通過 8/9 (89%) 8/9 (89%) 9/9 (100%) 結論 response_format 只保證是 JSON不保證字段名、類型、枚舉正確 guided_json 是唯一 100% 保證 schema 合法的方式 vllm在function call的例子里很有用可以做到約束模型給出合規(guī)的json輸出3.4 約束解碼原理簡述FSM有限狀態(tài)機在每一步token采樣時用FSM過濾掉不符合規(guī)則的候選token從生成源頭杜絕非法輸出首次構建Schema有FSM初始化開銷緩存后速度恢復正常第四章總結本文從分詞器底層講起深入KV Cache與vLLM兩大核心優(yōu)化技術并通過本地實驗復現驗證了vLLM的兩大工程價值第一極致的推理吞吐性能。PagedAttention借鑒操作系統(tǒng)虛擬內存分頁思想將KV Cache切分為離散的內存塊按需分配、即時回收大幅緩解傳統(tǒng)連續(xù)內存分配帶來的顯存碎片問題Continuous Batching則以單步token迭代為調度單位完成的請求立刻退出、新請求隨時補入避免靜態(tài)批處理的算力空轉。本地實測數據顯示在Qwen2-0.5B模型、50條請求的場景下vLLM的吞吐速度達到原生transformers串行的47倍是transformers靜態(tài)batch24的5.3倍充分體現了兩項技術協(xié)同帶來的性能收益。第二可靠的約束解碼能力。vLLM支持枚舉、正則、JSON、JSON Schema等多種約束模式通過FSM有限狀態(tài)機在token生成的每一步屏蔽非法候選從源頭保證輸出格式合規(guī)。實驗表明裸prompt和OpenAI標準的response_format雖然能保證JSON語法合法但在字段取值范圍、枚舉約束等細節(jié)上仍有89%左右的通過率而guided_json可以做到100%符合Schema定義。對于Agent工具調用、結構化數據抽取等對輸出格式有嚴格要求的場景這是公有API無法提供的工程價值。最后回到一個實際問題要不要自建vLLM如果你的業(yè)務有高并發(fā)、大批量、數據敏感、強結構化輸出的需求vLLM是非常值得投入的方案如果只是小流量原型驗證、追求快速上線、不需要強格式約束公有API依然是更省事的選擇。vLLM不是銀彈但它在性能和可控性兩個維度上給了開發(fā)者一個非常有競爭力的自建推理選項。