encode_image_with_clip: 5 segments encoded in 462.51 ms
encode_image_with_clip: image embedding created: 2880 tokens
encode_image_with_clip: image encoded in 483.20 ms by CLIP ( 0.17 ms per image patch)
{"function":"print_timings","level":"INFO","line":264,"msg":"prompt eval time = 2494.64 ms / 1 tokens ( 2494.64 ms per token, 0.40 tokens per second)","n_prompt_tokens_processed":1,"n_tokens_second":0.4008587998928906,"slot_id":0,"t_prompt_processing":2494.644,"t_token":2494.644,"task_id":0,"tid":"10108","timestamp":1709774423}
{"function":"print_timings","level":"INFO","line":278,"msg":"generation eval time = 1518.83 ms / 85 runs ( 17.87 ms per token, 55.96 tokens per second)","n_decoded":85,"n_tokens_second":55.9643145194476,"slot_id":0,"t_token":17.868529411764705,"t_token_generation":1518.825,"task_id":0,"tid":"10108","timestamp":1709774423}
{"function":"print_timings","level":"INFO","line":287,"msg":" total time = 4013.47 ms","slot_id":0,"t_prompt_processing":2494.644,"t_token_generation":1518.825,"t_total":4013.469,"task_id":0,"tid":"10108","timestamp":1709774423}
3条答案
按热度按时间qyyhg6bp1#
编辑:作为参考,我使用的是LLaVa v1.6 Mistral 7B模型(我认为是q5km)。
我发现,如果我手动从HF上下载一个mmproj-model-f16.gguf文件(我使用的是cjpais提供的),将其移动到C:Users\USERNAME.ollamamodels\blobs文件夹并将其重命名为长sha256-1234567...(通过将名称更改为.bak来备份旧文件),现在ollama显示我使用2880个令牌对图像进行编码,这意味着它正确地进行了平铺操作。只需检查sha256文件上的文件大小,mmproj将大约为600MB,而不是多GB的大小。
这是现在的server.log:
这是ollama想要下载的mmproj模型(显示图像需要576个令牌):
这是我使用已知有效的mmproj模型时的样子(显示图像需要2880个令牌):
我的猜测是,数据库可能正在使用旧的v1.5 mmproj模型,而没有正确的v1.6版本?
yjghlzjz2#
对于使用LLaVA 1.6 34b并将mmproj模型(在我的~/.ollama/models/blobs中为
sha256-83720bd8438ccdc910deba5efbdc3340820b29258d94a7a60d1addc9a1b5f095
)替换为https://hf-mirror.com/cjpais/llava-v1.6-34B-gguf/blob/main/mmproj-model-f16.gguf的任何人来说,如果观察到空输出,原因是默认的上下文窗口大小为2048,而正确的图像嵌入具有2880个标记,这大于上下文窗口。符号是一个类似于这样的日志行:解决方案是从LLaVA 1.6 34b模型创建一个具有较大上下文窗口的新模型(使用
PARAMETER num_ctx
),例如使用此模型文件:l7mqbcuq3#
根据我在https://ollama.com/highsunz/llava:34b-v1.6-q8_0-hires-ctx8k的先前评论,我已经将LLaVA 1.6 34b模型与Q8_0量化组合在一起。它的投影模型将输入图像投影到2880个标记上。