作者 ｜ 王碩

業(yè)務背景

在我們團隊的視頻審核服務中臺里，每天需要處理海量的視頻進審截圖。為了全方位保障內容安全，我們引入了多種 AI 小模型對圖片進行并發(fā)檢測，主要包括：

• 自研色情檢測服務（基于 ViT 模型）：Vision Transformer 擅長捕捉全局上下文信息，對于大面積的違規(guī)畫面有極高的識別率。

• 自研黑產分類檢測（基于 YOLO-cls 模型）：用于識別黑灰產廣告、二維碼貼紙、引流文字等具有特定特征的局部變體。

• 高級布控圖片檢測（基于 Chinese-CLIP）：基于圖文多模態(tài)大模型，把圖片生成高維 Embedding，然后同 Milvus 中的海量違規(guī)樣本庫進行近似最近鄰（ANN）向量比對，以實現(xiàn)“零樣本”命中相似變體圖。

• 臺標 / 拉橫幅目標檢測（基于 YOLO-det 模型）：需要精準輸出 Bounding Box，識別畫面中是否存在違規(guī)的橫幅、旗幟或特定標志。

初期的架構與“溫水煮青蛙”的困境

在系統(tǒng)建設初期，我們采用了經典的“責任鏈模式”（串行檢測）。架構設計的初衷是“快速失?。‵ail-Fast）”：按照命中率從高到低排列，一旦圖片命中某個違規(guī)項，就立刻中斷并返回結果，節(jié)約后續(xù)的 GPU 算力。

這套邏輯在邏輯推演上無懈可擊，但在真實的業(yè)務大盤數(shù)據(jù)面前卻暴露了致命的痛點：在真實的 UGC 業(yè)務場景中，90% 以上的圖片都是合法合規(guī)的。這意味著對于絕大多數(shù)的審核請求，四個模型必須“跑滿”全流程。串行架構下，整體耗時 = 各個模型耗時之和（例如：色情 80ms + 黑產 90ms + 布控 110ms = 280ms）。隨著我們后續(xù)即將接入“暴恐識別”、“旗幟識別”等更多模型，審核鏈路的 P99 延遲將奔向 500ms 甚至 1 秒以上，這對于實時 / 準實時審核業(yè)務是絕對不可接受的。

深度痛點分析：為什么

“串行改并行”沒那么簡單？

發(fā)現(xiàn)串行耗時過長后，團隊的第一直覺是：引入 CompletableFuture，串行改并行不就行了嗎？

但在深度梳理了整個請求鏈路，并用鏈路追蹤工具（SkyWalking）生成了火焰圖后，我們發(fā)現(xiàn)僅僅改并行遠遠不夠。系統(tǒng)的底層還潛伏著三個巨大的性能黑洞，如果把這些原封不動地并行化，不僅延遲降不下來，還會引發(fā)嚴重的系統(tǒng)雪崩。

黑洞一：被忽視的序列化與 IO 傳輸開銷

在之前的微服務調用中，由于歷史包袱，有的業(yè)務方傳圖片 URL，有的傳 Base64 編碼。

• Base64 Base64 編碼不僅會把原有的二進制數(shù)據(jù)體積撐大近 33%，還會導致 Java 網關層在反序列化時產生大量的 String 對象，給 JVM 年輕代帶來巨大的 GC（垃圾回收）壓力。網絡傳輸大包頭的數(shù)據(jù)也會吃滿帶寬。

• URL 如果傳 URL，會導致各個下游的 AI 檢測節(jié)點各自去發(fā)起 HTTP 請求拉取圖片。在分布式網絡中，公網 / 內網的抖動極其常見，拉取同一張圖，4 個服務可能經歷 4 次不同的網絡延遲、DNS 解析耗時、甚至 Read Timeout，這讓鏈路穩(wěn)定性大打折扣。

黑洞二：極其嚴重的算力浪費（重復前處理）

