1. 为什么要在 ASP.NET MVC 里塞进一个本机 LLM 工程先把场景说清楚。你手上有一个跑在 Visual Studio 里的 C# ASP.NET MVC 项目可能是企业内部的管理后台、工单系统、内容平台也可能是某个垂直行业的业务中台。现在你想让它具备看懂图片理解视频自动生成摘要或标签的能力而且不想把数据往外部服务上送或者至少希望核心链路可控。这就是本机 LLM 工程要解决的问题。这里说的本机有两层含义。第一层是调用侧在本机你的 C# 代码通过 HTTP 或 SDK 调用一个 LLM 服务这个服务可以跑在同一台机器的 GPU 上也可以跑在内网的另一台推理服务器上。第二层是工程侧在本机整个项目的编排、缓存、重试、日志、鉴权、限流都在你的 ASP.NET MVC 工程里完成而不是散落在一堆脚本里。很多人一开始只想着调个 API 而已结果做到后面发现图片要预处理、视频要抽帧、结果要落库、失败要补偿最后变成一坨没法维护的代码。所以思路一定要在动手前理清楚。阿里系的图像 LLM 和视频 LLM 在这类场景里是比较常见的选择原因很实际图像理解、视频理解这类多模态能力自建成本极高而通过云端多模态接口调用配合本机的业务编排是性价比最高的路径。关键词里出现的阿里云百炼 API 调用示例阿里云认证 SDK其实都指向同一件事——用成熟的云侧多模态能力喂给你本机的 MVC 工程。这篇文章适合谁看如果你是会写 C#、用过 ASP.NET MVC、但对 LLM 工程化还没形成完整认知的开发者这篇就是给你写的。如果你已经在调多模态接口但代码越写越乱、重试和缓存全靠拍脑袋这篇也能帮你把结构重新捋一遍。我不会只给你一段能跑的代码而是把每个设计决策背后的理由讲透包括我踩过的坑。2. 整体架构MVC 工程与 LLM 服务之间的那条边界2.1 三层职责划分Controller 只做编排不做推理很多人第一版代码会把调用 LLM 的逻辑直接写在 Controller 的 Action 里图省事。我早期也这么干过结果是一个 Action 三百行图片 base64 编码、HTTP 请求、JSON 解析、异常处理全糊在一起单元测试根本没法写换个模型要改半个控制器。正确的做法是分三层Controller 层只负责接收请求、参数校验、调用 Service、返回视图或 JSON。它不应该知道 LLM 的存在更不应该知道用的是哪家模型。Service 层业务编排层。它决定这张图要不要先压缩视频要不要抽帧结果要不要缓存失败了重试几次。这一层是工程的核心。Client 层纯粹的 LLM 通信层。封装 HTTP 调用、鉴权、超时、序列化。换模型时只改这一层。这样分的好处是当你想从图像 LLM 换成另一个供应商或者从云端切到本机推理服务时改动被限制在 Client 层Service 和 Controller 几乎不动。这是面向接口编程在多模态场景下最实在的价值。2.2 同步还是异步ASP.NET MVC 的坑要先填ASP.NET MVC注意是经典 MVC不是 ASP.NET Core默认是同步管道。如果你在 Action 里直接.Result或.Wait()去等一个 HTTP 调用在高并发下会线程池饥饿表现为平时好好的一压测就卡死。这是经典 MVC 里最经典的坑之一。我的建议是从 Controller 到 Client 全链路 async/await。Controller 的 Action 返回TaskActionResultService 方法返回TaskTClient 用HttpClient的异步方法。注意HttpClient要单例复用不要每次new否则会耗尽 socket。在经典 MVC 里可以用静态字段或者简单的单例容器持有。public class LlmClient { private static readonly HttpClient _http new HttpClient { Timeout TimeSpan.FromSeconds(120) }; public async Taskstring CallVisionAsync(string imageUrl, string prompt) { var payload new { model vision-model, image imageUrl, prompt prompt }; var content new StringContent( JsonConvert.SerializeObject(payload), Encoding.UTF8, application/json); var resp await _http.PostAsync(_endpoint, content); resp.EnsureSuccessStatusCode(); return await resp.Content.ReadAsStringAsync(); } }超时设 120 秒是有讲究的。图像理解通常几秒到十几秒但视频理解如果走抽帧再逐帧分析可能几十秒。设太短会频繁超时设太长会拖垮线程。我一般给图像 30 秒、视频 180 秒分开配置。2.3 配置与密钥别把 AccessKey 写进代码关键词里出现了阿里云认证 SDK阿里云 SSL说明鉴权是绕不开的。最忌讳的就是把 AccessKeyId 和 AccessKeySecret 硬编码在.cs文件里然后提交到代码仓库。我见过不止一个项目这么干后来密钥泄露被刷爆账单。正确做法是放在Web.config的appSettings里或者用环境变量生产环境用配置中心。读取时封装一个LlmOptions类集中管理 endpoint、key、model 名称、超时、重试次数。这样换环境只改配置不改代码。提示密钥轮换要留后路。把密钥读取封装成方法而不是静态字段将来接入配置中心动态刷新时不用重构。3. 图像 LLM 调用从一张图到一段结构化结果3.1 图片进入 LLM 之前的预处理决定了成败直接把手机关拍的 5MB 原图丢给图像 LLM是最常见的错误。原因有三一是传输慢二是很多接口对图片大小和分辨率有上限三是过大的图并不会提升理解质量反而可能因为缩放导致细节丢失。我的标准预处理流程是这样的格式统一统一转成 JPEG 或 PNG。JPEG 体积小适合照片PNG 适合带文字的截图。尺寸压缩长边压到 1568 像素左右这是很多多模态模型的有效分辨率上限附近。用System.Drawing或ImageSharp做等比缩放。质量压缩JPEG 质量设 80 左右肉眼几乎无差别体积能降一半以上。编码方式选择小图直接 base64 内联大图先上传到对象存储拿 URL 再传 URL。base64 会让请求体膨胀约 33%超过 1MB 的图我倾向走 URL。public static byte[] ResizeToJpeg(byte[] input, int maxSide 1568, int quality 80) { using (var ms new MemoryStream(input)) using (var img Image.FromStream(ms)) { double ratio Math.Min(1.0, (double)maxSide / Math.Max(img.Width, img.Height)); int w (int)(img.Width * ratio), h (int)(img.Height * ratio); using (var bmp new Bitmap(img, w, h)) { var codec ImageCodecInfo.GetImageEncoders() .First(c c.FormatID ImageFormat.Jpeg.Guid); var pars new EncoderParameters(1); pars.Param[0] new EncoderParameter(Encoder.Quality, (long)quality); using (var outMs new MemoryStream()) { bmp.Save(outMs, codec, pars); return outMs.ToArray(); } } } }这段代码在经典 MVC 里能直接用System.Drawing是框架自带的。注意Bitmap和Image都要using释放否则在批量处理时会内存暴涨——这是我在一个批量打标任务里踩过的坑跑了两千张图后进程直接 OOM。3.2 Prompt 设计让模型输出你能解析的结构图像 LLM 最怕的就是返回一段自由文本你还得写正则去抠字段。解决办法是在 Prompt 里明确要求 JSON 输出并给出字段定义和示例。比如做商品图理解我会这样写你是一个商品图像分析助手。请分析这张图片严格按以下 JSON 格式输出不要输出任何其他内容 { category: 商品大类, attributes: [属性1, 属性2], has_text: true/false, text_content: 图中文字没有则为空字符串, confidence: 0.0-1.0 }关键点有三个一是明确不要输出其他内容否则模型爱加好的以下是分析结果这种前缀二是给出字段类型和取值范围三是给一个示例few-shot能显著提升格式稳定性。即便如此仍会有小概率返回带 markdown 代码块包裹的 JSON。所以解析时要先剥掉json 和再反序列化并且用 try-catch 兜底解析失败就记录原始返回方便排查。3.3 结果落库与幂等同一张图不要重复花钱图像理解是按量计费的同一张图重复调用就是浪费。我的做法是对图片内容算一个哈希比如 SHA256以哈希为 key 缓存结果。缓存可以放内存MemoryCache、Redis 或数据库。命中缓存直接返回不调接口。string key img: Sha256(bytes); var cached _cache.Get(key) as string; if (cached ! null) return cached; var result await _client.CallVisionAsync(...); _cache.Set(key, result, TimeSpan.FromDays(7));哈希要基于预处理后的字节还是原始字节我建议基于原始字节因为预处理参数可能调整用原始字节能保证同一张原图永远同一个 key。这个细节不注意改了压缩参数后缓存全部失效白白多花钱。4. 视频 LLM 调用抽帧、分段与时间轴对齐4.1 视频不能直接喂抽帧策略是核心视频 LLM 有两种用法一种是直接把视频文件传给支持视频的多模态接口另一种是自己抽帧成图片序列再逐帧或抽样分析。前者省事但可控性差后者灵活但工程量大。我一般根据场景选短视频1 分钟、要整体理解直接传视频接口。长视频、要定位具体片段自己抽帧按时间轴分析。只要关键信息按固定间隔抽帧比如每 2 秒一帧再对帧做图像理解。抽帧工具在 Windows 环境下可以用 FFmpeg 命令行C# 里用Process.Start调用。抽帧命令大致是ffmpeg -i input.mp4 -vf fps1/2 -q:v 2 frame_%04d.jpgfps1/2表示每 2 秒一帧。-q:v 2控制 JPEG 质量。抽出来的帧按序号命名序号乘以间隔就是大致时间点。4.2 帧太多怎么办分层抽样与去重一个 10 分钟的视频每 2 秒一帧就是 300 帧。全丢给图像 LLM成本和耗时都受不了。我的策略是分层抽样先按较大间隔比如每 10 秒抽一批粗帧快速过一遍判断哪些时间段有内容变化。对变化大的时间段再加密抽帧。对连续高度相似的帧做去重比如计算相邻帧的感知哈希差异小于阈值就丢弃。感知哈希可以用简单的均值哈希实现把图缩到 8x8 灰度算平均值每个像素大于均值记 1 否则记 0得到 64 位指纹。两帧指纹的汉明距离小于 5 就认为是相似帧。这个算法几十行代码就能写完效果对画面基本没变的场景足够用。4.3 时间轴对齐让结果能定位回原视频视频理解的输出如果只是这个视频讲了什么价值有限。真正有用的是第 30 秒出现了产品 logo第 2 分钟有人在讲解参数。所以每一帧的分析结果都要带上时间戳。我的做法是维护一个FrameResult列表每项包含TimeSeconds、FramePath、Analysis。最后按时间排序合并相邻的相似结论输出一条带时间轴的结构化结果。这样前端可以做成点击结论跳转到对应画面的交互体验完全不一样。注意抽帧得到的帧文件要及时清理。我见过一个项目把抽帧图全留在磁盘上跑了一个月磁盘爆了。分析完就删或者放到临时目录定期清理。5. 训练与微调的思考什么时候该动手什么时候别碰5.1 先问自己提示词工程解决不了吗一提到 LLM很多人第一反应是我要微调一个自己的模型。但现实是80% 的业务场景用提示词工程 few-shot 就能解决根本不需要微调。微调的成本不只是训练那点算力还有数据标注、评估、版本管理、上线部署是一整套工程。我的判断标准很简单如果你要模型做的是格式转换信息抽取分类打标这类任务先花两天把 Prompt 打磨到极致加几个示例大概率就够了。只有当任务涉及特定领域的专业术语理解、固定的输出风格、大量私有知识且提示词怎么调都达不到要求时才考虑微调。5.2 如果真要微调数据准备比训练本身重要十倍微调的效果几乎完全取决于数据质量。我见过太多人随便凑几百条数据就开训结果模型学了一堆噪声。正确的数据准备流程是数据来源从真实业务日志里捞而不是自己编。真实数据才有真实的分布和边界情况。数据清洗去掉重复、矛盾、格式错误的样本。矛盾样本对模型是毒药。格式统一输入输出严格按训练框架要求的格式比如 JSONL每行一个{prompt: ..., completion: ...}。划分验证集至少留 10% 做验证否则你根本不知道模型是记住了还是学会了。数据量方面指令微调通常几百到几千条高质量样本就能看到效果关键是质量不是数量。一千条精标数据胜过一万条脏数据。5.3 本机微调的现实约束如果你想在本机做微调先看显卡。7B 参数的模型做 LoRA 微调至少需要 16GB 显存用 4-bit 量化能压到 10GB 左右。13B 以上基本要 24GB 起步。没有这个硬件条件就别在本机折腾老老实实用云端的微调服务或者干脆走提示词路线。另外微调后的模型部署和推理是另一套工程。你要考虑推理框架比如 vLLM、TGI 这类、并发、显存占用、模型版本切换。这些和你的 ASP.NET MVC 工程怎么对接又是一轮新的设计。所以我的建议是微调是最后手段不是第一选择。6. 工程化细节让这套东西在生产环境活下来6.1 重试与退避网络抖动是常态调用云端 LLM 接口超时和 5xx 错误是家常便饭。无脑重试会雪上加霜正确做法是指数退避 抖动。第一次失败等 1 秒第二次 2 秒第三次 4 秒每次加一点随机抖动避免同时重试。重试次数控制在 3 次以内超过就记录失败进死信队列人工介入。要注意区分错误类型4xx 通常不该重试参数错了重试也没用429 限流要退避更久5xx 和超时才重试。这个判断逻辑写在 Client 层Service 层不用关心。6.2 日志与可观测性出问题能查LLM 调用最怕线上出问题但查不到原因。我的日志策略是每次调用记录请求 ID、模型名、输入摘要图片记哈希不记内容、耗时、token 消耗、返回状态。输入内容不要全量记一是日志体积大二是可能含敏感信息。耗时和 token 消耗要单独统计做成看板。这样你能清楚知道钱花在哪、哪个接口慢。我有个项目就是通过耗时统计发现视频接口在特定时段特别慢后来调整了调用时段体验明显改善。6.3 限流与并发控制别把自己打挂如果你的 MVC 站点有并发用户每个用户请求都触发一次 LLM 调用很容易把接口配额打满或者把本机推理服务压垮。要在 Service 层做并发控制用SemaphoreSlim限制同时进行的 LLM 调用数量。private static readonly SemaphoreSlim _gate new SemaphoreSlim(5); public async Taskstring AnalyzeAsync(byte[] img) { await _gate.WaitAsync(); try { return await _client.CallVisionAsync(img); } finally { _gate.Release(); } }并发数设多少取决于你的接口配额和本机推理能力。云端接口看 QPS 限制本机推理看显存和批处理能力。宁可设小一点排队也不要设大了把服务打挂。7. 我在实际项目里踩过的几个坑第一个坑是图片 base64 编码后请求体过大导致 413。当时没做尺寸压缩用户上传的原图直接编码超过网关限制被拒。后来加了预处理问题消失。教训是永远不要相信用户上传的图片尺寸。第二个坑是视频抽帧的临时文件没清理。跑批量任务时磁盘写满整个服务挂了。后来改成分析完立即删除并且用独立的临时目录加了磁盘空间监控。第三个坑是Prompt 里的 JSON 示例被模型抄进输出。我在 Prompt 里给了一个示例 JSON结果模型有时候把示例本身也输出了。解决办法是把示例和指令用明确的分隔符隔开并且在指令里强调仅输出一个 JSON 对象。第四个坑是缓存 key 设计不当导致串数据。早期我用图片文件名做 key结果不同用户上传了同名文件返回了别人的分析结果。改成内容哈希后再没出现过。这个坑很隐蔽因为测试时很难复现只有真实多用户场景才暴露。第五个坑是异步方法里用了同步锁。在 async 方法里用lock会导致死锁风险应该用SemaphoreSlim。这个是我在代码审查时被同事指出的当时完全没意识到。8. 关于模型选型的一点个人看法图像和视频 LLM 的选型不要只看榜单分数。榜单上的分数是在标准数据集上测的和你的实际业务数据分布可能差很远。我的做法是拿一批自己业务的真实样本做小规模对比测试。同一批图分别用两三个候选模型跑人工评估结果质量再结合成本和延迟做决定。另外多模态模型的更新很快今天的最优解可能三个月后就变了。所以架构上一定要把模型调用抽象成接口换模型时只改配置和 Client 层。这是我在多个项目里验证过的、最省心的做法。还有一点别迷信参数越大越好。很多业务场景一个中等规模的模型配合好的 Prompt效果不输大模型但成本和延迟低得多。先用小模型跑通效果不够再往上换这个顺序不要反。最后分享一个实用技巧给 LLM 调用加一个降级开关。当云端接口不可用或者成本超预算时能一键切到备用模型或者返回缓存结果。这个开关在配置里控制不用改代码不用重新部署。生产环境里这种能兜底的设计比追求极致效果更重要。