北京
作者 ｜ 王碩
業務背景
在我們團隊的視頻審核服務中臺里，每天需要處理海量的視頻進審截圖。為了全方位保障內容安全，我們引入了多種 AI 小模型對圖片進行并發檢測，主要包括：
自研色情檢測服務（基于 ViT 模型）：Vision Transformer 擅長捕捉全局上下文信息，對于大面積的違規畫面有極高的識別率。
自研黑產分類檢測（基于 YOLO-cls 模型）：用于識別黑灰產廣告、二維碼貼紙、引流文字等具有特定特征的局部變體。
高級布控圖片檢測（基于 Chinese-CLIP）：基于圖文多模態大模型，把圖片生成高維 Embedding，然后同 Milvus 中的海量違規樣本庫進行近似最近鄰（ANN）向量比對，以實現“零樣本”命中相似變體圖。
臺標 / 拉橫幅目標檢測（基于 YOLO-det 模型）：需要精準輸出 Bounding Box，識別畫面中是否存在違規的橫幅、旗幟或特定標志。
初期的架構與“溫水煮青蛙”的困境
在系統建設初期，我們采用了經典的“責任鏈模式”（串行檢測）。架構設計的初衷是“快速失敗（Fail-Fast）”：按照命中率從高到低排列，一旦圖片命中某個違規項，就立刻中斷并返回結果，節約后續的 GPU 算力。
這套邏輯在邏輯推演上無懈可擊，但在真實的業務大盤數據面前卻暴露了致命的痛點：在真實的 UGC 業務場景中，90% 以上的圖片都是合法合規的。這意味著對于絕大多數的審核請求，四個模型必須“跑滿”全流程。串行架構下，整體耗時 = 各個模型耗時之和（例如：色情 80ms + 黑產 90ms + 布控 110ms = 280ms）。隨著我們后續即將接入“暴恐識別”、“旗幟識別”等更多模型，審核鏈路的 P99 延遲將奔向 500ms 甚至 1 秒以上，這對于實時 / 準實時審核業務是絕對不可接受的。
深度痛點分析：為什么
“串行改并行”沒那么簡單？
發現串行耗時過長后，團隊的第一直覺是：引入 CompletableFuture，串行改并行不就行了嗎？
但在深度梳理了整個請求鏈路，并用鏈路追蹤工具（SkyWalking）生成了火焰圖后，我們發現僅僅改并行遠遠不夠。系統的底層還潛伏著三個巨大的性能黑洞，如果把這些原封不動地并行化，不僅延遲降不下來，還會引發嚴重的系統雪崩。
黑洞一：被忽視的序列化與 IO 傳輸開銷
在之前的微服務調用中，由于歷史包袱，有的業務方傳圖片 URL，有的傳 Base64 編碼。
Base64 Base64 編碼不僅會把原有的二進制數據體積撐大近 33%，還會導致 Java 網關層在反序列化時產生大量的 String 對象，給 JVM 年輕代帶來巨大的 GC（垃圾回收）壓力。網絡傳輸大包頭的數據也會吃滿帶寬。
URL 如果傳 URL，會導致各個下游的 AI 檢測節點各自去發起 HTTP 請求拉取圖片。在分布式網絡中，公網 / 內網的抖動極其常見，拉取同一張圖，4 個服務可能經歷 4 次不同的網絡延遲、DNS 解析耗時、甚至 Read Timeout，這讓鏈路穩定性大打折扣。
黑洞二：極其嚴重的算力浪費（重復前處理）
在傳統的 AI 服務部署生態中，通常是 Java 業務端把原圖發給各個推理服務，由各個推理服務自己使用 Python（通常是 OpenCV 或 PIL 庫）去做 Decode（解碼）、Resize（縮放）和 Crop（裁剪）。我們仔細研讀了四個模型的輸入 Tensor（張量）要求，發現了驚人的計算復用空間：
ViT (色情)：需要輸入 224x224 的特征圖（一般直接 Resize 拉伸縮小）。
CLIP (布控)：同樣需要 224x224，但由于要提取高維特征，強烈依賴 BICUBIC（雙三次插值）算法來保證縮小后的圖片細節不丟失。
YOLO-cls (黑產)：需要 640x640 的分辨率（通常采用按比例縮放后居中 Crop 裁剪）。
YOLO-det (目標檢測)：同樣是 640 級別的輸入要求。
如果按照傳統做法，把一張 1080P 的原圖分別并發發給 4 個 Python 節點，同一張高清圖片會被反序列化 4 次，解碼 4 次，Resize 4 次！在 Python 的生態中，受限于 GIL（全局解釋器鎖），密集型的圖片解碼和矩陣變換不僅極度消耗 CPU 資源，還會拖慢同一臺機器上 GPU 的數據喂入（Data Loading）速度，最終導致 AI 服務的吞吐量（QPS）被前處理死死卡住。
黑洞三：黑產幻燈片與冗余幀
通過對線上違規樣本的聚類分析，我們發現相當一部分的黑灰產視頻、廣告、以及 AI 自動生成的視頻，往往采用類似“幻燈片”的呈現方式。我們的抽幀組件在一個視頻內可能抽出 8 張圖，這 8 張圖在視覺上肉眼可見地幾乎一模一樣。如果不做任何去重策略，這些重復的圖片不僅在 Java 測會重復走上述的復雜邏輯，更會把珍貴且昂貴的 GPU 算力浪費在推理一模一樣的張量數據上。
架構重構：壓榨性能的 “組合拳”設計
針對上述三大痛點，我們沒有停留在表面修補，而是對整體中臺鏈路進行了一次“刮骨療毒”式的重構。
優化點 1：統一收口，全鏈路零拷貝
Byte 字節流傳輸
為了徹底解決 IO 與 GC 的瓶頸，我們全面廢棄了內部微服務鏈路中的 URL 和 Base64 傳輸。在網關層，我們強制將外部請求轉化為圖片的純二進制 byte[]（字節數組）。在后續的內部 RPC 調用、并發分發過程中，全部基于內存中的字節數組直接傳遞。
收益：消滅了 33% 的帶寬冗余，打掉了 JVM 處理巨大 Base64 字符串帶來的 CPU 飆升與 Full GC 風險，同時規避了下游并發去對象存儲拉取同一張圖片的網絡抖動問題。全局只有在最頂層網關發起一次拉圖 IO 請求。
優化點 2：前置公共處理中間層
（Java 側統籌 AI 前處理）
這是本次架構優化最核心、收益最大的一環。我們打破了“業務層只管發數據，AI 層自己管處理”的傳統思維，將原本分散在各個 Python AI 節點的圖像預處理工作，剝離、上浮并收斂到了 Java 中臺側。
當請求到達時，Java 中臺會根據 Apollo 配置中心動態讀取當前圖片需要經過哪些檢測模型，隨后利用 Java 原生強大的多線程能力，統一生成各模型需要的定制化特征圖，然后再并發推送給下游。
我們引入了 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;
/**
* 核心入口：動態分析需求并生成對應的尺寸
*/
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. 計算中間態尺寸 (按最短邊 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. 生成中間態圖片 (必須使用 BICUBIC 保證 CLIP 的高質量要求)
BufferedImage intermediate = Thumbnails.of(original)
.size(interW, interH)
.resizer(Resizers.BICUBIC)
.asBufferedImage();
// 4.1 生成 Crop 數據 (給 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 數據 (給 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. 組裝結果并分發...
}
}
架構思考：為什么用 Java 做圖像前處理而不是 C++ 或 Python？Java 的長處在于高并發和工程管理。雖然 OpenCV (C++) 的絕對單幀處理速度比 Java 快，但在高并發 RPC 場景下，JNI (Java Native Interface) 的內存拷貝開銷極其昂貴。通過純 Java 實現中間層，不僅部署輕量，還能完美契合現有的 JVM 內存調優體系，配合并行 Stream，其綜合吞吐量反而是最高的。
優化點 3：基于 pHash 與
貪心圖染色算法的智能批次去重
為了徹底解決幻燈片視頻幀的算力浪費，我們在進入“核心縮放邏輯”和“并行推理”之前，增加了一個輕量級的預處理網關：感知哈希（pHash）分組去重。
pHash（Perceptual Hash）能夠根據圖像的低頻特征生成一串指紋，對圖像的縮放、微小水印等具備極強的抗干擾能力。我們計算單批次所有圖片的 pHash，然后通過計算漢明距離（Hamming Distance）來判斷圖片是否相似。
如果一批抽幀截圖中存在相似的圖片，怎么高效且嚴謹地把它們分到同一組？我們巧妙地借用了計算機科學中的經典算法——沖突圖與圖染色算法（Graph Coloring）。
連邊（構建沖突）：如果兩張圖片差異較大（漢明距離 > 閾值 maxDistance），說明它們絕對不能分在同一個去重組，我們在它們之間連一條邊，表示“沖突”。
貪心染色（分配組別）：用最少的顏色給圖節點染色，保證任何兩個相連的節點顏色不同。顏色相同的節點，就是互相之間沒有邊（即極度相似）的圖片集合！
執行策略：針對染色后分到同一組的圖片，中臺只取組內的 第一張 圖片進入后面的 ImageResizeService 和 AI 并發推斷，其余同組圖片直接掛起等待。推斷完成后，結果直接復用賦予掛起的圖片。
聚類核心代碼：
public Map > clusterByHashDistance(List list, int maxDistance) {
// 過濾無 pHash 的數據
List validList = list.stream()
.filter(bo -> Objects.nonNull(bo.getImagePHash()))
.collect(Collectors.toList());
// 構建沖突圖：差異大于 maxDistance 的節點之間連邊
List > conflictGraph = buildConflictGraph(validList, maxDistance);
int n = validList.size();
// 貪心染色：colors[i] 表示第 i 個節點的顏色編號（即組編號）
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 張以內，節點數 N 較小, 構建沖突圖耗時 O(N^2), 染色復雜度 O(N+E), 在 Java 中執行時間幾乎可以忽略不計（不到 1ms），但卻能阻斷后續大量的重度 CPU/GPU 計算，ROI 極高。
優化效果與深度反思：打破“木桶理論”
新架構上線后，我們迎來了極其驚艷的數據表現。
核心指標對比：
重構前（串行）：色情 (80ms) + 黑產 (90ms) + 布控 (110ms) = 平均總耗時約 280ms。
重構后（多路并發 + 統籌前置處理 + 圖染色去重）：復合檢測的總平均耗時穩定在了 90ms 左右！
深度剖析：為什么總耗時
跑贏了最慢的那個模型？
這是本次優化中最值得玩味的數據。按照傳統的并發思維（即“木桶理論”），并行計算的總耗時應當取決于耗時最長的那個分支。原本的 CLIP 服務單次耗時是 110ms，哪怕并發執行，整體耗時理應也在 110ms 左右。但為什么我們的實際中位數耗時跑進了 90ms？
答案在于：我們為 AI 節點實施了深度的“算力減負”。原先測得的 110ms，是一個“胖接口”的耗時。它包含了：HTTP 網絡拉取大圖 + Python 解釋器環境下的解碼 + OpenCV Resize/Crop 變換 + GPU 矩陣推斷。
在新架構下，極其消耗 CPU 的“圖像解碼與多尺度插值裁剪”這部分工作，被剝離并集中到了更擅長高并發多線程的 Java 中臺。通過本地網卡 / 內網 RPC 直接灌入下游的，是已經量身定做好的 224x224 或 640x640 的純凈小體積字節流。此時的 Python AI 服務被徹底解放，它不再需要去處理惡心的圖像 IO 和 CPU 軟解，而是直接將收到的字節流轉化為 Tensor 扔進 GPU（或者交由 Triton Inference Server 進行 Dynamic Batching 動態組批）。AI 模型自身的純 Inference（推斷）耗時，其實只有短短的幾十毫秒。
整體耗時 = Java 統籌前處理 (~15ms) + 網絡傳輸極小特征圖 (~5ms) + GPU 純推斷 (~70ms) ≈ 90ms。我們用架構的重組，擊穿了原本的性能底線。
總結與未來展望
在微服務泛濫和 AI 大模型爆火的今天，后端工程師非常容易陷入一種“服務絕對隔離”的思維定勢：把 AI 模型當成一個不可褻玩的“黑盒”，認為調用方只管扔原圖，AI 服務自己處理一切。
但當我們打破這種邊界，從全局鏈路的視角去審視網絡 IO 損耗、CPU/GPU 算力分布，并深入理解各種 AI 模型的數據輸入特征時，往往能發現極其可觀的優化空間。把非 AI 核心邏輯（網絡拉取、圖片解碼、縮放插值、哈希去重）向上層收斂，讓底層的 GPU 更純粹、更專注地去做高密度矩陣運算，這才是大吞吐量 AI 審核中臺架構設計的正確范式。
后續演進思考
未來，隨著審核規模的進一步擴張，我們計劃向架構的更深處探索：
AI 節點前置網關化：引入 NVIDIA Triton 等專業的推理服務器替代現有的 Python Flask/FastAPI 封裝，利用其 Dynamic Batching 功能，將高并發的散列請求組裝為大 Batch，進一步壓榨 GPU 的吞吐極限。
跨語言共享內存（Zero-Copy）：如果在 Kubernetes 集群的同一個 Pod 中混部 Java 中臺服務與 AI 推理容器，我們甚至可以考慮通過共享內存（如 Apache Arrow / Plasma 甚至 RDMA）來傳遞圖像的 Tensor 矩陣，徹底消滅最終的 RPC 序列化開銷。
希望這篇我們在底層性能優化上的實戰復盤，能為正在從事 AI 工程化落地、高并發中臺建設的開發者們帶來一些不一樣的啟發。
會議推薦
世界模型的下一個突破在哪？Agent 從 Demo 到工程化還差什么？安全與可信這道坎怎么過？研發體系不重構，還能撐多久？
AICon 上海站 2026，4 大核心專題等你來：世界模型與多模態智能突破、Agent 架構與工程化實踐、Agent 安全與可信治理、企業級研發體系重構。14 個專題全面開放征稿。
誠摯邀請你登臺分享實戰經驗。AICon 2026，期待與你同行。
今日薦文
你也「在看」嗎？
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
