模型層 開放閱讀

TensorRT-LLM

TensorRT-LLM

概念 ID
tensorrt-llm
更新時間
2026-05-29
來源數量
待補

TensorRT-LLM

3 秒看懂

TensorRT-LLM 是 NVIDIA 官方推出的開源庫，專門用於在大規模語言模型（LLM）推論場景中，將定義、最佳化、執行這三個環節統一打包，使 LLM 在 NVIDIA GPU 上達到極致吞吐和最低延遲。它不是一個“換個模型就自動變快”的黑盒，而是要求開發者用一套 Python API 描述模型結構，再由背後的 TensorRT 編譯器進行圖最佳化、核心融合、量化、多 GPU 並行編排，最後生成高度最佳化的推論引擎。核心思想：把 LLM 的推論看成編譯問題，用類似“提前編譯（AOT）”的方式把計算圖固化為極致並行、極低開銷的執行計劃。

3 分鐘產業解釋

大型語言模型的推論面臨著兩個根本矛盾：一是模型引數膨脹帶來的視訊記憶體牆，二是自迴歸解碼機制導致的“每次只能生成一個 token”的序列瓶頸。TensorRT-LLM 在產業層面的貢獻是把這兩個矛盾的解法工程化打包，形成一套可在資料中心大規模部署的標準化工具鏈。

它讓 LLM 推論能夠實現：

  • 連續批處理（in-flight batching）：不等整個批次內所有請求都完成才釋放資源，而是隨時動態插入新請求，GPU 利用率接近硬體上限。
  • 分頁注意力（paged attention）：將 KV 快取按頁管理，消除碎片化浪費，允許記憶體超量複用，與 vLLM 提出的理念一致但深度繫結 TensorRT 運算元。
  • 極致的多 GPU 拆分：不用使用者手寫通訊原語，通過 Python API 描述張量並行、流水線並行的切分方案，自動生成 NCCL 通訊與計算重疊的執行圖。
  • 多元量化通路：支援 FP8、INT8、INT4（包括 GPTQ/AWQ 等權重量化 + FP8/INT8 啟用結合），大幅降低視訊記憶體佔用和訪存壓力。

在供應鏈中，TensorRT-LLM 對推論晶片、AI 伺服器、雲端運算平台的競爭力有關鍵影響。它把 NVIDIA GPU 在推論階段的效能優勢放大，使得即便有第三方推論引擎（如 vLLM、llama.cpp），只要使用者追求極致效能和最短延遲，就離不開 TensorRT-LLM 在 NVIDIA 生態內的深度最佳化。

15 分鐘專家深入

TensorRT-LLM 的定位不是“又一個高效能推論執行時”，而是 LLM 推論的編譯基礎設施。它的設計哲學接近 TVM 或 XLA，但專精於 Transformer 解碼器，並與 NVIDIA 工具鏈深度耦合。

架構分層

  1. Python API 層（寫作時使用）：約 2023 年釋放到開源，提供類似 tensorrt_llm.Builder、tensorrt_llm.models 等模組，讓使用者用宣告式方式建置模型圖。與 FasterTransformer 的手寫 CUDA 運算元不同，TensorRT-LLM 的 API 描述的是計算邏輯，而非具體核心實現。
  2. 圖最佳化與編譯器層：將使用者定義的模型轉換為 TensorRT 的 INetworkDefinition，進行運算元融合（如 LayerNorm 與後續矩陣乘法合併、殘差連線融合、GELU 啟用與矩陣乘融合）、消除無用轉置、多流併發編排。
  3. 執行時層：提供 C++ 執行時，負責管理 GPU 記憶體池、KV 快取分頁、排程器（支援動態批處理）、多 GPU 執行協調。使用者程式通過 Python 繫結的 GptSession 或類似介面與引擎互動。

