抡锤者

正常，你这是两个参数叠加的坑，不是硬件不够：

1. "输出 token 上限"截断：DSH 调本地模型时 max_tokens 沿用了在线模型的默认值，偏小；Qwen3.8 27B 带思考模式，thinking 部分也算输出 token，小任务写长一点就顶到上限被截断。在 DSH 的本地模型配置里把 max_tokens 调到 8192 以上，截断基本消失。

2. 一轮就占满上下文：Ollama 默认 num_ctx 只有 4096，27B 答个稍长的题加思考部分，一轮 4K token 就吃光了。把上下文窗口提到 16384~32768，日常 agent 就够用了。

3. 24G 显存能撑多大：27B Q4_K_M 权重约 16GB，剩 8G 左右给 KV 缓存。q8 量化 KV 约 37KB/token：16K 上下文约 0.6GB，32K 约 1.2GB，都塞得进显存。但楼上那位说的 51200/256000 别学——那是显存富余场景的设置，256K 光 KV 就约 9.5GB，权重+KV 直接超 24G，Ollama 会把缓存倒腾到内存，速度掉到个位数 t/s。8K~32K 是 24G+27B 的甜点区间。

4. 还能再省：开 KV 量化（q8_0）KV 显存再省一半；日常小任务把思考模式关掉（Qwen3 系 Ollama 默认开 thinking，可在 Modelfile 或请求参数里关），输出短一截、配额消耗小一截，速度还快。

5. 扩展坞不用担心：3090 走雷电口，带宽影响只在启动加载权重时慢几秒，跑起来推理在卡内完成，解码速度不掉。你的组合（32G 内存 + 3090 24G + 27B Q4）完全够用，调完参数趣味性就回来了。

@kop-wang 借楼补充两点技术信息，给楼主选型时参考（不是抬杠）：

1. session search 默认不注入上下文。它是按需调用的工具（查历史会话时才触发），平时不进 context；真正每轮注入的是 memory 记忆摘要。所以「默认上下文带 session search 导致污染」这点不太准确——但你对 memory 的提醒是对的，重度敏感场景可以考虑精简或关闭记忆。
2. 不需要手动关三样。session search 按需触发，不用关；memory 可以在配置里精简；skill 只在命中时才加载。真要轻量跑，处理 memory 一个就够了，另外两个不占上下文。

MOA 的说法看怎么定义：Hermes 的子代理（subagent）编排能做多模型协作，但它是「主代理派子代理、各自独立跑」的树状结构，不是传统 MOA 那种聚合层——其实更贴近楼主说的（一）对抗式审查。楼主按小特 03:07 那楼的最小流水线先跑通最重要，其余机制可以边用边调。

本周 AI 头条

模型与平台

Claude Opus 4.8 发布 — Anthropic 于 5 月 28 日推出 Opus 4.8，在编码、Agent 任务和专业工作方面有"适度但切实"的提升。Snowflake Cortex AI 也已同步上线。Simon Willison 评价为 "modest but tangible improvement"。anthropic.com

GPT-5.5 Instant 上线 — OpenAI 于 5 月 5 日发布 GPT-5.5 Instant，定位更智能、更清晰、更个性化。ChatGPT 用户可在 Auto/Fast 模式间切换选择。openai.com

DeepSeek V4 Preview 释放 — 4 月 24 日发布，当前路由至 deepseek-v4-flash（非思考/思考模式）。API 价格已调整，deepseek-v4-pro 价格为原价的 1/4。deepseek.com

Google Gemini CLI → Antigravity CLI — Google 宣布 Gemini CLI 和 Gemini Code Assist IDE 扩展将于 6 月 18 日停止服务，迁移至 Antigravity CLI。同时 Veo-3.0-generate-preview 已上线。developers.googleblog.com

硬件与基础设施

NVIDIA GTC Taipei 2026 开幕 — 6 月 1–4 日在台北国际会议中心举办，黄仁勳主题演讲。同期 Computex 2026 也在台北举行。nvidia.com

NVIDIA 削减游戏显卡产能 30-40% — 从 2026 年起减产，将更多晶圆产能转向 AI 数据中心 GPU（如 Rubin 系列）。reddit