在傳統(tǒng)的 AI 服務部署生態(tài)中，通常是 Java 業(yè)務端把原圖發(fā)給各個推理服務，由各個推理服務自己使用 Python（通常是 OpenCV 或 PIL 庫）去做 Decode（解碼）、Resize（縮放）和 Crop（裁剪）。我們仔細研讀了四個模型的輸入 Tensor（張量）要求，發(fā)現(xiàn)了驚人的計算復用空間：

• ViT (色情)：需要輸入 224x224 的特征圖（一般直接 Resize 拉伸縮?。?/p>

• CLIP (布控)：同樣需要 224x224，但由于要提取高維特征，強烈依賴 BICUBIC（雙三次插值）算法來保證縮小后的圖片細節(jié)不丟失。

• YOLO-cls (黑產)：需要 640x640 的分辨率（通常采用按比例縮放后居中 Crop 裁剪）。

• YOLO-det (目標檢測)：同樣是 640 級別的輸入要求。

如果按照傳統(tǒng)做法，把一張 1080P 的原圖分別并發(fā)發(fā)給 4 個 Python 節(jié)點，同一張高清圖片會被反序列化 4 次，解碼 4 次，Resize 4 次！在 Python 的生態(tài)中，受限于 GIL（全局解釋器鎖），密集型的圖片解碼和矩陣變換不僅極度消耗 CPU 資源，還會拖慢同一臺機器上 GPU 的數(shù)據(jù)喂入（Data Loading）速度，最終導致 AI 服務的吞吐量（QPS）被前處理死死卡住。

黑洞三：黑產幻燈片與冗余幀

通過對線上違規(guī)樣本的聚類分析，我們發(fā)現(xiàn)相當一部分的黑灰產視頻、廣告、以及 AI 自動生成的視頻，往往采用類似“幻燈片”的呈現(xiàn)方式。我們的抽幀組件在一個視頻內可能抽出 8 張圖，這 8 張圖在視覺上肉眼可見地幾乎一模一樣。如果不做任何去重策略，這些重復的圖片不僅在 Java 測會重復走上述的復雜邏輯，更會把珍貴且昂貴的 GPU 算力浪費在推理一模一樣的張量數(shù)據(jù)上。

架構重構：壓榨性能的 “組合拳”設計

針對上述三大痛點，我們沒有停留在表面修補，而是對整體中臺鏈路進行了一次“刮骨療毒”式的重構。

優(yōu)化點 1：統(tǒng)一收口，全鏈路零拷貝

Byte 字節(jié)流傳輸

為了徹底解決 IO 與 GC 的瓶頸，我們全面廢棄了內部微服務鏈路中的 URL 和 Base64 傳輸。在網關層，我們強制將外部請求轉化為圖片的純二進制 byte[]（字節(jié)數(shù)組）。在后續(xù)的內部 RPC 調用、并發(fā)分發(fā)過程中，全部基于內存中的字節(jié)數(shù)組直接傳遞。

• 收益：消滅了 33% 的帶寬冗余，打掉了 JVM 處理巨大 Base64 字符串帶來的 CPU 飆升與 Full GC 風險，同時規(guī)避了下游并發(fā)去對象存儲拉取同一張圖片的網絡抖動問題。全局只有在最頂層網關發(fā)起一次拉圖 IO 請求。

優(yōu)化點 2：前置公共處理中間層

（Java 側統(tǒng)籌 AI 前處理）

這是本次架構優(yōu)化最核心、收益最大的一環(huán)。我們打破了“業(yè)務層只管發(fā)數(shù)據(jù)，AI 層自己管處理”的傳統(tǒng)思維，將原本分散在各個 Python AI 節(jié)點的圖像預處理工作，剝離、上浮并收斂到了 Java 中臺側。

當請求到達時，Java 中臺會根據(jù) Apollo 配置中心動態(tài)讀取當前圖片需要經過哪些檢測模型，隨后利用 Java 原生強大的多線程能力，統(tǒng)一生成各模型需要的定制化特征圖，然后再并發(fā)推送給下游。

我們引入了 Thumbnailator 庫，并設計了“混合模式 (Mixed Mode) 決策樹”。如果一張圖既需要 640 尺寸，又需要 224 尺寸，我們絕不解碼兩次！而是采用“一魚兩吃”的流水線模式：

