一、引言

作為國內領先的在線視頻平臺，嗶哩嗶哩（以下簡稱“B站”）正經歷著業務體量和用戶規模的快速增長。隨著訪問量的持續增長和業務復雜程度的增加，在相對有限的服務器資源下如何優化在線服務性能和提高資源利用率，成為了工程研發團隊面臨的重要挑戰之一。

本文將以筆者所在的商業技術中心為例，重點討論效果廣告引擎的在線推理部分。文章將分享筆者在實際工作中遇到的挑戰及相應的優化方案。首先，將介紹項目背景和當前系統的運行狀況；接著，將詳細探討性能指標量化、服務調用、CPU計算、內存治理及網絡IO等方面的優化策略；最后，將總結對性能優化的一些思考，并展望未來性能優化的方向。本文的目的是回顧并總結當前在線服務性能優化的工作，同時也希望這些經驗能為其他研發人員在處理類似問題時提供參考和啟發。

二、項目背景

筆者所在的團隊主要負責在線效果廣告引擎的研發工作，該服務作為商業化系統的重要組成之一，為公司帶來了實質性的商業貢獻。通過精準高效的廣告投放，能夠為公司帶來穩定且可觀的廣告收入，成為支撐平臺發展的關鍵營收來源之一，進一步支持了平臺的內容創新和技術研發，構成良性循環。對于廣告主而言，效果廣告引擎提供了精準定向用戶的能力，顯著提升了廣告傳播的效果，為其帶來更高的廣告轉化和投資回報。對于用戶而言，通過更貼近用戶行為習慣的廣告投放，確保了廣告內容與用戶興趣和需求的高度匹配，最大限度地保障了用戶體驗。

隨著效果廣告業務的快速發展，處理的業務復雜度不斷提升，對在線服務的處理效率和吞吐量提出了更高要求。同時，B站的用戶規模和使用時長的持續增長也加大了這一挑戰。以在線推理服務為例，它需要對廣告創意候選集進行一系列預估打分，主要包括特征計算和模型計算兩個環節。特征處理階段涉及用戶和廣告數據的提取、過濾、拼接等操作，隨著特征數據的深入挖掘和應用，所需要處理的數據量也在不斷增加。在模型計算階段，支持的模型類型從LR、FM模型逐漸升級到DNN模型，增強了模型的表達能力，但同時也加大了算力資源的消耗。類似的資源開銷增長問題也存在于效果廣告引擎的其他服務中。因此，工程研發團隊面臨的挑戰在于如何有效地對效果廣告引擎進行性能優化，確保在硬件資源相對有限的情況下，依然能夠支持并促進業務的持續增長。

三、系統現狀

首先需要介紹一下效果廣告引擎的系統構成，主要包含了以下幾個服務：

檢索引擎：作為廣告業務的入口，接受來自各個調用方的請求，并且會對流量進行預處理，其中包括對流量進行實驗分組和標記。

效果廣告檢索服務：作為效果廣告的業務核心，負責對候選集中的廣告創意進行優選，并且將勝選的結果回傳給檢索引擎。

召回/粗排服務：根據流量的上下文信息，從所有在投的廣告創意中挑選出一批符合條件的廣告創意，并且進行粗排打分，將最終的Top N作為候選集返回給效果廣告檢索服務。

推理服務：負責對候選集中的廣告創意進行一系列精排打分，將最終結果返回給效果廣告檢索服務。

此處需要說明的是，由于本文的重點是在線推理服務，因此對于廣告引擎中的其他部分進行了大幅簡化，實際的效果廣告引擎要更為復雜。為了進一步便于理解，使用下圖來說明簡化后的效果廣告引擎內部各服務之間的調用關系及主要功能模塊：

圖1 效果廣告引擎調用關系及主要功能模塊

目前效果廣告引擎的在線集群規模已經達到了數千臺服務器，其中在線推理服務的CPU資源占比約為整體的45%，召回/粗排服務占比約為21%，效果廣告檢索服務占比約為10%。通過CPU資源的分配比例，可以直觀反映出各服務之間計算復雜度的差異，同時也揭示了系統中存在的潛在性能瓶頸。推理服務作為系統資源開銷最大的在線服務，對其進行性能優化的收益也是最為顯著的。

