Översikt över Windows ML Runtime API

Windows ML Runtime API är ett inbyggt C/C++-lokalt AI-inferensramverk som skapats specifikt för Windows. Med Windows ML Runtime-API:et kan du läsa in en modell, välja ett cpu-, GPU- eller NPU-körningsmål (inklusive ett specifikt DXCore-kort eller en D3D12-enhet), binda tensorer till det målet, skapa modell- och processorsteg i en pipeline, kompilera pipelinen och köra den för att producera utdata tensorer.

De valfria API:erna för textgenerering och taligenkänning sammanfogar dessa samma Runtime-objekt till arbetsflöden på högre nivå över en modell som din app tillhandahåller: se Generera text med din egen språkmodell med Windows ML och Känn igen tal med din egen Whisper-modell med hjälp av Windows ML.

Runtime API jämfört med ONNX Runtime

Om din app endast riktar sig mot Windows (och du är villig att använda API:er som för närvarande är experimentella), använd Runtime-API:et. Den ger explicit kontroll över maskinvaruval (inklusive ett specifikt DXCore-kort eller D3D12-enhet), tensorresidens, pipelineplacering i flera steg och kompilering.

Annars, om din app behöver köras på andra plattformar eller redan har fungerande plattformsoberoende ONNX Runtime-sessionskod, använd ONNX Runtime-API:er som ingår i Windows ML i stället.

Kärnobjektmodell

Välj en backend och ett körningsmål

LoadModelFromFile väljer backend från modellartefaktens filnamnstillägg. Appen använder samma Runtime-objekt – modell, körningsmål, pipelinebyggare, steg, bindningar och Run – oavsett vilken backend som läser in filen.

Ett körningsmål representerar en maskinvaruklass – CPU, GPU eller NPU – som skapats med IWinMLRuntime. Återanvänd ett mål för att skapa steg och skapa tensorer: återanvändning av ett mål uttrycker samma måltillhörighet, samtidigt som distinkta mål gör överföringsgränser mellan mål explicita. När pipelinebyggarens Build-metod körs placerar körningen varje steg på exekveringsbackend för sitt mål och bekräftar kompatibiliteten mellan mål och backend.

För en maskinvaruklass utan att räkna upp enheter själv anropar du CreateExecutionTarget med en WINML_EXECUTION_TARGET_KIND och en WINML_EXECUTION_TARGET_PREFERENCE som rangordnar kandidater i den klassen, till exempel en integrerad kontra en diskret GPU. Behandla ERROR_NOT_FOUND och ERROR_NOT_SUPPORTED lika och använd en annan klass som reserv:

ComPtr<IWinMLExecutionTarget> target;
HRESULT hr = runtime->CreateExecutionTarget(
    WINML_EXECUTION_TARGET_KIND_NPU,
    WINML_EXECUTION_TARGET_PREFERENCE_EFFICIENCY,
    target.GetAddressOf());
if (hr == HRESULT_FROM_WIN32(ERROR_NOT_FOUND) ||
    hr == HRESULT_FROM_WIN32(ERROR_NOT_SUPPORTED))
{
    THROW_IF_FAILED(runtime->CreateExecutionTarget(
        WINML_EXECUTION_TARGET_KIND_GPU,
        WINML_EXECUTION_TARGET_PREFERENCE_PERFORMANCE,
        target.GetAddressOf()));
}
else
{
    THROW_IF_FAILED(hr);
}

CreateCpuExecutionTarget motsvarar att begära CPU-typen. CreateExecutionTargetFromAdapter och CreateExecutionTargetFromD3D12 binder ett mål till ett specifikt DXCore-kort eller en D3D12-enhet i stället för att låta Runtime välja ett. För ONNX-modeller som är beroende av en installerad execution provider (EP) kan du med en valfri ONNX Runtime-kompatibilitetsyta fästa en provider som du redan har registrerat. Varje serverdel löser dessa mål på olika sätt– till exempel kräver den llama.cpp serverdel som används av .gguf modeller minst delvis GPU-avlastning för att uppfylla ett GPU-mål och stöder inte NPU-mål eller leverantörslåsning. Den fullständiga målupplösningsmatrisen per backend och en genomgång av hur du kör en GGUF-modell finns i Begrepp för Windows ML Runtime API.

Nästa steg

• Konfigurera ett C++-projekt för Windows ML Runtime API
• Windows API-begrepp för ML Runtime
• Generera text med din egen språkmodell med hjälp av Windows ML
• Känn igen tal med din egen Whisper-modell med hjälp av Windows ML
• Kör en modell med Windows ML Runtime API