Infinity项目中的模型名称一致性优化方案

在Infinity项目中，用户发现了一个关于模型名称显示不一致的问题。当通过不同API端点查询模型信息时，返回的模型名称格式存在差异，这可能会给开发者带来困惑。

问题背景

Infinity是一个基于Hugging Face模型的高性能推理服务框架。在默认配置下，当用户启动服务并指定模型路径时，系统会在两个主要端点返回模型信息：

1. /models端点返回完整的模型路径，包括斜杠分隔符（如"BAAI/bge-m3"）
2. /embeddings端点返回的模型名称则移除了斜杠（如"BAAIbge-m3"）

这种不一致性源于系统对模型名称的不同处理方式，可能会影响客户端应用的逻辑判断。

技术解决方案

为了解决这个问题，项目引入了新的配置参数--served-model-name（或model-display-name），允许用户显式指定在API响应中使用的模型名称。这个方案借鉴了vLLM等同类项目的设计思路。

实现这一功能需要考虑以下几个方面：

1. 参数设计：新增的配置参数应该作为EngineArg的一部分，与模型紧密耦合
2. 默认行为：当用户不指定显示名称时，系统应保持向后兼容
3. 名称处理：统一所有端点的模型名称返回格式
4. API文档：需要更新相关文档说明新的参数用法

实现细节

在技术实现上，主要修改包括：

1. 在引擎参数解析部分添加新的model_display_name选项
2. 修改模型信息响应逻辑，统一使用指定的显示名称
3. 确保所有API端点（包括/models和/embeddings）返回一致的模型名称
4. 添加相应的测试用例验证功能正确性

这种设计不仅解决了当前的问题，还为未来的功能扩展奠定了基础，比如支持多模型部署时的名称管理。

对开发者的影响

这一改进对开发者带来的好处包括：

1. 一致性：所有API端点返回相同的模型名称格式
2. 可控性：开发者可以自定义API中显示的模型名称
3. 兼容性：不影响现有应用的默认行为
4. 灵活性：便于实现更复杂的模型部署场景

总结

模型名称一致性是API设计中的重要原则。Infinity项目通过引入可配置的模型显示名称参数，不仅解决了当前的问题，还提升了整个系统的灵活性和可用性。这种改进体现了项目对开发者体验的重视，也展示了开源社区通过协作解决问题的典型过程。