在對效果廣告引擎的背景及現狀有了初步的了解之后，下面本文將針對推理服務的各項優化手段進行更為詳細的介紹。

四、優化手段

在實際工作中，對于在線服務的性能優化首先要建立在性能度量的基礎上，因此在開始優化之前，需要對在線服務的各項數據指標進行可量化的測量和分析。

性能指標量化

從宏觀角度來看，可以通過埋點的方式對在線服務的各個模塊耗時進行監控和分析，定位到耗時較高的模塊。之后，可以通過更細粒度的埋點或者日志，來找到開銷較高的操作，并進行性能優化。同時作為在線服務，效果廣告引擎的各服務之間的調用耗時也是需要監控的。受益于服務使用的BRPC框架，效果廣告引擎的子服務都實現了較為完善的監控指標，包括各模塊之間的平均耗時、中位數耗時、97線耗時等，并且對于各類遠程調用也都有對應的耗時監控指標。依靠這些能夠被量化的數據，我們能夠快速定位到哪些模塊和調用的耗時較高，并且能夠在開發人力有限的情況下，給出性能優化的先后順序，盡可能提高單次性能優化的收益。需要特別注意的是，在確保性能指標不失真的前提下，可以對性能指標的收集和上報進行一定程度的采樣操作，主要是為了防止性能度量本身給服務帶來過大的額外算力開銷。

服務調用

在得到較為完善的性能指標之后，就可以結合對于推理服務的業務理解，從業務流程和服務調用的角度對在線服務進行全局分析。這部分的優化思路主要是在處理一次用戶請求的過程中，減少數據的重復計算，并且降低數據傳輸的成本。

在較早的設計中，效果廣告檢索服務會將候選集中的廣告創意拆分成多個推理請求，并行發送給多個推理服務節點，從而確保單個請求的處理耗時不會較高。如上文所述，推理服務需要獲取用戶側的數據來進行特征處理，這些數據存放在Redis集群中。因此在處理每一個推理請求時，推理服務都需要單獨訪問一次Redis來獲取用戶數據，造成了Redis服務端訪問較多，并且數據重復傳輸的問題。通過將訪問Redis的操作上移至廣告檢索服務，然后再發送給推理服務的方式，有效減少了對Redis服務的訪問量，降低了Redis服務端的算力開銷和網絡IO開銷。

此外，在對早期方案重構的過程中，我們對服務調用之間所使用的數據格式也進行了升級，將原本類似JSON的數據處理方式，升級成了基于Protobuf3的數據處理方式。相比于文本格式的JSON，PB編碼的數據通常更小，并且擁有更快的序列化和反序列化速度，這在處理大量數據時尤其重要。同時，將推理請求中的字段類型與特征計算中所需要的數據類型進行對齊，減少了大量的字符串轉化及數據校驗操作，降低了CPU算力開銷。

這一類問題看似比較基礎，但是在早期引擎架構快速迭代的過程中，由于不同階段的各種原因，導致各個服務之間的設計無法完全一致，一些細節問題是比較容易被忽略的。隨著業務的迭代和增長，這類小問題的影響就會被逐漸放大，導致服務性能下降和算力資源浪費。因此，定期對在線服務的業務和架構進行梳理回顧，是保障服務健康穩定的重要手段之一。

CPU算力

將視角聚焦到推理服務中，對于單次推理請求，我們同樣也可以使用減少數據重復計算的方式來降低CPU算力開銷，并且可以使用Perf性能分析工具，來進一步優化熱點函數的算力開銷。

首先在進行特征計算的過程中，包含了對于用戶側特征和廣告側特征的處理，其中用戶側特征的計算結果是能夠被重復使用的。在推理服務的處理過程中，單次請求中的多個廣告創意，會使用多線程并行的方式進行處理，此時會先將用戶側數據與單個廣告創意進行計算，將結果存儲在特征計算的運行時對象中，并且通過標記來區分用戶側特征和廣告側特征。然后，將其中的用戶側特征計算結果復制到其他線程的運行時對象中，再啟動線程進行并行計算。這樣既可以使用多線程來提高批量廣告的特征計算處理速度，又不會因為重復計算用戶側數據而造成額外的算力開銷。

