【CSDN 編者按】當(dāng)所有人都在追捧Python為AI的“絕對(duì)王者”時(shí)，你是否想過：我們是否把原型工具誤當(dāng)成了生產(chǎn)引擎？在實(shí)驗(yàn)室里靈活敏捷的Python，一旦面對(duì)每秒數(shù)千次推理請(qǐng)求、需要嚴(yán)格類型保障和多年穩(wěn)定運(yùn)行的企業(yè)級(jí)場(chǎng)景時(shí)，是否依然游刃有余？基于此，本文作者提出了一個(gè)行業(yè)幻覺：Python贏了探索，卻未必能贏生產(chǎn)。他并非要挑起語(yǔ)言之爭(zhēng)，而是直指AI工程化進(jìn)程中一個(gè)日益凸顯的斷層——從模型訓(xùn)練到系統(tǒng)交付，我們更需要的是 “可持續(xù)的AI”。

原文鏈接：https://www.the-main-thread.com/p/java-ai-production-python-systems

作者 | Markus Eisele 翻譯 | 鄭麗媛

出品 | CSDN（ID：CSDNnews）

只要你混跡當(dāng)下的 AI 技術(shù)圈，一定會(huì)聽到一個(gè)被反復(fù)提及、近乎真理的結(jié)論：Python 贏了。

Notebook、模型訓(xùn)練、科研實(shí)驗(yàn)室——幾乎清一色都是 Python。開發(fā)者覺得它上手友好、使用靈活，儼然已成 AI 領(lǐng)域的默認(rèn)開發(fā)語(yǔ)言。

但這個(gè)結(jié)論，其實(shí)刻意忽略了一個(gè)現(xiàn)實(shí)：Python 打贏的是探索之戰(zhàn)，而非生產(chǎn)之戰(zhàn)。

企業(yè)從不交付 Notebook，它們交付的是“系統(tǒng)”。而系統(tǒng)需要的是：穩(wěn)定性能、可維護(hù)性、可觀測(cè)性、明確的接口契約、可控的并發(fā)能力——當(dāng)你走到這一層，Python 的優(yōu)勢(shì)瞬間變得不堪一擊。

問題根源不在于 Python 本身，而在于人們想當(dāng)然地認(rèn)為，用于實(shí)驗(yàn)的語(yǔ)言也能扛起核心推理流程的重任。一旦你推翻這個(gè)假設(shè)，AI 才算真正走進(jìn)工程世界。

也是在這一刻，Java 就像一位成熟穩(wěn)重的 “成年人”，順勢(shì)登場(chǎng)。

迷思一：“Python 很快，因?yàn)?/strong>它調(diào)用的是 C++”

業(yè)界流傳著這樣一種說法：Python 的性能問題根本不值一提，因?yàn)?NumPy、PyTorch、TensorFlow 這些核心庫(kù)本質(zhì)上都是一層封裝，真正的計(jì)算邏輯都在經(jīng)過極致優(yōu)化的 C++ 或 CUDA 內(nèi)核中執(zhí)行。

但這種說法只對(duì)了一半，而且極其片面。

封裝層的存在，本身就會(huì)產(chǎn)生實(shí)實(shí)在在的時(shí)間和內(nèi)存開銷。Python 代碼與原生代碼之間的每一次切換，都會(huì)帶來額外的性能損耗。而且，封裝層之外的 “膠水代碼”，都運(yùn)行在 Python 解釋器的限制之下——其中就包括煩人的全局解釋器鎖（GIL），這個(gè)鎖會(huì)強(qiáng)制一個(gè)進(jìn)程內(nèi)同時(shí)只能有一個(gè) Python 線程處于活躍狀態(tài)。

