[GH-ISSUE #973] 显存占用是否存在优化方式 #693

New issue

Closed

opened 2026-10-29 14:42:57 +00:00 by bsakaguchi · 3 comments

bsakaguchi commented 2026-10-29 14:42:57 +00:00

Owner

Copy link

Originally created by @sunhaoyu-1990 on GitHub (Mar 25, 2025).
Original GitHub issue: https://github.com/kvcache-ai/ktransformers/issues/973

Originally assigned to: @KMSorSMS on GitHub.

目前通过Ktransformer 0.2版本，已经运行起来了DeepSeek-R1-671B-Q4-K-M的模型
硬件配置如下：
显卡：3080Ti（12GB） * 8
内存：512GB

运行命令为
ktransformers --optimize_config_path /ktransformers/ktransformers/optimize/optimize_rules/DeepSeek-V3-Chat.yaml --model_path /mount/DeepSeek-R1-671B --gguf_path /mount/DeepSeek-R1-671B-GGUF --cpu_infer 56 --max_new_tokens 1024 --model_name DeepSeek-R1-full
其中DeepSeek-V3-Chat.yaml配置文件内容进行了更改，权重分到了6个卡上，以下是其中一部分内容

刚布上去时显存总占用16GB，内存占用381GB，推理速度为7t/s，如下图所示

开启接口后，通过open webUI进行调用。目前问题是第一次请求，显存占用没有什么变化，但是继续请求沟通问题之后，显存直接暴涨到50GB，基本上吧5张卡占满了。

当再多次请求后，程序直接强退，并报错：Segmentation fault (core dumped)

请问这是什么原因，或者怎么解决

Originally created by @sunhaoyu-1990 on GitHub (Mar 25, 2025). Original GitHub issue: https://github.com/kvcache-ai/ktransformers/issues/973 Originally assigned to: @KMSorSMS on GitHub. 目前通过Ktransformer 0.2版本，已经运行起来了DeepSeek-R1-671B-Q4-K-M的模型 硬件配置如下： 显卡：3080Ti（12GB） * 8 内存：512GB 运行命令为 `ktransformers --optimize_config_path /ktransformers/ktransformers/optimize/optimize_rules/DeepSeek-V3-Chat.yaml --model_path /mount/DeepSeek-R1-671B --gguf_path /mount/DeepSeek-R1-671B-GGUF --cpu_infer 56 --max_new_tokens 1024 --model_name DeepSeek-R1-full` 其中DeepSeek-V3-Chat.yaml配置文件内容进行了更改，权重分到了6个卡上，以下是其中一部分内容  刚布上去时显存总占用16GB，内存占用381GB，推理速度为7t/s，如下图所示    开启接口后，通过open webUI进行调用。目前问题是第一次请求，显存占用没有什么变化，但是继续请求沟通问题之后，显存直接暴涨到50GB，基本上吧5张卡占满了。  当再多次请求后，程序直接强退，并报错：Segmentation fault (core dumped) 请问这是什么原因，或者怎么解决

bsakaguchi closed this issue 2026-10-29 14:42:57 +00:00

bsakaguchi commented 2026-10-29 14:42:58 +00:00

Author

Owner

Copy link

@KMSorSMS commented on GitHub (Mar 25, 2025):

目前通过Ktransformer 0.2版本，已经运行起来了DeepSeek-R1-671B-Q4-K-M的模型 硬件配置如下： 显卡：3080Ti（12GB） * 8 内存：512GB

运行命令为 ktransformers --optimize_config_path /ktransformers/ktransformers/optimize/optimize_rules/DeepSeek-V3-Chat.yaml --model_path /mount/DeepSeek-R1-671B --gguf_path /mount/DeepSeek-R1-671B-GGUF --cpu_infer 56 --max_new_tokens 1024 --model_name DeepSeek-R1-full 其中DeepSeek-V3-Chat.yaml配置文件内容进行了更改，权重分到了6个卡上，以下是其中一部分内容

刚布上去时显存总占用16GB，内存占用381GB，推理速度为7t/s，如下图所示

开启接口后，通过open webUI进行调用。目前问题是第一次请求，显存占用没有什么变化，但是继续请求沟通问题之后，显存直接暴涨到50GB，基本上吧5张卡占满了。

当再多次请求后，程序直接强退，并报错：Segmentation fault (core dumped)

请问这是什么原因，或者怎么解决

应该是server端有历史记录信息，但是第二次沟通直接暴涨的情况应该是之前版本的遗留bug，请问您是用的就是v0.2版本吗？有试试更高版本的吗？

<!-- gh-comment-id:2750094332 --> @KMSorSMS commented on GitHub (Mar 25, 2025): > 目前通过Ktransformer 0.2版本，已经运行起来了DeepSeek-R1-671B-Q4-K-M的模型 硬件配置如下： 显卡：3080Ti（12GB） * 8 内存：512GB > > 运行命令为 `ktransformers --optimize_config_path /ktransformers/ktransformers/optimize/optimize_rules/DeepSeek-V3-Chat.yaml --model_path /mount/DeepSeek-R1-671B --gguf_path /mount/DeepSeek-R1-671B-GGUF --cpu_infer 56 --max_new_tokens 1024 --model_name DeepSeek-R1-full` 其中DeepSeek-V3-Chat.yaml配置文件内容进行了更改，权重分到了6个卡上，以下是其中一部分内容 > >  > > 刚布上去时显存总占用16GB，内存占用381GB，推理速度为7t/s，如下图所示 > >  > >  > >  > > 开启接口后，通过open webUI进行调用。目前问题是第一次请求，显存占用没有什么变化，但是继续请求沟通问题之后，显存直接暴涨到50GB，基本上吧5张卡占满了。 > >  > > 当再多次请求后，程序直接强退，并报错：Segmentation fault (core dumped) > > 请问这是什么原因，或者怎么解决 应该是server端有历史记录信息，但是第二次沟通直接暴涨的情况应该是之前版本的遗留bug，请问您是用的就是v0.2版本吗？有试试更高版本的吗？

bsakaguchi commented 2026-10-29 14:42:58 +00:00

Author

Owner

Copy link

@sunhaoyu-1990 commented on GitHub (Mar 25, 2025):

目前通过Ktransformer 0.2版本，已经运行起来了DeepSeek-R1-671B-Q4-K-M的模型 硬件配置如下： 显卡：3080Ti（12GB） * 8 内存：512GB
运行命令为 ktransformers --optimize_config_path /ktransformers/ktransformers/optimize/optimize_rules/DeepSeek-V3-Chat.yaml --model_path /mount/DeepSeek-R1-671B --gguf_path /mount/DeepSeek-R1-671B-GGUF --cpu_infer 56 --max_new_tokens 1024 --model_name DeepSeek-R1-full 其中DeepSeek-V3-Chat.yaml配置文件内容进行了更改，权重分到了6个卡上，以下是其中一部分内容

刚布上去时显存总占用16GB，内存占用381GB，推理速度为7t/s，如下图所示



开启接口后，通过open webUI进行调用。目前问题是第一次请求，显存占用没有什么变化，但是继续请求沟通问题之后，显存直接暴涨到50GB，基本上吧5张卡占满了。

当再多次请求后，程序直接强退，并报错：Segmentation fault (core dumped)
请问这是什么原因，或者怎么解决

应该是server端有历史记录信息，但是第二次沟通直接暴涨的情况应该是之前版本的遗留bug，请问您是用的就是v0.2版本吗？有试试更高版本的吗？

对，目前用的就是v0.2的版本，高版本还没有试，那具体哪一个版本解决了这个bug嘞

<!-- gh-comment-id:2750139500 --> @sunhaoyu-1990 commented on GitHub (Mar 25, 2025): > > 目前通过Ktransformer 0.2版本，已经运行起来了DeepSeek-R1-671B-Q4-K-M的模型 硬件配置如下： 显卡：3080Ti（12GB） * 8 内存：512GB > > 运行命令为 `ktransformers --optimize_config_path /ktransformers/ktransformers/optimize/optimize_rules/DeepSeek-V3-Chat.yaml --model_path /mount/DeepSeek-R1-671B --gguf_path /mount/DeepSeek-R1-671B-GGUF --cpu_infer 56 --max_new_tokens 1024 --model_name DeepSeek-R1-full` 其中DeepSeek-V3-Chat.yaml配置文件内容进行了更改，权重分到了6个卡上，以下是其中一部分内容 > >  > > 刚布上去时显存总占用16GB，内存占用381GB，推理速度为7t/s，如下图所示 > >  > >  > >  > > 开启接口后，通过open webUI进行调用。目前问题是第一次请求，显存占用没有什么变化，但是继续请求沟通问题之后，显存直接暴涨到50GB，基本上吧5张卡占满了。 > >  > > 当再多次请求后，程序直接强退，并报错：Segmentation fault (core dumped) > > 请问这是什么原因，或者怎么解决 > > 应该是server端有历史记录信息，但是第二次沟通直接暴涨的情况应该是之前版本的遗留bug，请问您是用的就是v0.2版本吗？有试试更高版本的吗？ 对，目前用的就是v0.2的版本，高版本还没有试，那具体哪一个版本解决了这个bug嘞

bsakaguchi commented 2026-10-29 14:42:58 +00:00

Author

Owner

Copy link

@KMSorSMS commented on GitHub (Mar 25, 2025):

目前通过Ktransformer 0.2版本，已经运行起来了DeepSeek-R1-671B-Q4-K-M的模型 硬件配置如下： 显卡：3080Ti（12GB） * 8 内存：512GB
运行命令为 ktransformers --optimize_config_path /ktransformers/ktransformers/optimize/optimize_rules/DeepSeek-V3-Chat.yaml --model_path /mount/DeepSeek-R1-671B --gguf_path /mount/DeepSeek-R1-671B-GGUF --cpu_infer 56 --max_new_tokens 1024 --model_name DeepSeek-R1-full 其中DeepSeek-V3-Chat.yaml配置文件内容进行了更改，权重分到了6个卡上，以下是其中一部分内容

刚布上去时显存总占用16GB，内存占用381GB，推理速度为7t/s，如下图所示



开启接口后，通过open webUI进行调用。目前问题是第一次请求，显存占用没有什么变化，但是继续请求沟通问题之后，显存直接暴涨到50GB，基本上吧5张卡占满了。

当再多次请求后，程序直接强退，并报错：Segmentation fault (core dumped)
请问这是什么原因，或者怎么解决

应该是server端有历史记录信息，但是第二次沟通直接暴涨的情况应该是之前版本的遗留bug，请问您是用的就是v0.2版本吗？有试试更高版本的吗？

对，目前用的就是v0.2的版本，高版本还没有试，那具体哪一个版本解决了这个bug嘞

应该是在这里https://github.com/kvcache-ai/ktransformers/releases/tag/v0.2.3，
因为这里解决了显存大的开销，从而支持了长文本

<!-- gh-comment-id:2750287068 --> @KMSorSMS commented on GitHub (Mar 25, 2025): > > > 目前通过Ktransformer 0.2版本，已经运行起来了DeepSeek-R1-671B-Q4-K-M的模型 硬件配置如下： 显卡：3080Ti（12GB） * 8 内存：512GB > > > 运行命令为 `ktransformers --optimize_config_path /ktransformers/ktransformers/optimize/optimize_rules/DeepSeek-V3-Chat.yaml --model_path /mount/DeepSeek-R1-671B --gguf_path /mount/DeepSeek-R1-671B-GGUF --cpu_infer 56 --max_new_tokens 1024 --model_name DeepSeek-R1-full` 其中DeepSeek-V3-Chat.yaml配置文件内容进行了更改，权重分到了6个卡上，以下是其中一部分内容 > > >  > > > 刚布上去时显存总占用16GB，内存占用381GB，推理速度为7t/s，如下图所示 > > >  > > >  > > >  > > > 开启接口后，通过open webUI进行调用。目前问题是第一次请求，显存占用没有什么变化，但是继续请求沟通问题之后，显存直接暴涨到50GB，基本上吧5张卡占满了。 > > >  > > > 当再多次请求后，程序直接强退，并报错：Segmentation fault (core dumped) > > > 请问这是什么原因，或者怎么解决 > > > > > > 应该是server端有历史记录信息，但是第二次沟通直接暴涨的情况应该是之前版本的遗留bug，请问您是用的就是v0.2版本吗？有试试更高版本的吗？ > > 对，目前用的就是v0.2的版本，高版本还没有试，那具体哪一个版本解决了这个bug嘞 应该是在这里https://github.com/kvcache-ai/ktransformers/releases/tag/v0.2.3， 因为这里解决了显存大的开销，从而支持了长文本

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

auto/sync-sglang

gh-pages

docs/kt-ft-figure2-single-column-20261010

perf/bf16-grad-norm-20261010

docs/kt-ft-paper-20261008

release/20260911-carrier-repair

release/20260911-ci-python

release/20260911-pypi

ci/four-main-pypi-release

ci/model-e2e-acceptance

release/0.7.0.post3-frozen-pypi

fix/glm53-index-share-sync

release/0.7.0.post2-frozen-pypi

hotfix/0.7.0.post2-pypi-runtime

fix/avx2-wheel-feature-isolation

fix/release-self-hosted-runner

release/automate-kt-sft-pypi

support-glm5-next-djw

docs/deepseek-v4-flash-docker

ovowei-patch-3

support-glm52-djw

doc-reorg-entrypoints-support-matrix

bump-sglang-pr31

docs-v061-refresh

fp4-moe-amx

flatten-ktransformers-shim

archive-kt-sft

kt-kernel-torch-range-v061

sft-whl

sft

docs/gosim-2026-and-roadmap-link

ovowei-patch-2

ovowei-patch-1

revert-1918-fix/rocm-cpuinfer-stream-bridge

chore/kt-layerwise-prefill-main

chore/kt-layerwise-prefill-label

sft-rel

support-glm51-djw

release/v0.5.3

chore/kt-run-numa-nodes-unified

mtp

ksft-sglang

avx2

fix/sglang-kt-detection

layerwise-prefill-opt

feat/mistral-loader-support

fix-docker-build

minimax-m2.5

qwen3.5

add-maintainers

oql-doc

cli-dev-ljq

ljq-cli-dev-new

JimmyPeilinLi-patch-2

kimi_k2.5

oql-dev

experts_sched

JimmyPeilinLi-patch-1

ErvinXie-patch-1

ksft-llama

glm47_fp8

debug_llama

refactor_sft

ljq-cli-dev

refactor_sft_int4_debug

lut-nvfp4

fix-import

fix-deploy-djw

cpu-fix

ljq-dev-1

route-moe

sosp25-ae

v0.7.2

paper-ktft-v1.1

paper-ktft-v1

v0.7.1

v0.7.0.post4

v0.7.0.post1

v0.7.0

v0.6.4

v0.6.3.post1

v0.6.3

v0.6.2.post3

v0.6.2.post2

v0.6.2.post1

v0.6.2

v0.6.1

v0.6.1.post1

v0.5.3

v0.5.2.post1

v0.5.1

v0.5.0.post1

v0.5.0

v0.4.4

v0.4.3

v0.4.2

v0.4.1

v0.3.2

v0.3.1

v0.3

v0.2.4post1

v0.2.4

v0.2.3post2

v0.2.3post1

v0.2.3

v0.2.2

v0.2.2rc2

v0.2.2rc1

v0.2.1.post1

v0.2.1

v0.2.0

v0.1.4

v0.1.3

v0.1.2

v0.1.1

v0.1.0

Labels

Clear labels   

bug

  

duplicate

  

enhancement

  

good first issue

  

help wanted

  

pull-request

Mirrored from GitHub Pull Request

  

stale

No labels

bug

duplicate

enhancement

good first issue

help wanted

pull-request

stale

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

kvcache-ai/ktransformers#693

No description provided.