進一步的，通過使用Perf性能分析工具，可以觀察到具體某段代碼的執行效率，并且分析出主要的性能開銷點。在實際工作中，由于推理服務本身的迭代較為頻繁，我們會定期對服務性能進行評估和回顧。當發現存在性能熱點時，會優先進行性能優化，常見的代碼優化手段有：

1. 減少分支：分支預測失敗會導致CPU流水線刷新，浪費大量的CPU周期。盡可能地減少分支，或者盡量使分支預測更加準確，可以幫助提高代碼的性能。
2. 循環展開：循環展開可以減少分支和循環開銷，同時也可以提高指令級并行性。但是也要注意，過度展開可能會增大代碼體積，對指令緩存造成壓力。
3. 數據局部性優化：盡可能地保持數據的局部性，使得數據能夠高效地利用CPU緩存。這包括空間局部性（訪問相鄰的數據項）和時間局部性（短時間內重復訪問同一數據項）。
4. 向量化：利用CPU的SIMD指令集，可以同時對多個數據進行操作。在編寫代碼時，盡可能使數據結構和算法可以利用SIMD指令進行向量化操作。

針對這些優化手段，下面筆者會提供一些實際工作中遇到的具體事例以作參考。

1. 使用__builtin_expect內建函數來提供分支預測的提示，該函數會給GCC編譯器提示，告知其某個條件判斷的結果更可能是true還是false，通常用于優化代碼中高度可能或者不可能執行的分支。在實際編寫代碼的過程中，該函數通常與宏一起使用，包括Linux在內的各種代碼中都封裝了自己likely和unlikely宏來提高性能。

2. 使用循環展開來提高代碼性能，下面這段代碼是通過循環展開來優化數據構建的例子，需要注意的是，當批量處理完展開部分的循環體之后，還需要處理剩余的迭代。

// 循環展開
for (uint32_t idx = start_idx; idx + 3 < end_idx; idx += 4) {
    result[value[idx]].emplace_back(feaid, ins);
    result[value[idx + 1]].emplace_back(feaid, ins);
    result[value[idx + 2]].emplace_back(feaid, ins);
    result[value[idx + 3]].emplace_back(feaid, ins);
}
// 處理剩余的迭代
for (uint32_t idx = end_idx - (end_idx - start_idx) % 4; idx < end_idx; ++idx) {
    result[value[idx]].emplace_back(feaid, ins);
}

3. 使用函數指針的方式來減少條件判斷，并且提高時間局部性，下面是一個簡化后的例子。這段代碼的目的是根據“field_type”獲取“AdInfo”類中對應的成員函數指針，并且在一個循環中對“ad_info_list”集合中的每一個“AdInfo”對象調用這個成員函數。

typedef int64_t (AdInfo::*field_func)(void) const;
static field_func get_field_func(int field_type) {
    switch(field_type) {
        case 1:
            return &AdInfo::id1;
        case 2:
            return &AdInfo::id2;
        case 3:
            return &AdInfo::id3;
        default:
            return nullptr;
    }
}
 
auto selected_func = get_field_func(field_type);
if (selected_func != nullptr) {
    for (const auto& ad_info : ad_info_list) {
        auto val = (ad_info.*selected_func)();
        // ...
    }
}

4. 利用AVX指令集進行并行計算，下面是一個使用AVX256指令集計算兩個“std::vector”向量的點積的代碼示例，首先使用“_mm256_mul_ps“函數和“_mm256_add_ps”函數完成了浮點數的相乘和累加，然后通過“_mm256_hadd_ps”函數得到計算結果，最后處理不能被8整除的部分。

float dot_product_avx256(const std::vector<float>& vec1, const std::vector<float>& vec2) {
    if (vec1.size() != vec2.size()) {
        return 0;
    }
    size_t vec_size = vec1.size();
    size_t block_width = 8;
    size_t loop_cnt = vec_size / block_width;
    size_t remainder = vec_size % block_width;
 
    __m256 sum = _mm256_setzero_ps();
    for (size_t i = 0; i < loop_cnt * block_width; i += block_width) {
        __m256 a = _mm256_loadu_ps(&vec1[i]);
        __m256 b = _mm256_loadu_ps(&vec2[i]);
        __m256 c = _mm256_mul_ps(a, b);
        sum = _mm256_add_ps(sum, c);
    }
    __m256 hsum = _mm256_hadd_ps(sum, sum);
    __m256 hsum2 = _mm256_hadd_ps(hsum, hsum);
    float result[8];
    _mm256_storeu_ps(result, hsum2);
    float dot = result[0] + result[4];
 
    for (size_t i = loop_cnt * block_width; i < vec_size; ++i) {
        dot += vec1[i] * vec2[i];
    }
 
    return dot;
}