@Service
@Slf4j
public class ImageResizeService {

     private static final Set 
 
 SQUASH_GROUP = EnumSet.of(CheckMethod.NSFW, CheckMethod.CH_CLIP); 
 
    private static final Set 
 
 CROP_GROUP = EnumSet.of(CheckMethod.YOLO_HEICHAN); 
 

     public static final String FORMAT_OUT_PUT = "jpg";
    public static final int IMAGE_SIZE_SMALL = 224;
    public static final int IMAGE_SIZE_LARGE = 640;

     /**
     * 核心入口：動態(tài)分析需求并生成對應的尺寸
     */
    public Map 
 
 resizeForChecks(byte[] originalBytes, List 
 
 methods) throws IOException { 
 
 
        Map 
 
 resultMap = new EnumMap<>(CheckMethod.class); 
 
        if (CollectionUtils.isEmpty(methods)) return resultMap;

         boolean needSquash = methods.stream().anyMatch(SQUASH_GROUP::contains);
        boolean needCrop = methods.stream().anyMatch(CROP_GROUP::contains);

         if (needSquash && needCrop) {
            // 混合模式：一圖多吃
            processMixedMode(originalBytes, methods, resultMap);
        } else if (needSquash) {
            processSquashOnly(originalBytes, methods, resultMap);
        } else if (needCrop) {
            processCropOnly(originalBytes, methods, resultMap);
        }
        return resultMap;
    }

     private void processMixedMode(byte[] originalBytes, List 
 
 methods, Map 
 
 resultMap) throws IOException { 
 
 
        // 1. 解碼 (IO 耗時，全局僅此一次)
        BufferedImage original = ImageIO.read(new ByteArrayInputStream(originalBytes));
        if (original == null) throw new IOException("Image decode failed");

         // 2. 計算中間態(tài)尺寸 (按最短邊 640 縮放)
        int w = original.getWidth();
        int h = original.getHeight();
        int targetShort = IMAGE_SIZE_LARGE;
        int interW = w < h ? targetShort : (int) (w * ((double) targetShort / h));
        int interH = w < h ? (int) (h * ((double) targetShort / w)) : targetShort;

         // 3. 生成中間態(tài)圖片 (必須使用 BICUBIC 保證 CLIP 的高質量要求)
        BufferedImage intermediate = Thumbnails.of(original)
                .size(interW, interH)
                .resizer(Resizers.BICUBIC)
                .asBufferedImage();

         // 4.1 生成 Crop 數(shù)據(jù) (給 YOLO-CLS -> 640x640 居中裁剪)
        byte[] cropBytes;
        try (ByteArrayOutputStream os = new ByteArrayOutputStream()) {
            Thumbnails.of(intermediate)
                    .sourceRegion(Positions.CENTER, IMAGE_SIZE_LARGE, IMAGE_SIZE_LARGE)
                    .size(IMAGE_SIZE_LARGE, IMAGE_SIZE_LARGE)
                    .outputFormat(FORMAT_OUT_PUT)
                    .toOutputStream(os);
            cropBytes = os.toByteArray();
        }

         // 4.2 生成 Squash 數(shù)據(jù) (給 NSFW, CLIP -> 224x224 強制拉伸)
        byte[] squashBytes;
        try (ByteArrayOutputStream os = new ByteArrayOutputStream()) {
            Thumbnails.of(intermediate)
                    .forceSize(IMAGE_SIZE_SMALL, IMAGE_SIZE_SMALL)
                    .outputFormat(FORMAT_OUT_PUT)
                    .toOutputStream(os);
            squashBytes = os.toByteArray();
        }

         // 5. 組裝結果并分發(fā)...
    }
}

架構思考：為什么用 Java 做圖像前處理而不是 C++ 或 Python？Java 的長處在于高并發(fā)和工程管理。雖然 OpenCV (C++) 的絕對單幀處理速度比 Java 快，但在高并發(fā) RPC 場景下，JNI (Java Native Interface) 的內存拷貝開銷極其昂貴。通過純 Java 實現(xiàn)中間層，不僅部署輕量，還能完美契合現(xiàn)有的 JVM 內存調優(yōu)體系，配合并行 Stream，其綜合吞吐量反而是最高的。