在科研用的 Notebook 中，這個(gè)問題幾乎可以忽略不計(jì)。但在一個(gè)需要處理數(shù)千并發(fā)請(qǐng)求的高吞吐量推理服務(wù)中，GIL 會(huì)直接成為性能瓶頸的元兇。為了解決這個(gè)問題，技術(shù)團(tuán)隊(duì)一般會(huì)采用多進(jìn)程架構(gòu)、復(fù)雜的負(fù)載均衡策略，以及激進(jìn)的水平擴(kuò)容方案。這些方法雖然可行，卻會(huì)造成大量的內(nèi)存浪費(fèi)，推高運(yùn)維成本。

而 Java 完全沒有這個(gè)煩惱。JVM 的并發(fā)模型，在金融、電信、基礎(chǔ)設(shè)施等大規(guī)模系統(tǒng)中打磨了整整二十年，早已成熟可靠。它的線程創(chuàng)建成本極低，調(diào)度機(jī)制高效，吞吐量可實(shí)現(xiàn)無(wú)壁壘的線性擴(kuò)展。

再加上 Project Panama 提供的外部函數(shù)與內(nèi)存 API，Java 的優(yōu)勢(shì)被進(jìn)一步放大。如今的 Java 可以繞開傳統(tǒng) JNI 的高額開銷，直接調(diào)用原生庫(kù)。這就促成了一種理想狀態(tài)：一門兼具托管語(yǔ)言安全性、又能達(dá)到原生代碼性能的開發(fā)語(yǔ)言。

對(duì)于 AI 推理場(chǎng)景而言，這不是什么理論上的優(yōu)勢(shì)，而是實(shí)實(shí)在在的結(jié)構(gòu)性領(lǐng)先。

迷思二：“Python 更好用”

不可否認(rèn)，當(dāng)你編寫第一版代碼時(shí)，Python 確實(shí)用著順手。動(dòng)態(tài)類型和靈活的數(shù)據(jù)結(jié)構(gòu)，讓你能以極快的速度完成原型驗(yàn)證，甚至可以在不同代碼塊之間隨意改變變量類型，解釋器也不會(huì)拋出任何錯(cuò)誤。

但問題是：這份便利的代價(jià)，最終由誰(shuí)來承擔(dān)？

在生產(chǎn)環(huán)境中，Notebook 風(fēng)格的“自由”會(huì)瞬間變成致命的負(fù)擔(dān)。代碼邏輯變得難以梳理，接口契約從顯式約定退化為隱式默契，代碼重構(gòu)的風(fēng)險(xiǎn)陡增，各種錯(cuò)誤也不會(huì)在編譯階段暴露，而是要等到運(yùn)行時(shí)才會(huì)集中爆發(fā)。

對(duì)于需要長(zhǎng)期維護(hù)的核心系統(tǒng)而言，“寫起來容易”往往會(huì)演變成“維護(hù)起來要命”。

而 Java 的設(shè)計(jì)理念，從一開始就優(yōu)先保障長(zhǎng)期的代碼清晰度。類型安全機(jī)制，相當(dāng)于生成了一份可以編譯執(zhí)行的 “活文檔”；接口契約是清晰可見的，而非靠開發(fā)者腦補(bǔ)；開發(fā)工具可以輕松分析代碼邏輯，強(qiáng)制執(zhí)行代碼約束。即便是代碼量突破數(shù)十萬(wàn)行的大型項(xiàng)目，維護(hù)工作依然能有條不紊地推進(jìn)。

這一點(diǎn)，在 AI 系統(tǒng)中尤為重要。模型的輸入輸出維度不是 “建議值”，而是硬性規(guī)定。一個(gè)格式錯(cuò)誤的向量，理應(yīng)在早期就被檢測(cè)出來并終止流程；一個(gè)缺失的字段，也不能被隨意“解讀”或默默丟棄——而 Java 的設(shè)計(jì)哲學(xué)，從根源上就強(qiáng)制保障了這種嚴(yán)謹(jǐn)性。

反觀 Python，它的設(shè)計(jì)思路卻恰恰與之相反。

迷思三：“用 Java 搞不了現(xiàn)代 AI”

“現(xiàn)代 AI 開發(fā)必須用 Python” 的固有認(rèn)知，早就站不住腳了。

