作者 ｜ 王碩

業(yè)務(wù)背景

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

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

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

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

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

初期的架構(gòu)與“溫水煮青蛙”的困境

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

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

深度痛點(diǎn)分析：為什么

“串行改并行”沒(méi)那么簡(jiǎn)單？

發(fā)現(xiàn)串行耗時(shí)過(guò)長(zhǎng)后，團(tuán)隊(duì)的第一直覺(jué)是：引入 CompletableFuture，串行改并行不就行了嗎？

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

黑洞一：被忽視的序列化與 IO 傳輸開(kāi)銷

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

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

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

黑洞二：極其嚴(yán)重的算力浪費(fèi)（重復(fù)前處理）

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

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

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

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

• YOLO-det (目標(biāo)檢測(cè))：同樣是 640 級(jí)別的輸入要求。

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

黑洞三：黑產(chǎn)幻燈片與冗余幀

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

架構(gòu)重構(gòu)：壓榨性能的 “組合拳”設(shè)計(jì)

針對(duì)上述三大痛點(diǎn)，我們沒(méi)有停留在表面修補(bǔ)，而是對(duì)整體中臺(tái)鏈路進(jìn)行了一次“刮骨療毒”式的重構(gòu)。

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

Byte 字節(jié)流傳輸

為了徹底解決 IO 與 GC 的瓶頸，我們?nèi)鎻U棄了內(nèi)部微服務(wù)鏈路中的 URL 和 Base64 傳輸。在網(wǎng)關(guān)層，我們強(qiáng)制將外部請(qǐng)求轉(zhuǎn)化為圖片的純二進(jìn)制 byte[]（字節(jié)數(shù)組）。在后續(xù)的內(nèi)部 RPC 調(diào)用、并發(fā)分發(fā)過(guò)程中，全部基于內(nèi)存中的字節(jié)數(shù)組直接傳遞。

• 收益：消滅了 33% 的帶寬冗余，打掉了 JVM 處理巨大 Base64 字符串帶來(lái)的 CPU 飆升與 Full GC 風(fēng)險(xiǎn)，同時(shí)規(guī)避了下游并發(fā)去對(duì)象存儲(chǔ)拉取同一張圖片的網(wǎng)絡(luò)抖動(dòng)問(wèn)題。全局只有在最頂層網(wǎng)關(guān)發(fā)起一次拉圖 IO 請(qǐng)求。

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

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

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

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

我們引入了 Thumbnailator 庫(kù)，并設(shè)計(jì)了“混合模式 (Mixed Mode) 決策樹(shù)”。如果一張圖既需要 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;

     /**
     * 核心入口：動(dòng)態(tài)分析需求并生成對(duì)應(yīng)的尺寸
     */
    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 耗時(shí)，全局僅此一次)
        BufferedImage original = ImageIO.read(new ByteArrayInputStream(originalBytes));
        if (original == null) throw new IOException("Image decode failed");

         // 2. 計(jì)算中間態(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 的高質(zhì)量要求)
        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 強(qiáng)制拉伸)
        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. 組裝結(jié)果并分發(fā)...
    }
}

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

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

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

為了徹底解決幻燈片視頻幀的算力浪費(fèi)，我們?cè)谶M(jìn)入“核心縮放邏輯”和“并行推理”之前，增加了一個(gè)輕量級(jí)的預(yù)處理網(wǎng)關(guān)：感知哈希（pHash）分組去重。

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

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

• 連邊（構(gòu)建沖突）：如果兩張圖片差異較大（漢明距離 > 閾值 maxDistance），說(shuō)明它們絕對(duì)不能分在同一個(gè)去重組，我們?cè)谒鼈冎g連一條邊，表示“沖突”。

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

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

聚類核心代碼：

public Map 

 > clusterByHashDistance(List 

 list, int maxDistance) { 


    // 過(guò)濾無(wú) pHash 的數(shù)據(jù)
    List 

 validList = list.stream() 

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

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

     // 貪心染色：colors[i] 表示第 i 個(gè)節(jié)點(diǎn)的顏色編號(hào)（即組編號(hào)）
    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;
}

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

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

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

核心指標(biāo)對(duì)比：

• 重構(gòu)前（串行）：色情 (80ms) + 黑產(chǎn) (90ms) + 布控 (110ms) = 平均總耗時(shí)約 280ms。

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

深度剖析：為什么總耗時(shí)

跑贏了最慢的那個(gè)模型？

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

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

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

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

總結(jié)與未來(lái)展望

在微服務(wù)泛濫和 AI 大模型爆火的今天，后端工程師非常容易陷入一種“服務(wù)絕對(duì)隔離”的思維定勢(shì)：把 AI 模型當(dāng)成一個(gè)不可褻玩的“黑盒”，認(rèn)為調(diào)用方只管扔原圖，AI 服務(wù)自己處理一切。

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

后續(xù)演進(jìn)思考

未來(lái)，隨著審核規(guī)模的進(jìn)一步擴(kuò)張，我們計(jì)劃向架構(gòu)的更深處探索：

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

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

希望這篇我們?cè)诘讓有阅軆?yōu)化上的實(shí)戰(zhàn)復(fù)盤，能為正在從事 AI 工程化落地、高并發(fā)中臺(tái)建設(shè)的開(kāi)發(fā)者們帶來(lái)一些不一樣的啟發(fā)。

會(huì)議推薦

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

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

誠(chéng)摯邀請(qǐng)你登臺(tái)分享實(shí)戰(zhàn)經(jīng)驗(yàn)。AICon 2026，期待與你同行。

今日薦文

你也「在看」嗎？