过去一年GitHub 上增长最快的一批 AI 项目里中国团队和中国公司的开源项目占了非常显眼的位置。DeepSeek、通义千问 Qwen、智谱 GLM 这些开源大模型已经不只是论文里的名字而是被全球开发者在本地显卡、云服务器、企业内部系统里直接跑起来的东西。对于正在做 AI 应用开发、模型推理部署或者企业智能化改造的工程师来说中国开源技术生态的变化已经不是背景信息而是影响技术选型的关键变量。这篇文章不评价哪个国家开源更强而是把中国开源 AI 当作一个技术对象来看。我会梳理几个确定性事实哪些模型和框架值得关注下载部署走什么路径API 和批量任务怎么接选型和排错时看哪些指标。整篇文章按工程落地的方式来写你可以照着做也可以拿去作为团队技术评审的参考资料。如果只想记住三句话开源模型可以本地跑关键看模型规模和量化方式国内模型平台已经解决了下载和部署的便利性问题接口层面正在向 OpenAI 兼容生态对齐迁移成本比想象中低。下面的内容就是把这三句话展开。1. 中国开源 AI 核心能力速览在进入具体操作之前先用一张表看清全局。下表列出的项目都是开源 AI 生态中被高频使用的代表项目覆盖模型层、框架层、平台层和应用工具层。项目类型主要能力典型使用场景DeepSeek 系列开源大模型通用对话、代码生成、数学推理、长文本理解通用助手、代码辅助、复杂推理任务通义千问 Qwen 系列开源大模型通用对话、多模态、工具调用、Agent 能力对话应用、RAG 知识库、Agent 工作流智谱 GLM 系列开源大模型中英对话、代码生成、Agent 能力中文场景较强的对话与任务处理PaddlePaddle深度学习框架训练、推理、模型转换工业级模型训练、飞桨生态模型部署MindSpore深度学习框架训练、推理、科学计算大规模分布式训练、端云协同ModelScope 魔搭模型平台模型下载、在线体验、一键部署国内开发者获取开源模型的便捷入口Transformers模型库与工具链模型加载、微调、推理基于 Python 的模型研究与部署vLLM推理服务框架高吞吐推理、OpenAI 兼容 API生产环境 LLM 服务化Ollama本地部署工具一键拉取模型、命令行交互、API 服务个人电脑本地实验与小规模部署从整体分布看中国开源 AI 的能力并不只在某一个点上而是形成了“模型 框架 平台 工具”的完整链条。模型层的开源让开发者不再依赖闭源接口框架层提供了训练和推理的底座平台层解决了模型获取和部署渠道工具层则让普通工程师也能快速看到效果。这对开发者最直接的价值是你不用先从论文复现模型也不用自己从零搭训练流程而是可以站在已经开源的成果之上做应用、做微调、做性能优化。下面按层次展开说明。2. 开源 AI 生态全景模型、框架、平台、工具2.1 模型层开源权重与开放技术报告模型层是整个开源 AI 生态里最受关注的部分。与过去只发布论文不同现在很多中国团队选择直接开放模型权重甚至公开训练细节和技术报告。这个变化非常关键因为只有权重开放开发者才能实际上手部署、微调和商用。从实际使用情况看DeepSeek、Qwen、GLM 都提供了多个尺寸的开源版本参数规模从 1.5B 到 70B 以上不等覆盖了从手机端到服务器端的应用场景。小尺寸模型适合边缘设备和个人开发者测试大尺寸模型适合追求效果的生产环境。开源模型的可选择性让团队可以根据显存、算力、成本和效果要求自由搭配。2.2 框架与推理基础设施模型需要跑起来才有效果。早期 AI 开发主要依赖 TensorFlow、PyTorch 这类通用框架现在中国开源生态里也出现了自己的框架和推理优化工具。PaddlePaddle 和 MindSpore 是比较有代表性的两个深度学习框架分别对应飞桨生态和昇思生态覆盖训练、推理、移动端部署和科学计算等场景。对于大多数应用开发者来说不需要从底层框架开始学习但当你要做模型转换、量化、端侧部署或者特定硬件加速时这些框架的生态工具会派上用场。更值得关注的是推理服务层的工具。vLLM、llama.cpp、Ollama 等开源推理工具与开源模型配合得非常成熟其中 vLLM 的高吞吐推理能力和 OpenAI 兼容 API 设计已经成为部署开源模型到生产环境的热门选择。它的好处在于团队用一套接口既能对接闭源商业模型也能切换到本地开源模型。2.3 模型平台与工具链对国内开发者来说模型下载渠道是否顺畅直接决定开源模型能不能真正落地。ModelScope 魔搭解决了这个问题它提供的模型下载、在线体验和云端部署功能让开发者不需要跨平台寻找模型文件下载速度和稳定性都比直接从海外源拉取好很多。当然HuggingFace 仍然是全球开源模型的重要分发渠道许多中国团队也会同步上传模型到 HuggingFace。实际工程中国内开发者可以优先走 ModelScope海外部署或与海外团队协作时再走 HuggingFace两个平台互为备份。工具链方面Transformers 库是加载模型最常用的方式配合 PEFT、LoRA 等微调工具可以在有限算力下完成模型适配。整体来看从模型获取到模型训练、推理、部署开源 AI 已经形成了一条比较完整的工程链。3. 值得关注的开源大模型盘点3.1 DeepSeek 系列DeepSeek 系列是开源社区讨论度很高的模型之一。它最大的特点是推理能力强尤其是数学和代码类任务表现突出同时以相对较低的训练成本实现了较强的模型效果。DeepSeek 还公开了技术报告其中一些训练细节对研究团队和算法工程师非常有参考价值。从工程角度DeepSeek 提供了多种参数规模的模型并且支持标准的 Transformers 加载方式。如果你需要在本地部署一个偏推理和代码方向的通用助手DeepSeek 是值得第一时间纳入测试的候选模型。3.2 通义千问 Qwen 系列Qwen 系列是覆盖面最广的开源中文模型之一。它不仅提供通用的对话模型还开源了多模态模型、代码模型和数学模型并有多个参数量版本。对于应用开发者来说Qwen 系列的优点是模型生态完整、中文能力强、工具调用和 Agent 能力支持成熟。在本地部署体验上Qwen 是各大推理框架适配最好的模型家族之一。Ollama、vLLM、llama.cpp 都有对应的模型支持按名称直接拉取就能跑。也就是说即使你不熟悉底层推理细节也能在十几分钟内启动一个可用的对话服务。3.3 GLM 系列GLM 来自智谱 AI是中英双语对话能力比较均衡的模型系列。GLM 在中文语境下的表现稳定同时提供了一些针对 Agent 任务的优化版本。对国内企业来说如果业务主要面向中文用户GLM 是值得做 A/B 测试的模型之一。需要注意的是不同模型的 License 不完全相同有的允许商用有的需要申请有的存在附加条款。选择模型时除了看效果和显存还要确认当前项目的使用目的是否符合对应模型的许可要求。3.4 其他值得跟踪的模型除了上面三个系列还有不少中国团队开源的模型值得关注包括以中文开源模型起步的 Baichuan 系列、以长文本和 Agent 见长的 InternLM 系列以及一些特定垂直领域的微调模型。这些模型各有侧重在具体任务上可能比通用大模型效果更好。我的建议是不要迷信单一模型而是建立一个小模型测试池把 7B 到 14B 量级的几个开源模型都跑一遍用最接近实际业务的测试集做对比。只有自己的数据跑出来的结果才是可靠的选型依据。4. 本地部署环境准备4.1 硬件要求开源模型部署的硬件门槛没有很多文章写得那么高关键看模型参数量和精度。1.5B 到 4B 的小模型量化后可以在 4GB 到 6GB 显存上运行适合个人电脑和入门级显卡。7B 到 8B 模型FP16 精度通常需要 14GB 到 16GB 显存4bit 量化后大约需要 5GB 到 7GB 显存。14B 模型FP16 大约需要 28GB 显存量化后可以压到 10GB 到 12GB 左右。32B 到 70B 的大模型基本需要 24GB 以上显存或多卡部署量化后也需要较高显存。以上是通用估算范围实际占用还取决于上下文长度、并发数和推理框架的优化程度。如果你只有 CPU也不是完全不能跑llama.cpp 和 Ollama 都支持 CPU 推理但速度会比 GPU 慢很多适合测试阶段使用。新显卡需要确认对应版本的 CUDA、PyTorch 或推理框架驱动支持具体以官方兼容矩阵为准。4.2 软件环境软件环境方面建议用一张核对清单来准备操作系统LinuxUbuntu 系比较常用、Windows 和 macOS 均有支持生产环境优先 Linux。Python3.9 到 3.12 之间的版本都可以具体看推理框架要求。GPU 驱动NVIDIA 显卡需要安装较新的驱动并确认 CUDA 可用。PyTorch根据显卡驱动和 CUDA 版本安装对应版本。模型下载工具HuggingFace CLI 或 ModelScope SDK。推理框架Ollama、vLLM、Transformers 中至少选择一个。我不建议在生产环境用 Anaconda 的全局环境直接装所有依赖而是用虚拟环境或 Docker 把项目依赖隔离起来避免多个项目之间的版本冲突。4.3 部署方式选型部署方式特点适用场景Ollama安装简单命令少模型管理方便个人学习、快速原型、小规模内部工具llama.cppCPU 友好支持量化单文件运行低配置机器、边缘设备Transformers生态完整便于微调和二次开发研究、微调、定制化开发vLLM吞吐高支持并发兼容 OpenAI API生产环境 API 服务、批量推理快速判断方法是如果只是自己体验选 Ollama如果要接生产 API选 vLLM如果要微调模型选 Transformers。5. 模型下载、启动与推理验证5.1 从 ModelScope 下载模型国内开发者建议优先使用 ModelScope 下载模型速度更稳定。先安装 ModelScope SDKpip install modelscope然后通过 Python 脚本下载模型到本地目录from modelscope import snapshot_download # 替换为你实际需要的模型这里以 Qwen 系列为例 model_path snapshot_download(Qwen/Qwen2.5-7B-Instruct, cache_dir./models) print(f模型已下载到: {model_path})注意模型名称要以 ModelScope 页面上的实际仓库名为准。下载完成后可以在本地目录看到模型权重文件、配置文件等。5.2 用 Ollama 快速启动Ollama 是目前最省事的本地部署方式之一。安装 Ollama 后拉取模型只需要一条命令ollama run qwen2.5:7b如果模型库里没有对应标签也可以先拉取ollama pull qwen2.5:7b启动后可以直接在终端对话它会自动下载模型并加载到本地。Ollama 还提供了 API 服务默认监听 11434 端口方便后续接入其他工具。5.3 用 vLLM 启动 OpenAI 兼容服务如果你需要把模型做成生产级 API 服务vLLM 是更稳的选择。先安装 vLLMpip install vllm然后启动 OpenAI 兼容的 API 服务python -m vllm.entrypoints.openai.api_server \ --model ./models/Qwen/Qwen2.5-7B-Instruct \ --host 127.0.0.1 \ --port 8000这里的--model参数可以填本地模型路径也可以填模型仓库名称具体取决于你的使用环境。启动成功后控制台会输出一个http://127.0.0.1:8000/v1的服务地址。5.4 最小推理验证服务启动后先用一个最简单的 Python 请求验证模型是否正常工作from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:8000/v1, api_keyEMPTY # vLLM 本地服务通常不校验 key ) resp client.chat.completions.create( modelQwen/Qwen2.5-7B-Instruct, messages[ {role: system, content: 你是一个简洁的助手。}, {role: user, content: 请用一句话介绍你自己。} ], max_tokens128, temperature0.7 ) print(resp.choices[0].message.content)如果返回了正常文本说明模型部署链路已经打通。接下来可以测试不同的上下文长度、并发请求和批处理效果。6. 接口 API 与批量任务接入6.1 OpenAI 兼容 API 调用vLLM 启动的服务兼容 OpenAI API 格式这让项目迁移变得很简单。你之前如果对接过 OpenAI 接口只需要把base_url换成http://127.0.0.1:8000/v1模型名换成实际的本地模型名即可。为什么这件事很重要因为团队可以保留原有业务代码只是在环境配置里切换模型地址。这降低了开源模型引入的工程成本也让“开发环境用开源模型、生产环境再决定接商业模型还是继续用开源模型”成为了可行的策略。6.2 批量任务设计开源模型最常见的落地方式之一就是批量离线任务比如给一批文档做摘要、给一批客服会话做分类、给一批代码做注释生成。批量任务不要简单写一个 for 循环直接压进单进程而是要考虑并发、限速和失败重试。一个简单的并发处理示例import json import time from concurrent.futures import ThreadPoolExecutor, as_completed from openai import OpenAI client OpenAI(base_urlhttp://127.0.0.1:8000/v1, api_keyEMPTY) def process(item): resp client.chat.completions.create( modelQwen/Qwen2.5-7B-Instruct, messages[{role: user, content: item[text]}], max_tokens512 ) return {id: item[id], result: resp.choices[0].message.content} def run_batch(tasks, max_workers4): results [] with ThreadPoolExecutor(max_workersmax_workers) as pool: future_map {pool.submit(process, t): t for t in tasks} for future in as_completed(future_map): try: results.append(future.result()) except Exception as e: print(f任务失败: {future_map[future][id]}, 错误: {e}) return results if __name__ __main__: tasks [{id: i, text: f这是第 {i} 条测试文本} for i in range(10)] output run_batch(tasks) print(json.dumps(output, ensure_asciiFalse, indent2))这里把请求封装成process函数用线程池控制并发数。生产环境建议再加一个任务队列把输入、输出、失败状态落到本地文件或数据库里方便中途断点续跑。6.3 失败重试与任务日志批量任务最容易翻车的地方是长文本和并发过高。长文本超过模型上下文窗口会直接报错并发过高则会触发 OOM 或者请求超时。工程上可以这样做每个任务 id 保持唯一方便追踪。输入输出分别存文件输入放在inputs/输出放在outputs/。失败任务记录到failed.json包含错误类型和任务 id。整体重跑只处理失败任务而不是重跑全部。API 调用加上超时、重试和退避策略。定期记录显存和内存占用方便定位 OOM。这样一套最小批量任务系统大概百行以内就能搭出来但稳定性会好很多。7. 模型选型与性能评估维度7.1 选型维度面对众多开源模型选型不要只看排行榜分数而要用自己的业务场景去验证。下面这张表是我建议团队在技术评审时使用的评估维度评估维度具体问题判断方法任务匹配度我的业务是对话、分类、抽取还是代码生成用 100 条真实业务样本做效果测试中文能力模型在中文表达上是否自然准确对比多个模型的中文输出显存占用目标卡上能否跑起来用 4bit 量化和不同上下文长度测试推理速度单请求延迟和并发吞吐能否接受压测不同并发数License 限制能否商用、能否二次分发阅读模型官方许可社区活跃度出问题能否找到解决方案看 GitHub Issue 和模型更新频率生态兼容是否支持 Ollama / vLLM / Transformers查推理框架官方模型列表7.2 显存、量化与上下文显存是本地部署最大的约束。降低显存占用最直接的办法是量化常见的有 8bit 和 4bit。量化后模型体积缩小推理速度可能提升但极端量化会带来一定的效果损失。建议在正式评估时对同一个模型分别测试 FP16、8bit、4bit 三档效果找到可接受的最低配置。此外上下文长度也直接影响显存占用。上下文越长KV Cache 占用越大。如果你只是做短对话可以把max_model_len调小如果要做长文档分析就要留出更多显存。7.3 性能观察方法部署之后推荐用以下三个工具观察资源占用nvidia-smi观察 GPU 显存和利用率。htop观察 CPU 与内存占用。API 压测工具或自定义脚本统计请求延迟、吞吐量与错误率。观察的关键指标是显存是否接近满载、GPU 利用率是否稳定、单请求时间是否波动、并发上升后是否出现超时。这些数据才是调优的依据而不是只看模型理论知识。8. 常见问题与排查方法问题现象可能原因排查方式解决方案模型下载慢或失败网络不稳定、平台限流检查下载日志换 ModelScope / 使用镜像源 / 断点续传启动后端口被占用上一次服务未退出或端口冲突查看端口占用更换端口或清理旧进程CUDA 报错驱动与 PyTorch 版本不匹配运行 nvidia-smi 核对 CUDA按官方矩阵重装对应版本显存不足 OOM模型太大或并发过高观察 nvidia-smi 显存占用换小模型、开量化、降低并发输出乱码或空内容Tokenizer 加载错误或上下文超限查看服务日志确认模型路径和 tokenizer 对齐API 调用超时并发高、模型响应慢检查请求耗时与排队加超时、调低并发、升级硬件批量任务中途卡住单条任务异常导致整个进程等待检查任务日志加失败重试和超时机制多轮对话效果差上下文管理不正确检查历史消息拼接使用正确的 messages 格式并控制长度部署开源模型时很多问题不是模型本身的问题而是环境、版本和进程管理的问题。遇到报错先看日志再逐项核对环境版本比盲目重装更高效。9. 合规边界与最佳实践9.1 合规提醒开源模型不等于可以随意使用。用开源模型做项目时至少要注意以下几点确认模型 License 是否允许商用商用是否有限制条件。微调时使用的数据要有合法来源不包含未授权个人信息。对外提供服务时要对模型输出内容做必要的合规审核。涉及人脸、声音、肖像、版权素材等生成能力时必须确认授权。涉及隐私数据的调用避免直接发送原始数据到远程服务。这些不只是道德要求也是实际工程里必要的风险控制。9.2 工程化建议从项目启动到上线我建议遵循这些实践第一次先小参数测试最短路径跑通全流程。保留一套最小可运行配置出问题可以快速回退。模型文件、输入数据、输出结果分目录管理。批量任务记录完整日志支持断点续跑。接口服务只监听可信网段不要暴露到公网。固定依赖版本升级前先在测试环境验证。模型更新后重新跑一遍评估集防止效果回退。9.3 下一步建议如果你准备把开源 AI 引入自己的项目我建议按这个顺序推进先选一个 7B 到 14B 量级的模型在本地部署跑通对话接着用 50 条真实业务数据做效果测试然后接入 vLLM API写一个最小批量任务脚本最后再考虑量化、并发调优和长期维护。开源 AI 的价值不在于某一个模型多强大而在于它给工程团队提供了更多选择权。你可以用最低成本验证想法用本地部署控制数据边界用 API 服务做业务集成。先把一台机器上的部署链路跑通你就已经站在了这些开源成果之上。