在編寫CUDA應用程序，您可以在驅動程序級別或在運行時級別在這個圖像上所示的工作（該庫是CUFFT和CUBLAS的高等數學）：CUDA驅動程序API對CUDA運行時
我認爲兩者之間的權衡是降低低級API的性能，但代價是代碼複雜度增加。具體的區別是什麼？有沒有什麼重要的事情你不能用高級API來做？
我使用CUDA.net與C＃進行互操作，並將它構建爲驅動程序API的副本。這鼓勵在C＃中編寫大量相當複雜的代碼，而使用運行時API可以使C++相當簡單。這樣做有什麼可以贏嗎？我可以看到的一個好處是，將智能錯誤處理與其他C＃代碼集成起來會更容易。
CUDA運行時可以編譯CUDA內核並將其鏈接到可執行文件中。這意味着您不必在應用程序中分發cubin文件，或者通過驅動程序API處理它們。正如你所指出的，它通常更易於使用。
相比之下，驅動程序API很難編程，但提供了更多的CUDA使用控制。程序員有直接處理初始化，模塊加載等
顯然更詳細的設備信息，可以通過驅動程序API查詢不是通過運行時API。例如，設備上可用的空閒內存只能通過驅動程序API查詢。
從CUDA程序員指南：
它由兩個API組成：
- 一個低級別的API調用CUDA驅動程序API，
- 更高級別的API調用CUDA運行時API，在CUDA驅動程序API的頂層實現 。
這些API是互斥的：一個應用程序應該使用其中一個或者使用 。
CUDA運行時通過提供隱式的 初始化，上下文管理和模塊管理來簡化設備代碼管理。通過NVCC生成的C主機代碼 基於CUDA運行時（見第4.2.5節），所以 應用鏈接到這個代碼必須使用CUDA運行時API。相比之下，CUDA驅動程序API需要更多的代碼，更難編程和調試，但提供了更好的控制級別，並且與語言無關，因爲它只處理cubin對象的 （請參閱第4.2.5節） 。特別是，它是使用CUDA驅動程序API 配置和啓動內核比較困難，因爲執行 配置和內核參數必須使用顯式函數調用來指定 ，而不是在4.2.3所述的執行配置語法。此外，設備 仿真（見4.5.2.9）不使用CUDA驅動程序API的工作。
API之間沒有明顯的性能差異。你的內核如何使用內存以及它們在GPU上的佈局（經線和塊）將會產生更爲明顯的效果。
的CUDA子集，一個引用？如果是這樣，我找不到它。你能說出確切的文件名稱和章節在哪裏發現？ – dialer 2012-06-16 13:19:54
`這些API是互斥的：對於更新的CUDA版本，這不再是真實的。現在該文檔聲明`一個應用程序可以將運行時API代碼與驅動程序API代碼混合在一起.`也是cfr。 http://stackoverflow.com/a/27014990/1938163 – 2014-11-19 11:00:05
了幾個重要的事情需要注意：
第一的API之間的差異僅適用於主機端的代碼。內核完全一樣。在主機端，驅動程序api的複雜性相當微不足道，其基本區別如下：
在驅動程序api中，您可以訪問運行時api中沒有的功能，如上下文。
模擬器僅適用於爲運行時API編寫的代碼。
哦，目前的cudpp這是一個非常方便的庫，僅適用於運行時api。
參數對齊和驅動程序API存在一些實際問題。查看CUDA 2.2 beta（或更高版本）文檔以獲取更多信息。
今天這種情況仍然存在嗎？ – einpoklum 2016-02-01 22:35:57
我發現爲了在多線程應用程序中部署庫，對驅動程序API提供的CUDA上下文的控制至關重要。我的大多數客戶都希望將GPU加速集成到現有的應用程序中，而現在，幾乎所有的應用程序都是多線程的。由於我無法保證所有的GPU代碼都會被同一個線程初始化，執行和釋放，所以我不得不使用驅動程序API。我發現我可以反覆地通過執行來自不同線程的錯誤的CUDA調用集合，立即重新啓動計算機，從而導致失敗，有時會以驚人的方式失敗。
由於我們將所有內容都通過驅動程序API進行了遷移，所以一切正常。
Ĵ
一個驅動程序API的優勢將是編譯器開發人員添加其他語言編寫內核支持，C. – 2009-10-21 22:12:37