上周帮一个朋友看他的C# AI项目他在周末用一天时间把一个大模型Demo跑通了控制台里敲一句话回车模型乖乖吐出结构化JSON他兴奋地给我看效果。但我翻了翻代码问他三个问题——并发50时会不会把限流打穿模型偶发吐出不合法JSON你能怎么兜底如果这个月账单翻了三倍你能从日志里找到原因吗他沉默了。C#做AI在这两年确实是黄金窗口官方把统一的AI集成层补进了基础库社区的编排框架越来越成熟本地推理运行时的选择也多了C#开发者第一次不用跨界写Python就能端到端完成AI功能。但Demo跑通与生产稳定之间隔着大量工程功课。这篇文章就把我团队从原型到上线过程中踩过的坑、做过的取舍、最后沉淀下来的方法一次性讲清楚给正在用C#接大模型的你做个参考。1. C#这个生态为什么突然适合搞AI了1.1 三块拼图同时到位其实C#做AI不是今天才开始。早年间有传统的机器学习框架能做推荐、预测这类事儿但到了大语言模型时代主流工具链几乎全在Python那边C#开发者多少有点局外感。转机出现在最近两年准确说是三件事同时发生。第一.NET官方把AI抽象层直接做进了基础库。原来你要自己去拼HTTP请求、处理流式响应、维护不同的供应商协议现在官方提供了一套统一的聊天补全、向量化、工具调用接口。你写业务代码时不再关心后面接的是哪家的模型换供应商往往只是改配置。对一家以C#为主力语言的公司来说这是决定性的。第二社区里的编排框架成熟了。所谓编排就是让AI不只是一问一答而是能调用你的业务函数、按步骤完成多阶段任务。之前这些能力基本是Python生态专属现在C#这边也有了几套被广泛使用的方案。我做过的几个Agent类项目稳定性和可调试性已经不比Python差。第三本地推理的选项越来越多。有些场景数据不能出内网或者延迟敏感需要在本机跑小模型。C#在这块的绑定能力比一般人想象的要顺嵌入模型和分类模型跑起来非常快。1.2 Demo满足的是好奇心生产满足的是SLADemo和生产不是量变是质变。模型的接口没变但周围环境全变了。我用一张表来说明两者差距维度Demo阶段生产阶段调用频率手动触发、几分钟一次每秒几十上百次请求错误容忍失败重跑一次就行需要自动重试、降级、熔断、告警数据安全测试数据随便写涉及用户数据、权限、脱敏、审计成本几乎没人算每一千Token都在烧钱延迟预期等30秒没问题超过10秒用户就流失这表里每一行背后都是一整套工程措施。更麻烦的是模型输出的非确定性会渗透到所有原本你认为确定的地方解析不老老实实给你JSON、偶尔答非所问、同一个Prompt不同模型表现天差地别。所以做C# AI生产化绝不能只把它当成一个普通HTTP服务来治理。2. 第一道分水岭把模型调用请进网关2.1 网关模式换供应商不慌我在不少项目里见过这种写法业务Service里直接new一个供应商的客户端页面上调用一次就在业务代码里裸调一次模型接口。Demo非常痛快到了生产就是灾难——想换一个模型供应商得把整个代码库翻一遍想统一加日志和成本统计根本找不到切入点。正确做法是先定义一个极薄的网关接口public interface IChatGateway { TaskChatResult CompleteAsync( ChatRequest request, CancellationToken ct); }业务层只依赖这个接口。网关的实现内部去对接具体的供应商解析供应商特有响应、统一返回业务模型。这样切开之后有四个立竿见影的好处换供应商只改一个类重试、超时、日志、指标全部集中在一处做A/B测试时可以直接在网关里切流量比例写测试时可以注入桩件不用真调模型。但我也要提醒一句别一上来就抽象过度。某些团队把网关做成了七八层接口、四个工厂结果是没人能改代码。一个接口加一个实现类顶多再针对流式输出加一个StreamAsync方法够用就行。2.2 密钥、模型、Prompt三层配置分开管生产环境的第一个低级事故往往是把API密钥写在代码里或者签进代码仓库。密钥类秘密信息走环境变量或托管密钥服务禁止进配置文件。模型名和供应商Endpoint属于环境配置放配置文件并用配置中心管理让升级模型、切换部署变成改配置而不是发版。Prompt模板这也是配置但它有自己的生命周期需要版本管理。我把Prompt拆成了独立的资源文件带版本号部署时和代码一起发布线上可以直接查当前用的是哪个版本的Prompt。三层分开后运维和研发心里都会踏实很多改Prompt不用动代码改模型不用动Prompt改密钥不用动模型。下面是一个简化配置示意{ Ai: { Provider: cloud, Model: chat-large-2, Deployment: prod-cn, MaxTokens: 2048, Temperature: 0.3 } }读取时用框架自带的配置绑定IConfiguration IOptions不要把整份配置当字典传来传去。2.3 输出校验别相信模型的格式承诺大模型供应商大多提供了结构化输出能力你可以规定它返回JSON甚至给它一个JSON Schema。但生产经验告诉我结构化输出能大幅降低错误率却不能消除错误。原因多种多样输出被max_tokens截断、偶尔混入Markdown代码围栏、供应商在边缘情况下的schema违例。所以网关内部必须做一道校验和修复public async TaskT? CompleteJsonAsyncT( ChatRequest request, int retryTimes 2, CancellationToken ct default) { for (var i 0; i retryTimes; i) { var raw await _inner.CompleteAsync(request, ct); var cleaned StripCodeFence(raw.Content); try { return JsonSerializer.DeserializeT(cleaned, JsonOptions); } catch (JsonException) { request.Conversation.Add(new ChatMessage( Role: user, Content: 上一条回复不符合JSON格式。请只输出JSON不要包含任何解释或代码围栏。)); } } return default; }这个方法我称为JSON自救循环。第一次解析失败把错误信息反馈给模型让它重新生成一次配合限定输出结构成功率能拉到99%以上。注意这种重试消耗的是Token不是免费重试所以次数要克制一般两到三次封顶。3. 从跑通到扛住连接、超时与重试的工程细节3.1 客户端生命周期单例是标准答案别每次new很多第一次接触AI的C#开发者会踩同一个坑每个请求都new一个供应商客户端或者干脆在Controller里new一个HttpClient。前者的代价是每请求都创建新客户端、新连接池在高并发下socket端口快速耗尽也就是常说的socket耗尽后者的代价是TCP连接得不到复用延迟和资源占用都上来了。正确姿势是用依赖注入把客户端注册为单例services.AddSingleton(sp { var client new HttpClient { Timeout TimeSpan.FromMinutes(2) }; return CreateChatClient(client, options); });供应商SDK里的客户端对象本身就设计成线程安全的单例完全没问题。记住一个简单判断如果你的代码里出现了每个请求都new网络客户端那基本可以断定上线后会出连接问题。把创建逻辑收敛到启动阶段所有请求共享同一批连接这是生产化的第一课。3.2 超时与取消给慢画一条红线模型推理的特点是可快可慢一个复杂输出可能30秒还没吐完。生产环境不能无限等。区分三种超时超时类型建议策略说明连接超时5-10秒建立TCP/HTTPS连接的上限首Token超时10-20秒用户能接受的最长等待开始输出时间整体超时60-120秒大输出任务的最长执行时间实际编码时除了在配置里设置客户端超时还应该在调用点创建链路的CancellationTokenSourceusing var cts CancellationTokenSource.CreateLinkedTokenSource(userCancellationToken); cts.CancelAfter(TimeSpan.FromSeconds(90)); var result await _gateway.CompleteAsync(request, cts.Token);这里的关键是响应式取消前端断开、用户切换页面、请求被网关熔断都要能立刻中断模型调用。流式场景下尤其重要客户端一旦断开服务端还在生成内容烧钱Token就白花了。3.3 重试要有策略但不能只会无脑重试模型服务有它自己的可用性特征偶尔5xx、偶发网络抖动、限流返回429。常见错误是一失败就重试重试还立刻再打一次结果是把限流打成雪崩。我的重试准则只有网络异常、5xx、429值得重试。400、401、403、404这类错误重试一百次也是白费直接抛出。429必须看服务端返回的Retry-After头至少等这个时间再试。重试要有退避和抖动。退避让流量分开抖动防止多个请求在同一时刻一起重试形成脉冲。每次重试都记日志因为重试意味着Token消耗翻倍。实现上我会在网关内部包一层带退避的循环private async TaskChatResult SendWithRetryAsync( ChatRequest request, CancellationToken ct) { var attempt 0; while (true) { try { return await _inner.CompleteAsync(request, ct); } catch (Exception ex) when (IsRetryable(ex)) { attempt; if (attempt 3) throw; var delay ComputeBackoff(attempt); Logger.LogWarning(模型调用第{Attempt}次重试原因{Reason}, attempt, ex.Message); await Task.Delay(delay, ct); } } } private static TimeSpan ComputeBackoff(int attempt) TimeSpan.FromMilliseconds( Math.Min(8000, 1000 * Math.Pow(2, attempt - 1)) Random.Shared.Next(0, 500));看到没有真正起作用的是退避抖动限次日志而不是简单的while循环重试。3.4 客户端限流别让并发把自己打崩模型供应商都有每分钟请求数和每分钟Token数的配额。生产环境初期最容易出现的翻车就是线上流量一起来瞬间触发429然而重试又把这些429请求再打一遍。我一般会在网关内部加一个信号量做并发闸门public sealed class ConcurrencyGate { private readonly SemaphoreSlim _gate new(16); public async TaskT ExecuteAsyncT( FuncCancellationToken, TaskT action, CancellationToken ct) { await _gate.WaitAsync(ct); try { return await action(ct); } finally { _gate.Release(); } } }配合供应商返回的限流信息动态调整闸门宽度效果更好。核心思路是把模型供应商当成一个配额极其有限、单次极慢的下游系统来治理你的架构就不会出大问题。3.5 流式输出体验好治理要求也高如果要做聊天机器人、逐字输出这类体验流式接口是必选项。C#的异步迭代IAsyncEnumerable处理流式响应非常顺手await foreach (var chunk in _gateway.StreamAsync(request, cts.Token)) { await client.SendAsync( ReceiveToken, new { content chunk.Text, requestId }, cts.Token); }但流式有几个坑一是网络异常只会出现在枚举过程中重试不再简单二是Token用量需要自行累加很多供应商的流式响应并不会每个chunk都带usage通常要在最后一个chunk才给不能漏记三是如果用户中途断开必须立刻取消枚举否则后端还会继续生成。4. 内存、成本与性能三个容易看漏的黑洞4.1 上下文膨胀是成本失控的第一元凶这个坑几乎每个团队都会踩。聊天类应用最自然的实现是每次请求把整个会话历史都带上因为大模型需要上下文。但对话轮数一多成本增长非常夸张。假设每轮用户输入平均1000Token模型回答500Token单轮开销1500Token。到第N轮时光是历史上文就有大约1500×(N-1)个Token再叠加当前输入和输出累计Token消耗是平方级增长的。做个简化计算对话轮数当次请求的输入Token约累计Token消耗约1100015001010000825003030000697500我见过最典型的案例内部知识库机器人上线两周平均每次请求携带的历史信息已经接近模型上下文上限账单直接乘了三倍响应还明显变慢。控制上下文是个系统工程。常用的手段有滑动窗口只保留最近N轮对话旧的裁剪掉这是最简单有效的。分层摘要对更早的历史做一次摘要把摘要当作一条消息放进上下文。RAG注入先按问题检索相关片段只把命中的知识放进提示词而不是把所有文档全塞进去。关键要记住上下文长度不只是成本问题还是延迟问题。输入Token越多首Token出来的时间越长。把省Token当成性能优化来做方向就对了。4.2 内存里的幽灵缓存、事件与巨大的字符串模型返回的内容动辄几千字符如果服务里还叠加了会话缓存、静态字典、事件订阅内存泄漏会来得很隐蔽。排查顺序我一般是先看托管堆有没有持续增长的巨大对象。某些团队为了做会话快照把原始响应字符串整个存进ConcurrentDictionary还不设过期几天下来就是GB级内存。有人为了让前端能实时统计Token把事件处理器挂到静态事件上服务重启前永远不会回收——这不是AI独有的问题但AI场景下因为调用频繁泄漏速度会放大很多倍。解析大JSON时如果到处用字符串截取和拼接也会产生大量临时对象压榨GC。诊断时建议先用官方命令行工具看关键计数器托管堆大小、GC次数、线程池饥饿指标如果GC频率持续偏高且堆只涨不降再抓内存转储做对象类型统计。90%的情况都能在对象统计里一眼定位到那个无人清理的缓存。4.3 延迟优化先算好首字时间生产环境评价AI接口最直观的体验指标是首Token时间而不是整体响应时间。用户看到正在生成的动画等待焦虑会大幅下降。优化的顺序也有讲究优先确认请求是否走了流式非流式在生成完才返回体验天然差。检查是否存在同步转异步的写法。C#里最常见的是用Task.Result去等一个异步方法这在并发上来以后会拖垮线程池。必改。看业务逻辑里有没有串行调多个模型接口。比如一个请求里既要做意图识别又要做摘要生成如果两者没有依赖关系完全可以并行。信不信由你很多延迟问题最后定位出来是上下文太长而不是模型太慢。把历史消息裁剪后首Token时间能下降一个数量级。5. 可观测性让每次AI调用都能被审计5.1 日志里必须有的AI专属字段普通请求日志记录URL、状态码、耗时就够了AI调用还得多记几个字段不然出了问题你根本没法复盘。字段作用RequestId串联业务请求与模型调用ModelName出问题时确认用的哪个模型PromptVersion辨析Prompt变更造成的影响InputTokens / OutputTokens成本核算的直接依据LatencyMs / TtftMs性能分析依据RetryCount区分一次成功和重试成功的调用ProviderTraceId供应商侧排查的凭证日志还有一个特殊风险Prompt里可能包含用户隐私数据。生产日志系统必须有脱敏机制比如手机号、地址、证件号自动打码。建议默认不打印完整Prompt只打印截断后的摘要需要排查时再从带权限的存储里按RequestId检索原文。5.2 指标告警延迟、错误、429、成本四件套指标层面我会给每个功能模块、每个模型分别打点。重点盯四类延迟看P50/P95/P99P95比平均值重要得多。一个慢调用会把平均拉高但P95能反映真实用户体感。错误率按状态码分类尤其把429单列它代表限流而不是模型挂了。429占比一旦持续升高说明客户端限流没生效或是配额不够需要扩容配额或收紧闸门。Token消耗按功能、按模型、按用户维度统计设置每日预算阈值。这个指标最容易被忽略因为它不是故障顶多算流失但流失也是真金白银。告警规则别贪多先设三条最核心的错误率持续5分钟超5%、P95延迟超阈值上限、日Token消耗超预算80%。我见过一上来配二十条告警的团队结果真正出大事时反而被告警噪音淹没。5.3 全链路追踪从用户点击到模型响应的完整链路一旦AI功能被嵌入复杂的业务流程先检索、再调用模型、再落库、再通知没有链路追踪会很难排查。.NET生态里标准做法是用Activity创建追踪跨度每次调用模型时把业务TraceId传给供应商请求头这样两端日志可以对上。实操上我会要求业务请求入口生成TraceId网关每次调用模型时把TraceId、RequestId都写进日志上下文如果供应商支持传递自定义标识一并传过去。排查问题时拿到一个用户投诉顺着TraceId就能看到检索用了多少毫秒、模型调用等待了多少毫秒、在哪个环节重试了一次效率提升不止一倍。6. 测试与发布把不稳定关进笼子里6.1 单元测试用桩件隔离模型单元测试阶段千万别调真实的模型服务。原因很直接模型输出不稳定测试用例就没法稳定而且测一次烧一次钱。做法是给IChatGateway注入桩件public sealed class StubChatGateway : IChatGateway { public TaskChatResult CompleteAsync( ChatRequest request, CancellationToken ct) Task.FromResult(new ChatResult($桩件响应: {request.UserText})); }这样业务逻辑的分支、异常路径、格式解析都能确定性验证。真实模型的正确性验证放到集成测试或回归评测阶段而不是单元测试阶段。6.2 黄金样本集模型功能的回归基线AI功能最大的痛点是这周还好好的下周怎么就不对劲了。原因通常是供应商悄悄更新了模型、或者你改了Prompt。解决思路是搞一个黄金样本集准备几十到几百条有代表性的输入每条都定义好通过标准比如JSON结构是否合法、关键字段是否非空、是否包含必需的关键词。每天晚上用当前配置的模型跑一遍记录通过率、平均延迟、Token消耗。这个回归基线能帮你抓住两类问题模型升级后的质量退化通过率下降Prompt改动引发的连锁副作用之前能过的样例开始不过。相关阈值一跌立刻报警然后在灰度环境中排查是哪个因素导致的。这套东西一开始会有点繁琐但它是我见过的性价比最高的AI质量保障手段。6.3 灰度发布与快速回滚让模型版本变更可控模型部署和代码交付一样要讲发布策略。不要某天早上直接把生产环境全部切到新模型哪怕新模型看起来表现更好。我的标准流程是先用配置中心把新模型、新Prompt只放给5%的白名单用户。对比这5%和95%的黄金样本通过率、P95延迟、Token消耗。确认没问题后再逐步放量10%、30%、50%、100%。一旦发现异常通过配置中心一键切回旧模型代码不需要发版。记住回滚在AI系统里往往不是回滚代码而是回滚配置。所以从第一天起模型名、供应商、Prompt版本都要做成可配置项这一条怎么强调都不过分。7. 三个真实踩坑实录教训比经验更值钱7.1 坑一JSON偶发不合法线上反序列化崩溃某内部服务上线第一周就出现了一个诡异的错误用户反馈解析失败异常信息指向JSON反序列化的第127行。Demo阶段测试了20个样例全部通过生产线上却有约2%的请求失败。排查过程还原一下网关没有校验层拿到的原始响应直接JsonSerializer.Deserialize。出错集中在两种场景一是答案被max_tokens截断JSON结构不完整二是模型偶尔把JSON包进了Markdown代码围栏json。修复分三步在网关里先剥离代码围栏解析失败后把错误提示喂回模型让它重新生成把max_tokens上调留出格式合规的余量。修复后错误率从2%降到0.01%以下。这个经历后来被我写进了团队规范所有模型输出进业务代码之前必须过一层格式校验。7.2 坑二并发一上去429和超时一起爆炸某对外服务在压测时重现过经典雪崩客户端不加限流地并发调用一个批任务同时发起30个请求瞬间打到限流上线返回一堆429。而重试策略又是失败后立即重试30个429又各自重试把下行的请求数放大成了60、90服务端直接进入熔断状态。根因有两个没有客户端侧并发闸门重试没有退避。修复后我们在网关加了SemaphoreSlim限制并发为8重试改为指数退避加抖动并且把429的Retry-After纳入等待时间。再压测请求曲线平滑了429大幅减少整体吞吐反而因为少了一堆无效重试而变高。这个案例说明一个反直觉的事实对限流系统来说你越努力重试吞吐反而越低。控制住重试和并发才是对吞吐最大的尊重。7.3 坑三上下文没裁剪账单翻了三倍某客服机器人上线时一切正常两周后账单陡增。查日志发现平均每次请求的输入Token从3000涨到了近3万。真相很简单会话历史全部保留没有任何裁剪。用户聊了50轮机器人就把50轮的历史全部发给模型。聊天体验没变好反而因为输入太长响应开始变慢。修复方案是三层滑动窗口只保留最近20轮更早的内容用摘要压缩成一条记忆为每个会话设置累计Token预算超了强制触发摘要或结束会话。修完之后的指标很直接账单回落P95延迟下降40%。现在我把上下文管理列进所有AI项目的架构评审必查项凡是看到全量历史直传的一律先做裁剪再放行。最后再分享一点我个人的体会。C#做AI最值钱的地方恰恰是那些在Python Demo里被省略的工程能力类型安全、依赖注入、诊断工具、完善的测试框架。Demo帮你验证的是模型能不能做这件事而生产要做的是这件事在真实流量下能不能一直做下去。这两者之间差的那一大截就是这篇文章想帮你填上的。如果你现在正处于从Demo走向生产的阶段我建议你从三件事开始把模型调用收进网关、给所有调用加上超时和取消、把Token消耗和错误率打点接上。做完这三件事再往前走你会轻松很多。