對于在線服務的性能優化是一件細致且瑣碎的工作，上述的優化手段及實踐僅是一小部分，更多繁復的細節不再贅述。針對不同的業務場景，性能優化是否最終有效還需要更全面的測試才能得到驗證。通過“觀測、定位、優化、測試”這樣的正向循環，在經過持續一年的性能優化后，推理服務的CPU開銷相對降低了21%，同時峰值的吞吐量提高了13%。

內存治理

在內存治理方面，常見的優化手段主要圍繞著數據格式的設計與升級，而此處筆者想分享的，是關于服務運行時的內存治理。具體到實際工作中，效果廣告引擎中的多數在線服務，都是基于BRPC框架開發的C++服務，通過SessionData對象來管理一次請求中的數據。

在筆者目前使用的版本中，BRPC框架可以通過在服務啟動時預生成若干個SessionData對象來響應請求，當某個SessionData對象完成一次響應后，會清理其中保存的數據以等待下一個請求調用。當SessionData對象中需要存儲的成員變量過多時，就會產生頻繁的內存申請和釋放，同時容易導致內存碎片化。為了解決這個問題，我們對SessionData中的數據進行了預分配和池化處理，當SessionData創建時就對其進行了初始化，一次性分配了所需的內存，并且在清理數據時僅重置數據而不進行銷毀操作。

此外，SessionData對象本身也是通過一個對象池進行管理的，當請求到達時會從對象池中獲取一個SessionData對象來處理請求，當請求處理完成后歸還至對象池中。若在線服務的訪問量突然增加，或者服務處理時間突然變長時，將會導致對象池中沒有可用的SessionData對象。此時，對象池會創建并初始化新的SessionData對象以響應后續請求。然而，當服務恢復平穩之后，這些新創建出的SessionData對象就會處于閑置狀態，不會被主動回收釋放，這就導致了運行時內存的增加。為了解決這個問題，通過BRPC框架中的hook函數，實現了SessionData對象的回收機制。需要注意的是，回收SessionData對象時會釋放一部分內存，如果同時進行大量的回收操作，會導致服務性能的抖動，因此設計了一個較為平滑的回收方案。當服務檢測到目前對象池的空閑對象數量大于設定時，會按一定概率對多余的SessionData對象進行回收，在保證服務的穩定性和彈性的同時，也有效降低了服務運行時的內存開銷。根據SessionData對象在服務中的定義及內存占比不同，在線服務的運行時內存開銷下降了約15%～22%左右。

網絡IO

在網絡IO方面，已經通過采用Protobuf作為服務間的傳輸格式來降低數據的傳輸量，然而對于一些特殊場景而言，直接使用原生的數據格式可能并不是最優解。

例如，推理服務以容器化的方式部署在物理機上，服務需要加載多個模型數據以及用于進行特征計算的正排詞表數據，當內存占用較大時會使用多個節點的NUMA節點內存，當出現訪問遠端節點的內存時會導致一定的內存延遲增加。由于推理服務是一個計算密集型的服務，在負載較高時帶寬競爭的情況會更為明顯，內存延遲可能會導致服務的響應時間顯著升高，嚴重情況下可能會導致服務不可用。

為了解決這類問題，同時進一步對服務架構進行解耦，計劃將推理服務中的模型計算模塊單獨進行服務化改造，同時該服務僅需要加載少量模型數據，將內存用量限制在單個NUMA節點所管理的內存空間內，通過將進程進行NUMA節點綁定的部署方式避免了跨節點訪問內存。

