所謂一份工作，其實是企業在服務客戶的過程中製造出來的一整包問題。每一項技術都只改變這個系統中的某一個環節。負責人必須證明：這項改動確實滿足了客戶在品質、時間、可靠度與成本上的要求。
主要參考資料：Philip Kiely，Inference Engineering，Baseten Books，2026。涵蓋範圍取材自 Gauri Gupta 的 LLM Optimization Interview Notes: Training and Inference。文中的商業情境與圖解皆為原創的說明性範例，並非已發表的案例研究。
找不到符合的項目。請重設或調整篩選條件。
文件助理開放上傳更長的檔案後，第一次回應變得太慢。公司需要守住回應時間上限，又不想為了原本可以避免的記憶體流量而加買算力。負責人得替注意力做效能剖析、挑一顆相容的核心，並驗證整條請求路徑。
把注意力切成分塊（tile），讓有用的中間值留在速度快的晶片內記憶體。避免在裝置記憶體中完整展開整張注意力分數矩陣；除浮點誤差外，仍保留原本的密集注意力計算。
核心相容性與張量形狀都會影響結果。密集預填注意力的運算量仍是二次方；注意力變快，並不會消除排隊等待或所有記憶體成本。
預填時間、記憶體峰值、端到端的首個 token 時間（TTFT），以及輸出結果檢查。
聊天產品必須在固定的裝置預算下，讓更多對話同時保持在線。若每個查詢頭都配上一整組 key 與 value，快取消耗就太大了。負責人要挑選或訓練一個 KV 頭較少的模型，並確認任務品質仍在可接受範圍內。
多查詢注意力讓所有查詢頭共用同一組 KV 頭。分組查詢注意力則使用數個 KV 頭群組，落在「全部共用一組」與「每個查詢頭各配一組」之間。
這是模型架構層級的選擇，不是可以對任意權重隨意開關的執行期設定。轉換既有檢查點可能得再訓練一輪。
每個 token 的 KV 位元組數、可同時在線的序列數、解碼時間，以及任務品質。
文件類產品需要從長輸入中散落各處的線索找出答案，但完整注意力已經超出預算。負責人必須判斷：這項任務到底需要哪些長距離關聯。比較省的注意力樣式，只有在模型仍然找得到、也串得起這些線索時才有價值。
限制哪些 token 配對之間可以互動。區域視窗保留鄰近的連結；全域 token 或稀疏的長距離連結則負責串起相隔很遠的區段。把區域層與全域層交錯堆疊，是另一種架構選擇。
改變可見範圍就可能改變答案。並不存在一體適用的安全視窗大小、擴張率，或「每 N 層插一層」的通則。
長距離檢索與推理的正確率、預填時間，以及在目標上下文長度下的記憶體用量。
Longformer：區域視窗加上選定的全域注意力，適合長文件任務。BigBird 在區域與全域連結之外，再加入隨機連結。LongNet 則以擴張注意力延伸涵蓋範圍。每一種都改動了模型內部的資訊路徑；負責人必須針對自家產品實測長距離依賴關係。各篇一手論文連結另見「資料來源」一節。
長上下文服務光是保留注意力狀態，就吃掉太多記憶體。公司需要在每張裝置上撐出更多可用的上下文，又不能漏掉重要細節。負責人要評估相容的壓縮狀態架構，並檢驗它在最長支援輸入下的品質。
低秩方法把選定的注意力分量表示在較小的空間中。多頭潛在注意力（MLA）把 KV 資訊壓縮成潛在表示；Linformer 則是縮減注意力投影的序列維度。這些概念彼此相關，但並不是同一套演算法。
架構相容性與近似品質都很關鍵。不要假設每一種投影或位置分量，都能用同樣的方式壓縮。
快取大小、注意力運算時間，以及長上下文任務上的品質。
裝置端應用在目標上下文長度下，沒辦法替每一個注意力層各留一份 KV 狀態。負責人開始研究那些設計上就能跨層重用狀態的模型。只有在記憶體足跡變小、應用行為又維持不變的前提下，公司才會接受這項改動。
跨層注意力讓多個層共用同一組 key 與 value，藉此減少必須保留的相異 KV 狀態數量。
架構層級的改動需要訓練階段的配合。在既有模型上任意重用某幾層的快取，並不是同一回事。
KV 記憶體用量、可支援的上下文長度，以及任務品質的差異。
寫作助理必須在使用者乾等的時候產出一長段回應。每走一步就把先前 token 的狀態重算一遍，等於白做工。負責人要維護正確的請求狀態、設定上下文長度上限，並確保被放棄的請求會把記憶體釋放掉。
把先前 token 的 key 與 value 保留下來。每個解碼步驟只新增狀態，並讀取既有上下文，而不是把那些先前的 key 與 value 再算一次。
快取會佔用記憶體，而且隨著上下文長度與同時在線請求數一起成長。它省下的是運算；並不會讓所有注意力變成常數時間，也不會減少所有記憶體用量。
token 之間的延遲、配置出去的快取位元組數、同時在線請求數上限，以及請求取消後的清理狀況。
客服助理每次都把同一份政策文件，連同不同的問題一起送出。重複預填既墊高成本，也拖慢第一次回應。負責人要讓可重用的前綴保持穩定、確保快取狀態相容，並在真實的請求組合下檢查到底省了多少。
對於與先前 token 序列開頭相符的那一段，直接重用它的 KV 狀態。不相符的後半段則照常處理並產生新輸出。
第一個變動的 token 就終結了一般的前綴重用。斷詞方式、模型版本、adapter、位置編碼處理與隔離政策，都可能讓狀態不相容。
冷啟動與熱啟動的首個 token 時間、預期與實際的重用率、實際處理掉的輸入 token 數，以及任務品質。
服務的總記憶體其實夠用，卻浪費在過大或破碎的請求配置上，導致能同時服務的客戶數變少。負責人要管好 KV 區塊與排程，讓長度不一的請求更有效率地吃下這些容量。
把 KV 狀態切成固定大小的實體區塊。再用一張邏輯區塊對照表，讓注意力即使在區塊於記憶體中不連續的情況下，仍能正確存取整個序列。
頁表與核心會增加實作成本。分頁屬於記憶體管理；它本身既不會近似注意力，也不會縮減邏輯上的上下文長度。
配置浪費比例、同時在線請求數、記憶體壓力、失敗次數，以及尾端延遲。
文件服務沒辦法把每一份可重用的上下文都留在 GPU 記憶體裡。但直接把狀態丟掉，換來的是昂貴的重複預填。負責人要決定：哪些留在快速記憶體、哪些搬到較慢的儲存，以及什麼時候乾脆重算還比較划算。
把較少使用的 KV 區塊，從 GPU 記憶體搬到主機記憶體，或本機、網路儲存。當重用的價值蓋得過搬運成本時，再把區塊載回來。
命中慢速儲存的快取，有可能比直接重算還慢。傳輸頻寬、資源競爭、相容性與快取存活時間都會左右結果。
各層級的命中率、傳輸時間、搬移的位元組數、重算成本，以及端到端延遲。
多副本的聊天機器人，一旦每一輪都打到不同的工作節點，就失去了重用機會。公司為重複的上下文付錢，使用者也等得更久。負責人要在快取區域性與佇列長度之間拿捏，別讓一個「有熱快取但已經滿載」的節點反而變成慢路徑。
挑選工作節點時，把可重用的快取狀態與負載、可用性一起納入考量。只有在總預期完成成本划算時，才優先選擇握有熱快取的節點。
追求完美的區域性，反而可能製造熱點。故障切換與擴縮容必須能處理「快取位置資訊缺漏或過期」的情況。
快取命中率、佇列等待時間、首個 token 延遲、節點之間的不均衡程度，以及故障復原表現。
產品原本驗收通過的模型，對它的部署預算來說太大、也太貴。負責人調降特定部分的數值精度，並拿產品自己的失敗案例來測。只有在品質要求之內確實改善了記憶體或成本，公司才會保留這項改動。
透過縮放因子（必要時再加上校準資料），把訓練好的數值轉換成較小的數值格式。要挑選哪些元件做量化，而不是把整個模型當成單一格式一視同仁。
離群值、校準資料不匹配，以及不支援的核心，都可能傷害品質或速度。檔案變小，不等於服務就跑得更快。
相對於驗收基線的品質、記憶體峰值、延遲，以及每個合格結果所花的成本。
用最小／最大值決定範圍雖然簡單，卻對離群值很敏感。以誤差最小化為目標的校準能降低重建誤差；但貼近任務的檢查還是不能省。校準目標並不等於商業品質的保證。
全面採用低精度確實省記憶體，卻弄壞了重要的產品情境。但把整個模型退回原精度，又等於白白放棄可觀的節省。負責人要找出敏感元件，在那裡保留較高精度，其餘照壓不誤。
分別替權重、活化值、KV 狀態或特定層指定不同格式。在評估結果有要求的地方，把敏感運算維持在較高精度。
混合格式需要有支援的核心與轉換路徑。KV 的誤差會一路影響後續 token，所以長輸出測試格外重要。
各任務的品質、格式轉換的額外開銷、記憶體用量，以及不同上下文長度下的效能表現。
目標裝置或成本要求非得用低精度不可，但訓練後轉換卻過不了品質檢查。於是公司手上除了服務端問題，又多出一個模型開發問題。負責人要把量化效應納入訓練，並交出一份已在目標執行環境驗證過的檢查點。
在運算中重現量化效應的前提下進行訓練或微調。如此一來，模型能讓自己的權重去適應預定的數值限制。
訓練會墊高資料、算力與發布流程的成本。實際部署的核心與格式，必須與模型開發階段測試時的假設一致。
最終部署後的品質、訓練成本、模型記憶體用量，以及服務延遲。
程式助理的首個 token 時間有達標，但長輸出收尾太慢。負責人要驗證：換一個比較便宜的提議者，能不能減少昂貴的目標模型回合數。公司要的是縮短完成時間，同時不改變已驗收的輸出行為。
由草稿模型提出候選 token，目標模型再用一次較大的運算加以驗證。接受合法的前綴，並在被駁回的位置，依解碼演算法進行修正或重新取樣。
草稿生成、驗證與額外的快取狀態都要吃資源。精確取樣必須搭配正確的接受與修正程序；「貪婪解碼下剛好一致」只是教學範例。
每回合被接受的 token 數、草稿與驗證時間、總完成時間、吞吐量，以及輸出結果檢查。
高流量助理需要更快的生成速度，但另外掛一個通用草稿模型，額外開銷又太大。負責人開始評估那些「與目標模型搭配訓練」的推測元件。這一來，工作範圍就擴大到訓練相容性、服務整合與發布驗證。
Medusa 額外加上預測頭，用來提議接下來的 token。EAGLE 系列方法則是在訓練好的推測器中，運用目標模型的隱藏狀態資訊。無論哪一種，提議都仍須由目標模型驗證。
這些變體都需要相容且已訓練好的元件。EAGLE 各版本之間有差異；固定的隱藏層數或草稿長度並不是通則。
接受率、推測器的額外開銷、任務品質、完成時間，以及負載下的效能表現。
程式編輯產品經常回傳與輸入非常接近的文字。對這種重複性高的工作來說，特地訓練一個草稿模型可能根本沒必要。負責人要測試「直接從重複序列取出的廉價提議」，再把它的價值拿去和驗證成本相比。
N-gram 查表會從重複出現的 token 樣式中提議接續。前瞻式方法則能在推論過程中額外產生候選序列；而提議一律由目標模型驗證。
一旦輸出跟現有樣式對不上，查表就失去價值。額外產生候選要耗算力，也可能壓縮服務容量。
樣式涵蓋率、每回合被接受的 token 數、總完成時間，以及負載下的吞吐量。
需要用的模型塞不進單一裝置，或是單裝置執行達不到回應時間目標。負責人把層內運算切分到多張裝置，並挑選一種具備合適連線的拓撲。公司要的是可用的服務容量，而不只是「模型載得起來」。
在層內對張量做分片，讓不同裝置去算同一個運算的不同部分。按欄切分會產生輸出切片；按列切分則產生必須再行合併的部分和。
通訊與同步的成本，有可能把運算上的收益全部吃掉。若下一個運算支援該佈局，中間輸出可以維持在分片狀態、不必急著合併。
單一使用者的延遲、集體通訊時間、每張裝置的記憶體用量，以及每個合格結果的成本。
超大模型或超大快取所需的裝置數，已經超過單一節點能提供的量。負責人把成組的層擺到不同裝置上，並管理它們之間的交接。公司必須接受：為了服務這個模型，就得付出相應的傳輸成本與延遲。
依層切分模型。一個請求的活化值會依序流過各階段；而多個請求或微批次，則可以同時佔用不同階段。
單一請求還是得等前面的階段。階段之間負載不均與閒置空檔，會同時損害延遲與使用率。
端到端延遲、各階段使用率、活化值傳輸時間，以及故障復原表現。
影片或長上下文的工作負載，所產生的注意力運算與狀態已經超出單張裝置能處理的量。負責人把與序列相關的工作切分到多張裝置上。公司要的是在期限內交出完整的影片或答案，同時仍保有整段輸入的資訊。
對注意力工作的序列（上下文）維度進行切分。裝置之間會交換該注意力樣式所需的遠端狀態，而且通常會讓傳輸與運算重疊進行。
把序列切開，不代表各段之間就此彼此獨立。通訊成本、被複製的權重，以及模型本身的注意力實作，共同決定了實際效益。
記憶體峰值、注意力運算時間、裝置間傳輸量、總完成時間，以及品質。
服務使用的是混合專家（MoE）模型，要把完整的專家權重全部擺妥，成本相當高。負責人把專家分散部署，再將 token 的工作路由過去。公司要的是高總體容量，而不是讓少數幾個忙碌的專家，決定每一位客戶的等待時間。
把不同專家放到不同裝置上。將 token 的活化值路由到選定的專家，再合併它們的輸出；至於注意力，則可能採用另一套平行化配置。
稀疏啟用並不會免除「整個模型都得存放」這件事。路由不均與 all-to-all 通訊，都可能反客為主成為主要瓶頸。
每個專家分到的 token 數、裝置之間的不均衡、路由與傳輸時間、吞吐量，以及尾端延遲。
流量成長了，但一次只跑一個請求會讓硬體閒著。負責人讓多個請求共用執行資源，同時守住回應時間上限。只有在個別使用者仍能及時拿到結果的前提下，公司才算真的賺到吞吐量。
靜態批次使用固定的一組請求。動態批次會持續填滿一組，直到達到數量或時間上限。連續批次則是在執行邊界上，只要有活躍請求完成，就立刻放新工作進來。
為了湊滿批次而等待、以及保留更多 KV 狀態，都會推高延遲與記憶體壓力。最大 token 速率並不是唯一的目標。
佇列等待時間、P95 回應時間、實際被接受的吞吐量、記憶體用量，以及拒絕率。
一個超長的提示，就足以打斷其他進行中對話的流暢輸出。負責人要限制每個排程步驟能放進多少預填工作。公司需要支援長輸入，但不能因此讓其他使用者的串流卡住。
把一大段預填切成數個 token 分塊。在執行環境的資源預算之內，把這些分塊與解碼工作一起排程。
分塊切得越小，公平性可能越好，但也會增加排程開銷，或是拖慢那個長請求的首個 token。
既有串流的 token 間延遲、長請求的首個 token 時間、吞吐量，以及公平性。
忙碌的程式助理，同時得應付大型提示與長輸出串流。預填與解碼互搶資源，而且各自沒能達成不同的延遲目標。負責人要評估分開的節點資源池、兩者的容量比例，以及在它們之間搬移 KV 狀態的成本。
讓預填與解碼跑在不同的節點上。在繼續解碼之前，先把產生的 KV 狀態傳過去；也可以用條件式路由，把適合的短請求或已快取請求留在本地處理。
多出來的裝置、傳輸與控制邏輯，都必須賺回自己的成本。在低流量的情況下，分離不見得划算。
首個 token 與 token 間延遲、KV 傳輸時間、各資源池使用率、成本，以及過載時的行為。
效能剖析顯示：小型運算之間反覆出現裝置記憶體搬運或啟動開銷。負責人挑一個有支援的實作，或把相容的運算合併起來。公司要的是可量測的服務改善，而且要能撐過硬體與模型的更新。
融合會把中間結果留在合併後的核心內部，而不是在運算之間先寫出去、再讀回來。核心選擇則是讓實作去配合張量形狀、數值格式與硬體。
融合可能拉高暫存器壓力，或是失去某條高效的函式庫路徑。單獨一顆核心跑得更快，也可能完全沒動到服務真正的瓶頸。
核心執行時間、搬移的位元組數、數值檢查，以及完整請求層級的效能。
微調工作跑在具代表性的樣本上就把記憶體吃光了。負責人選擇多花一點運算，換取更少的活化值保留量。公司要的是在訓練預算與發布時程之內，拿到一個可用的模型更新。
在前向傳播時只保存選定的活化值。等反向傳播真正需要時，再把缺少的中間值重算回來。
這是針對反向傳播狀態的訓練技術，跟一般請求的 KV 快取不是同一回事。重算會實實在在增加工作量。
訓練時的記憶體峰值、每步耗時、可重現性，以及最終模型品質。
公司拿大量短樣本做微調，但補滿填充的批次等於在浪費裝置算力。負責人把樣本打包起來，同時保住它們的訓練邊界。只有在打包沒有改變模型學到的東西時，步驟變快才有意義。
把多個樣本放進同一條打包序列，並附上邊界中繼資料與合適的注意力遮罩。執行環境因此可以去處理有用的 token，而不是處理填充。
遮罩或損失邊界一設錯，樣本之間就會互相洩漏資訊。打包跟服務端的連續批次處理並不是同一件事。
每秒處理的有用 token 數、填充佔比、邊界正確性，以及驗證集品質。
以全精度跑一次模型更新，不是太慢就是太吃記憶體。負責人挑選能加速訓練、又不會讓訓練失穩的運算資料型別。公司要的是可靠的收斂，而不只是把單一步驟縮短。
對適合的運算使用較低精度，並在需要的地方保留較高精度。FP16 訓練通常會用梯度縮放來降低下溢；而 BF16 因為指數範圍較大，一般來說就不需要這項特定處理。
數值穩定性依舊因模型而異。混合精度訓練與訓練後量化，處理的是工作流程中不同階段的問題。
達到目標驗證品質所需的時間、非有限值梯度出現的次數、記憶體峰值，以及最終部署後的品質。
模型塞得進單一裝置，但要把整份訓練資料集跑完，就趕不上發布期限。負責人把樣本分散到多個副本上，並確保它們的更新保持一致。公司衡量的是「達到所需驗證品質」所花的時間與成本。
每個副本處理不同的資料分片。分散式資料平行（DDP）訓練會同步梯度，讓各副本套用彼此相容的更新；相對地，推論副本則是各自服務獨立請求，完全不做梯度同步。
資料載入、通訊，以及被改變的有效批次大小，都可能限制擴展效果。非同步訓練能減少等待，卻會引入過期的更新並改變收斂行為。
達到目標品質的時間、每秒處理的樣本數、同步耗時，以及可重現的資料涵蓋範圍。
DataParallel 採用單一行程、多裝置的做法；DDP 則通常是每張裝置配一個行程。整體同步式（bulk-synchronous）更新必須等協調完成。非同步更新雖然能減少等待，但負責人得實測更新過期程度與收斂狀況，不能想當然地認為「節點跑得快，模型就學得快」。
訓練任務的前向運算塞得下，但重複存放的優化器與梯度狀態塞不下。負責人把狀態切分到各個工作節點，並量測新增的通訊成本。只有在改完之後整體仍在預算內，公司才真的能訓練更大的模型或更大的批次。
第 1 階段切分優化器狀態。第 2 階段連梯度一起切分。第 3 階段再把參數也切分，並在執行過程中把需要的片段收集回來。
記憶體究竟能省多少，取決於狀態格式與平行度。通訊與暫存緩衝區依然存在；固定的縮減倍數並不是通則。
每張裝置的記憶體峰值、收集與歸約的耗時、訓練每步時間，以及收斂狀況。
加了裝置之後，換來的不是額外容量，而是同步延遲甚至整個卡死。負責人要選對集體通訊操作，並檢查它們的拓撲與呼叫順序。公司需要的，是所有參與節點之間可預測的訓練或服務時間。
All-reduce 會讓每個 rank 都拿到歸約後的完整結果。Reduce-scatter 讓每個 rank 各拿到一份歸約後的分片；all-gather 則讓每個 rank 都拿到全部分片的集合。這兩者合起來，就能實作出 all-reduce。
每一個參與者都必須使用相容的張量形狀、型別與呼叫順序。對小型運算來說，傳輸成本與同步開銷可能反客為主。
集體通訊延遲、傳輸的位元組數、落後節點造成的等待時間、數值正確性，以及逾時後的復原能力。
Broadcast 把某個 rank 的緩衝區複製給所有人。Reduce 在單一 root 上合併所有輸入。Scatter 把 root 持有的片段分送出去；gather 則把片段收集回 root。Ring all-reduce 只是其中一種實作方式，並不是每一次 DDP 訓練都非它不可。
模型需要好幾個管線階段，但當單一批次在其中流動時，其他裝置只能乾等。負責人排入多個微批次，讓各階段的工作重疊起來。公司要的是減少硬體閒置，同時不改變原訂的優化器更新方式。
把層分配到各個階段，並把一個批次切成多個微批次。用它們的前向與反向工作把管線填滿，最後再執行同步更新。
暖機與排空階段仍會留下閒置空檔。微批次數量增加與活化值重算，都會改變記憶體與排程成本。
各階段使用率、閒置比例、活化值峰值，以及達到驗證品質所需的時間。
又長又深的訓練管線，時間都耗在全域等待上。負責人讓前向與反向工作重疊起來，同時維持權重與梯度之間該有的對應關係。公司除了吞吐量，還必須一併評估收斂狀況與記憶體成本。
PipeDream 會跨多個小批次安排工作，並追蹤權重版本。權重暫存（weight stashing）會保留進行中工作所需的版本；相關的排程方案，則各自選擇不同的同步與緩衝策略。
權重過期或版本對不上，都會改變訓練行為。光看使用率很高，並不能證明收斂比較快。
達到目標品質的時間、進行中狀態佔用的記憶體、版本一致性，以及管線使用率。
垂直同步（vertical synchronization）讓版本一致性跨階段延續。PipeDream-flush 採用同步化的排空邊界。PipeDream-2BW 則搭配特定的更新排程來限制權重緩衝量。這些是不同的一致性取捨，不是可以隨意互換的開關。
在大規模訓練下，閒置空檔與通訊延遲會吃掉預算中相當可觀的一塊。負責人在尊重相依關係與記憶體上限的前提下，重新安排彼此獨立的工作。公司要的是更快拿到一個有效的檢查點，而不是一張沒有空格的漂亮排程圖。
零氣泡排程把反向工作中「算輸入梯度」與「算權重梯度」拆開，再把可以挪動的部分填進空檔。DualPipe 則以雙向管線排程，讓運算與通訊重疊進行。
理想排程的前提是各階段耗時均衡、記憶體也夠用。實際的連線狀況、優化器同步與模型邊界，都可能留下填不滿的空檔。
實測的閒置時間、傳輸重疊程度、記憶體用量、數值等價性，以及達到目標品質的時間。
ZB-H1 與 ZB-H2 是在不同記憶體限制下的兩種排程設計。廣度優先與深度優先的迴圈式排程，對虛擬階段的工作採取不同排序。Llama 式的階段平衡，則是在成本高昂的邊界附近重新分配層。DualPipe 針對的是通訊密集的執行情境。每一種都需要自己跑一次 trace 與收斂檢查；有名字的排程，不等於通用的保證。
少數幾個專家收走了絕大多數 token，其他裝置卻在空等。負責人必須壓下這種不均，又不能丟掉任務真正需要的資訊。公司要的是在真實 token 分布下，仍然可預測的吞吐量與品質。
Top-1 或 top-k 路由替每個 token 挑選專家。訓練階段可以採用平衡性目標；部分架構則使用免輔助損失（auxiliary-loss-free）的機制。在支援的前提下，服務階段也能調整專家的放置位置與容量。
硬性的容量上限或丟棄 token，都會改變輸出結果。訓練階段的路由規則，絕不能跟「可安全調整的服務端設定」混為一談。
各專家的負載分布、溢出或被丟棄的 token 數、傳輸時間、尾端延遲，以及任務品質。
裝置平衡損失與通訊平衡損失，把資源平衡直接寫進訓練目標裡。免輔助損失的方法則走另一條機制。隨機路由、容量上限與優先權丟棄，各自對品質有不同影響；請只採用該模型與執行環境確實支援的設計。
常見的 KV 佈局：32 層、每個頭 128 個數值、16 位元 KV。假設各請求長度相同、無前綴共享、無滑動視窗、無分片，也不計配置器開銷。
這是依 KV 張量維度推算出來的估計值，不是書中引用的基準測試數字。權重儲存、暫存緩衝區與執行期餘裕都得另計。更動 KV 頭數，必須有相容的模型架構配合。
這個示意用的貪婪回合會提出四個 token。假設一般目標模型每步 10 ms、草稿生成合計 4 ms、驗證 12 ms。這些都是為了教學而虛構的輸入值。
這個簡化回合裡的「+1」，指的是目標模型自己產出的那一個 token。序列結束處理、修正成本、批次處理與服務開銷都未計入。接受率高，並不保證在正式環境就會變快。
| 技術 | 階段 | 負責人範例 | 主要依據 |
|---|---|---|---|
| 01 · FlashAttention | 服務部署 | 執行環境／核心工程師 | 紙本 pp. 67–68 |
| 02 · 多查詢與分組查詢注意力 | 模型設計 | 模型／推論工程師 | 一手補充來源 |
| 03 · 稀疏、滑動視窗與擴張注意力 | 模型設計 | 模型工程師 | 紙本 pp. 68–69, 141 |
| 04 · 低秩與潛在注意力 | 模型設計 | 模型工程師 | 紙本 pp. 69 |
| 05 · 跨層 KV 共享 | 模型設計 | 模型工程師 | 一手補充來源 |
| 06 · 單一請求內的 KV 快取 | 服務部署 | 推論工程師 | 紙本 pp. 53, 136 |
| 07 · 跨請求的前綴快取 | 服務部署 | 推論工程師 | 紙本 pp. 136–138 |
| 08 · PagedAttention 與區塊配置 | 服務部署 | 執行環境工程師 | 紙本 pp. 68, 141 |
| 09 · KV 快取卸載與儲存層級 | 服務部署 | 推論／平台工程師 | 紙本 pp. 139–140 |
| 10 · 快取感知路由 | 服務部署 | 服務平台工程師 | 紙本 pp. 140–141 |
| 11 · 訓練後量化 | 服務部署 | 推論／模型工程師 | 紙本 pp. 120–128 |
| 12 · 選擇性與混合精度量化 | 服務部署 | 推論／模型工程師 | 紙本 pp. 125–128 |
| 13 · 量化感知訓練 | 訓練 | 模型訓練工程師 | 紙本 pp. 125–128 |
| 14 · 草稿—目標推測解碼 | 服務部署 | 推論工程師 | 紙本 pp. 129–132 |
| 15 · Medusa 與 EAGLE 推測 | 服務部署 | 模型／推論工程師 | 紙本 pp. 132–134 |
| 16 · N-gram 與前瞻推測 | 服務部署 | 推論工程師 | 紙本 pp. 134–136 |
| 17 · 張量平行 | 服務部署 | 推論平台工程師 | 紙本 pp. 142–147 |
| 18 · 推論場景的管線平行 | 服務部署 | 推論平台工程師 | 紙本 pp. 143–148 |
| 19 · 上下文平行 | 服務部署 | 分散式推論工程師 | 紙本 pp. 144, 176 |
| 20 · 專家平行 | 服務部署 | MoE 服務工程師 | 紙本 pp. 53–54, 145–146 |
| 21 · 靜態、動態與連續批次處理 | 服務部署 | 服務工程師 | 紙本 pp. 186–188 |
| 22 · 分塊預填 | 服務部署 | 執行環境工程師 | 紙本 pp. 141 |
| 23 · 預填／解碼分離 | 服務部署 | 推論平台工程師 | 紙本 pp. 148–150 |
| 24 · 核心選擇與融合 | 服務部署 | 執行環境／核心工程師 | 紙本 pp. 98–100 |
| 25 · 活化值檢查點 | 訓練 | 訓練系統工程師 | 一手補充來源 |
| 26 · 序列打包 | 訓練 | 訓練資料／系統工程師 | 一手補充來源 |
| 27 · 混合精度訓練 | 訓練 | 訓練工程師 | 一手補充來源 |
| 28 · 資料平行訓練與 DDP | 訓練 | 分散式訓練工程師 | 一手補充來源 |
| 29 · ZeRO 狀態分片 | 訓練 | 分散式訓練工程師 | 一手補充來源 |
| 30 · 分散式通訊原語 | 共通 | 分散式系統工程師 | 紙本 pp. 143, 145 |
| 31 · GPipe 與訓練微批次 | 訓練 | 訓練系統工程師 | 一手補充來源 |
| 32 · PipeDream 與權重版本管理 | 訓練 | 訓練系統工程師 | 一手補充來源 |
| 33 · 零氣泡與通訊重疊排程 | 訓練 | 訓練系統工程師 | 一手補充來源 |
| 34 · MoE 路由與負載平衡 | 共通 | 模型／MoE 系統工程師 | 紙本 pp. 53–54, 145–146 |
Philip Kiely，Inference Engineering。Baseten Books，2026。文中頁碼皆以紙本頁數標示；本 PDF 的頁碼索引比紙本多兩頁。
「書籍來源」代表該段說明有本書作為依據，並不表示這項技術是 Kiely 發明的。所有圖解皆為重新繪製的示意圖；書中任何插圖都未被重製。
Gauri Gupta 的文章撐起了這張地圖的廣度，包括訓練端的技術。具名的變體，都與其運作機制和權責界線歸在一起。
凡是書中未加說明的技術，該節會標示為一手補充來源，並附上論文或官方文件連結。稀疏注意力、潛在注意力、管線變體與數值方法，都需要針對特定架構另行檢查。
文中的商業情境與負責人標籤，都是分析性的舉例。不同團隊完全可以有不同的分工方式。它們既不是就業市場的統計數字、不是薪資主張，也不能用來證明每一位推論工程師都必須精通全部 34 節。
用圖解建立假設。保留一條基線、一次只改一個主要變數，並用貼近正式環境形狀的輸入來測試。品質與服務成效必須一起量測。在把個別成功的改動組合起來之前，先確認它們彼此之間的交互作用。