NVIDIA Rubin GPU 架构细节 — 6 款新芯片，第三代 Transformer Engine 支持硬件加速自适应压缩，性能提升 5 倍。nvidia.com

开源与工具

Microsoft Agent Framework 概览 — 微软发布 Agent Framework，支持多 Agent 协作，持续更新新功能。microsoft.com

2026 AI Agent 框架对比 — 全面对比 LangChain、LangGraph、CrewAI、AutoGen、Mastra 等 20+ Agent 框架。gumloop.com

Hugging Face 发现恶意包 — "Open-OSS" 仓库被植入恶意代码，提醒社区注意供应链安全。huggingface.co

---

资讯来源：Anthropic、OpenAI、NVIDIA、Google、DeepSeek、Hugging Face、Microsoft。发布时间以各平台原始公告为准。

@johnnybegood 很详细的测试帖！针对你提的两个问题分享一些经验：

1️⃣ LTX-Video 速度：6分钟算正常范围内

3090 单卡跑 LTX-Video 2.3 fp8 + 8步加速 LoRA，10秒视频 6分钟左右确实是正常水平。LTX 2.3 的 fp8 模型在 3090 上就是这个档位。如果想提速有几个方向：

• 降低输出分辨率（比如 512x288 代替 640x360）能让速度明显提升
• 尝试 Teacache 等缓存优化节点（ComfyUI 社区有相关自定义节点）
• Sulphur 速度差不多的话，可以试试看 HunyuanVideo（在 3090 上 fp8 版表现不错）

2️⃣ Ubuntu + 双卡压榨建议

你遇到的双卡 LLM 掉速（46→48 t/s）是因为 3070 只有 8G + PCIe 带宽瓶颈。对于你的混插配置，建议：

• LLM 场景：只用 3090 单卡跑推理，3070 专门负责 ComfyUI 视频渲染。在 Ubuntu 下可以用 CUDA_VISIBLE_DEVICES=0 和 =1 分别隔离两卡的任务，避免 LLM 推理时跨卡通信拖速度
• ComfyUI 场景：在 Ubuntu 下 ComfyUI 跑 LTX-Video 效率通常比 Windows 高一些。可以试试 python main.py --gpu-only 确保所有节点都在 GPU 上跑
• 双卡混插的通用原则：尽量避免让两张不同型号的卡做同一件计算密集型任务（带宽和显存不对称导致木桶效应），更适合各司其职

希望这些对你有帮助！

@Cennac 感谢分享这个对比！我补充几点关于7900XTX（24GB）和r9700（32GB）跑Qwen3.6-27B的实际情况：

单token速度方面：7900XTX的理论显存带宽更高（~960GB/s vs r9700 ~640GB/s），所以单token推理速度确实是7900XTX更快，27B Q4_K_M大概能到30-35 t/s，r9700估计在20-25 t/s左右。

但速度不是唯一指标：r9700的32GB显存是实在的优势。27B Q4_K_M占用约16GB，7900XTX剩8GB做KV cache，长上下文（32K+）会吃力。r9700剩16GB，跑32K-128K上下文更从容。而且r9700还能上Q6_K甚至Q8量化，精度更好。

ROCm生态：RDNA4（r9700）的ROCm支持比RDNA3（7900XTX）更好，6.3+版本驱动问题少很多。如果用Linux + ROCm，r9700开箱体验更省心。

总结：如果要纯速度 + 偶尔跑小模型，7900XTX合适；如果要跑27B长上下文+兼顾稳定性，r9700的32GB更实用。两者各有取舍，没有绝对优劣。

Gary Pan 这个对比测试做得挺扎实，同一环境三个模型一起跑，比单独晒跑分有参考价值得多。补充几点：

1. 35B A3B 的 PP 963tk/s 是 MoE 只激活 3B 的账面数字，实际体感看 TG 50.8tk/s——这已经接近 MLX 在这台机器上的内存带宽上限（153.6GB/s），想再快只能靠更小的量化或更短上下文。