曾經(jīng)，這個(gè)說法是成立的——畢竟早期的模型訓(xùn)練流程和科研工具，幾乎都誕生于 Python 生態(tài)。即便到了今天，Python 在 AI 研究領(lǐng)域的地位依然穩(wěn)固，但這一點(diǎn)，對(duì)企業(yè)級(jí) AI 應(yīng)用來說已經(jīng)不重要了：

企業(yè)不需要用 Java 來訓(xùn)練模型，它們只需要用 Java 來運(yùn)行模型。

具體來說，模型訓(xùn)練是科研屬性的工作，而模型推理是工程屬性的工作，二者需要的技術(shù)特性、工具鏈和方法論，都截然不同。

好在 ONNX（開放神經(jīng)網(wǎng)絡(luò)交換格式）的興起，正式將這種分工標(biāo)準(zhǔn)化：技術(shù)團(tuán)隊(duì)完全可以在 PyTorch 中完成模型訓(xùn)練，將模型導(dǎo)出為 ONNX 格式，再交由 Java 工程師在 JVM 上完成部署和運(yùn)維。

如今，這種分工協(xié)作模式已經(jīng)成為行業(yè)標(biāo)準(zhǔn)，而非特例。ONNX Runtime、TensorRT-LLM、vLLM 等主流推理框架，都已支持穩(wěn)定的生產(chǎn)級(jí)推理架構(gòu)，而 Java 可以與它們實(shí)現(xiàn)無(wú)縫集成。

為了更直觀地展示這一點(diǎn)，我們來看一段基于標(biāo)準(zhǔn) JDK 21 的簡(jiǎn)單 ONNX Runtime 推理代碼：

importai.onnxruntime.*;
importjava.nio.FloatBuffer;
importjava.util.Collections;

publicclassProductionInference{
publicstaticvoidmain(String[] args)throwsOrtException{

try(var env =OrtEnvironment.getEnvironment();
var session = env.createSession("model.onnx",newOrtSession.SessionOptions())){

float[] data =newfloat[]{1.0f,2.0f,3.0f};
var tensor =OnnxTensor.createTensor(env,
FloatBuffer.wrap(data),
newlong[]{1,3});

var inputs =Collections.singletonMap("input_node", tensor);

try(var results = session.run(inputs)){
OnnxTensor outputTensor =(OnnxTensor) results.get(0);
FloatBuffer buffer = outputTensor.getFloatBuffer();
float result = buffer.get(0);
System.out.println("Inference Result: "+ result);
}
}
}
}

這不是什么老舊的 Java 代碼，而是現(xiàn)代、內(nèi)存安全、線程安全的 Java 應(yīng)用。它可以無(wú)縫融入現(xiàn)有的企業(yè)技術(shù)棧，不需要額外的容器封裝、邊車服務(wù)，更不需要復(fù)雜的跨語(yǔ)言橋接層。

說到底，這個(gè)道理其實(shí)很簡(jiǎn)單：創(chuàng)新不再局限于某一種編程語(yǔ)言。模型訓(xùn)練的陣地依然在 Python，但模型推理的歸屬，只取決于哪個(gè)環(huán)境能提供穩(wěn)定、可擴(kuò)展、可觀測(cè)的系統(tǒng)——而 Java，正是這樣的理想環(huán)境。

下一個(gè)風(fēng)口：Project Panama

Foreign Function & Memory API 的出現(xiàn)，堪稱 JVM 的一次結(jié)構(gòu)性升級(jí)。它徹底消除了 JNI 的冗余代碼和性能開銷，打通了 Java 與原生庫(kù)之間的隔閡。

具體來說，Project Panama 帶來了四大核心能力：

● 直接訪問堆外內(nèi)存

● 自動(dòng)映射原生結(jié)構(gòu)體的內(nèi)存布局

● 高性能、類型安全的外部函數(shù)調(diào)用

● 大幅優(yōu)化 C++ 或 CUDA 庫(kù)的集成體驗(yàn)

