核心分析¶

问题核心：从使用 OpenAI 云服务迁移到本地 Foundry Local，需要哪些实际修改，迁移的阻碍点是什么？

技术分析¶

• 典型迁移改动：
  1. 切换 endpoint/凭证：将应用的 OpenAI endpoint 指向本地服务地址（或改用 C# 本地 SDK 接口）。
  2. 模型别名映射：确认本地模型别名（如 phi-3.5-mini 或 qwen2.5-0.5b）与应用期望一致。
  3. 流式与超时设置：本地延迟与吞吐不同于云端，需调整超时、重试和并发策略。
  4. 响应字段验证：检查 OpenAI 响应中是否存在微小差异（字段名、元数据），并更新解析逻辑。

• 潜在兼容性坑点：

• 高级或专有接口缺失：Foundry Local 兼容基础 OpenAI 调用，但云端某些专有特性（训练/微调、特定工具集成）可能不支持。
• 性能与并发限制：本地资源决定了并发能力，需重新评估并发策略以避免 OOM 或磁盘/CPU 瓶颈。
• SDK 细节差异：C# 进程内接口与 HTTP 服务在行为上可能有差异（错误码、取消/中断处理），需要对接入点进行验证。

实用建议¶

1. 从功能最低耦合处开始：先迁移简单的聊天/补全 API，确保逻辑与模型输出符合预期。
2. 保持回退通道：在初期保留云端开关以便对比模型质量与可用性。
3. 建立验证套件：自动化测试请求/响应兼容性、延迟与内存占用，避免运行时惊喜。

注意事项¶

重要：不要假定所有 OpenAI 功能在本地都可用。迁移前应列出依赖的 OpenAI 特性并确认 Foundry Local 的支持矩阵。

总结：对大多数以聊天/补全为核心的应用，迁移到 Foundry Local 的工作量偏小——主要是修改 endpoint、校验模型别名与适配超时策略。但对依赖高级云服务特性的应用，需深入兼容性与性能验证。