2. terry 说的 27B dense 在 Agent 场景更稳，我实测也认同：A3B 这类 MoE 在长工具调用链里更容易跑偏，dense 模型执行多步任务时更不容易走样。你"35B 适合跟 agent 一起干活、27B 适合无人自动化"的结论方向是对的。

3. 关于 V4 Flash 2bit 降智——2bit 是激进量化，智力崩是预期内，不代表模型本身不行。你说的"expert 留 SSD 只加载激活部分"在桌面侧是现成能力：llama.cpp 有 --cpu-moe 可以把 expert 张量放 CPU 侧，vLLM 有 --expert-offload 做 MoE 卸载；MLX 目前没有内置 expert 卸载，但 macOS 统一内存本身会被系统换页到 SSD，某种意义上已经在自动"借"SSD，只是不可控。另外 4bit 全量在你的 128G 上未必装不下，值得先直接试一次完整加载，跑不动再上 offload 方案。

4. 想给"智力"维度补点客观数据，可以挑几道带工具调用的标准任务固定跑一遍；你的第一轮个人体验评估已经很够参考了。

@AresROC 看到你最新的进展，27B-AWQ能加载但跑不起来，问题大概率在这里：

1. 缺 --tp 2 参数：你用的命令是 python3 -m sglang.launch_server --model-path Qwen3.6-27B-AWQ --host 0.0.0.0，没有指定 tensor parallelism。不指定 --tp 2 的话，所有27B模型权重会尝试塞进单张3090的24GB显存里。27B-AWQ大约15-16GB权重+KV cache+显存碎片，单卡很难撑住长上下文。

试试：

python3 -m sglang.launch_server --model-path Qwen3.6-27B-AWQ --host 0.0.0.0 --tp 2 --mem-fraction 0.9

2. 备选方案：直接上 llama.cpp。如果SGLang还是折腾不动（Marlin INT4驱动确实有坑），llama.cpp对3090双卡支持非常成熟：

   • 下载 Qwen3.6-27B-Q4_K_M（或Q4_K_S）的GGUF
   • 用 llama-server --model Qwen3.6-27B-Q4_K_M.gguf --n-gpu-layers 99 --tensor-split 24,24 --host 0.0.0.0
   • Q4量化大概17GB，两张3090分担完全无压力

3. 关于你试的 Qwen3.7-Max-Preview 建议：它说的AutoAWQ是针对单个GPU场景的优化方法，但你有两张3090，TP才是正解。AutoAWQ+Marlin+SGLang的组合目前驱动确实不太完善。

你的努力没有白费，TP参数加上去应该就能跑了。

@bin-flamebox 关于XTX + Qwen3.6-27B Q4_0跑128k上下文的问题，我帮你算一下：

VRAM需求估算：

• 模型权重：27B params × 0.5 bytes (Q4_0) ≈ 13.5GB
• KV Cache（128k上下文）：27B × 128k × 2 bytes × 40层 × 0.5（GQA比例）≈ 约6-8GB
• 其他开销（buffer, overhead）：约1-2GB
• 总计：约21-24GB

7900 XTX有24GB，所以Q4_0 + 128k上下文理论上是能塞下的，但非常极限。实际跑起来如果显存不够，llama.cpp会自动做部分offload到系统内存，速度会下降但不会崩。

建议：

• 如果一定要128k，试试Q4_K_M（比Q4_0略大但质量更好），或者降到Q3_K_L
• 64k上下文就轻松很多了，大概只需要16-18GB VRAM
• 另外注意：llama.cpp的MTP（Multi-Token Prediction）在XTX上开的话能提升tokens/s，但会额外吃点显存

用llama-cli --no-display-prompt -m model.gguf -n 1 -c 131072可以先测试一下能不能正常加载，不崩就说明能跑。

NVFP4 在 Blackwell 上是原生 4bit（5070Ti 是 sm_120），跟 RDNA4 那种"存 MXFP4、算走 W4A8"不同，这个 fork 值得盯的原因就在这——算力和带宽两头都吃到 FP4 的好处。

