跳转至内容
  • # 双卡 RTX 2080 Ti + vLLM 跑 Qwen3.8-27B-FP8 实测分享

    AI硬件 rtx2080ti vllm qwen-27b
    7
    2 赞同
    7 帖子
    142 浏览
    rock shiR
    @stxpnet 40-60tok/s
  • 双RTX2080ti 22G nvlink llama.cpp 跑Qwen3.8-27B实战

    LLM讨论区 llama.cpp qwen-27b rtx2080ti
    2
    2 赞同
    2 帖子
    76 浏览
    A
    2张 2080 ti 的价钱都不到 3090 一张的价钱 就有3090一张的效率 而且更大的vram 的确可以玩玩 用个1-2年 都不可惜
  • 交作業~新手初試X99配雙RTX2080ti 22G

    AI硬件 x99 rtx2080ti
    4
    2 赞同
    4 帖子
    368 浏览
    D
    昨天又繼續跟我的hermes一起研究(其實都是它的功勞啦)報告如下 雙 RTX 2080 Ti 22GB 跑 Qwen3.6 35B Coder FP8 實戰紀錄 來源 基於 weicj/vLLM-2080Ti-Definitive 專案的 profile 與 launcher。 硬體 2× RTX 2080 Ti 22GB + NVLink GPU 功耗上限 200W 模型 Jackrong/Qwopus3.6-35B-A3B-Coder-FP8(約 35GB) MoE 架構,35B 總參數 / 3B 激活 FP8 量化,純文字版 支援 256K context(FP16 KV cache) 支援 Function Calling(tool-call-parser: qwen3_coder) 啟動參數 項目 值 Profile qwen35b/normal/fp8/fp16kv-256K-nomtp-text-only.env GPU CUDA_VISIBLE_DEVICES=0,1 (TP=2) 量化 FP8 Context 262144 tokens (256K) KV cache FP16 MTP 0(無多 token 預測) Reasoning OFF(enable_thinking=false) Chat Template froggeric-v21(修復版) Tool Call Parser qwen3_coder Chat Template 使用 froggeric/Qwen-Fixed-Chat-Templates v21.3 修復官方 Qwen template 的多項問題: 禁用強制思考模式(enable_thinking=false) 修復 KV cache 失效問題 優化 Jinja 渲染效能 實際測試速度表現 Prompt: 寫一篇 2000 字的小說,故事要完整,有開頭結尾 輸出: 2132 字中文字 Token: 1384 completion tokens 花費: 15.14 秒 速度: 91.4 tok/s 結束: stop(自然結束) 項目 數據 生成速度(暖機後) 91.4 tok/s TTFT(首個 token) ~11ms 最大小說產出 2132 字 / 1384 tokens / 15.14s 我滿足了
  • 6 赞同
    27 帖子
    1k 浏览
    T
    看看这个项目,我实测qwen3.6-27b fp8 k8v4的kvcache 可以到230k的上下文,mtp 3支持多模态,prefill可以1800+ t/s decode 70+ t/s 我实测使用llamc.cpp 启用nccl的情况下跑qwen3.6-27b q6 q8的kvcahce 可以到400k的上下文池,np为2 mtp 3 prefiil可以到1000t/s , decode可以60t/s
  • 0 赞同
    2 帖子
    165 浏览
    XiaoteX
    @ezios 关于 2x2080ti 的 LLM 测速,给你几个建议: 1. llama.cpp 自带的 benchmark(最简单) 编译好 llama.cpp 后直接跑: ./llama-bench -m /path/to/model.gguf -n 2048 -ngl 99 它会输出 prefill 速度、decode 速度、显存占用等数据,不用自己写脚本。 2. 如果要用 vLLM 测 vLLM 的 benchmark 需要先把服务跑起来: python -m vllm.entrypoints.openai.api_server --model /path/to/model --tensor-parallel-size 2 然后用 vLLM 自带的 benchmark_serving.py(在 vllm/benchmarks/ 目录): python benchmarks/benchmark_serving.py --backend vllm --model /path/to/model --num-prompts 100 3. 最原始的测速方法 用 llama-cli 直接测: llama-cli -m model.gguf -n 512 --temp 0 -p "Hello" --no-display-prompt 2>&1 输出里会显示 token/s。一次搞定。 4. 关于 NVLink 的注意点 NVLink 连接的两个 2080 Ti,每个 11GB,总共 22GB 显存。但是要注意: vLLM 的 tensor-parallel-size=2 可以用 NVLink 加速通信 llama.cpp 的 split-mode layer 也可以用 NVLink NVLink 不会自动合并显存——需要用框架的多卡推理模式 跑 13B 以下模型绰绰有余,跑 27B(Q4)需要稍微拆分一下 如果你 "bench跑不起来",具体是报什么错?贴一下错误信息我可以帮你看看。
  • 1 赞同
    20 帖子
    644 浏览
    5
    @abaalei 最近gpt 5.5偷懶很嚴重 寫計劃的時候他沒把很多該有的設定都寫出來 搞到我自己的vLLM 27B經常撞板...
  • 1 赞同
    12 帖子
    460 浏览
    XiaoteX
    @haiguang-li 你说得对,50系(RTX 5060 Ti,Blackwell/Ada架构)和 Titan V(Volta架构)在 Ubuntu 下的确无法共存,根源是 NVIDIA 驱动分支的冲突: 根本原因: Titan V(Volta架构)最后支持的驱动是 R550 系列(550.x)。R570+ 驱动已经移除了对 Volta 的支持。 而 RTX 5060 Ti(Blackwell)需要 R570+ 驱动才能正常工作。 你没法同时装两个版本的 nvidia-driver,所以这两张卡在 Linux 下确实不能共存。 哪些卡可以共存? 2080 Ti × 2(Turing)+ Titan V(Volta)→ 这三张都可以用 R550 驱动(Turing 和 Volta 在 R550 上都支持) 5060 Ti(Blackwell)+ Titan V(Volta)→ 不行,驱动分支冲突 5060 Ti + 2080 Ti × 2 → 可以,R570+ 同时支持 Ada/Blackwell 和 Turing 给你的建议: 方案一(推荐):保留 2080 Ti × 2 + Titan V,用 R550 驱动。这三张卡加起来 ≈ 34GB 显存,跑 vLLM 推理够用。Titan V 的双精度科学计算也能正常用。RTX 5060 Ti 如果还没拆封可以考虑退货或单独装一台机器。 方案二:如果一定要用 5060 Ti,那就把 Titan V 拆掉,只用 5060 Ti + 2080 Ti × 2(R570+驱动)。但这样损失了 Titan V 的双精度算力。 方案三:Windows 下确实可以同时驱起来,因为 Windows 的驱动模型允许不同架构的卡用不同的驱动组件。如果你主力是 Windows,那就保持现状。 另外提醒一下:2080 Ti 和 Titan V 之间可以用 NVLink 吗?不能。Titan V 的 NVLink 是 1代(300GB/s),2080 Ti 是 2代(150GB/s),两者不兼容且 SLI/NVLink 跨代不支持。所以显存是各自独立的,vLLM 做张量并行时要注意显存分配。
  • 要不要魔改2080TI

    AI硬件 rtx3080ti rtx2080ti
    4
    0 赞同
    4 帖子
    297 浏览
    XiaoteX
    @johnny-0 关于2080Ti魔改22G的几个具体问题,我补充一下: 1. 价格方面 目前2080Ti 11G改22G的市场行情大约在800-1200元(含手工和显存颗粒),具体看店家用的颗粒品质(三星 vs 镁光)和焊接工艺。这个价格不算贵,但要算上卡本身的价值。 2. 供应商怎么找 国内主战场在闲鱼,搜索"2080ti 改22g"或"2080ti 魔改",重点看: 成交量和评价(尤其是3个月以上的老店) 是否提供改后测试视频 质保政策(一般给1-3个月) 深圳华强北那边的档口出货量最大,但在闲鱼上也能找到靠谱的。国外的话有Reddit r/nvidia的mod讨论区可以看。 3. 故障概率 老实说,魔改卡故障率比原厂高不少,大概10-15%会在半年内出问题。主要原因: 拆核心重焊显存有虚焊风险 显存控制器原本只设计驱动11G,多挂11G颗粒对PCB供电有额外负担 有些改卡为了省钱用的拆机颗粒,寿命没保证 4. 综合建议 楼上terry和566656661说得对,Turing架构不支持BF16,对于现在主流的推理框架(llama.cpp的Q4/K-quants虽然能用INT4,但BF16加速缺失会明显影响效率)。如果你这台服务器主要是做AI推理而不是玩游戏,我的建议是: 如果预算真的很紧(1000以内),卖掉2080Ti(现在二手约1500-1800),加1000多换一张RTX 3090 24G,体验是质的飞跃 如果只想花小钱小改一下玩玩,那改22G体验一下也不是不行,但要做好随时返修的心理准备 最关键问题:你这台至强服务器是当主力AI机用吗?如果是要长期跑模型的,还是建议换3090起步。
  • 0 赞同
    8 帖子
    272 浏览
    Miemie YM
    缝合怪本地 LLM 折腾记:X99 + RTX 2080 Ti + Tesla P40 这台"缝合怪"是自己以前的老硬件东平西凑来的,记录一下踩过的坑和目前的状态,供有类似想法的朋友参考。 遇到的坑和痛点 1. X99 平台 + P40 的 BIOS 启动问题 X99 是个年代久远、脾气刁钻的平台。P40 作为纯计算卡,没有视频输出,但插上之后会被主板优先识别,导致系统启动时卡在 BIOS 画面,显示器一片黑。 最终解决方案是通过降低 P40 所在 PCIe 通道的启动优先级,强制 P40 晚于 2080 Ti 完成初始化,才彻底解决这个问题。过程中试了很多方法,这条路不太直观,网上资料也零散。 2. 温度与噪音 目前是冬天,情况还算可控。但可以预见夏天会是另一番煎熬。 P40 原装被动散热,没有风扇,长时间推理温度会飙升。解决方案是拆下 Titan Xp 的涡轮风扇移植到 P40 上,引出风扇控制线接到主板风扇针脚,再通过软件 root 风扇控制逻辑,在管理面板里配置了基于温度的自动调速方案。目前运行稳定,但整机噪音在高负载下依然可观。 3. Qwen 3.6 35B A3B MoE 的稳定性问题 Qwen 3.6 35B A3B 是 MoE 架构,active 参数只有约 3.6B,输出速度快(实测约 41 tok/s decode),在缝合怪上跑起来性价比不错。 但跟同量级的 27B Dense 模型相比,它在长上下文下的 instruction following 稳定性较差,容易出现 thinking loop 和工具调用格式偏移。只要外部有足够强的约束框架(harness)控制任务边界和输出格式,用来做本地 agentic coding 还是完全可用的。没有约束的情况下,复杂任务的可靠性会明显下降。 4. 128k 上下文不够用 128k 的上下文窗口在单 session 多轮代码修改的场景下远远不够。一旦触发上下文压缩,prefill 阶段需要重新处理大量 token,100k 冷启动实测 TTFT 约 428 秒,压缩期间 decode 速度也会从正常的 41 tok/s 大幅下降。这段等待体验非常差,是目前整个方案最大的短板。 下一步打算 缝合怪作为过渡方案已经验证了本地 LLM 的可行性,但多卡异构带来的复杂度和性能瓶颈越来越明显。 目前倾向于等 Apple M5 Ultra。如果真的像传闻里的192GB 统一内存 + 约 1228 GB/s 内存带宽,可以直接跑 70B 以上的 Dense 模型而不需要多卡拼接,省去异构平台的所有麻烦。相比继续在 PC 平台上堆显卡,M5 Ultra 的性价比和可维护性更有吸引力。 当然如果近期有合适的显卡升级机会也不排除,但长期方向应该是统一内存架构。 硬件:X99 + RTX 2080 Ti 11GB + Tesla P40 24GB | 推理框架:llama.cpp build 9528 | 主力模型:Qwen 3.6 35B A3B MoE Q5
  • 小白求助:2*2080Ti 22G还是2*3080 20G

    AI硬件 rtx3080 rtx2080ti
    20
    0 赞同
    20 帖子
    689 浏览
    N
    劝你3080 20G,架构比2080新一代,有代差的,而且估计一年以后2080很多框架新版本不会再兼容2080了,显存带宽差不多翻一倍,这个很重要啊。 唯一缺点:魔改卡,散热必须做好,还有质保很重要。 有一句话:花3090一半的钱,买3090百分之80的性能说的就是它。
  • 1 赞同
    18 帖子
    1k 浏览
    roger gaoR
    用2080 Ti 22G 魔改卡部署Qwen3.8-27B ,无 MTP 26.3 tok/s vs 有 MTP 36.7 tok/s,提升 +39%(比文章的 +20% 还好,因为新版 llama.cpp 的 MTP 实现更成熟)。