👁 116 次阅读

Jan 下载模型卡在初始化？原因与解决

来源：https://github.com/janhq/jan/issues/7728

现象描述

在 Jan v0.7.8 中，进入 Hub 页面选择模型下载后，下载图标停留在 “Initializing Download” 状态不再变化，控制台无任何错误输出。issue 正文标注的环境为 Linux，另有用户在评论中报告 macOS 上同样出现。据 issue 讨论，多数报告认为 v0.7.6 正常、问题在后续版本引入；也有用户报告全新安装的 v0.7.7 即已异常，受影响起点存在分歧。

背景原因

据 issue 讨论，区分该问题是否出现的因素并非操作系统，而是安装方式。AppImage v0.7.6 可正常工作，并在首次启动时安装 llama.cpp 扩展。AppImage 与 jan-bin 的 0.7.8 / 0.7.9 / 0.8.2 版本会卡在初始化阶段。该问题的根因据 issue 讨论指向扩展安装环节：打包安装版本中 llama.cpp 扩展缺失，而 AppImage 中存在。界面显示 “Initializing Download” 的条件是下载未上报任何字节数，属于下载从未启动，而非下载缓慢。部分用户报告了关联症状：已保存的聊天记录、助手配置和扩展目录为空，但 mcpServers.json 与 app.log 写入正常。

排查或量化方法

确认问题是否属于已知模式时，可依次执行以下检查： 1. 记录环境信息：操作系统类型、安装方式（AppImage / AUR / Flatpak）、窗口管理器、Jan 版本号 2. 检查 app.log：尽管 “Initializing Download” 阶段控制台无输出，app.log 通常仍会写入日志，可搜索异常条目 3. 回退验证：多位用户报告降级至 v0.7.6 后恢复正常，可据此判断问题是否属于同一失效模式 4. 检查数据目录：尝试删除 ~/.local/share/jan/ 目录并恢复出厂设置，根据 issue 讨论中的报告，此方法无法解决问题 5. 检查关联报错：若尝试加载旧模型时出现 Failed to create model: No running session found for model 错误，属于同类问题

完整解决方案

根据 issue 讨论中的社区复测结论，升级至 Jan v0.8.4 及以上版本可能解决该问题。多位用户确认在 cachyos/jan-bin 0.8.4-2 版本中下载功能恢复正常。以下为常见场景的操作思路： 升级至 v0.8.4（推荐） 根据所使用的包管理器执行升级：

# Arch Linux / AUR
yay -Syu jan-bin

# CachyOS 仓库
pacman -Syu jan-bin

若使用 AppImage 方式，下载最新版 AppImage 替换旧版本后重新运行即可。 临时回退至 v0.7.6 若升级后出现其他问题，可回退至据 issue 讨论确认正常的最后一个版本：

# 从 GitHub Releases 页面下载 v0.7.6 的 AppImage
# 替换本地安装后运行
./Jan-0.7.6.AppImage

注意：以上修复版本为社区复测结论，issue 当前状态仍为 open，官方尚未合入正式修复方案。v0.8.4 的修复效果尚未获得维护者明确确认。

版本与安装方式对照表

版本	安装方式	下载功能状态	备注
v0.7.6	AppImage	正常	首次启动安装 llama.cpp 扩展
v0.7.7	AppImage	有分歧	多数报告正常，也有用户报告全新安装即已异常
v0.7.8	AppImage / jan-bin	卡在 Initializing	issue 正文报告版本
v0.7.9	AppImage / jan-bin	卡在 Initializing	据 issue 讨论
v0.8.2	AUR (jan-bin)	卡在 Initializing	据 issue 讨论
v0.8.4	cachyos/jan-bin 0.8.4-2	正常	社区复测确认，非官方确认

常见错误排查

1. “No running session found for model” 错误：在 v0.7.8 及之后版本中，尝试加载模型时出现此错误。据 issue 讨论，清除数据目录和恢复出厂设置均无法解决，该错误与下载卡在初始化属于同一类问题。 2. 与 Flatpak 的关系存在分歧：维护者在 issue 中询问 GNOME 下的 Flatpak 安装是否为 100% 损坏，另有用户明确回复问题与 Fedora、Flatpak、GNOME 均无关，同一现象出现在 Arch Linux 的 AUR 安装（jan-bin）上。安装方式才是相关因素，具体包管理渠道不能单独作为判断依据。 3. 图形界面无报错：”Initializing Download” 卡住时界面不显示任何错误，issue 正文作者也提到控制台无输出。但通过 CLI 启动时可见 extensions.json 读取失败（No such file or directory）这类异常条目，说明关键线索在 CLI 日志里而非界面。 4. 数据持久化异常：部分用户报告 chats、assistants、extensions 目录为空，但 mcpServers.json 和 app.log 正常写入。该功能的异常行为尚未被单独追踪。 5. 降级后旧模型不可用：有用户报告安装受影响版本后已下载的模型无法加载。据 issue 讨论，一次运行过 0.7.6 会为数据目录写入扩展，之后再用 0.7.9 即可工作，说明问题与磁盘上共享的状态有关。

实践建议

锁定在 v0.7.6，或升级到 v0.8.4 以上版本；v0.7.8 及之后的版本在讨论中均有复现报告，据 issue 讨论不作为可选目标版本
避免使用 Flatpak 安装 Jan，优先选择 AppImage 或 AUR 方式
安装后首次启动时检查 app.log，确认 llama.cpp 运行时是否正确安装
在切换版本前备份 ~/.local/share/jan/ 目录
提交新 issue 时附带操作系统、安装方式、窗口管理器和 Jan 版本信息，便于维护者复现

FAQ

Q: 为什么下载卡在 “Initializing Download” 而不报错？ A: 据 issue 讨论，该阶段涉及底层运行时的初始化流程，异常时进程可能挂起而非抛出可见错误。控制台和日志系统均未捕获到相关异常信息，导致问题难以定位。 Q: 清除数据目录能解决吗？ A: 据 issue 讨论，用户尝试删除 ~/.local/share/jan/ 目录并恢复出厂设置均未解决问题，说明根因不在用户数据层面，而在运行时初始化流程中。 Q: 官方修复何时发布？ A: 截至该 issue 最后更新，状态仍为 open，官方尚未合入正式修复方案。社区复测结论显示 v0.8.4 版本可能已包含修复，但该结论由社区贡献者提出，非官方确认。 Q: 哪些安装方式受影响？ A: AppImage 与 AUR（jan-bin）在 v0.7.8 及之后版本均有复现报告；维护者曾询问 Flatpak 是否 100% 损坏，也有用户明确否认该关联。据 issue 讨论，AppImage v0.7.6 不受影响。 Q: 可以使用替代软件吗？ A: 据 issue 讨论中的用户反馈，LM Studio 等专有软件可作为 Jan 问题期间的替代方案，两者使用独立的模型存储，互不影响。开源替代方案的选择需要权衡功能完备性。