1. 项目缘起与整体设计思路1.1 为什么要在ASP.NET MVC里塞进一个本机LLM先说说这个项目的来龙去脉。我手头有一个跑了三年多的ASP.NET MVC老系统主要做企业内部工单流转和文档管理技术栈就是经典的C# .NET Framework 4.7.2 ASP.NET MVC 5前端是Razor视图加jQuery数据库SQL Server。这套东西稳定是稳定但这两年业务侧提了一个新需求能不能在系统里直接做智能问答、文档摘要、工单自动分类这些AIGC能力。一开始想的是直接调云端API但实际评估下来有几个绕不过去的坎。第一是数据敏感性工单里经常夹着客户名称、合同金额、内部流程细节走公网API合规上过不去。第二是成本按调用量算下来一年要花不少钱而且业务量还在涨。第三是响应延迟网络抖动的时候体验很差。所以最终决定走本机LLM这条路把模型跑在本地服务器上通过C#直接调用。这个决策背后的核心逻辑是数据不出内网、成本一次性投入、延迟可控。当然代价也很明显——本机LLM的推理质量肯定不如云端大模型尤其是AIGC的准确性会打折扣。所以整个项目的重点其实不是“怎么把模型跑起来”而是“怎么在算力受限的前提下把AIGC的准确性做到业务可接受的程度”。1.2 整体架构的分层设计整个工程我分成了四层从下往上依次是模型推理层负责加载GGUF格式的量化模型提供本地推理能力。这一层我用的是LLamaSharp它是llama.cpp的C#绑定能在Windows上直接跑不需要额外装Python环境。服务封装层把推理能力包装成C#服务处理Prompt模板、上下文管理、流式输出、超时重试这些通用逻辑。业务适配层针对工单分类、文档摘要、智能问答三个场景分别做Prompt工程和结果后处理。MVC集成层通过Controller暴露接口前端用AJAX调用流式结果用SSE推送到页面。这样分层的好处是模型换了、Prompt改了上层业务代码基本不用动。我试过从Qwen2.5-7B换到Llama-3.1-8B只改了配置文件里的模型路径和几个参数业务层一行没动。1.3 技术选型背后的取舍选LLamaSharp而不是其他方案主要考虑几点。一是它是纯C#库跟ASP.NET MVC集成最自然不需要跨进程通信。二是支持GGUF量化格式7B模型量化到Q4_K_M大概4.5GB一台16GB内存的服务器就能跑。三是支持流式输出这对前端体验很重要。模型方面我最终选了Qwen2.5-7B-Instruct的Q4_K_M量化版。原因很实际中文能力强指令跟随好7B规模在CPU上推理速度勉强能接受大概每秒8-12个token。如果你们服务器有GPU那选择面就宽多了可以上14B甚至32B。注意本机LLM的准确性天花板很大程度上由模型规模和量化等级决定。Q4量化会损失一部分精度如果业务对准确性要求极高建议用Q5或Q8代价是内存和速度。2. 核心细节解析与实操要点2.1 LLamaSharp的引入与模型加载在ASP.NET MVC项目里引入LLamaSharp通过NuGet装两个包LLamaSharp和LLamaSharp.Backend.Cpu。如果你有CUDA环境把第二个换成LLamaSharp.Backend.Cuda12。模型加载的核心代码如下我把它封装成了一个单例服务public class LlmService { private readonly LLamaWeights _weights; private readonly LLamaContext _context; private readonly InteractiveExecutor _executor; public LlmService(string modelPath) { var parameters new ModelParams(modelPath) { ContextSize 4096, GpuLayerCount 0, BatchSize 512 }; _weights LLamaWeights.LoadFromFile(parameters); _context _weights.CreateContext(parameters); _executor new InteractiveExecutor(_context); } }这里有几个参数需要重点说。ContextSize是上下文窗口大小4096够用但不算宽裕如果要做长文档摘要建议开到8192代价是内存翻倍。GpuLayerCount设为0表示纯CPU推理有GPU的话设成-1表示全部卸载到GPU。BatchSize影响吞吐512是CPU上的折中值。实操心得模型加载很慢7B模型在机械硬盘上要十几秒。一定要做成单例在Application_Start时预热加载不要每次请求都加载。2.2 Prompt模板的设计与准确性关系AIGC的准确性一半靠模型一半靠Prompt。我在项目里踩过最大的坑就是Prompt写得太随意导致输出格式不稳定。以工单分类为例最初的Prompt是“请判断以下工单属于哪个类别”结果模型有时候输出类别名有时候输出一句话解释有时候还自己编类别。后来改成结构化Prompt你是一个工单分类助手。请将用户工单归类到以下类别之一 [网络故障, 硬件报修, 软件安装, 账号权限, 其他] 要求 1. 只输出类别名称不要任何解释 2. 如果无法判断输出其他 3. 不要输出标点符号 工单内容{content} 类别改完之后准确率从大概70%提升到90%以上。核心思路是约束输出空间让模型没有发挥的余地。2.3 上下文管理与多轮对话智能问答场景需要多轮对话但本机LLM的上下文窗口有限不能无限堆积历史。我的做法是滑动窗口加摘要压缩保留最近3轮完整对话更早的对话用模型自己生成一句摘要塞进System Prompt。private string BuildPrompt(ListChatMessage history, string userInput) { var sb new StringBuilder(); sb.AppendLine(你是一个企业内部助手回答要简洁准确。); // 只保留最近3轮 var recent history.TakeLast(6).ToList(); foreach (var msg in recent) { sb.AppendLine(${msg.Role}: {msg.Content}); } sb.AppendLine($user: {userInput}); sb.AppendLine(assistant:); return sb.ToString(); }这个策略实测下来在4096上下文窗口里能稳定支撑10轮左右的对话再长就会开始丢信息。2.4 流式输出的实现细节前端体验的关键是流式输出不能让用户干等十几秒。LLamaSharp支持IAsyncEnumerablestring配合ASP.NET MVC的Response.WriteAsync和Flush就能实现SSE。public async Task StreamAnswer(string prompt) { Response.ContentType text/event-stream; Response.Headers.Add(Cache-Control, no-cache); await foreach (var token in _executor.InferAsync(prompt)) { await Response.WriteAsync($data: {token}\n\n); await Response.FlushAsync(); } await Response.WriteAsync(data: [DONE]\n\n); }注意IIS默认会缓冲响应必须在web.config里关掉responseBufferLimit或者在Action里设置Response.BufferOutput false否则流式效果出不来。3. 实操过程与核心环节实现3.1 环境准备与依赖安装第一步是把运行环境搭起来。服务器是Windows Server 201916GB内存8核CPU没有独立显卡。这个配置跑7B Q4模型是底线再低就卡了。安装步骤在VS里新建或打开现有的ASP.NET MVC项目目标框架选.NET Framework 4.7.2或更高。通过NuGet安装LLamaSharp0.13.0和LLamaSharp.Backend.Cpu0.13.0。下载Qwen2.5-7B-Instruct的GGUF文件放到项目外的独立目录比如D:\Models\。在Web.config里配置模型路径方便不同环境切换。appSettings add keyLlmModelPath valueD:\Models\qwen2.5-7b-instruct-q4_k_m.gguf/ add keyLlmContextSize value4096/ /appSettings3.2 推理服务的封装与参数调优推理参数对准确性影响很大我调了好几轮才找到合适的组合参数取值说明Temperature0.1分类和摘要场景要低问答可以到0.7TopP0.9配合Temperature使用TopK40默认值一般不用改RepeatPenalty1.1防止重复输出MaxTokens512根据场景调整摘要可以到1024Temperature是最关键的。做分类的时候我设0.1几乎就是确定性输出做创意问答的时候设0.7输出更自然。这个参数没有万能值必须按场景调。var inferenceParams new InferenceParams { Temperature 0.1f, TopP 0.9f, AntiPrompts new Liststring { user:, assistant: }, MaxTokens 512 };AntiPrompts这个参数很实用它能让模型在生成到指定字符串时自动停止避免模型自己续写对话。3.3 三个业务场景的落地实现工单分类输入工单标题和描述输出类别。用结构化Prompt加低Temperature准确率能到90%以上。后处理再做一层校验如果输出不在预设类别里直接归为“其他”。文档摘要输入长文档输出200字摘要。这里有个坑文档超过上下文窗口时要分段摘要再合并。我的做法是每2000字切一段分别摘要最后把各段摘要拼起来再让模型做一次总摘要。智能问答基于知识库的问答需要先做检索。我用的是简单的关键词匹配加BM25把Top3相关文档片段塞进Prompt。这块没上向量检索因为本机跑embedding模型又是一笔开销关键词匹配在内部文档场景够用了。3.4 MVC层的集成与前端交互Controller层很薄主要做参数校验和调用服务public class AiController : Controller { private readonly LlmService _llm; public AiController() { _llm LlmService.Instance; } [HttpPost] public async TaskActionResult Classify(string content) { var prompt PromptTemplates.Classify.Replace({content}, content); var result await _llm.InferAsync(prompt); return Json(new { category result.Trim() }); } }前端用fetch调用流式接口用EventSource接收。这里要注意跨域和超时设置IIS默认超时是110秒长文本推理可能超时需要在web.config里调大executionTimeout。4. 常见问题与排查技巧实录4.1 AIGC准确性不达标的排查思路准确性问题是这个项目最头疼的。我整理了一个排查顺序现象可能原因排查方法输出格式不稳定Prompt约束不够加结构化约束和示例分类准确率低Temperature过高降到0.1试试答非所问上下文被截断检查ContextSize和Prompt长度重复输出RepeatPenalty太低调到1.1-1.2中文乱码模型不支持中文换Qwen或ChatGLM系列我的经验是先怀疑Prompt再怀疑参数最后才怀疑模型。大部分准确性问题都是Prompt没写好。4.2 性能瓶颈的定位与优化CPU推理慢是必然的但可以优化。我实测下来几个有效的点开启BatchSize到512吞吐能提升20%左右。用mmap加载模型减少内存占用和加载时间。把GpuLayerCount设成-1如果有GPU速度能提升5-10倍。限制MaxTokens不要让它无限生成。如果并发量上来了单实例扛不住可以考虑起多个进程做负载均衡每个进程加载一份模型。内存够的话这是最简单的扩展方式。4.3 内存溢出与模型加载失败16GB内存跑7B Q4模型理论占用约5GB但实际运行中峰值能到8-9GB。如果同时跑IIS和其他服务很容易OOM。解决办法一是把IIS的应用程序池内存限制调大二是模型加载用mmap模式让操作系统管理内存三是如果实在不够换3B模型或者Q3量化。模型加载失败最常见的原因是GGUF文件损坏或版本不兼容。LLamaSharp对GGUF版本有要求太新的模型可能加载不了。遇到加载失败先用llama.cpp的命令行工具验证一下模型文件是否正常。4.4 独家避坑技巧汇总几个文档里不会写但实际很重要的点模型文件不要放在项目目录里否则VS的发布流程会把它打包进去几个GB的文件能把发布搞崩。Application_Start里预热加载模型第一个请求才不会超时。给推理加超时和取消机制用户关掉页面了还在跑推理是浪费资源。日志要记录完整的Prompt和输出排查准确性问题时这是唯一线索。不同场景用不同的LlmService实例因为推理参数不一样共享实例会互相干扰。提示本机LLM的准确性优化是个持续过程建议建一个测试集每次改Prompt或参数后跑一遍用数据说话不要凭感觉。5. 关于AIGC准确性的深度思考5.1 本机LLM准确性的天花板在哪里说实话7B量化模型的能力边界很明显。简单分类、短文本摘要、FAQ问答这些任务能做到可用但涉及复杂推理、长文档理解、多跳问答效果就明显不如云端大模型。我的判断是本机LLM适合任务边界清晰、输出格式固定、容错率较高的场景。如果你的业务需要模型做开放式创作或者复杂逻辑推理本机方案大概率会让你失望。这时候要么上更大的模型配GPU要么老老实实调云端API。5.2 工程手段能弥补多少准确性工程手段能弥补的准确性大概在10-20个百分点。具体来说Prompt工程能提升10-15个点这是性价比最高的。结果后处理能提升5个点左右比如格式校验、关键词兜底。检索增强能提升10个点以上但需要额外的检索系统。模型微调能提升更多但成本高本机场景不太现实。所以我的策略是把Prompt工程和后处理做到极致把模型能力榨干而不是一味追求更大的模型。5.3 准确性评估的落地方法没有评估就没有优化。我建了一个200条的测试集覆盖三个场景的典型case每次改动后跑一遍记录准确率、响应时间、格式合规率三个指标。评估脚本很简单就是一个控制台程序读测试集调服务比对预期结果输出报告。这个投入很值得它让优化从玄学变成了工程。6. 后续可扩展的方向这套架构跑通之后扩展空间其实挺大的。我目前想到几个方向一是接入向量数据库做真正的RAG提升问答准确性二是加一层缓存相同问题直接返回历史结果三是做模型热切换不同场景用不同模型四是把推理服务独立成Windows服务跟Web应用解耦。我个人在实际操作中的体会是本机LLM工程最难的不是技术而是预期管理。要让业务方明白本机方案是在数据安全和成本约束下的折中准确性有天花板。把预期对齐了项目推进会顺利很多。最后再分享一个小技巧如果你们团队有多个项目要用LLM把推理服务做成独立的HTTP服务用C#写个简单的Web API包装一下其他项目直接调比每个项目都集成一遍LLamaSharp要省事得多。 
长河君 · 2026/10/10 13:24:53 · 阅读 1.2k ASP.NET MVC集成LLamaSharp本机LLM：AIGC准确性优化实战
1. 项目缘起与整体设计思路1.1 为什么要在ASP.NET MVC里塞进一个本机LLM先说说这个项目的来龙去脉。我手头有一个跑了三年多的ASP.NET MVC老系统主要做企业内部工单流转和文档管理技术栈就是经典的C# .NET Framework 4.7.2 ASP.NET MVC 5前端是Razor视图加jQuery数据库SQL Server。这套东西稳定是稳定但这两年业务侧提了一个新需求能不能在系统里直接做智能问答、文档摘要、工单自动分类这些AIGC能力。一开始想的是直接调云端API但实际评估下来有几个绕不过去的坎。第一是数据敏感性工单里经常夹着客户名称、合同金额、内部流程细节走公网API合规上过不去。第二是成本按调用量算下来一年要花不少钱而且业务量还在涨。第三是响应延迟网络抖动的时候体验很差。所以最终决定走本机LLM这条路把模型跑在本地服务器上通过C#直接调用。这个决策背后的核心逻辑是数据不出内网、成本一次性投入、延迟可控。当然代价也很明显——本机LLM的推理质量肯定不如云端大模型尤其是AIGC的准确性会打折扣。所以整个项目的重点其实不是“怎么把模型跑起来”而是“怎么在算力受限的前提下把AIGC的准确性做到业务可接受的程度”。1.2 整体架构的分层设计整个工程我分成了四层从下往上依次是模型推理层负责加载GGUF格式的量化模型提供本地推理能力。这一层我用的是LLamaSharp它是llama.cpp的C#绑定能在Windows上直接跑不需要额外装Python环境。服务封装层把推理能力包装成C#服务处理Prompt模板、上下文管理、流式输出、超时重试这些通用逻辑。业务适配层针对工单分类、文档摘要、智能问答三个场景分别做Prompt工程和结果后处理。MVC集成层通过Controller暴露接口前端用AJAX调用流式结果用SSE推送到页面。这样分层的好处是模型换了、Prompt改了上层业务代码基本不用动。我试过从Qwen2.5-7B换到Llama-3.1-8B只改了配置文件里的模型路径和几个参数业务层一行没动。1.3 技术选型背后的取舍选LLamaSharp而不是其他方案主要考虑几点。一是它是纯C#库跟ASP.NET MVC集成最自然不需要跨进程通信。二是支持GGUF量化格式7B模型量化到Q4_K_M大概4.5GB一台16GB内存的服务器就能跑。三是支持流式输出这对前端体验很重要。模型方面我最终选了Qwen2.5-7B-Instruct的Q4_K_M量化版。原因很实际中文能力强指令跟随好7B规模在CPU上推理速度勉强能接受大概每秒8-12个token。如果你们服务器有GPU那选择面就宽多了可以上14B甚至32B。注意本机LLM的准确性天花板很大程度上由模型规模和量化等级决定。Q4量化会损失一部分精度如果业务对准确性要求极高建议用Q5或Q8代价是内存和速度。2. 核心细节解析与实操要点2.1 LLamaSharp的引入与模型加载在ASP.NET MVC项目里引入LLamaSharp通过NuGet装两个包LLamaSharp和LLamaSharp.Backend.Cpu。如果你有CUDA环境把第二个换成LLamaSharp.Backend.Cuda12。模型加载的核心代码如下我把它封装成了一个单例服务public class LlmService { private readonly LLamaWeights _weights; private readonly LLamaContext _context; private readonly InteractiveExecutor _executor; public LlmService(string modelPath) { var parameters new ModelParams(modelPath) { ContextSize 4096, GpuLayerCount 0, BatchSize 512 }; _weights LLamaWeights.LoadFromFile(parameters); _context _weights.CreateContext(parameters); _executor new InteractiveExecutor(_context); } }这里有几个参数需要重点说。ContextSize是上下文窗口大小4096够用但不算宽裕如果要做长文档摘要建议开到8192代价是内存翻倍。GpuLayerCount设为0表示纯CPU推理有GPU的话设成-1表示全部卸载到GPU。BatchSize影响吞吐512是CPU上的折中值。实操心得模型加载很慢7B模型在机械硬盘上要十几秒。一定要做成单例在Application_Start时预热加载不要每次请求都加载。2.2 Prompt模板的设计与准确性关系AIGC的准确性一半靠模型一半靠Prompt。我在项目里踩过最大的坑就是Prompt写得太随意导致输出格式不稳定。以工单分类为例最初的Prompt是“请判断以下工单属于哪个类别”结果模型有时候输出类别名有时候输出一句话解释有时候还自己编类别。后来改成结构化Prompt你是一个工单分类助手。请将用户工单归类到以下类别之一 [网络故障, 硬件报修, 软件安装, 账号权限, 其他] 要求 1. 只输出类别名称不要任何解释 2. 如果无法判断输出其他 3. 不要输出标点符号 工单内容{content} 类别改完之后准确率从大概70%提升到90%以上。核心思路是约束输出空间让模型没有发挥的余地。2.3 上下文管理与多轮对话智能问答场景需要多轮对话但本机LLM的上下文窗口有限不能无限堆积历史。我的做法是滑动窗口加摘要压缩保留最近3轮完整对话更早的对话用模型自己生成一句摘要塞进System Prompt。private string BuildPrompt(ListChatMessage history, string userInput) { var sb new StringBuilder(); sb.AppendLine(你是一个企业内部助手回答要简洁准确。); // 只保留最近3轮 var recent history.TakeLast(6).ToList(); foreach (var msg in recent) { sb.AppendLine(${msg.Role}: {msg.Content}); } sb.AppendLine($user: {userInput}); sb.AppendLine(assistant:); return sb.ToString(); }这个策略实测下来在4096上下文窗口里能稳定支撑10轮左右的对话再长就会开始丢信息。2.4 流式输出的实现细节前端体验的关键是流式输出不能让用户干等十几秒。LLamaSharp支持IAsyncEnumerablestring配合ASP.NET MVC的Response.WriteAsync和Flush就能实现SSE。public async Task StreamAnswer(string prompt) { Response.ContentType text/event-stream; Response.Headers.Add(Cache-Control, no-cache); await foreach (var token in _executor.InferAsync(prompt)) { await Response.WriteAsync($data: {token}\n\n); await Response.FlushAsync(); } await Response.WriteAsync(data: [DONE]\n\n); }注意IIS默认会缓冲响应必须在web.config里关掉responseBufferLimit或者在Action里设置Response.BufferOutput false否则流式效果出不来。3. 实操过程与核心环节实现3.1 环境准备与依赖安装第一步是把运行环境搭起来。服务器是Windows Server 201916GB内存8核CPU没有独立显卡。这个配置跑7B Q4模型是底线再低就卡了。安装步骤在VS里新建或打开现有的ASP.NET MVC项目目标框架选.NET Framework 4.7.2或更高。通过NuGet安装LLamaSharp0.13.0和LLamaSharp.Backend.Cpu0.13.0。下载Qwen2.5-7B-Instruct的GGUF文件放到项目外的独立目录比如D:\Models\。在Web.config里配置模型路径方便不同环境切换。appSettings add keyLlmModelPath valueD:\Models\qwen2.5-7b-instruct-q4_k_m.gguf/ add keyLlmContextSize value4096/ /appSettings3.2 推理服务的封装与参数调优推理参数对准确性影响很大我调了好几轮才找到合适的组合参数取值说明Temperature0.1分类和摘要场景要低问答可以到0.7TopP0.9配合Temperature使用TopK40默认值一般不用改RepeatPenalty1.1防止重复输出MaxTokens512根据场景调整摘要可以到1024Temperature是最关键的。做分类的时候我设0.1几乎就是确定性输出做创意问答的时候设0.7输出更自然。这个参数没有万能值必须按场景调。var inferenceParams new InferenceParams { Temperature 0.1f, TopP 0.9f, AntiPrompts new Liststring { user:, assistant: }, MaxTokens 512 };AntiPrompts这个参数很实用它能让模型在生成到指定字符串时自动停止避免模型自己续写对话。3.3 三个业务场景的落地实现工单分类输入工单标题和描述输出类别。用结构化Prompt加低Temperature准确率能到90%以上。后处理再做一层校验如果输出不在预设类别里直接归为“其他”。文档摘要输入长文档输出200字摘要。这里有个坑文档超过上下文窗口时要分段摘要再合并。我的做法是每2000字切一段分别摘要最后把各段摘要拼起来再让模型做一次总摘要。智能问答基于知识库的问答需要先做检索。我用的是简单的关键词匹配加BM25把Top3相关文档片段塞进Prompt。这块没上向量检索因为本机跑embedding模型又是一笔开销关键词匹配在内部文档场景够用了。3.4 MVC层的集成与前端交互Controller层很薄主要做参数校验和调用服务public class AiController : Controller { private readonly LlmService _llm; public AiController() { _llm LlmService.Instance; } [HttpPost] public async TaskActionResult Classify(string content) { var prompt PromptTemplates.Classify.Replace({content}, content); var result await _llm.InferAsync(prompt); return Json(new { category result.Trim() }); } }前端用fetch调用流式接口用EventSource接收。这里要注意跨域和超时设置IIS默认超时是110秒长文本推理可能超时需要在web.config里调大executionTimeout。4. 常见问题与排查技巧实录4.1 AIGC准确性不达标的排查思路准确性问题是这个项目最头疼的。我整理了一个排查顺序现象可能原因排查方法输出格式不稳定Prompt约束不够加结构化约束和示例分类准确率低Temperature过高降到0.1试试答非所问上下文被截断检查ContextSize和Prompt长度重复输出RepeatPenalty太低调到1.1-1.2中文乱码模型不支持中文换Qwen或ChatGLM系列我的经验是先怀疑Prompt再怀疑参数最后才怀疑模型。大部分准确性问题都是Prompt没写好。4.2 性能瓶颈的定位与优化CPU推理慢是必然的但可以优化。我实测下来几个有效的点开启BatchSize到512吞吐能提升20%左右。用mmap加载模型减少内存占用和加载时间。把GpuLayerCount设成-1如果有GPU速度能提升5-10倍。限制MaxTokens不要让它无限生成。如果并发量上来了单实例扛不住可以考虑起多个进程做负载均衡每个进程加载一份模型。内存够的话这是最简单的扩展方式。4.3 内存溢出与模型加载失败16GB内存跑7B Q4模型理论占用约5GB但实际运行中峰值能到8-9GB。如果同时跑IIS和其他服务很容易OOM。解决办法一是把IIS的应用程序池内存限制调大二是模型加载用mmap模式让操作系统管理内存三是如果实在不够换3B模型或者Q3量化。模型加载失败最常见的原因是GGUF文件损坏或版本不兼容。LLamaSharp对GGUF版本有要求太新的模型可能加载不了。遇到加载失败先用llama.cpp的命令行工具验证一下模型文件是否正常。4.4 独家避坑技巧汇总几个文档里不会写但实际很重要的点模型文件不要放在项目目录里否则VS的发布流程会把它打包进去几个GB的文件能把发布搞崩。Application_Start里预热加载模型第一个请求才不会超时。给推理加超时和取消机制用户关掉页面了还在跑推理是浪费资源。日志要记录完整的Prompt和输出排查准确性问题时这是唯一线索。不同场景用不同的LlmService实例因为推理参数不一样共享实例会互相干扰。提示本机LLM的准确性优化是个持续过程建议建一个测试集每次改Prompt或参数后跑一遍用数据说话不要凭感觉。5. 关于AIGC准确性的深度思考5.1 本机LLM准确性的天花板在哪里说实话7B量化模型的能力边界很明显。简单分类、短文本摘要、FAQ问答这些任务能做到可用但涉及复杂推理、长文档理解、多跳问答效果就明显不如云端大模型。我的判断是本机LLM适合任务边界清晰、输出格式固定、容错率较高的场景。如果你的业务需要模型做开放式创作或者复杂逻辑推理本机方案大概率会让你失望。这时候要么上更大的模型配GPU要么老老实实调云端API。5.2 工程手段能弥补多少准确性工程手段能弥补的准确性大概在10-20个百分点。具体来说Prompt工程能提升10-15个点这是性价比最高的。结果后处理能提升5个点左右比如格式校验、关键词兜底。检索增强能提升10个点以上但需要额外的检索系统。模型微调能提升更多但成本高本机场景不太现实。所以我的策略是把Prompt工程和后处理做到极致把模型能力榨干而不是一味追求更大的模型。5.3 准确性评估的落地方法没有评估就没有优化。我建了一个200条的测试集覆盖三个场景的典型case每次改动后跑一遍记录准确率、响应时间、格式合规率三个指标。评估脚本很简单就是一个控制台程序读测试集调服务比对预期结果输出报告。这个投入很值得它让优化从玄学变成了工程。6. 后续可扩展的方向这套架构跑通之后扩展空间其实挺大的。我目前想到几个方向一是接入向量数据库做真正的RAG提升问答准确性二是加一层缓存相同问题直接返回历史结果三是做模型热切换不同场景用不同模型四是把推理服务独立成Windows服务跟Web应用解耦。我个人在实际操作中的体会是本机LLM工程最难的不是技术而是预期管理。要让业务方明白本机方案是在数据安全和成本约束下的折中准确性有天花板。把预期对齐了项目推进会顺利很多。最后再分享一个小技巧如果你们团队有多个项目要用LLM把推理服务做成独立的HTTP服务用C#写个简单的Web API包装一下其他项目直接调比每个项目都集成一遍LLamaSharp要省事得多。