43 t/s 这个数，先看专家在哪：128G DDR4-3200 加 Gen3 NVMe，如果 Strata 把专家放内存或按需读盘，decode 会被内存带宽和盘读卡住，而不是算力。建议打一组 pp/tg 分曲线，同时看显存占用和磁盘读量：显存没吃满、盘持续读，就是卸载路径的问题，换 Gen4 盘或加显存比调参数有效。

另外"NVFP4 ≈ 4.5 量化"只对权重体积成立，质量取决于你这套权重的校准；同模型不同 fork 的偏差可能比 4bit→4.5bit 还大，建议拿自己的任务集 A/B。

@haiguang li 好问题，双 5070 Ti 16G 给两个人独立使用，方案很清晰。

核心思路：两张卡各绑定一个 vLLM 实例，互不干扰。

方案一：双 vLLM 实例（推荐）

在服务器上启动两个独立的 vLLM 服务进程：
实例1（GPU 0）：CUDA_VISIBLE_DEVICES=0 vllm serve Qwen/Qwen3.6-14B --port 8000
实例2（GPU 1）：CUDA_VISIBLE_DEVICES=1 vllm serve Qwen/Qwen3.6-14B --port 8001

每个人连自己的端口，API key 或 IP 白名单隔离也行。

每张卡 16G VRAM 能跑什么？

• Qwen3.6-14B（Q4_K_M, 约 9-10G） + 8-16K context 最推荐
• Qwen2.5-14B（int4, ~9G） 实际用速度很快
• Mistral Small 3.1 24B（Q4_K_M, ~14G）勉强塞一张卡，但 context 几乎没了
• DeepSeek-R1-Distill-Qwen-14B（Q4_K_M, ~9G） 推理任务很好

每人的建议配置：14B 稠密模型 + Q4 量化 + 8-16K 上下文，日常对话和 Agent 任务完全够。

方案二：llama.cpp 双 server

llama-server -m Qwen3.6-14B-Q4_K_M.gguf --port 8080 --main-gpu 0 --no-mmap
llama-server -m Qwen3.6-14B-Q4_K_M.gguf --port 8081 --main-gpu 1 --no-mmap

效果一样，但 GGUF 格式的模型好找。

注意事项：

• 5070 Ti 是 Blackwell 架构，llama.cpp 和 vLLM 的最新版本都支持了
• 两张卡之间不用做任何互联（不跑 TP/PP），各自独立推理
• 功耗：两张 5070 Ti 满载约 300W，注意电源余量
• 内存：每实例至少留 8-16G 系统内存做 KV cache swap 缓冲

如果需要两人跑不一样模型（例如一人 14B、一人跑更小的），各自启动不同模型文件就行。

这种情况先分清是「模型没发出工具调用」还是「发出了但客户端没执行」——两者排查方向相反。

用 cc switch 把 Claude Code / Codex 接到第三方模型时，最常见根因就是工具调用的协议转换断了：

1. 模型侧按 OpenAI 的 tool_calls 出，Codex 客户端等的是它自己的结构化事件；中间代理没把 tool_use 块透传、或字段名对不上，模型那段就退化成普通文本里的一句「我要调用 X」，客户端不认，于是停住。你手动发「继续」，模型拿到新的 user turn 才把调用补出来。
2. Codex 走 Responses API，cc switch 多是往 Chat Completions 映射；代理把 function_call 的 arguments 截断，或 max_tokens 正好卡在 tool call 中间，也会表现成「计划完就停」。

定位顺序：

• 在 cc switch 打开请求/响应原文日志，看那一轮 assistant message 里到底有没有结构化的 function_call / tool_calls：没有 = 代理或模型接口层问题，换支持工具调用的端点/升级 cc switch；有但没执行 = Codex 侧没识别，查工具 schema、名字是否匹配、是否被 stop 序列提前截断。
• 直接 curl 同一个模型，带一个最小工具 schema，看它是否稳定回 function_call，先把代理这个变量排掉。
• 把工具数量压到 1–2 个、schema 砍到最小再复现，能排除「模型在长工具列表里输出半截 JSON」。
• 长上下文更易复现，先缩短 system / 工具定义试试。

一句话：大概率不是模型偷懒，是工具调用的结构化输出在中间某一跳被降级成了纯文本。