關鍵機制

  • In-flight batching：傳統靜態批處理要求一個 batch 內所有序列長度對齊，且必須等待其中最長的序列生成結束才能整體釋放槽位。In‑flight batching 將排程粒度從“請求級”下放到“token 級”，可以在一批正在生成的序列中隨時插入新的 token 生成任務，使得 GPU 計算單元始終不空閒。該機制最早由 Oracle/快手等團隊提出，後在 FasterTransformer、vLLM 中實現，TensorRT-LLM 將其整合進自己的排程器，並與記憶體管理系統耦合。
  • PagedAttention 及 KV 快取管理：將每個序列的 KV 快取切分為固定大小頁（如 64 或 128 token），通過頁表將邏輯位置對映到物理視訊記憶體。當序列長度增長，動態分配新頁，不必提前預留最大長度，從而顯著降低視訊記憶體浪費。TensorRT-LLM 在建置引擎時已經把“分頁載入儲存”運算元固化，而非外掛記憶體管理器，減少執行時開銷。
  • 多 GPU 並行：支援張量並行（Tensor Parallelism）和流水線並行（Pipeline Parallelism）。張量並行把每一層的權重矩陣在隱藏維度切分，計算後在列或行方向做一次 All‑Reduce 或 All‑Gather（ReduceScatter），通訊模式與 Megatron-LM 一致；流水線並行按層切分到不同 GPU，採用 1F1B 排程以平衡計算與通訊。通過 API 設定 tp_size、pp_size，編譯器自動插入必要的 NCCL 操作並儘可能重疊傳輸。
  • 量化方案：支援僅權重量化（INT4/INT8）和權啟用均量化（FP8/INT8）。具體實現上，對於 GPTQ 風格量化，會插入定製反量化運算元；對於 FP8，利用 H100 的 Transformer Engine 能力，在矩陣乘之前將 FP8 轉回 FP16/BF16 精度進行累加。校準可在建置引擎階段用少量資料完成，無需模型重新訓練。

並行規模與限制

  • 張量並行的最大 GPU 數受限於單層內可切分的頭數或隱藏維度，通常單個節點內使用 8 卡 TP 已接近閾值；流水線並行的最大階段數受模型層數限制，一般數十個階段。兩者可組合使用。
  • 通訊方式上，張量並行使用 All‑Reduce/ReduceScatter 而非 All‑to‑All；MoE 模型的 expert dispatch 會引入額外的 All‑to‑All 通訊，但典型稠密模型以 All‑Reduce 為主。沒有公開資料表明 TensorRT-LLM 在通用稠密路徑上使用 All‑to‑All。

硬體適配

  • 架構：針對從 Turing 到 Hopper 各代 GPU 的 Tensor Core 特性進行指令級調優，但並非每代都獨立編寫核心，而是依賴 TensorRT 核心自動調諧系統在目標裝置上生成最優實現。
  • 製程與封裝：推論效能與具體 GPU 的製程無關，但多 GPU 並行效能受片間互聯頻寬（如 NVLink/NVSwitch）顯著影響。典型部署使用 HGX 或 DGX 整機，涉及 NVSwitch 全互聯拓撲，減少跨卡通訊延遲。

以上技術細節基於截至 2023 年 10 月的公開資訊，未獲得額外網際網路檢索補充。部分實現細節可能隨版本更新變化。

技術原理（最深，含機制、引數，可加 ASCII 圖）

TensorRT-LLM 的本質是一個“張量編譯器 + 執行時”的組合體，它把 LLM 推論流程編譯為一個有狀態的有向無環圖（DAG），狀態即 KV 快取。

編譯期圖最佳化 使用者通過 Python API 定義各層：

embedding -> TransformerBlock x N -> lm_head
其中 TransformerBlock = Attention + MLP + residual + LayerNorm

編譯器首先將這些層轉化為 TensorRT 的圖層 IR，然後施加一系列圖重寫：

  • 層間融合：將殘差加法與 LayerNorm 合併為單個核心 AddResidualLayerNorm，將 MatMul + Bias + GELU 合併為 FusedGemmGelu。H100 上還會嘗試將 FMHA (Fused Multi-Head Attention) 替換為 FlashAttention-2 核心。
  • 量化插入：如果指定 INT4 權重量化，會在每一層的權重 MatMul 前插入量化解碼節點；若為 FP8 啟用量化，則在輸入 MatMul 處插入動態縮放因子計算。
  • 並行切分：根據張量並行度，將權重矩陣沿輸出或輸入維度切分，插入通訊節點。例如，對於 Attention 的 QKV 投影，會在列方向切分，計算後各卡持有部分頭的結果，接著在 attention 分數計算後隱式完成 reduce（因 Softmax 需要全域性資料），或使用 ReduceScatter 合併多頭。簡化示例如下：
[Input] -> ColumnParallel( Linear_QKV ) -> [ head_i ] --\
                                                          --> (attention) -> ReduceScatter -> ...