在這個設計方案中，推理服務需要在特征計算后，將每個廣告創意得到的特征簽名數組（通常為uint64數組）發送給模型計算服務。最直觀的數據傳輸方案是為每一個待處理的廣告創意定義一個uint64數組來傳輸特征簽名數組，這里有個問題就是每個uint64數組都會添加一些額外的數據信息，導致消息體變大。并且由于每個特征簽名都是經過哈希計算后的數值較大的uint64，因此Protobuf內置的變長算法并不能起到壓縮數據的作用。

// 原版（未使用）
message Input {
    repeated uint64 value = 1 [packed = true];
}
message Request {
    repeated Input inputs = 1;
}

改進后的設計，是將所有廣告創意放在同一個uint64數組中，并且新增一個uint32數組來記錄每個廣告創意對應的特征簽名下標。使用兩個大數組的方式降低了數據傳輸開銷。

// 改進I
message Request {
    repeated uint32 index = 1 [packed = true];
    repeated uint64 value = 2 [packed = true];
}

由于在同一批請求中，包含了許多公共的特征簽名，主要是來自用戶側的特征數據，因此可以提取出公共的部分，以減少value中的重復數據。相較于“改進I”，實測網絡傳輸的帶寬下降了50%。

// 改進II
message Request {
    repeated uint32 index = 1 [packed = true];
    repeated uint64 value = 2 [packed = true];
    repeated uint64 shared = 3 [packed = true];
}

在“改進II”方案上取得的收益，主要來自于用戶側特征簽名占整體比例的多少，隨著將來模型的迭代升級，這個比例的變化情況會難以預估，并且篩選公共特征簽名的過程也帶來了不少的性能開銷。最終的數據傳輸方案采用倒排索引的方式，對同一批次的特征簽名和廣告創意創建一個倒排索引。

// 改進III
message Inverted {
    repeated uint64 key = 1 [packed = true];
    repeated uint32 index = 2 [packed = true];
    repeated uint32 value = 3 [packed = true];
    repeated uint32 length = 4 [packed = true];
}
message Request {
    Inverted inverted = 1;
}

在“改進III”方案中，key字段用來存儲所有的特征簽名，index字段記錄了每個特征簽名對應在value數組中的起始和終止下標，value字段則記錄了該特征簽名所對應的廣告創意下標。這個方案的優點是所有特征簽名數據僅記錄一次，最大限度減少了不可壓縮的uint64的數據量，index和value字段的數值大小十分有限，在實際場景中都可以通過變長壓縮的方式進行大幅壓縮，同時使用了packed標志，進一步減少了元數據帶來的開銷。為了后續重建每個廣告創意的特征簽名列表時的性能考慮，額外定義了length字段來存儲每個廣告創意的特征簽名列表長度。即使在額外增加length信息之后，相較于“改進II”方案，該方案進一步將網絡傳輸的帶寬下降了10%，同時由于構建請求的計算復雜度下降，構建請求的模塊耗時也降低了14%，在降低網絡IO的同時，也降低了CPU算力開銷。

五、思考與展望

在保障業務持續迭代的同時，通過對在線服務進行多輪不斷的升級和優化，服務性能有了顯著提升，其中CPU、內存、網絡IO等資源的使用效率得到了明顯改善，在線集群整體節省了上萬核的CPU算力。在此過程中，研發團隊也積累了豐富的經驗和知識，將為未來的項目研發提供了重要支持。

性能優化是一個持續的過程，它要求我們的研發人員在業務發展和技術更新的過程中不斷發現問題、探索解決方案，并持續進行精細化調整。這不僅僅是一個單次任務，而是一個長期的、不斷打磨和優化的過程，旨在尋找既實用又高效的優化策略。更為關鍵的是，性能優化往往不是孤立的任務，而是需要跨服務、跨團隊的協作，這要求項目主導方需要全面考慮系統的負載和收益，協同各方共同推進優化方案的實施，實現真正的效益最大化。

在編寫本文的過程中，由于文章篇幅限制以及個人工作經驗的局限，筆者僅能分享在線推理服務性能優化方面的部分心得和成果。在此，要感謝所有在工作項目中給予幫助和支持的公司及團隊成員。本文旨在為從事相關領域的讀者提供一些啟發，尤其希望能對面臨類似性能挑戰的研發人員帶來靈感和實際收獲。

本期作者

李淵馳嗶哩嗶哩資深開發工程師