優(yōu)化點 3：基于 pHash 與

貪心圖染色算法的智能批次去重

為了徹底解決幻燈片視頻幀的算力浪費，我們在進入“核心縮放邏輯”和“并行推理”之前，增加了一個輕量級的預處理網關：感知哈希（pHash）分組去重。

pHash（Perceptual Hash）能夠根據(jù)圖像的低頻特征生成一串指紋，對圖像的縮放、微小水印等具備極強的抗干擾能力。我們計算單批次所有圖片的 pHash，然后通過計算漢明距離（Hamming Distance）來判斷圖片是否相似。

如果一批抽幀截圖中存在相似的圖片，怎么高效且嚴謹?shù)匕阉鼈兎值酵唤M？我們巧妙地借用了計算機科學中的經典算法——沖突圖與圖染色算法（Graph Coloring）。

• 連邊（構建沖突）：如果兩張圖片差異較大（漢明距離 > 閾值 maxDistance），說明它們絕對不能分在同一個去重組，我們在它們之間連一條邊，表示“沖突”。

• 貪心染色（分配組別）：用最少的顏色給圖節(jié)點染色，保證任何兩個相連的節(jié)點顏色不同。顏色相同的節(jié)點，就是互相之間沒有邊（即極度相似）的圖片集合！

• 執(zhí)行策略：針對染色后分到同一組的圖片，中臺只取組內的 第一張 圖片進入后面的 ImageResizeService 和 AI 并發(fā)推斷，其余同組圖片直接掛起等待。推斷完成后，結果直接復用賦予掛起的圖片。

聚類核心代碼：

public Map 

 > clusterByHashDistance(List 

 list, int maxDistance) { 


    // 過濾無 pHash 的數(shù)據(jù)
    List 

 validList = list.stream() 

            .filter(bo -> Objects.nonNull(bo.getImagePHash()))
            .collect(Collectors.toList());

     // 構建沖突圖：差異大于 maxDistance 的節(jié)點之間連邊
    List 
 
 > conflictGraph = buildConflictGraph(validList, maxDistance); 
 
    int n = validList.size();

     // 貪心染色：colors[i] 表示第 i 個節(jié)點的顏色編號（即組編號）
    int[] colors = new int[n];
    Arrays.fill(colors, -1);

     for (int i = 0; i < n; i++) {
        Set 
 
 usedColors = new HashSet<>(); 
 
        for (int neighbor : conflictGraph.get(i)) {
            if (colors[neighbor] != -1) {
                usedColors.add(colors[neighbor]);
            }
        }
        // 選擇最小的可用顏色
        int color = 0;
        while (usedColors.contains(color)) {
            color++;
        }
        colors[i] = color;
    }

     // 按顏色分組返回
    Map 
 
 > groupMap = new HashMap<>(); 
 
    for (int i = 0; i < n; i++) {
        groupMap.computeIfAbsent(colors[i], k -> new ArrayList<>()).add(validList.get(i));
    }
    return groupMap;
}

算法復雜度分析：考慮到單次視頻進審抽幀一般在 19 張以內，節(jié)點數(shù) N 較小, 構建沖突圖耗時 O(N^2), 染色復雜度 O(N+E), 在 Java 中執(zhí)行時間幾乎可以忽略不計（不到 1ms），但卻能阻斷后續(xù)大量的重度 CPU/GPU 計算，ROI 極高。

優(yōu)化效果與深度反思：打破“木桶理論”

新架構上線后，我們迎來了極其驚艷的數(shù)據(jù)表現(xiàn)。

核心指標對比：

• 重構前（串行）：色情 (80ms) + 黑產 (90ms) + 布控 (110ms) = 平均總耗時約 280ms。

• 重構后（多路并發(fā) + 統(tǒng)籌前置處理 + 圖染色去重）：復合檢測的總平均耗時穩(wěn)定在了 90ms 左右！

深度剖析：為什么總耗時

跑贏了最慢的那個模型？