[Input] -> ColumnParallel( Linear_QKV ) -> [ head_j ] --/
  • 排程策略嵌入：在圖中為 KV 快取的讀取/寫入插入“頁表查詢”節點，將邏輯 token 位置對映到物理儲存頁。

執行時執行模型 編譯生成的引擎包含一個計劃檔案，執行時按計劃流式執行。對於自迴歸解碼，每次迭代實質是執行一次圖的前向傳播，其中 attention 運算元會讀取/更新 KV 快取頁。排程器維護一個請求佇列，每個請求有一個序列狀態（token 序列、KV 頁表、已生成 token 數）。在一次主機端迴圈中：

  1. 排程器從佇列中取出可批處理的序列，將它們本次要執行的 token 拼接為 batch。
  2. 將 batch 的輸入 token ID、位置編碼、頁表等傳給引擎。
  3. 引擎執行一次前向，輸出各序列的下一個 token logits。
  4. 取樣得到新 token，更新序列狀態，若未遇到結束符，則將新 token 作為下一次的輸入把該請求重新入隊。
  5. 已結束的請求釋放其佔用的 KV 頁，可以被新請求複用。

這種設計將 GPU 計算與排程解耦：GPU 側只負責執行固定的圖，排程邏輯在 CPU 側，通過主機到裝置的資料傳遞控制每次迭代的引數。

關鍵效能引數（定性）

  • 吞吐量化常以 tokens/s 衡量，受限於 GPU 算力和視訊記憶體頻寬。在 in-flight batching 下，理想情況是 GPU SM 利用率接近 100%，實際可達 80–90% 級別（依據 NVIDIA 官方演示，未獲第三方復現）。
  • 首 token 延遲（TTFT）取決於上下文處理的計算量，批處理下可能增加排隊延遲。TensorRT-LLM 通過分頁注意力允許上下文在多個 token 之間並行處理，配合 FlashAttention 降低延遲。
  • 視訊記憶體佔用 ≈ (模型權重 + KV 快取頁池 + 啟用臨時緩衝區)。量化可將權重壓縮 2–4x，分頁可使 KV 快取節省 50% 或更多視訊記憶體（較靜態預留方式）。

缺少搜尋補充說明 因搜尋功能異常，本頁無法獲取 2024 年以後新增特性（如對 FP4 支援、MoE 切分的更細粒度最佳化、PD分離等）的具體細節。以上基於 2023 年已公開機制描述。

技術演進史

  • 前身 FasterTransformer：NVIDIA 早期釋出的高效能 Transformer 推論庫，主要靠手工最佳化 CUDA 核心實現 BERT/GPT 等模型推論。不足是擴充套件新模型需要大量 C++/CUDA 開發，多 GPU 並行邏輯與模型耦合，難以靈活組合量化與並行策略。
  • TensorRT-LLM 誕生（約 2023 年 9 月）：NVIDIA 在 GTC 2023 前後宣佈將 FasterTransformer 思想升級為基於 TensorRT 編譯架構的全新庫。首個開源版本隨 TensorRT 9.x 釋出，提供 Python 定義模型的全新方式，並原生支援 in-flight batching 和 paged attention。
  • 快速迭代：隨後幾個月內，陸續增加對更多模型架構的支援（如 GPT-NeoX、LLaMA 2、ChatGLM 等），強化量化工具鏈，加入對 H100 上 FP8 Transformer Engine 的整合，並改善與 Triton Inference Server 的協作。
  • 與生態整合：逐步成為 NVIDIA AI Inference 軟體棧的 LLM 官方推薦方案，取代 FasterTransformer 成為開源主力，同時與 NeMo、Megatron-LM 等訓練架構形成搭配。 （以上時間節點依據公開新聞，未得到本次搜尋驗證，可能存在版本號偏差。）

技術路線對比（量化表）

因搜尋不可用，以下對比基於 2023 年的通用知識，部分引數估算為定性，標註 [估算] 或 [未揭露]。

