本文介紹使用GPU執行個體過程中可能遇到的問題，並提供對應的解決方案。
Function ComputeGPU執行個體的驅動和CUDA版本是什麼?
GPU執行個體涉及的組件版本主要分為以下兩個部分：
驅動版本：包含核心態驅動
nvidia.ko、CUDA使用者態驅動libcuda.so等。Function ComputeGPU執行個體所使用的驅動由NVIDIA提供，由Function Compute平台負責部署。隨著功能迭代、新卡型推出、BUG修複、驅動生命週期到期等原因，GPU執行個體所使用的驅動版本未來可能變化，請避免在容器鏡像中添加驅動特定相關內容，更多內容，請參見無法找到NVIDIA驅動程式怎麼辦？。CUDA Toolkit版本：包含CUDA Runtime、cuDNN、cuFFT等。CUDA Toolkit版本由您在構建容器鏡像時決定。
GPU驅動和CUDA Toolkit由NVIDIA發布，兩者有一定的對應關係，細節資訊請參見對應版本的CUDA Toolkit Release Notes。
Function ComputeGPU目前使用的驅動版本為580.95.05，其對應的CUDA使用者態驅動版本為13.0。為了最佳的相容性支援，建議您使用的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控制台編輯和儲存函數配置的方式（無需實際調整參數），重新觸發加速鏡像的轉換。
模型應該打在鏡像裡，還是與鏡像分離？
如果您的模型檔案較大、迭代頻繁或隨鏡像發布時超過平台鏡像大小限制，建議模型與鏡像分離。如果選擇模型與鏡像分離的部署方式，可以將模型儲存在NAS檔案系統或OSS檔案系統中，詳情請參見GPU執行個體模型儲存最佳實務。
如何做模型預熱，有沒有最佳實務？
建議在/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。
另外，請勿在鏡像中添加驅動相關的組件，同時請您避免應用對特定的驅動版本產生依賴。例如，不要將提供CUDA Driver API的libcuda.so放入鏡像中，此動態庫與裝置核心驅動版本強相關。鏡像中的此類動態庫不匹配可能導致應用因相容性問題出現行為異常。
建立函數執行個體時，Function Compute平台會預先將驅動相關的使用者態組件注入到容器中，這些組件與平台提供的驅動版本相匹配。這也是NVIDIA Container Runtime等GPU容器虛擬化技術的行為，將驅動特定的任務交予平台資源提供方，從而最大化GPU容器鏡像的環境適應能力。Function ComputeGPU執行個體所使用的驅動由NVIDIA提供。隨著功能迭代、新卡型推出、BUG修複、驅動生命週期到期等原因，GPU執行個體所使用的驅動版本未來可能變化。
若您已經在使用NVIDIA Container Runtime等GPU容器虛擬化技術，請您避免使用docker commit命令建立鏡像，此類鏡像中會包含已注入的驅動相關組件。當您在Function Compute平台使用此類鏡像時，可能因組件版本與平台不匹配而產生未定義行為，如應用異常等。
按量調用無法彈出GPU執行個體，提示"ResourceExhausted"、"ResourceThrottled"如何處理？
由於GPU資源供應相對稀缺，按量調用會受到資源集區水位波動的影響，可能導致無法及時彈出執行個體服務滿足調用請求。如果需要可預期的資源交付，建議為函數配置Auto Scaling規則來預留資源。有關預留執行個體計費詳情，請參見計費概述。