本文介紹使用GPU執行個體過程中可能遇到的問題，並提供對應的解決方案。
Function ComputeGPU執行個體的驅動和CUDA版本是什麼?
GPU執行個體涉及的組件版本主要分為以下兩個部分：
驅動版本：包含核心態驅動
nvidia.ko、CUDA使用者態驅動libcuda.so等。Function ComputeGPU執行個體所使用的驅動由NVIDIA提供，由Function Compute平台負責部署。隨著功能迭代、新卡型推出、BUG修複、驅動生命週期到期等原因，GPU執行個體所使用的驅動版本未來可能變化，請避免在容器鏡像中添加驅動特定相關內容，更多內容，請參見鏡像使用說明。CUDA Toolkit版本：包含CUDA Runtime、cuDNN、cuFFT等。CUDA Toolkit版本由您在構建容器鏡像時決定。
GPU驅動和CUDA Toolkit由NVIDIA發布，兩者有一定的對應關係，細節資訊請參見對應版本的CUDA Toolkit Release Notes。
Function ComputeGPU目前使用的驅動版本為550.54.15，其對應的CUDA使用者態驅動版本為12.4。為了最佳的相容性支援，建議您使用的CUDA Toolkit最低版本為11.8，最高不超過平台提供的CUDA使用者態驅動版本。
執行時遇到CUFFT_INTERNAL_ERROR怎麼辦？
目前已知CUDA 11.7中的cuFFT庫存在前向相容性問題，在較新的卡型中可能遇到上述錯誤，建議至少升級至CUDA 11.8版本。關於GPU卡型介紹，請參見執行個體規格。
以PyTorch為例，升級後，可以用以下程式碼片段來驗證，無報錯說明升級有效。
import torch
out = torch.fft.rfft(torch.randn(1000).cuda())構建鏡像時報錯CUDA GPG Error如何解決？
構建鏡像時報錯GPG error，具體資訊如下。
W: GPG error: https://developer.download.nvidia.cn/compute/cuda/repos/ubuntu2004/x86_64 InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY A4B469963BF863CC
E: The repository 'https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64 InRelease' is not signed.此時，您可以在Dockerfile檔案的RUN rm命令列後面增加如下指令碼，然後重新構建鏡像。
RUN apt-key adv --keyserver keyserver.ubuntu.com --recv-keys A4B469963BF863CC為什麼我的GPU執行個體規格顯示的是g1？
執行個體規格設定為g1等同於設定為fc.gpu.tesla.1。更多資訊，請參見執行個體規格。
為什麼我的預留GPU執行個體預留不成功？
預留執行個體失敗可能有以下原因：
預留執行個體啟動逾時
錯誤碼："FunctionNotStarted"
錯誤資訊："Function instance health check failed on port XXX in 120 seconds"
解決方案：檢查應用啟動邏輯，是否存在公網模型下載、10 GB以上大模型載入邏輯。建議優先完成Web Server啟動，再執行模型載入邏輯。
已達到函數或地區層級的執行個體數量上限
GPU鏡像大小限制是多少？
鏡像大小限制是針對壓縮後的鏡像，非壓縮前的鏡像。您可以在阿里雲Container Registry控制台查看壓縮後鏡像尺寸，也可以在本地執行命令docker images查詢壓縮前鏡像尺寸。
通常情況下，壓縮前尺寸小於20 GB的鏡像可以正常部署到Function Compute並使用。
GPU鏡像加速轉換失敗怎麼辦？
隨著您的鏡像尺寸增長，鏡像加速轉換耗時會同步的增長，可能會因為逾時導致鏡像加速轉換失敗。您可以通過在Function Compute控制台編輯和儲存函數配置的方式（無需實際調整參數），重新觸發加速鏡像的轉換。
模型應該打在鏡像裡，還是與鏡像分離？
如果您的模型檔案較大、迭代頻繁或隨鏡像發布時超過平台鏡像大小限制，建議模型與鏡像分離。如果模型尺寸較小，例如百MB左右，變更也不頻繁，可以考慮模型檔案隨鏡像分發。關於平台鏡像大小限制，請參見GPU鏡像大小限制是多少？。
如果選擇模型與鏡像分離的部署方式，可以將模型儲存在NAS檔案系統或OSS檔案系統，應用啟動時從掛載點載入模型。具體操作，請參見配置NAS檔案系統和配置OSSObject Storage Service。
如何做模型預熱，有沒有最佳實務？
建議在/initialize方法中進行模型預熱，僅當/initialize方法完成後，模型才會真正接入生產流量。更多資訊，請參見以下文檔：
GPU鏡像啟動報錯：[FunctionNotStarted] Function Instance health check failed on port xxx in 120 seconds.
問題原因：AI/GPU應用啟動耗時過長，導致Function ComputeFC平台健全狀態檢查失敗。其中導致AI/GPU應用啟動耗時過長的常見原因是載入模型耗時過長，導致WebServer啟動逾時。
解決方案：
不要在應用啟動時從公網動態載入模型，建議將模型放置在鏡像中，或者Apsara File Storage NAS中，就近載入模型。
將模型初始化放置在
/initialize方法中，優先完成應用啟動。即WebServer啟動後，再載入模型。說明關於函數執行個體生命週期的詳細資料，請參見配置執行個體生命週期。
我的函數端到端延遲較大，並且波動很大，需要怎麼處理？
首先需要確認環境資訊中鏡像加速準備狀態為可用。
確認NAS檔案系統的類型。如果您的函數需要從NAS檔案系統中讀取資料，如讀模數型，為了保證效能，強烈建議使用通用型NAS的效能型，不推薦使用容量型。更多資訊，請參見通用型NAS。
無法找到NVIDIA驅動程式怎麼辦？
通過docker run --gpus all命令指定容器，並使用docker commit方式構建應用鏡像時，構建的鏡像會攜帶本地NVIDIA驅動程式資訊，這將導致鏡像部署到Function Compute後驅動程式無法正常掛載。此時，系統無法找到NVIDIA驅動程式。
為瞭解決以上問題，Function Compute建議您使用Dockerfile的方式構建應用鏡像。更多資訊，請參見dockerfile。
請您避免在容器鏡像中添加特定驅動版本相關的內容，更多資訊，請參見鏡像使用說明。
使用Ada系列卡型，報錯On-demand invocation of current GPU type is disabled...如何處理？
遇到報錯ResourceExhausted：On-demand invocation of current GPU type is disabled, please provision instances instead通常是由於實際請求數超過函數當前預留執行個體可以承載的最大請求數量，由於Ada卡型僅支援預留模式，建議您根據實際請求數增加函數預留執行個體個數。
使用閑置GPU執行個體有哪些注意事項？
CUDA版本
推薦使用CUDA 12.2以及更早的版本。
鏡像許可權
推薦在容器鏡像中以預設的root使用者權限運行。
執行個體登入
閑置GPU執行個體中，由於GPU凍結等原因，暫不支援登入執行個體。
模型預熱/預推理
閑置GPU執行個體中，為保證執行個體的首次喚醒延遲符合預期，建議您在業務代碼中使用
initialize生命週期回調功能來進行模型預熱/預推理，詳情請參見模型服務預熱。預留配置
切換閑置模式開關時會使該函數現有的GPU預留執行個體優雅下線，預留執行個體數短暫歸零，直到新的預留執行個體出現。