維度TensorRT-LLMvLLMFasterTransformerDeepSpeed Inference
核心最佳化手段TensorRT 編譯 + 手工核心PagedAttention + CUDA 核心純手工 CUDA 核心ZeRO-Inference 視訊記憶體解除安裝 + 核心融合
批處理排程原生 in-flight batching，token 級排程原生 continuous batching僅靜態批處理支援動態批處理，但粒度較粗
KV 快取管理PagedAttention 風格，整合在執行時PagedAttention 核心發明者連續預分配基於 ZeRO 的分片，無分頁
多 GPU 並行原生支援 TP + PP，編譯期自動插入通訊僅支援 TP（vLLM 最初版本），PP 有限必須手寫 TP/PP 配置支援 TP/PP，但需額外配置
模型定義方式Python API 宣告 + 編譯新增新模型需手動實現模型類需 C++ 實現每個模型使用通用模型實現，較易擴充套件
量化支援FP8/INT8/INT4（含 GPTQ/AWQ），與 TensorRT 量化工具鏈整合支援 AWQ/GPTQ 等，需配合外部量化僅部分 INT8 最佳化支援 INT8 量化，與 DeepSpeed 壓縮庫整合
生態繫結深度繫結 NVIDIA GPU 和 TensorRTGPU 通用，但最佳化偏重 NVIDIA僅 NVIDIA GPU理論上 GPU 通用，實際強依賴 NVIDIA
開源協議Apache 2.0Apache 2.0Apache 2.0MIT
社群活躍度較新，NVIDIA 主導極活躍，學術界與產業界大量採用穩定但發展放緩伴隨 DeepSpeed 訓練生態，更新較快
典型延遲/吞吐對比在高階裝置上通常吞吐最高 [未充分揭露第三方標準測試]吞吐略低於 TRT-LLM，但部署簡單吞吐低於二者，但延遲可預測吞吐介於之間

表中所有效能比較均基於 [估算] 或 NVIDIA 官方博文聲稱，未獨立復現。實際表現與模型結構、硬體、工作負載高度相關。

上下游

上游：

  • NVIDIA GPU/軟體棧：TensorRT、CUDA、cuBLAS、cuDNN、NCCL、Transformer Engine。TensorRT-LLM 依賴於 TensorRT 的圖解析和核心自動調諧，以及 NCCL 的多卡通訊。
  • 模型訓練架構：Megatron-LM、NeMo、Hugging Face Transformers 等訓練產出的模型檢查點。需通過轉換指令碼將權重對映到 TensorRT-LLM 的引數命名。
  • 量化工具：NVIDIA AMMO（原 TensorRT-Model-Optimizer）用於量化前校準和最佳化。

下游：

  • 推論服務平台：Triton Inference Server 整合 TensorRT-LLM 後端，提供 HTTP/gRPC API 和動態批處理、模型併發控制、多模型服務等企業功能。
  • 雲端廠商/AI 服務：AWS、Azure、GCP 等的 GPU 例項上提供預配置的 TensorRT-LLM 環境；NVIDIA AI Enterprise 包含支援。
  • 應用架構：如 LangChain、LlamaIndex 等可通過 Triton 或自定義後端呼叫 TensorRT-LLM 加速的模型。
  • 私有化部署：金融、醫療、自動駕駛等低延遲場景直接整合 TensorRT-LLM runtime。

關鍵指標

推論效能指標

  • 吞吐量 (tokens/s)：單位時間內生成的 token 總數，通常在不同 batch size 和序列長度下測量。
  • 首 token 延遲 (TTFT)：從請求到達到第一個 token 產生的時間，受 prompt 長度和系統負載影響。
  • 每 token 時間 (TPOT)：生成每個後續 token 的平均時間。
  • 最大併發請求數：系統可同時處理的請求數量，受視訊記憶體和排程效率制約。
  • 模型載入時間：從磁碟載入引擎檔案並初始化所需時間。
  • 視訊記憶體利用率：實際使用視訊記憶體與分配視訊記憶體的比率，高利用率意味著更經濟的成本。

質量指標

  • 吞吐量一致性：在不同併發數下吞吐量是否穩定。
  • 延遲尾部 (P99)：長尾延遲對使用者體驗影響顯著，是衡量排程公平性的關鍵。

以上各項具體數值受模型、硬體、量化設定、batch size 組合等影響，無統一基準。[無本次搜尋更新]

供需與市場資料