對(duì)于推理密集型應(yīng)用而言，這徹底改變了系統(tǒng)的構(gòu)建模式。我們不再需要把原生庫(kù)當(dāng)作黑盒引擎，隔著一層低效的邊界去調(diào)用，而是可以將其視為“一等公民”組件，深度集成到 Java 系統(tǒng)中。這為定制化內(nèi)核開發(fā)、向量運(yùn)算優(yōu)化、自定義內(nèi)存管理流水線，以及高性能推理框架的直接集成等，都鋪平了道路。

而 Python 的內(nèi)存模型從設(shè)計(jì)之初就沒有考慮過這些場(chǎng)景，根本無(wú)法實(shí)現(xiàn)這種級(jí)別的深度集成。

現(xiàn)在的 Java，真正做到了魚與熊掌兼得——在不犧牲安全性的前提下，達(dá)到了原生代碼的性能水準(zhǔn)。

企業(yè)級(jí) AI 的核心訴求：不再是“玩一玩”大模型

當(dāng)下企業(yè)級(jí) AI 的核心目標(biāo)，早已不是簡(jiǎn)單地“玩玩”大模型，而是將 AI 能力轉(zhuǎn)化為穩(wěn)定的業(yè)務(wù)支撐。這要求 AI 系統(tǒng)具備可預(yù)測(cè)的延遲、故障容錯(cuò)能力、可審計(jì)性、版本管理機(jī)制、生命周期管理能力，以及成本控制能力。

基于此，架構(gòu)師必須選擇符合以下條件的運(yùn)行時(shí)環(huán)境：能在高負(fù)載下穩(wěn)定運(yùn)行、支持水平擴(kuò)展、能無(wú)縫融入現(xiàn)有的可觀測(cè)性體系，并且可以長(zhǎng)期運(yùn)維。而 JVM，早就在企業(yè)級(jí)應(yīng)用的其他領(lǐng)域證明了自己的實(shí)力。

如果強(qiáng)行將 Python 推理服務(wù)嫁接到這樣的企業(yè)架構(gòu)中，只會(huì)徒增風(fēng)險(xiǎn)。它可能會(huì)帶來沉重的運(yùn)維債務(wù)，需要部署更多的容器、進(jìn)程，編寫更復(fù)雜的擴(kuò)容邏輯。在一些企業(yè)里，Python 推理服務(wù)甚至?xí)葑兂梢粋€(gè)獨(dú)立的平臺(tái)，與其他業(yè)務(wù)系統(tǒng)完全割裂。這種架構(gòu)碎片化，會(huì)削弱系統(tǒng)的穩(wěn)定性，推高整體成本。

相較之下，Java 從來不會(huì)拖慢 AI 的速度，它只會(huì)讓 AI 系統(tǒng)走得更穩(wěn)、走得更遠(yuǎn)。

總結(jié)：Python 做研究，Java 搞生產(chǎn)

最后強(qiáng)調(diào)一點(diǎn)：我并非有意要挑起一場(chǎng)編程語(yǔ)言的戰(zhàn)爭(zhēng)，這只是一次關(guān)注點(diǎn)分離的實(shí)踐。

科研人員需要靈活的探索環(huán)境，而工程師需要嚴(yán)謹(jǐn)?shù)恼_性和可操作性；相應(yīng)的，Python 擅長(zhǎng)快速探索，Java 擅長(zhǎng)構(gòu)建系統(tǒng)。

所以，如果你的業(yè)務(wù)命脈依賴于 AI 能力，那么你不應(yīng)該圍繞 Python 的局限性重構(gòu)架構(gòu)，而應(yīng)該基于 JVM 已有的成熟能力進(jìn)行構(gòu)建。Java 也不是 Python 的替代品，而是企業(yè)級(jí) AI 系統(tǒng)的升級(jí)方案。

在我看來，未來企業(yè)級(jí) AI 的主戰(zhàn)場(chǎng)，應(yīng)屬于那些能交付穩(wěn)定系統(tǒng)的語(yǔ)言，而非只能用來做原型驗(yàn)證的語(yǔ)言。