Hugging Face 被英伟达以 129 亿美元收购后，很多人重新开始讨论一个问题：中国有没有自己的开源模型平台？答案是有，模力方舟（Moark）就是其中一个代表。
在天际资本创始人张倩与开源中国 CEO 徐勇围绕这场收购的直播中，徐勇分享了模力方舟的建设过程。这个故事的重点并不只是“做一个模型网站”，而是如何从开源社区、模型分发、在线推理和开发者协作等环节，逐步拼出一个真正可用的平台。摘要信息从 2022 年 11 月开始，因此下文只讨论已给出的背景与可以据此推导出的工程实践，不臆测平台未披露的具体实现。
难点不在页面，而在基础设施
一个模型平台看起来可能只是模型列表、搜索框和下载按钮，但真正运行起来，需要处理一整套工程问题：
- 模型文件体积大，下载成本和带宽峰值远高于普通代码仓库。
- 同一个模型可能包含权重、配置、Tokenizer、许可证和推理说明，缺少元数据就很难复用。
- 模型不仅要“存下来”，还要能被开发者拉取、转换、部署和评测。
- 开源项目依赖社区贡献，平台必须降低上传、发现、讨论和反馈的门槛。
- 模型服务通常需要 GPU，资源调度和成本控制会直接影响平台能否长期运行。
因此，模力方舟这类平台的核心不是复制某个网页，而是建立一条从“模型发布”到“模型使用”的完整链路。平台价值也不只来自模型数量，而来自模型是否容易找到、容易验证、容易运行。
从开源社区切入
开源模型平台的冷启动通常比普通内容平台更难。没有模型，开发者没有理由来；没有开发者，模型作者也缺少发布动力。一个可行的切入点，是先连接已有的开源社区和开发者网络，把平台做成模型项目的组织工具，而不是单纯的文件存储服务。
这意味着平台至少要支持几类信息：
- 模型身份：名称、版本、作者、组织和发布时间。
- 运行信息：参数规模、框架、硬件要求、量化方式和推理入口。
- 使用边界：许可证、训练数据说明、适用场景和已知限制。
- 协作记录：版本变更、问题反馈、评测结果和社区讨论。
这些信息越结构化，模型就越容易被搜索和自动化工具消费。对于开发者来说，最有用的页面往往不是一段宣传文案，而是明确回答“这个模型是什么、怎么运行、能不能用于我的场景”。
平台可以拆成四层
可以把一个开源模型平台拆成四个相互配合的层次：
1. 模型仓库层
负责保存模型权重、配置文件、Tokenizer 和 README。大文件不应全部依赖应用服务器转发，实践中通常会使用对象存储、分片上传、断点续传和 CDN。
2. 元数据与检索层
负责维护模型卡片、标签、许可证、任务类型、语言、硬件要求和评测指标。数据库保存结构化字段，搜索引擎负责全文检索和筛选。
3. 运行与评测层
负责将模型部署到可用的计算资源上，提供在线体验或 API，并记录延迟、吞吐、显存占用和输出质量。模型“能下载”不等于“能稳定运行”，这一层决定平台是否真正服务于应用开发。
4. 社区协作层
负责评论、问题、版本讨论、贡献者身份和内容审核。开源平台需要在开放与治理之间取得平衡：过度审核会削弱社区活力，完全缺少治理又会让恶意模型、错误说明和版权风险进入生态。
一个可改造的最小模型登记 API
下面是一个独立的 FastAPI 示例，用来演示平台如何登记模型元数据。它不是模力方舟的官方实现，而是一种可以实践的最小设计。运行前安装依赖：pip install fastapi uvicorn。
# app.py
from typing import List
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel, Field
app = FastAPI(title="Mini Model Hub")
class ModelCard(BaseModel):
model_id: str = Field(min_length=3, pattern=r"^[a-z0-9][a-z0-9_-]+$")
owner: str
task: str
license: str
framework: str
tags: List[str] = []
artifact_url: str
models: dict[str, ModelCard] = {}
@app.post("/models", response_model=ModelCard, status_code=201)
def register_model(model: ModelCard):
if model.model_id in models:
raise HTTPException(status_code=409, detail="model already exists")
models[model.model_id] = model
return model
@app.get("/models", response_model=list[ModelCard])
def list_models(task: str | None = None):
items = list(models.values())
if task:
items = [item for item in items if item.task == task]
return items
启动并创建一个模型记录：
uvicorn app:app --reload
curl -X POST http://127.0.0.1:8000/models \
-H 'Content-Type: application/json' \
-d '{
"model_id": "demo-chat-7b",
"owner": "example-org",
"task": "text-generation",
"license": "apache-2.0",
"framework": "pytorch",
"tags": ["中文", "对话", "7b"],
"artifact_url": "s3://model-bucket/demo-chat-7b/v1/"
}'
curl 'http://127.0.0.1:8000/models?task=text-generation'
真正的生产实现还需要加入鉴权、对象存储签名 URL、模型版本、病毒扫描、许可证校验、审计日志以及异步索引。这个例子最重要的地方，是把“模型文件”和“模型描述”分开：前者适合放在对象存储中，后者适合进入数据库与搜索系统。
中国本土平台的机会与边界
本土平台的机会，首先来自本地开发者和企业对中文模型、国内硬件、合规要求以及本地部署的实际需求。一个面向这些场景的平台，可以在模型说明、运行脚本、镜像、量化版本和企业私有仓库方面做得更贴近用户。
但平台不能只依赖地域标签。模型质量、许可证透明度、下载稳定性、API 兼容性和社区活跃度，最终都会转化为开发者的迁移成本。若平台只提供模型目录，不提供可靠的版本管理、评测和部署工具，开发者仍然可能回到已有的国际生态。
还需要特别注意三类风险：
- 许可证风险：模型权重、训练数据和下游商用条件可能并不一致。
- 安全风险：不可信模型文件、恶意代码和提示注入内容需要隔离与审核。
- 成本风险：GPU 在线体验很容易形成高昂且不可预测的账单，应设置配额、休眠和缓存策略。
落地时的检查清单
如果要从零建设一个类似的平台，可以按下面的顺序验证：
- 先确定服务对象，是研究者、应用开发者，还是企业内部团队。
- 先建立统一的模型卡片格式，再扩展复杂的在线推理功能。
- 用对象存储和断点续传承载大文件，避免应用服务成为带宽瓶颈。
- 为每个模型保留不可变版本，禁止覆盖正在被依赖的文件。
- 把许可证、硬件需求、评测数据和已知限制设为必填或强提示字段。
- 用小规模 GPU 池验证真实使用率，再决定是否提供长期在线 Demo。
- 通过 API、CLI 和标准化目录结构降低迁移成本，而不是把用户锁在网页里。
模力方舟的故事说明，所谓“中国版 Hugging Face”并不是把一个国外网站换成中文界面。它需要在开源社区、模型资产管理、计算资源和开发者工具之间建立连接。真正的竞争力，最终会落在模型是否可信、使用是否顺畅，以及平台能否让一个模型从发布当天走到真实生产环境。