因搜尋失敗，無法提供最新的市場份額、使用者增長資料。以下基於 2023 年行業趨勢定性分析。

  • 需求側：大型模型落地從訓練轉向推論，企業對推論成本、延遲、併發能力關注持續上升。推論引擎成為算力效率的關鍵槓桿，TensorRT-LLM 因直接來自 NVIDIA 而被許多 GPU 叢集使用者視為“官方標準”，尤其在對延遲有嚴苛要求的線上服務中。
  • 供給側：NVIDIA 通過開源 TensorRT-LLM 鞏固其推論生態，同時帶動高階 GPU（H100、A100）的繫結銷售。推論最佳化越離不開 TensorRT-LLM，客戶越傾向於購買 NVIDIA 硬體。其他晶片廠商的推論解決方案因缺乏同等成熟度的軟體棧而面臨挑戰。
  • 競爭格局：vLLM、llama.cpp 等開源引擎佔據輕量部署和成本敏感市場；TensorRT-LLM 在追求極致吞吐和低延遲的商業部署中佔優。部分雲端廠商在內部同時維護多種引擎，根據服務 SLA 選擇。
  • 估算趨勢：隨著模型尺寸增長，推論最佳化價值進一步放大，TensorRT-LLM 的採用率可能在 2024 年持續攀升，尤其在基於 GPT-4 級別私有化部署需求出現後，量化與多 GPU 並行成為剛需。[未獲具體市場份額資料]

代表公司與資本對映

核心公司

  • NVIDIA（開發方）：TensorRT-LLM 是其 AI 推論平台的核心組成，直接拉動 H100/H200/B100 等資料中心 GPU 需求。NVIDIA 通過 DGX 整機、HGX 基板、AI Enterprise 軟體許可等捕獲價值。
  • 雲端服務提供商（使用者）：AWS、Microsoft Azure、Google Cloud、Oracle Cloud 等將 TensorRT-LLM 用於其 GPU 例項上的模型服務，提升單位時間營收，降低每 token 成本以吸引客戶。
  • AI 模型部署企業：如 Anthropic（若租用 GPU 服務）、Stability AI、Midjourney 等，雖然各自有最佳化方案，但對高效能推論引擎有依賴；大量基於開源 LLM 建置應用的初創公司使用 TensorRT-LLM 加速。
  • AI 伺服器 ODM/OEM：超微、廣達、富士康等提供預裝 TensorRT-LLM 最佳化環境的伺服器，作為硬體附加價值。

資本影響邏輯

  • NVIDIA 軟體生態越強，硬體可替代性越低，股價支撐越穩固。
  • 推論引擎的廣泛採用會提升 GPU 利用率，變相降低 AI 服務的資本支出，利好整個 AI 產業。
  • 若 TensorRT-LLM 成為事實標準，將擠壓第三方推論引擎的商業化空間，但不影響開源生態的共存。

投資邏輯

  1. 硬體銷量放大器：TensorRT-LLM 讓同等硬體推論吞吐量提升數倍（據 NVIDIA 官方聲稱），直接降低客戶的 TCO（總擁有成本），從而推動更多企業採用 NVIDIA GPU 進行推論，形成正向反饋。
  2. 生態護城河：對推論最佳化的深度依賴將客戶鎖定在 NVIDIA 軟硬體體系內，提高遷移到其他晶片（如 ASIC、AMD GPU）的門檻。即使競爭者晶片效能接近，缺乏同等推論引擎軟體支援也會阻礙替換。
  3. 資料中心價值：對於雲端廠商，TensorRT-LLM 是提升 GPU 例項盈利能力的關鍵工具，能提高每個 GPU 例項的併發承載，直接增加營收。資本支出回報率（ROIC）因此改善。
  4. 風險點：
    • 若出現跨硬體的統一推論引擎（如 OpenXLA、IREE 大幅進步），可降低對 TensorRT 的依賴。
    • 模型架構變化（如 Mamba 等非 Transformer）可能使針對 Transformer 最佳化的核心失效，但 NVIDIA 可通過更新 TensorRT 補全。
    • 許可證或開源策略變化可能引發社群分叉。
  5. 關聯投資標的：NVIDIA 自身是最直接受益標的；伺服器代工廠、光模組等間接受益於推論算力擴張；雲端運算廠商中，更早推出最佳化推論服務的可能獲得客戶遷移。

常見誤讀糾偏

誤讀 1：“TensorRT-LLM 就是帶模型的 TensorRT，不用自己寫程式碼就能加速任意 LLM。” 糾偏：TensorRT-LLM 不是自動最佳化工具。雖然提供了常見模型的示例，但若使用非標準模型架構，仍需通過 Python API 手寫模型定義，再編譯。對自定義運算元支援有限，超出內建融合模式的改造會退化為 TensorRT 外掛，最佳化效果大打折扣。它本質上是一個“編譯器目標”，非“零程式碼推論方案”。

