本文主要介紹如何在無需閘道器，無需配置 HttpClient 的情況下，使用 Semantic Kernel 直接呼叫本地大模型與阿裏雲靈積 DashScope 等 OpenAI 介面相容的大模型服務。
1. 背景
一直以來，我們都在探索如何更好地利用大型語言模型（LLM）的能力。 Semantic Kernel [1] 作為一個微軟開源的語意內核 SDK，它提供了一種高效的方式讓使用者可以在自己的應用程式中整合大語言模型 (LLM) 的強大功能。
同時，隨著 OpenAI 的發展，其介面呼叫方式已被廣泛采用和認可，成為了眾多大型語言模型的標準介面或相容標準。在 .Net 使用的 OpenAI 庫，大家之前一直廣泛使用的是
Azure.AI.OpenAI
，但是因為設計上的一些限制，我們無法直接呼叫本地大模型或者一些相容 OpenAI 介面的大模型服務。因為內部審計，統一管理，成本分攤，無法直接存取或自建服務等原因，可以方便的修改服務地址，一直是大家的迫切需求。
近期 OpenAI 正式釋出了第一個官方 .NET 版的測試 SDK，
Azure.AI.OpenAI
的 2.x 版本，這個版本的 SDK 也將基於這個新的 SDK 進行開發。但是目前這個 SDK 還處於測試階段。
在之前的文章中，我也介紹了如何在 Semantic Kernel 中使用本地大模型的臨時方案。當前隨著 Semantic Kernel 的不斷完善，我們有了更方便的方式來呼叫本地大模型與阿裏雲靈積 DashScope 等一些相容 OpenAI 介面的大模型服務。
2. 本地服務
相信大家都有自己的本地大模型服務，或者是一些相容 OpenAI 介面的大模型服務。本地大模型部署的方式有很多種，也越來越簡單，我們可以方便的使用 Ollama、llama-server（llama.cpp） 等開源計畫，來執行 Llama 3， Phi 3， Qwen2， Mistral，Gemma 等流行的大模型。
在這裏我介紹一下我近期的一個開源計畫 LLamaWorker [2] ，一個基於 LLamaSharp [3] 的 ASP.NET 計畫，提供 OpenAI 相容的介面，感興趣的同學可以了解一下。
雖然都是開源計畫，但相比較而言，Ollama 更適合普通使用者。而 llama.cpp 和 LLamaWorker 更適合開發者，可以更方便的進行二次開發和計畫整合。
3. 程式碼實作
在 Semantic Kernel 中，提供了一個實驗性的功能，在 OpenAI 連結器中提供了自訂伺服端點的功能。這個功能可以讓我們直接呼叫本地大模型或者一些相容 OpenAI 介面的大模型服務。
我們可以透過
AddOpenAIChatCompletion()
建立自訂的 OpenAI 服務。對於
var services = newServiceCollection();services.AddKernel();services.AddOpenAIChatCompletion("qwen-long", newUri("https://dashscope.aliyuncs.com/compatible-mode/v1/chat/completions"), "you key");
4. 註意事項
使用
AddOpenAIChatCompletion
時，我們需要輸入完整的
ChatCompletion
端點，這與之前的使用習慣並不一致。
另外，由於改功能也尚處於試驗階段，並且其依賴的
Azure.AI.OpenAI
還是 1.0 的版本，對於後面的推出的 2.x 還並沒有升級適配，還是需要時刻關註該接入方式的變更。
5. 最後
Semantic Kernel 的出現為開發者提供了一個強大且靈活的工具，使得在不同的環境下呼叫大型語言模型變得更加簡單和高效。透過直接呼叫本地大模型或相容 OpenAI 介面的服務，我們可以更好地控制數據的私密和安全，同時也能夠根據自己的需要調整服務的配置和效能。
此外，隨著技術的發展和社群的貢獻，我們期待看到更多的開源計畫和工具的出現，這將進一步降低技術門檻，讓更多的開發者和企業能夠輕松地利用大型語言模型的強大能力。
References
[1]
Semantic Kernel:
https://github.com/microsoft/semantic-kernel?wt.mc_id=DT-MVP-5005195
[2]
LLamaWorker:
https://github.com/sangyuxiaowu/LLamaWorker?wt.mc_id=DT-MVP-5005195
[3]
LLamaSharp:
https://github.com/SciSharp/LLamaSharp?wt.mc_id=DT-MVP-5005195