這是本次優(yōu)化中最值得玩味的數(shù)據(jù)。按照傳統(tǒng)的并發(fā)思維（即“木桶理論”），并行計算的總耗時應當取決于耗時最長的那個分支。原本的 CLIP 服務單次耗時是 110ms，哪怕并發(fā)執(zhí)行，整體耗時理應也在 110ms 左右。但為什么我們的實際中位數(shù)耗時跑進了 90ms？

答案在于：我們?yōu)?AI 節(jié)點實施了深度的“算力減負”。原先測得的 110ms，是一個“胖接口”的耗時。它包含了：HTTP 網絡拉取大圖 + Python 解釋器環(huán)境下的解碼 + OpenCV Resize/Crop 變換 + GPU 矩陣推斷。

在新架構下，極其消耗 CPU 的“圖像解碼與多尺度插值裁剪”這部分工作，被剝離并集中到了更擅長高并發(fā)多線程的 Java 中臺。通過本地網卡 / 內網 RPC 直接灌入下游的，是已經量身定做好的 224x224 或 640x640 的純凈小體積字節(jié)流。此時的 Python AI 服務被徹底解放，它不再需要去處理惡心的圖像 IO 和 CPU 軟解，而是直接將收到的字節(jié)流轉化為 Tensor 扔進 GPU（或者交由 Triton Inference Server 進行 Dynamic Batching 動態(tài)組批）。AI 模型自身的純 Inference（推斷）耗時，其實只有短短的幾十毫秒。

整體耗時 = Java 統(tǒng)籌前處理 (~15ms) + 網絡傳輸極小特征圖 (~5ms) + GPU 純推斷 (~70ms) ≈ 90ms。我們用架構的重組，擊穿了原本的性能底線。

總結與未來展望

在微服務泛濫和 AI 大模型爆火的今天，后端工程師非常容易陷入一種“服務絕對隔離”的思維定勢：把 AI 模型當成一個不可褻玩的“黑盒”，認為調用方只管扔原圖，AI 服務自己處理一切。

但當我們打破這種邊界，從全局鏈路的視角去審視網絡 IO 損耗、CPU/GPU 算力分布，并深入理解各種 AI 模型的數(shù)據(jù)輸入特征時，往往能發(fā)現(xiàn)極其可觀的優(yōu)化空間。把非 AI 核心邏輯（網絡拉取、圖片解碼、縮放插值、哈希去重）向上層收斂，讓底層的 GPU 更純粹、更專注地去做高密度矩陣運算，這才是大吞吐量 AI 審核中臺架構設計的正確范式。

后續(xù)演進思考

未來，隨著審核規(guī)模的進一步擴張，我們計劃向架構的更深處探索：

• AI 節(jié)點前置網關化：引入 NVIDIA Triton 等專業(yè)的推理服務器替代現(xiàn)有的 Python Flask/FastAPI 封裝，利用其 Dynamic Batching 功能，將高并發(fā)的散列請求組裝為大 Batch，進一步壓榨 GPU 的吞吐極限。

• 跨語言共享內存（Zero-Copy）：如果在 Kubernetes 集群的同一個 Pod 中混部 Java 中臺服務與 AI 推理容器，我們甚至可以考慮通過共享內存（如 Apache Arrow / Plasma 甚至 RDMA）來傳遞圖像的 Tensor 矩陣，徹底消滅最終的 RPC 序列化開銷。

希望這篇我們在底層性能優(yōu)化上的實戰(zhàn)復盤，能為正在從事 AI 工程化落地、高并發(fā)中臺建設的開發(fā)者們帶來一些不一樣的啟發(fā)。

會議推薦

世界模型的下一個突破在哪？Agent 從 Demo 到工程化還差什么？安全與可信這道坎怎么過？研發(fā)體系不重構，還能撐多久？

AICon 上海站 2026，4 大核心專題等你來：世界模型與多模態(tài)智能突破、Agent 架構與工程化實踐、Agent 安全與可信治理、企業(yè)級研發(fā)體系重構。14 個專題全面開放征稿。

誠摯邀請你登臺分享實戰(zhàn)經驗。AICon 2026，期待與你同行。

今日薦文

你也「在看」嗎？