AI 模块：DeepSeek 配置校验中的反射

当前问题与原因

DeepSeekOptionsValidator 会检查 TTS、ASR、图像生成和图像编辑模型是否错误地指向只支持 Chat 的 DeepSeek。原辅助方法对每个模型配置调用 typeof(TModelOptions).GetProperty("Provider") 和 GetValue。属性名已在编译期确定，但运行期属性查找增加了校验耗时，也让 Trimming 和 Native AOT 难以静态确认这一属性访问。

配置校验发生在启动或配置验证时，不在 AI 请求的网络调用路径中。因此这里的主要目标是去掉反射；基准数据只说明该校验方法的成本，不代表端到端 AI 请求延迟。

解决方式与取舍

四类模型配置现在各自传入静态 Provider 属性选择器，公共循环仍负责大小写不敏感的 DeepSeek 匹配和原有错误信息。这样不增加配置缓存，也不改变 AIOptions 可变配置的读取时机。静态选择器可由编译器缓存，且属性访问能被静态分析。

没有改动模型路由中的字典扫描。微基准确认其成本随模型配置数增长；但解析器目前需要返回配置中原始大小写的 Scenario 名称，而配置字典可在运行期修改。为这个路径加入缓存需要额外的失效机制，当前没有足够的请求级性能数据支持它。

测量结果

从仓库根目录运行 benchmarks/MS.Microservice.AI.Benchmarks；环境为 Windows x64、.NET 10.0.12、Release。每场景预热 2,000 次后测量 5 轮，每轮 20,000 次，取中位数。每种能力配置相同数量的非 DeepSeek 模型，测量成功校验路径。

每类能力模型数	优化前耗时	优化后耗时	优化前分配	优化后分配
1	1,347.5 ns/次	952.7 ns/次	544.4 B/次	432.0 B/次
16	2,726.5 ns/次	1,114.9 ns/次	480.4 B/次	368.0 B/次
128	19,084.9 ns/次	6,722.0 ns/次	480.4 B/次	368.0 B/次

由于这是微基准且校验通常只执行少量次数，不应将上述差值换算成请求吞吐收益。

后续方向

SystemTextJsonQuestionContract 仍使用 DefaultJsonTypeInfoResolver 和运行期 Type 执行题目类型的序列化及 Schema 生成。该路径依赖业务方注册的动态题目类型；如需让整个 AI 模块支持 Native AOT，应另行设计显式 JsonTypeInfo 注册与 Schema 生成契约，并验证现有插件式题目定义。此次修改没有解决这部分限制。