誤讀 2：“使用 TensorRT-LLM 後，推論延遲一定比 vLLM 低得多。” 糾偏：效能優勢高度依賴硬體、工作負載和最佳化努力。在高階 GPU 且經過精細調校的批次服務場景，TensorRT-LLM 常能實現最高吞吐；但在低併發、長尾延遲敏感的場景，或者小模型單卡部署時，差異可能不顯著。此外，vLLM 的開銷更小，排程靈活性更強，在一些場合下延遲表現更穩定。不可一概而論。

誤讀 3：“TensorRT-LLM 的多 GPU 並行只需設定 tp_size，通訊細節自動最優。” 糾偏：雖然編譯器自動插入通訊節點，但最優的並行配置仍依賴使用者對模型和硬體的理解。例如，如何在 tp 和 pp 之間分配 GPU 數、是否啟用 All-Reduce 與計算的重疊、選擇何種集合通訊演算法，都需要結合模型層數、頭數、序列長度和頻寬特性做定製，否則可能出現通訊瓶頸。內建啟發式演算法能應付常見情況，但極致最佳化需要手動調整。

學習路徑

入門級

  1. 閱讀 NVIDIA 官方 GitHub 倉庫的 README 和 Quick Start Guide，在單卡上跑通一個示例（如 GPT-2）。
  2. 理解 TensorRT 基礎：瞭解 builder、network、engine、context 的概念。
  3. 使用 Triton Inference Server 的 TensorRT-LLM 後端部署一個 HTTP API 服務。

進階級

  1. 學習 Python API 中如何定義自定義模型：從 FunctionalLayers 建置 attention、MLP 等。
  2. 動手實踐量化：使用 AMMO 量化一個 Llama 2 模型並對比 FP16 效能與視訊記憶體。
  3. 在多 GPU 環境配置 TP/PP，通過 Nsight Systems 分析通訊時間與計算重疊情況。

高階/貢獻級

  1. 閱讀 TensorRT-LLM 的核心原始碼，理解圖最佳化 passes 和執行時排程器實現。
  2. 為新模型架構（如 Mixtral 的 MoE）貢獻模型定義檔案。
  3. 最佳化特定硬體平台的 kernel，參與 TensorRT 核心自動調諧引數調整。
  4. 將 TensorRT-LLM 引擎整合進已有的推論服務閘道器，實現多模型路由與混合加速。

參考資源

  • NVIDIA TensorRT-LLM GitHub 倉庫（連結略，因搜尋不可用）
  • TensorRT 開發者指南
  • vLLM 論文《Efficient Memory Management for Large Language Model Serving》以深入理解分頁注意力。

一句話總結

TensorRT-LLM 是將 LLM 推論視作編譯問題的 N 卡原生化方案，通過深度圖最佳化、分頁視訊記憶體與連續批處理，將 NVIDIA GPU 的推論效率推到硬體極限，是追求極致吞吐企業的核心選型。

延伸閱讀與來源

  • NVIDIA 官方 Blog：《TensorRT-LLM 正式釋出，加速生成式 AI 推論》（2023 年 9 月前後）
  • TensorRT-LLM 開源倉庫 Wiki 與示例文件
  • 相關學術論文：FlashAttention、PagedAttention、Orca（連續批處理）
  • 技術分析文章：SemiAnalysis 等對推論引擎的對比（部分內容需訂閱）

由於搜尋服務不可用，本頁面未連結具體 URL，建議直接訪問 NVIDIA 開發者網站獲取最新文件。所有涉及規格、版本、效能數字的描述均基於截至 2023 年的公開資料及合理推斷，未取得即時檢索資料支援。

相關推薦

同產業鏈：cloud

同產業鏈 · 相關公司

阿里巴巴BABA / 9988.HK百度BIDU / 9888.HKGoogle AlphabetGOOGL騰訊0700.HK亞馬遜 AWSAMZN字節跳動未上市Anthropic未上市CoreWeaveCRWV

相關概念

3D 高斯潑濺3D 生成Adapter TuningAgent 通訊協議Ahead-of-Time 編譯 (AOT)Attention With Linear Biases音訊 TokenAutogen
source: 公開揭露與公開資料整理 本頁僅用於產業鏈學習、資訊檢索和研究輔助；不構成投資建議，不預測漲跌，不提供買賣、部位或目標價建議。
完整概念頁 複盤 13 節結構 公司投研頁 沿產業鏈找到受益公司 投資課 把概念轉成可跟蹤模型